Gestor de ensayos de campo
El sistema donde una compañía fitosanitaria registra, valida, analiza y publica sus ensayos de campo: estadística dentro del flujo, analítica del contenido para decidir, y una API pensada para que un agente de IA consulte los ensayos y ayude a cargarlos con una persona al mando.
Partí de un sistema de ensayos anterior cuyo modelo ya no admitía evolucionar: lo reconcebí y lo reconstruí casi por completo, pieza a pieza y sin sacarlo de producción. Desde finales de 2025 vive separado de su visor de consulta, para que cada uno evolucione por su lado, y su dato alimenta también la app móvil de casos de campo. En evolución hasta el final de mi etapa, en julio de 2026.
- Un sistema heredado reconstruido casi por completo, modelo de datos incluido, sin sacarlo de producción.
- Estadística aplicada dentro del producto: ANOVA de un factor y Tukey, con transformaciones configurables y pruebas de homogeneidad.
- Una fuente única del dato experimental, con varios consumidores y la publicación decidida en un solo sitio.
- IA sobre el dato propio: extracción estructurada de informes, preguntas a un ensayo y una API con skills para que un agente consulte, compare y cargue ensayos con una persona al mando.
- Analítica del contenido y de su uso para decidir, no solo para mirar.
El dato de ensayo vivía disperso en informes PDF, hojas de cálculo y cabezas. No había fuente única ni comparabilidad entre campañas, y el análisis se rehacía a mano cada vez. Cuando alguien preguntaba qué se sabe de un producto en un cultivo, la respuesta tardaba días y dependía de a quién se preguntara.
Una sola fuente de verdad del dato de ensayo, con la captura y la validación separadas de la consulta, y abierta por API a quien la necesite —personas, otras aplicaciones o un agente— sin copiar el dato.
Django con módulos por función —búsqueda, edición, gestión y validación, análisis estadístico, flujo de tareas, rejillas de revisión, métricas— sobre un modelo del ensayo en aplicaciones que solo contienen modelos. La misma base de datos la leen el visor de consulta y la app móvil; lo que cada uno puede ver se decide aquí. Y una API versionada para agentes, separada de la interfaz.
- ANOVA de un factor y Tukey dentro del flujo, con transformación configurable por criterio, retrotransformación y pruebas de homogeneidad de varianzas.
- Una API para agentes de IA como alternativa a un servidor MCP: el esquema de filtros es el contrato, los nombres se resuelven con umbrales de confianza y la escritura identifica al editor declarado y comprueba el estado del ensayo.
- Analítica del contenido para decidir: eficacia por criterio y cruces de producto, cultivo y país, además de qué ensayos y productos se consultan.
Las evidencias23
- Estadística aplicadaCódigo · Confidencial
ANOVA de un factor y prueba de Tukey sobre los datos por réplica, con transformación configurable por criterio —arcoseno-raíz, raíz, logaritmo o sin transformación—, retrotransformación, letras de significación y pruebas de Bartlett y Levene. El cálculo parte de un diseño completamente aleatorizado, sin bloques ni covariables. Eficacia por Abbott frente al testigo.
- Modelado de dominioCódigo · Confidencial
- Function callingCódigo · Confidencial
- Extracción de datos con LLMCódigo · Confidencial
- Seguridad de agentes LLM (prompt injection)Código · Confidencial
- LLM en producciónCódigo · Confidencial
- Visualización de datosCódigo · Confidencial
- Gobierno del dato (data governance)Código · Confidencial
- Refactorización del modelo de datosHistorial de commits · Confidencial
- Métricas de producto y adopciónCódigo · Confidencial
- Tests de regresión y equivalenciaCódigo · Confidencial
- Revisión de código generado por IADocumento · Confidencial
- Tooling propio para agentes de IADocumento · Confidencial
- Diseño de APIs RESTCódigo · Confidencial
- Mantenimiento de código legacyHistorial de commits · Confidencial
- Control de acceso y autorizaciónCódigo · Confidencial
- Integración de APIs de tercerosCódigo · Confidencial
- Diseño de UX para usuarios no técnicosCódigo · Confidencial
- Análisis de requisitos de negocioCódigo · Confidencial
- Dominio agronómico y regulatorioCódigo · Confidencial
- Comunicación escritaDocumento · Confidencial
- Desarrollo web full stackCódigo · Confidencial
- Prompt engineeringCódigo · Confidencial
Principios que se ven aquí14
- PrincipioCuando migro o refactorizo, verifico la equivalencia con código, no con confianza
- Una optimización de consultas en el cálculo de eficacia, comparada con el cálculo anterior sobre todos los criterios antes de darla por buena: cero diferencias
- PrincipioEl modelo de datos primero, la herramienta después
- Lo primero que se rehízo del sistema heredado fue el modelo de datos, en marcha y sin parar el servicio; la aplicación se reconstruyó después, encima
- PrincipioCuando el uso contradice el modelo, se rehace el modelo — y se escribe por qué
- La API para agentes empezó sin sobrescribir valores y se cambió al chocar con el flujo real; el motivo quedó escrito en el propio código
- PrincipioRigor donde importa, deuda consciente donde no — y saber decir en cuál está cada cosa
- Estadística integrada con transformaciones configurables, pruebas de homogeneidad y comparaciones de Tukey, con los supuestos del diseño escritos y deuda declarada en otras capas
- PrincipioEn producción, lo mínimo que resuelve el problema
- Resolución de nombres con erratas con la librería estándar, sin dependencias ni extensiones de base de datos, y escrito en el código cuál es el reemplazo si un día hace falta más velocidad
- PrincipioConstruyo sistemas, no piezas: diseño la siguiente fase y construyo solo la actual
- La API para agentes se diseñó para consumirse hoy con skills y mañana con un servidor MCP, sin construir el servidor antes de hacer falta
- PrincipioLos agentes, más para contrastar que para producir; y lo que dicen se verifica
- Revisión de código en tres fases —encontrar, intentar refutar cada hallazgo, sintetizar—: solo cuenta lo que sobrevive a la refutación
- PrincipioLo difuso se resuelve en el borde; el núcleo es determinista
- La API para agentes primero convierte los nombres con erratas en identificadores y solo después consulta o escribe: el gestor es fuente de datos, no sistema de inferencia
- PrincipioPrefiero un fallo visible a un éxito aparente
- Si un nombre con erratas no alcanza el umbral de confianza, la API devuelve las alternativas en lugar de elegir una por su cuenta
- PrincipioEl dato dice cuánto sabe: vacío, provisional o validado
- Un ensayo pasa por la validación del editor y la del responsable, y a la app comercial solo llega cuando está finalizado
- PrincipioCambio por debajo sin que lo note quien consume
- Una optimización de consultas fue aditiva: mismo resultado, y la consulta original como respaldo
- PrincipioLo irreversible lo ejecuta una persona
- La skill de carga pide confirmación humana antes de escribir y una prueba previa de los datos por réplica; la API identifica al editor declarado y deja la creación de catálogos fuera de sus operaciones
- PrincipioLo que parece un error se demuestra antes de corregirlo
- Escrito en el contexto del proyecto: hay redundancias aparentes que son semánticas, y no se normaliza por normalizar
- PrincipioLa interfaz sigue cómo trabaja quien la usa; el modelo, cómo es el negocio
- Los datos de cada réplica se capturan en una plantilla de hoja de cálculo de ida y vuelta, la herramienta con la que ya trabajaban los técnicos