Harness engineering: el arnés que frena la IA

Qué es harness engineering y por qué importa a tu equipo técnico

Harness engineering es la práctica de envolver la generación de código con IA dentro de un arnés de herramientas deterministas, revisión basada en agentes y controles periódicos de entropía. La idea la formuló Birgitta Böeckeler, Distinguished Engineer en Thoughtworks, en un artículo publicado en martinfowler.com (también lo desarrolla en profundidad en el podcast de InfoQ From MCP and Vibe Coding to Harness Engineering). Su tesis: los asistentes de IA producen código verosímil, pero sin restricciones derivan, repiten errores y erosionan la coherencia interna del codebase. El código compila, los tests pasan y la degradación es silenciosa.

La metáfora viene del test harness clásico: las pruebas no hacen que el código sea correcto por construcción, sino que detectan cuándo deja de serlo. Llevado al código generado por IA, la pregunta deja de ser "¿el programa hace lo que debe?" y pasa a ser "¿el codebase todavía refleja las decisiones arquitectónicas, convenciones de naming, restricciones de seguridad y reglas estructurales que el equipo acordó?". Los tests funcionales son necesarios, pero no suficientes.

Los tres componentes del harness

Según Boeckeler, el harness tiene tres ejes que un equipo debe atender:

• Context engineering: disciplina de asegurar que la IA sepa lo que necesita saber. En la práctica, se traduce en un documento (el plugin que documenta la propuesta lo llama HARNESS.md) que captura stack, decisiones arquitectónicas, convenciones y la razón detrás de cada una. No es un README para humanos: es una base de conocimiento para el agente, y debe ser específica y estar viva.
• Restricciones arquitectónicas: conocer las reglas y hacerlas cumplir son problemas separados. Por eso Boeckeler introduce los verification slots — momentos definidos en el flujo donde corre un check que pasa o bloquea. Cada slot se implementa con herramienta determinista (linter, script, regex, aserción de estructura) cuando la restricción es expresable con precisión, o con revisión basada en agente (un LLM que juzga) cuando la reglainvolucra intención o semántica.
• Garbage collection: proceso periódico contra la entropía acumulada. El código muerto crece, los TODO persisten, las dependencias caducan, las convenciones se abandonan. A diferencia de los otros dos componentes, la GC corre por calendario, no por evento de código. El output no bloquea PRs: produce un reporte que señala problemas antes de que se vuelvan críticos.

Progressive hardening: la escalera de madurez de las restricciones

Una pieza clave del modelo es la escalera de promoción de las restricciones:

• Unverified: declaraste la regla en el documento, crees que es importante, no tienes mecanismo para validarla. Es contabilidad honesta, no un fracaso.
• Agent: ya escribiste un prompt que la revisa. Funciona la mayoría de las veces, pero es un LLM juzgando, no una regla determinista.
• Deterministic: la restricción está codificada como script, regla de linter o check estructural. Corre en CI. Pasa o bloquea el merge. Sin juicio.

La dirección siempre va hacia determinista. Cuando un agente repite capturas de la misma clase de violación, esa repetición es señal de que el patrón ya está lo suficientemente entendido como para automatizarlo. Escribes el script, retiras el agente y mueves la entrada en el documento a estado deterministic.

Por qué este tema dejó de ser opcional en 2026

El marco de Boeckeler lleva meses ganando tracción, pero en 2026 dejó de ser discusión académica para convertirse en problema operativo. Varios datos publicados este año lo ilustran:

• Microsoft reporta que GitHub Copilot está desplegado en el 90% de las empresas Fortune 100, con 4,7 millones de suscriptores pagos en enero de 2026, un crecimiento interanual cercano al 75% (cifras recogidas en el comunicado de Salt Security).
• GitHub estima que los asistentes de IA ya generan el 46% del código escrito por desarrolladores en la plataforma; Sonar sitúa la cifra de código generado o asistido por IA en el 42% del código empresarial en su Developer Survey 2026, y proyecta que superará el 50% antes de 2027.
• Veracode, en pruebas sobre más de 100 modelos de IA en tareas sensibles de seguridad, encontró que el 45% de las muestras de código generado por IA introducen vulnerabilidades del OWASP Top 10.
• CodeRabbit, herramienta de code review, halló que los pull requests con código de IA contienen 2,74 veces más vulnerabilidades que los escritos por humanos, y que la IA produce 1,7 veces más problemas que el código humano (cifras recogidas por TechCrunch).

