# Cómo OpenAI creó 1 millón de líneas de código solo con agentes: 5 principios de Harness Engineering > Author: Tony Lee > Published: 2026-02-12 > URL: https://tonylee.im/es-LA/blog/openai-harness-engineering-five-principles-codex/ > Reading time: 5 minutes > Language: es-LA > Tags: ai, ai-agents, openai, codex, harness-engineering, software-engineering ## Canonical https://tonylee.im/es-LA/blog/openai-harness-engineering-five-principles-codex/ ## Rollout Alternates en: https://tonylee.im/en/blog/openai-harness-engineering-five-principles-codex/ ko: https://tonylee.im/ko/blog/openai-harness-engineering-five-principles-codex/ ja: https://tonylee.im/ja/blog/openai-harness-engineering-five-principles-codex/ zh-CN: https://tonylee.im/zh-CN/blog/openai-harness-engineering-five-principles-codex/ zh-TW: https://tonylee.im/zh-TW/blog/openai-harness-engineering-five-principles-codex/ ## Description El equipo Codex de OpenAI construyó un código base de un millón de líneas usando solo agentes de IA. Estos son los cinco principios de harness engineering que descubrieron. ## Summary Cómo OpenAI creó 1 millón de líneas de código solo con agentes: 5 principios de Harness Engineering is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - El conocimiento que el agente no puede ver no existe - Pregunta "qué capacidad falta" en lugar de "échale más ganas" - La aplicación mecánica, no la documentación, mantiene la consistencia del código - Dale ojos al agente y trabaja solo durante 6 horas - Da un mapa, no un manual de 1,000 páginas - Preguntas todavía abiertas ## Content Ú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ó. ## Related URLs - Author: https://tonylee.im/en/author/ - Publication: https://tonylee.im/en/blog/about/ - Related article: https://tonylee.im/es-LA/blog/eight-hooks-that-guarantee-ai-agent-reliability/ - Related article: https://tonylee.im/es-LA/blog/medvi-two-person-430m-ai-compressed-funnel/ - Related article: https://tonylee.im/es-LA/blog/claude-code-layers-over-tools-2026/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/es-LA/blog/openai-harness-engineering-five-principles-codex/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/es-LA/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.