En marzo de 2026, el equipo de Codex de OpenAI publicó un post documentando un experimento radical: construyeron una aplicación de producción con más de 1 millón de líneas de código donde cero líneas fueron escritas por manos humanas. El producto tiene usuarios internos diarios y testers alpha externos. Ship, deploy, se rompe y se arregla — todo por agentes.
Los ingenieros no escribieron código. Diseñaron el sistema que permitió que la IA escribiera código de forma confiable.
Ese sistema — las restricciones, loops de retroalimentación, documentación, linters y gestión del ciclo de vida — es lo que la industria ahora llama un harness (arnés). Y la disciplina de diseñar estos sistemas es harness engineering.
¿Qué Es Harness Engineering?
El término “harness” viene del equipo de un caballo — riendas, silla, bocado — el conjunto completo para canalizar a un animal poderoso pero impredecible en la dirección correcta. La metáfora es deliberada: el modelo de IA es el caballo (poderoso, rápido, pero sin dirección), el harness es la infraestructura a su alrededor, y el ingeniero es el jinete dando dirección.
Formalmente, harness engineering es el diseño e implementación de sistemas que:
- Restringen lo que un agente de IA puede hacer (límites arquitectónicos, reglas de dependencias)
- Informan al agente sobre lo que debe hacer (ingeniería de contexto, documentación)
- Verifican que el agente lo hizo correctamente (tests, linting, validación en CI)
- Corrigen al agente cuando se equivoca (loops de retroalimentación, mecanismos de auto-reparación)
Por Qué Harness Engineering Importa Ahora
Aquí está la verdad incómoda que la industria de IA está enfrentando: el modelo subyacente importa menos que el sistema a su alrededor.
LangChain lo demostró definitivamente. Su agente de codificación pasó de 52.8% a 66.5% en Terminal Bench 2.0 — saltando del Top 30 al Top 5 — sin cambiar nada del modelo. Solo cambiaron el harness:
- Loop de auto-verificación: Middleware de checklist pre-completado — atrapó errores antes de enviar
- Ingeniería de contexto: Mapeo de estructura de directorios al inicio — el agente entendió el codebase desde el principio
- Detección de loops: Rastreo de ediciones repetidas — previno “doom loops”
- Sándwich de razonamiento: Razonamiento alto para planificar/verificar, medio para implementar — mejor calidad dentro de presupuestos de tiempo
Mismo modelo. Harness diferente. Resultados dramáticamente mejores.
La Prueba del Millón de Líneas de OpenAI
Ryan Lopopolo, Miembro del Staff Técnico de OpenAI, documentó el experimento en detalle. El equipo comenzó con un repositorio vacío en agosto de 2025. Cinco meses después, habían lanzado un producto donde cada línea de código — lógica de aplicación, tests, configuración de CI, documentación, observabilidad y herramientas internas — había sido escrita por Codex.
Estiman que lo construyeron en aproximadamente 1/10 del tiempo que habría tomado escribir el código a mano. Humanos dirigían. Agentes ejecutaban.
La idea clave: cuando el trabajo principal de un equipo de ingeniería ya no es escribir código, el recurso escaso se convierte en tiempo y atención humana. Cada decisión sobre qué poner en el harness tiene que medirse contra esa restricción.
Los Tres Pilares del Harness Engineering
1. Ingeniería de Contexto
Asegurar que el agente tenga la información correcta en el momento correcto.
Contexto estático: Documentación local del repositorio (specs de arquitectura, contratos de API, guías de estilo), archivos AGENTS.md o CLAUDE.md con reglas específicas del proyecto, y documentos de diseño con referencias cruzadas validados por linters.
Contexto dinámico: Datos de observabilidad (logs, métricas, trazas) accesibles para agentes, mapeo de estructura de directorios al inicio, y estado del pipeline CI/CD.
La regla crítica: desde la perspectiva del agente, cualquier cosa que no pueda acceder en contexto no existe. El repositorio debe ser la única fuente de verdad.
2. Restricciones Arquitectónicas
En lugar de decirle al agente “escribe buen código,” aplicas mecánicamente cómo se ve el buen código:
- Capas de dependencias: Tipos → Config → Repo → Servicio → Runtime → UI. Cada capa solo puede importar de capas a su izquierda, enforced por tests estructurales y CI.
- Linters determinísticos: Reglas personalizadas que detectan violaciones automáticamente
- Auditores basados en LLM: Agentes que revisan el código de otros agentes para cumplimiento arquitectónico
- Tests estructurales: Como ArchUnit, pero para código generado por IA
Paradójicamente, restringir el espacio de soluciones hace a los agentes más productivos. Cuando un agente puede generar cualquier cosa, gasta tokens explorando callejones sin salida.
3. Gestión de Entropía
El componente más subestimado. Los codebases generados por IA acumulan entropía — la documentación se desvía de la realidad, las convenciones de nombres divergen, el código muerto se acumula. El harness engineering aborda esto con agentes de limpieza periódicos que verifican documentación, escanean violaciones de restricciones, aplican patrones y auditan dependencias — manteniendo el codebase saludable tanto para revisores humanos como para futuros agentes de IA.
Cómo lo Hacen los Equipos en la Práctica
OpenAI: Cero Código Humano
La ingeniería tradicional se trata de escribir código. En un modelo de harness engineering, ese nunca es el trabajo principal. El rol del ingeniero cambia a diseñar arquitectura, escribir documentación como infraestructura crítica, revisar output de agentes y efectividad del harness, analizar patrones de comportamiento de agentes, y diseñar estrategias de test que los agentes ejecutan.
Stripe: Minions a Escala
Los agentes internos de Stripe, llamados Minions, producen más de 1,000 pull requests fusionados por semana. El flujo: el desarrollador publica una tarea en Slack → Minion escribe el código → Minion pasa CI → Minion abre un PR → humano revisa y mergea. Sin interacción del desarrollador entre el paso 1 y el paso 5.
LangChain: Middleware First
LangChain estructura su harness como capas de middleware componibles: LocalContextMiddleware → LoopDetectionMiddleware → ReasoningSandwichMiddleware → PreCompletionChecklistMiddleware. Cada capa añade una capacidad específica sin modificar la lógica central del agente.
Construyendo Tu Primer Harness
- Nivel 1 (Desarrollador individual): Un archivo
CLAUDE.mdcon convenciones del proyecto, pre-commit hooks para linting, un suite de tests que el agente pueda ejecutar, y una estructura de directorios clara. Setup en 1-2 horas. - Nivel 2 (Equipo pequeño): Un
AGENTS.mdcon convenciones del equipo, restricciones arquitectónicas enforceadas por CI, plantillas de prompt compartidas, documentación como código validada por linters, y checklists de code review para PRs generados por agentes. Setup en 1-2 días. - Nivel 3 (Organización de ingeniería): Capas de middleware personalizadas, integración de observabilidad, agentes de gestión de entropía, versionado de harness y A/B testing, y monitoreo de rendimiento de agentes. Setup en 1-2 semanas.
Errores Comunes
-
Sobre-ingeniería del flujo de control: Los modelos mejoran rápido. Construye tu harness para que sea removible — deberías poder eliminar lógica “inteligente” cuando el modelo se vuelva lo suficientemente inteligente.
-
Tratar el harness como estático: Revisa y actualiza los componentes del harness con cada actualización importante del modelo.
-
Ignorar la capa de documentación: La mejora más impactante suele ser mejor documentación. Si tu
AGENTS.mdes vago, el output del agente será vago. -
Sin loop de retroalimentación: El agente necesita saber cuándo está teniendo éxito y cuándo está fallando. Incorpora auto-verificación, ejecución de tests y métricas de éxito.
-
Documentación solo para humanos: Todo lo que el agente necesita debe estar en el repositorio — no en hilos de Slack, páginas de Confluence o cabezas de personas.
Qué Significa Esto
El harness engineering representa una evolución genuina en lo que hacen los ingenieros de software. El trabajo pasa de escribir código a diseñar entornos donde la IA escribe código. Esto no significa que los ingenieros se vuelvan menos técnicos — si acaso, requiere un pensamiento arquitectónico más profundo. Estás diseñando sistemas que deben funcionar sin tu intervención constante.
El modelo es commoditie. El harness es el moat.
Fuentes: NxCode — Harness Engineering: The Complete Guide y OpenAI — Harness Engineering: Leveraging Codex in an Agent-First World