Cómo OpenAI creó 1 millón de líneas de código solo con agentes: 5 principios de Harness Engineering

Últimamente, la palabra «harness» aparece cada vez con más frecuencia. Un artículo de blog publicado por OpenAI ha dado por fin una definición clara a este concepto. Esto es lo que los ingenieros realmente deben hacer en la era de los agentes.

Un harness es la carcasa de herramientas que permite a un agente de IA actuar sobre el mundo real. Si el modelo de razonamiento es el cerebro, el harness son las manos y los pies. Leer archivos, corregir código, ejecutar pruebas, desplegar en producción: todo ocurre dentro del harness.

Un equipo interno de OpenAI partió de un repositorio vacío a finales de agosto de 2025 y construyó un producto de un millón de líneas utilizando únicamente agentes Codex. La condición: ningún código escrito por humanos. El tiempo necesario fue una décima parte del desarrollo manual. Los cinco principios descubiertos durante este proceso se detallan a continuación.

El conocimiento que el agente no puede ver no existe

Desde la perspectiva de Codex, la información a la que no puede acceder en tiempo de ejecución es como si no existiese. Los documentos de planificación en Google Docs, las decisiones de arquitectura acordadas en Slack, el conocimiento tácito guardado en la cabeza de alguien: nada de eso es visible. Es la misma situación que afrontaría un nuevo empleado que se incorporase tres meses después.

Por eso el equipo trasladó cada decisión al repositorio en forma de markdown, esquemas y planes de ejecución (ExecPlans).

• ExecPlan es un documento de diseño autocontenido definido en PLANS.md
• El criterio de aceptación: un principiante debe poder leerlo e implementar la funcionalidad de extremo a extremo
• Existen casos en los que Codex trabajó de forma continua durante más de 7 horas con un solo prompt
• La estructura amplía el concepto ARCHITECTURE.md de matklad para su uso con agentes

Pregunta «qué capacidad falta» en vez de «esfuérzate más»

Al principio, la velocidad del agente era inferior a lo esperado. La causa no era el rendimiento del modelo, sino un entorno insuficientemente preparado. Cada vez que algo fallaba, el equipo se preguntaba: «¿Qué capacidad falta y cómo hacemos que el agente pueda leerla y verificarla?»

• Helpers de concurrencia desarrollados internamente en lugar de bibliotecas externas, con integración al 100 % con OpenTelemetry
• La llamada «tecnología aburrida» resulta favorable para los agentes (por la estabilidad de las API y su alta representación en los datos de entrenamiento)

La aplicación mecánica, no la documentación, mantiene la coherencia del código

Solo con documentación no fue posible mantener la coherencia de la base de código generada por agentes. Así que el equipo optó por aplicar mecánicamente reglas invariantes en lugar de prescribir los detalles de implementación. Exigieron el parsing en las fronteras de datos, pero dejaron la elección de la biblioteca al agente. La arquitectura se fijó en una estructura de dominios por capas y la dirección de las dependencias se verifica con linters.

• Capas fijas por dominio de negocio: Providers → Service → Runtime → UI
• Estructura de preocupaciones transversales donde Types, Config y Repo se comparten en los niveles inferiores
• Linters personalizados y pruebas estructurales que rompen el build inmediatamente ante cualquier violación
• Los propios linters también fueron escritos por Codex

Dale ojos al agente y trabaja solo durante 6 horas

El equipo conectó el Chrome DevTools Protocol al runtime del agente, dando a Codex acceso a snapshots del DOM, capturas de pantalla y navegación. La estructura compara snapshots antes y después de la tarea, observa eventos en tiempo de ejecución y aplica correcciones en bucle hasta que todo queda limpio.

Las herramientas de observabilidad se integraron del mismo modo. Por cada git worktree se levanta una pila de observabilidad temporal que desaparece al terminar el trabajo.

• Victoria Logs (LogQL) y Victoria Metrics (PromQL) permiten al agente consultar logs y métricas directamente
• Prompts como «haz que el servicio arranque en menos de 800 ms» se vuelven ejecutables
• Se observan regularmente ejecuciones únicas de Codex que mantienen el foco en una sola tarea durante más de 6 horas

Da un mapa, no un manual de 1000 páginas

La gestión del contexto determina la eficacia del agente. Al principio el equipo intentó meter todo en un único archivo AGENTS.md gigante, y fracasó. El concepto de ARCHITECTURE.md escrito por matklad en 2021 demostró su valor aquí. El principio: ofrecer una vista panorámica breve de la estructura del proyecto, incluyendo solo lo que rara vez cambia. El mismo principio se aplica a los agentes.

• ARCHITECTURE.md es un mapa del código, no un atlas del código
• Los invariantes arquitectónicos suelen expresarse como «algo no existe»
• Declarar fronteras de forma explícita restringe toda la implementación posterior

Preguntas aún abiertas

Incluso para el equipo de Codex quedan preguntas sin responder. Nadie sabe si un sistema construido enteramente por agentes puede mantener la coherencia arquitectónica durante años. Cómo evolucionará este marco a medida que los modelos mejoren también es una incógnita.

Una cosa está clara: la era de escribir buen código está terminando, y la era de diseñar buenos entornos ha comenzado.