La velocidad de adopción no se está traduciendo en reducción de costes de mantenimiento. TechCrunch recoge que empresas gastan hasta el 44% de sus tokens en arreglar bugs generados por su propia IA (según la CEO de Entelligence AI, Aiswarya Sankar). Uber consumió el presupuesto 2026 de IA en los primeros cuatro meses del año sin un aumento medible de productividad, según reportó The Information y recogió TechCrunch. Amazon cerró su leaderboard interno de uso de tokens (Kirorank) tras detectar que los empleados lo gamificaban sin impacto real.

La pregunta ya no es si el equipo debe montar un harness, sino cuánto está perdiendo por no tenerlo.

Qué significa esto para tu startup

Si tu equipo usa Claude Code, Cursor, GitHub Copilot, Windsurf, Codex o Gemini CLI —según el anuncio de Salt Security del 1 de junio de 2026, el catálogo de asistentes compatibles que las empresas estandarizan hoy— vas a enfrentar el mismo problema que Boeckeler describe: el código parece correcto, los tests pasan, y la base se degrada en silencio. La diferencia es que ahora tienes herramientas para evitarlo.

Acciones concretas para implementar en las próximas dos semanas:

1. Escribe un HARNESS.md (o equivalente) hoy. No esperes al documento perfecto. Lista tu stack, las decisiones arquitectónicas no obvias, las convenciones de naming y las restricciones de seguridad como bullets. Cada entrada debe tener una frase de por qué. El documento no es para el equipo humano: es para el agente. Mantenlo vivo o se vuelve ignorado.
2. Separa los verification slots en tres loops como propone el marco: inner loop (advisory en tiempo de edición, baja fricción, no bloquea), middle loop (estricto en PR, autoridad para bloquear merges), outer loop (programado, investigativo, produce reportes — ideal para garbage collection). Empieza con el middle loop en CI: linter, type-checker, tests, y una revisión con agente sobre las restricciones que no puedas codificar como regla.
3. Mide qué come tus tokens. Antes de añadir más automatización, instrumenta cuánto del gasto se va en arreglar bugs generados por la propia IA. Si la cifra se acerca al 44% que reportan equipos como Entelligence AI, tu ROI actual de IA es negativo aunque los devs se sientan más rápidos. La métrica útil no es velocidad de generación sino coste total de mantenimiento.

La propuesta de Boeckeler —y la del plugin que la implementa— añade una capa más: el harness puede aprender de su propia operación. Tras cada sesión, un comando como /reflect captura qué falló y qué convención se violó; los agentes leen ese log al revisar. Con el tiempo, el sistema detecta regresiones y propone endurecer las restricciones que más se repiten. No reemplaza el juicio humano, pero sí elimina el trabajo mecánico de detectar el mismo patrón de error por tercera vez.

Riesgos abiertos que el harness no resuelve solo

Conviene tenerlo presente: el marco de Boeckeler cubre bien mantenibilidad y consistencia interna, pero deja abierta la pregunta del comportamiento. Boeckeler misma lo reconoció en InfoQ: "todavía hay pocas ideas sobre un harness para el comportamiento". Lo que la mayoría de equipos hace hoy —escribir una spec, hacer que el agente genere tests, y dar por bueno cuando el suite queda verde— es unsatisfying, en sus palabras, porque el mismo agente generó los tests que ahora validan su propio código.

Hay señales de movimiento. Salt Security anunció en junio de 2026 Salt Code, una capa que aplica políticas de seguridad (OWASP API Top 10, MCP Security Top 10, LLM Security Top 10, OpenAPI/Swagger) en tiempo de generación, conectándose a los asistentes vía Model Context Protocol. OpenAI, por su parte, adquirió Ona el 11 de junio de 2026 para dotar a Codex de entornos cloud que soporten tareas más largas —Codex ya pasó de 3 millones de usuarios activos semanales en abril a más de 5 millones tras el anuncio, según CNBC.

El mensaje para founders: el harness engineering no es una moda de Thoughtworks. Es el nombre que está tomando el conjunto de prácticas que tu equipo necesita si no quieres descubrir, seis meses después, que la deuda técnica generada por IA supera el tiempo que ahorraste.

Fuentes

• Harness Engineering — Habitat Thinking (fuente original)
• From MCP and Vibe Coding to Harness Engineering — InfoQ
• Salt Security launches Salt Code — PR Newswire / Morningstar
• Coders are refusing to work without AI — TechCrunch