PulseFlow Tecnologia
← Insights
·6 min de lectura·actualizacion-de-producto·openai·harness-engineering·codex
PulseFlow Tecnologia

OpenAI Harness Engineering: qué cambia para los equipos de ingeniería

OpenAI documentó un experimento interno que funciona como caso de estudio y argumento de producto al mismo tiempo: un repositorio que nació vacío en agosto de 2025, con el scaffold inicial generado por Codex CLI (GPT-5), alcanzó cerca de un millón de líneas de código en cinco meses, con más de 1.500 pull requests fusionados - producidos por solo tres ingenieros conduciendo agentes, sin ninguna línea escrita manualmente por un humano. El nombre que OpenAI le da a la disciplina detrás de esto es harness engineering.

Qué cambia: de escribir código a diseñar el entorno

El cambio central que describe OpenAI es de rol, no de herramienta: cuando el trabajo principal de un equipo de ingeniería deja de ser escribir código y pasa a ser diseñar entornos, especificar intención, y construir bucles de retroalimentación que permitan a los agentes Codex hacer trabajo confiable. El propio AGENTS.md inicial del repositorio del experimento fue escrito por un agente - no por un humano estableciendo reglas desde afuera hacia adentro.

Codex como motor: aislamiento y pruebas iterativas

Codex, el motor detrás de este experimento, corre sobre codex-1 (una versión de o3 optimizada para ingeniería de software), dentro de un contenedor aislado en la nube, sin acceso a internet durante la ejecución - solo ve el código del repositorio y las dependencias preinstaladas vía un script de configuración. El agente lee y edita archivos, ejecuta pruebas, linters y verificadores de tipos, e itera hasta que las pruebas pasan. Dentro de la propia OpenAI, el uso más común es justamente tareas bien delimitadas y repetitivas - refactorización, renombrado, escritura de pruebas - no generación abierta de funcionalidades completas sin supervisión.

Legibilidad: el requisito que nadie documentaba antes

El aprendizaje central del experimento es lo que OpenAI llama "legibilidad": el repositorio necesita estar optimizado para que un agente pueda entender todo el dominio de negocio a partir del propio código y la documentación - sin depender de contexto tácito. Cuando las decisiones de arquitectura vivían solo en conversaciones de Slack, eran tan invisibles para el agente como lo serían para un empleado nuevo el primer día. La solución fue traer ese contexto al propio repositorio, al lugar donde el agente realmente busca - no como documentación aparte, sino como parte del propio código.

Qué significa esto para el liderazgo de ingeniería

El mensaje práctico para los equipos de ingeniería no es "adopten Codex" - es que la estructura del propio repositorio se convierte en un factor decisivo de la productividad del agente, de la misma forma en que hoy se trata la cobertura de pruebas o la deuda técnica. Los equipos que ya documentan arquitectura, convenciones y decisiones dentro del repositorio (no en herramientas externas de conocimiento) tienen una ventaja inmediata al introducir coding agents. Los equipos que dependen de contexto tácito - conversaciones, reuniones, conocimiento no escrito - sentirán ese vacío en el primer intento serio de usar un agente a escala.

Fuentes