Harness Engineering: la nueva forma de desarrollar software con agentes de inteligencia artificial
La inteligencia artificial aplicada a la programación está evolucionando muy rápido. Hace poco, usar IA para desarrollar software significaba copiar un fragmento de código en un chat y pedir una explicación. Después llegaron los asistentes del editor capaces de completar funciones enteras. El siguiente paso son los agentes de programación: exploran un repositorio, modifican archivos, ejecutan comandos y prueban una tarea durante varios pasos.
Sin embargo, tener un modelo potente no garantiza obtener buen software. Un agente necesita saber cómo está organizado el proyecto, qué puede modificar, qué arquitectura debe respetar, cómo demostrar que funciona y qué hacer si algo falla. Ahí aparece un concepto cada vez más relevante en 2026: Harness Engineering.
¿Qué es Harness Engineering?
Harness puede traducirse como arnés, estructura de control o sistema que mantiene algo dirigido. En el desarrollo con IA, un agent harness es la infraestructura que rodea al modelo y le permite actuar como un agente de desarrollo.
El modelo aporta razonamiento y generación; el harness aporta el entorno de trabajo. Puede proporcionar contexto del proyecto, acceso controlado a archivos, comandos y documentación, reglas arquitectónicas, memoria entre pasos, permisos, tests y feedback sobre el resultado.
Por tanto, Harness Engineering es la práctica de diseñar ese entorno para que los agentes de IA desarrollen software de forma más fiable y autónoma. No se trata solo de pedir código mejor: se trata de crear un sistema donde el agente pueda encontrar información, actuar con límites y comprobar sus propias decisiones.
Del prompt engineering al context engineering y al harness engineering
La evolución puede entenderse en tres niveles.
1. Prompt Engineering
El primer objetivo era aprender a formular instrucciones útiles.
Funciona para generar una función, explicar código o resolver una duda aislada. Pero una aplicación real requiere conocer arquitectura, convenciones, dependencias, decisiones anteriores y requisitos.
2. Context Engineering
El siguiente reto consiste en decidir qué información necesita conocer el modelo en cada momento: los archivos relevantes, las APIs, la documentación, los tests y las restricciones. Ya no importa únicamente cómo se redacta el prompt, sino qué contexto recibe el agente.
3. Harness Engineering
Cuando el modelo actúa sobre un repositorio aparece una capa adicional: hay que decidir qué sabe, qué puede hacer, cómo se valida el resultado, qué ocurre si falla y qué feedback obtiene después. Ese sistema completo es el harness.
¿Por qué se habla ahora de Harness Engineering?
Herramientas como Codex, Claude Code y otros agentes pueden inspeccionar repositorios, buscar código, crear archivos, ejecutar tests y encadenar varias modificaciones. El problema deja de ser solo:
¿Puede la IA escribir este código?
Y pasa a ser:
¿Puede trabajar de manera fiable dentro de nuestro proyecto?
Cuando un desarrollador copia una sugerencia, conserva el control de casi todo el proceso. Cuando un agente modifica una aplicación directamente, necesitamos mecanismos que limiten su comportamiento y conviertan sus afirmaciones en evidencia verificable.
En febrero de 2026, OpenAI publicó una experiencia de desarrollo orientado a agentes en la que un equipo construyó un producto interno con código, pruebas, configuración de integración continua, documentación y herramientas producidos por Codex. Su aprendizaje principal fue que el trabajo humano se desplazaba hacia el diseño del entorno, las especificaciones y los ciclos de feedback que permiten al agente trabajar de forma fiable.
Un ejemplo sencillo
Supongamos una aplicación con React, NestJS, PostgreSQL, Jest, Playwright y GitHub Actions. Pedimos a un agente: «implementa la recuperación de contraseña».
Sin un harness adecuado podría interpretar mal la arquitectura, añadir dependencias innecesarias, tocar código sensible o terminar una implementación parcial afirmando que está lista. No siempre sería un problema de capacidad del modelo: puede ser que el entorno no le haya dado señales suficientemente claras.
Con un buen harness, el repositorio define arquitectura, convenciones, restricciones, tests y validaciones. El agente consulta esas reglas, implementa el cambio y ejecuta comprobaciones como:
npm run test
npm run build
Si un test falla, el resultado pasa a ser feedback para otra iteración. Si rompe una restricción arquitectónica, una comprobación automática lo detecta. La finalización deja de depender de «parece correcto» y exige evidencia.
Tests → Validación → Feedback → Nueva iteración
Las piezas de un Development Harness
No existe una arquitectura universal, pero los harness de desarrollo eficaces suelen combinar estas piezas.
Contexto y documentación
El agente debe encontrar rápido la información relevante. Archivos como AGENTS.md, README.md, docs/, especificaciones y tests sirven como mapa. La documentación ya no está dirigida únicamente a personas: también debe ser localizable y comprensible para un agente.
Herramientas y permisos
Leer y escribir archivos, buscar código, ejecutar comandos, consultar documentación o llamar APIs son capacidades que deben estar disponibles de forma controlada. El objetivo es reducir la improvisación y limitar las acciones que puedan afectar al sistema.
Restricciones arquitectónicas
Un agente no debería poder modificar cualquier parte de un proyecto sin reglas. Una arquitectura puede, por ejemplo, permitir dependencias en una dirección determinada y rechazar las inversas. Lo importante no es dictar cada línea de implementación, sino establecer invariantes que nunca se deben romper.
Verificación y feedback
La parte decisiva es sustituir afirmaciones por comprobaciones ejecutables. Tests unitarios, integración, end-to-end, análisis estático, builds y revisiones estructurales convierten el resultado de una acción en información útil para la siguiente.
También son importantes las herramientas de diagnóstico. Las DevTools de Chrome son un ejemplo de cómo la observación de la interfaz y el rendimiento puede complementar los tests automatizados.
AGENTS.md: instrucciones dentro del repositorio
Una técnica habitual es mantener un archivo AGENTS.md con un mapa inicial: arquitectura, comandos obligatorios, convenciones, restricciones de datos y rutas hacia documentación más detallada.
Toda nueva funcionalidad debe incluir tests.
Antes de terminar ejecutar:
npm run lint
npm run test
npm run build
No sustituye a los tests ni a la arquitectura. Sirve para que el agente sepa cómo navegar el proyecto. El valor está en que las reglas importantes vivan junto al código, estén versionadas y puedan comprobarse.
Los tests ganan importancia con la IA
Cuanto más código pueda producir una IA, más difícil será revisar cada línea manualmente. Por eso los tests no son un detalle final: forman parte del sistema que controla al agente.
Las pruebas unitarias, de integración y end-to-end, junto al análisis estático y las reglas de arquitectura, permiten detectar errores antes de que se conviertan en deuda técnica. Esta disciplina también beneficia a proyectos web estáticos y de frontend: entender la estructura y el proceso de build, como se explica en esta introducción a Gatsby, hace que el trabajo automatizado sea más predecible.
Harness Engineering no elimina al desarrollador
Los agentes reducen parte del código escrito manualmente, pero alguien sigue teniendo que decidir qué construir, qué requisitos son válidos, qué riesgos aceptar, qué arquitectura utilizar y cuándo existe evidencia suficiente para dar una tarea por terminada.
El trabajo puede desplazarse de escribir cada línea a diseñar sistemas capaces de producir y validar código. Sigue siendo ingeniería de software, pero a un nivel de abstracción distinto.
Harness Engineering frente a vibe coding
En el llamado vibe coding, el resultado depende de una conversación larga: «crea esto», «añade aquello», «corrige el error». Harness Engineering intenta trasladar el conocimiento que vive en esa conversación a reglas persistentes, documentación, automatizaciones, validaciones y feedback loops.
Un prompt sigue importando, pero es una pieza de un sistema mayor:
Un prompt excelente dentro de un entorno deficiente seguirá produciendo resultados poco fiables. Un buen harness busca que el proceso sea resistente incluso cuando dos ejecuciones del modelo no son idénticas.
¿Qué debería aprender un desarrollador en 2026?
Aprender Codex o Claude Code es útil, pero los principios sobreviven a una herramienta concreta. Conviene saber proporcionar contexto, escribir especificaciones verificables, estructurar repositorios legibles, automatizar pruebas, definir restricciones arquitectónicas, controlar permisos y diseñar tareas que puedan ejecutarse de forma autónoma.
El repositorio pasa a ser algo más que código, configuración y documentación: también es el entorno desde el que los agentes aprenden cómo mantener ese software.
Conclusión
Harness Engineering representa el paso de usar IA para responder preguntas sobre código a diseñar entornos donde los agentes puedan actuar sobre sistemas de software con controles y evidencia. El debate ya no es solo qué modelo genera mejor código, sino qué sistema permite que un agente produzca software fiable.
La pregunta relevante para los próximos años quizá no sea únicamente «¿qué puede programar una inteligencia artificial?», sino «¿qué entorno necesitamos construir para que pueda hacerlo de forma fiable?».
Preguntas frecuentes
¿Qué es Harness Engineering?
Es la práctica de diseñar el contexto, herramientas, restricciones y mecanismos de validación que permiten a un agente de IA trabajar de forma fiable sobre un proyecto de software.
¿Qué es un Agent Harness?
Es la infraestructura que rodea a un modelo de IA y le permite interactuar con herramientas, archivos, comandos, memoria y validaciones para completar tareas de varios pasos.
¿Qué diferencia hay entre Prompt Engineering y Harness Engineering?
Prompt Engineering se centra en la instrucción enviada al modelo. Harness Engineering incluye además contexto, permisos, herramientas, tests, arquitectura y feedback automático.
¿Qué relación tiene con Codex o Claude Code?
Son agentes capaces de trabajar directamente sobre proyectos. Harness Engineering estudia cómo preparar el proyecto y su entorno para que esos agentes trabajen de manera más fiable y autónoma.
¿Es necesario para usar IA al programar?
No para una consulta pequeña o un fragmento de código. Su importancia crece cuando un agente realiza cambios complejos o trabaja durante más tiempo sobre un repositorio.