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 más seguido. Un artículo de blog publicado por OpenAI le dio por fin una definición clara a este concepto. Esto es lo que los ingenieros realmente tienen que hacer en la era de los agentes.

Un harness es la carcasa de herramientas que le 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, correr pruebas, hacer deploy a producción, todo pasa dentro del harness.

Un equipo interno de OpenAI arrancó desde un repositorio vacío a finales de agosto de 2025 y construyó un producto de un millón de líneas usando únicamente agentes Codex. La condición: nada de código escrito por humanos. El tiempo requerido fue una décima parte del desarrollo manual. Los cinco principios que descubrieron 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 existiera. Los documentos de planeació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 enfrentaría alguien nuevo que entre al equipo tres meses después.

Por eso el equipo movió cada decisión al repositorio en forma de markdown, schemas 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 punta a punta
• Hay casos donde Codex trabajó de forma continua por más de 7 horas con un solo prompt
• La estructura extiende el concepto ARCHITECTURE.md de matklad para uso con agentes

Pregunta “qué capacidad falta” en lugar de “échale más ganas”

Al inicio, la velocidad del agente era menor a lo esperado. La causa no era el rendimiento del modelo sino un entorno que no estaba lo suficientemente 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 librerías externas, con integración al 100% con OpenTelemetry
• La famosa “tecnología aburrida” resulta favorable para los agentes (por la estabilidad de las APIs y su alta representación en los datos de entrenamiento)

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

Solo con documentación no se pudo mantener la consistencia del código generado por agentes. Entonces el equipo optó por aplicar mecánicamente reglas invariantes en lugar de prescribir los detalles de implementación. Exigieron parseo en las fronteras de datos, pero dejaron la elección de la librería 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 de inmediato 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, dándole 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 loop hasta que todo quede limpio.

Las herramientas de observabilidad se integraron de la misma forma. Por cada git worktree se levanta un stack de observabilidad temporal que desaparece al terminar el trabajo.

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

Da un mapa, no un manual de 1,000 páginas

La gestión del contexto determina la efectividad del agente. Al principio el equipo intentó meter todo en un solo archivo AGENTS.md gigante, y fracasó. El concepto de ARCHITECTURE.md escrito por matklad en 2021 demostró su valor aquí. El principio: dar una vista panorámica breve de la estructura del proyecto, incluyendo solo lo que rara vez cambia. El mismo principio aplica para 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 que viene después

Preguntas todavía abiertas

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

Una cosa queda clara: la era de escribir buen código se está acabando, y la era de diseñar buenos entornos ya empezó.