El desarrollo de software asistido por Large Language Models (LLMs) presenta un desafío fundamental: cómo garantizar la consistencia y fiabilidad de las implementaciones generadas, especialmente con modelos de menor costo. Este problema se agrava por la tendencia de los LLMs a 'olvidar' detalles de requisitos complejos a medida que el contexto de generación crece. La tesis central es que un 'harness comportamental' —un sistema de guías y sensores que proporciona feedback ejecutable continuo— puede mitigar esta inconsistencia, transformando modelos de costo optimizado en herramientas de desarrollo fiables, e incluso más económicas que modelos de frontera sin asistencia.
Históricamente, la ingeniería de software ha dependido de pruebas unitarias, de integración y de aceptación para validar la corrección. Sin embargo, la naturaleza iterativa y generativa de los agentes de codificación requiere un mecanismo de validación más dinámico e intrusivo. Este enfoque se alinea con principios de control de sistemas, donde la realimentación temprana y precisa es crucial para mantener un proceso dentro de los parámetros deseados. La relevancia actual radica en la proliferación de LLMs con diferentes perfiles de costo/rendimiento, donde la elección del modelo no solo depende de su capacidad bruta, sino también de su integración en un flujo de trabajo que garantice resultados consistentes.
Arquitectura del Sistema
El sistema propuesto se basa en una arquitectura de doble bucle: un 'inner loop' de desarrollo asistido por el harness comportamental y un 'outer loop' de evaluación independiente. El harness comportamental integra 'guías' (especificaciones OpenAPI, AsyncAPI, ejemplos de request-response, y habilidades de desarrollo API) y 'sensores' (verificación de contratos, pruebas API, aserciones de efectos secundarios como llamadas a mocks y publicación en Kafka). Estas guías y sensores se mantienen sincronizados mediante la validación de ejemplos contra las especificaciones antes de ejecutar las pruebas.
Durante el 'inner loop', el agente de codificación invoca el harness a través de un comando de prueba. Este comando valida la configuración, ejecuta builds y unit checks, inicia mocks de dependencias (contract-driven dependency mocks) y lanza la aplicación. Los sensores reportan discrepancias en contratos, valores de respuesta e interacciones. El agente interpreta estos resultados y modifica su implementación o configuración. Herramientas como Specmatic se utilizan para la verificación de contratos y la virtualización de servicios. El 'outer loop' es una evaluación post-desarrollo, ejecutada en un entorno aislado (contenedores Docker), que aplica un conjunto fijo de 178 pruebas de aceptación funcionales contra el servicio generado, independientemente de si se usó el harness o no. Este bucle utiliza sus propios fixtures downstream y captura de mensajes, asegurando una evaluación imparcial. La separación de estos bucles garantiza que el feedback del harness no contamine la evaluación final de la calidad del código.
Flujo de Desarrollo con Harness Comportamental (Inner Loop)
- 1 Agente recibe Brief y Harness Agente recibe requisitos, especificaciones (OpenAPI, AsyncAPI), ejemplos y he...
- 2 Agente implementa Agente escribe código, mapea componentes y comportamientos.
- 3 Agente invoca 'test' comando Comando valida config, build, unit checks, inicia mocks y lanza app.
- 4 Sensores ejecutan checks Verifican contratos, respuestas HTTP, efectos secundarios (Kafka, mocks).
- 5 Feedback al Agente Reportes de mismatches (CTRF, API coverage) son devueltos al agente.
- 6 Agente diagnostica y corrige Agente interpreta resultados, modifica implementación o setup, re-ejecuta esc...
- 7 Bucle de Refinamiento Repite hasta que los escenarios pasen y se ejecute la suite completa.
Flujo de Evaluación Independiente (Outer Loop)
- 1 Aplicación Finalizada Agente completa el desarrollo de la aplicación.
- 2 Despliegue en Entorno Aislado Aplicación desplegada en contenedor Docker con workspace y Codex home limpios.
- 3 Ejecución de Evaluación Harness de evaluación ejecuta 178 pruebas funcionales (inputs, fallos, recupe...
- 4 Captura de Resultados Se registran resultados de aceptación, uso de tokens, tiempo y costo.
- 5 Colación y Análisis Resultados comparados entre condiciones con/sin harness.
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | Docker | Proporcionar entornos de ejecución aislados y consistentes para cada intento del agente, asegurando que no haya estado persistente entre ejecuciones. |
| messaging | Kafka | Servir como sistema de publicación de eventos asíncronos, requiriendo que el agente implemente la publicación de mensajes con garantías de entrega y conformidad de contrato. |
| data-processing | OpenAPI | Definir las especificaciones de las APIs HTTP (BFF y Order API) de forma legible por máquina, actuando como 'guía' para el agente y base para la generación determinista de checks. vs RAML, API Blueprint |
| data-processing | AsyncAPI | Definir las especificaciones de la API de mensajería (Kafka) de forma legible por máquina, complementando OpenAPI para interacciones asíncronas. |
| observability | Specmatic | Implementar el harness comportamental, proporcionando capacidades de contract testing y service virtualization para generar feedback ejecutable durante el desarrollo. vs Pact, WireMock, Hoverfly |
Trade-offs
Ganancias
- ▲ Fiabilidad de modelos de costo optimizado
- ▲ Costo total por resultado aceptado
Costes
- ▲▲ Uso de tokens por run
- ▲ Tiempo de ejecución por run
- ▲ Costo por run (para modelos de frontera)
Fundamentos Teóricos
El concepto de 'harness' y 'feedback loops' en el desarrollo de software tiene raíces profundas en la teoría de control y la ingeniería de sistemas. La idea de guías y sensores, como se describe en el artículo, se alinea con los principios de control de procesos, donde los 'guías' actúan como referencias o setpoints y los 'sensores' proporcionan la realimentación necesaria para ajustar el sistema. En el contexto de la inteligencia artificial, esto se relaciona con el aprendizaje por refuerzo y la ingeniería de prompts, donde la realimentación estructurada y ejecutable es fundamental para guilar el comportamiento de un agente.
La distinción entre 'controles computacionales' (deterministas) e 'inferenciales' (basados en la interpretación del modelo) resuena con la dicotomía entre sistemas formales y heurísticos. Los controles computacionales, derivados de especificaciones formales como OpenAPI y AsyncAPI, proporcionan una base determinista para la verificación, similar a la verificación formal de software. Esto se conecta con trabajos pioneros en verificación de programas y pruebas basadas en modelos, donde las propiedades deseadas del sistema se expresan en un lenguaje formal y se verifican automáticamente. La aplicación de estos principios a los LLMs para el desarrollo de software es una extensión moderna de estas ideas fundamentales, adaptándolas a la naturaleza generativa y a veces impredecible de los modelos de lenguaje.