Harness Engineering para Agentes de Código IA desde Argentina

El término ganó tracción a comienzos de 2026, después de que Mitchell Hashimoto (cofundador de HashiCorp) le puso nombre a algo que muchos líderes de ingeniería ya habían concluido a los golpes: cuando un agente se porta mal, el arreglo correcto suele ser cambiar el sistema que lo rodea, no agregar otra oración al prompt. OpenAI reforzó la idea poco después, describiendo cómo shipeó un producto interno sin código escrito a mano invirtiendo en el andamiaje alrededor de sus agentes Codex, más que en los prompts que los guiaban.

El Thoughtworks Technology Radar (Volumen 34, abril de 2026) marcó al harness engineering como una de las macrotendencias definitorias del sector. Su lectura: el espacio pasa de experimentar a buscar repetibilidad y estabilidad. La confiabilidad del agente dejó de ser "una preocupación más" para convertirse en un riesgo de nivel directivo en varias de las empresas con las que hablamos.

El argumento central es simple. Decirle a un agente "seguí nuestros estándares" en el system prompt es como pedirle a alguien recién ingresado que "escriba buen código": funciona a veces. El cumplimiento de un LLM con las instrucciones es probabilístico, no determinista. El mismo agente puede respetar cada convención arquitectónica el lunes e introducir una consulta SQL directa que saltea el ORM el martes. Los prompts sugieren; no hacen cumplir.

Un harness agrega la capa de enforcement. Los archivos AGENTS.md codifican los límites arquitectónicos en un formato que el agente puede razonar. Los gates de CI rechazan el código que los viola antes de que llegue a main. Los loops Plan-Execute-Verify obligan al agente a pasar por checkpoints explícitos. Los dashboards de observabilidad exponen si el harness está funcionando o si aparecen nuevos patrones de falla. Cada capa refuerza a las otras: las restricciones bajan el volumen de fallas, la verificación atrapa lo que se escapa y la observabilidad expone los patrones que ambas capas se pierden.

Plan

El agente lee la especificación, carga contexto del proyecto desde AGENTS.md y archivos de reglas, descompone la tarea, chequea las restricciones y propone un abordaje de implementación. Para cambios de alto riesgo insertamos un gate de aprobación humana entre planificación y ejecución. El agente no avanza hasta que el abordaje queda explícitamente validado.

Execute

El agente genera código y tests dentro de un sandbox. La ejecución queda acotada por las restricciones definidas en la planificación. Los cambios bajan como commits incrementales, no como un diff gigante. Si el agente intenta tocar un módulo protegido o importar una dependencia no permitida, la capa de restricciones bloquea la acción antes de llegar al repositorio.

Verify

La suite de tests corre en todos los niveles: unitarios, integración, end-to-end. El análisis estático marca problemas de calidad y de seguridad. Verificadores de conformidad arquitectónica confirman que el cambio respetó los límites de módulo. El mutation testing comprueba que los nuevos tests atrapan bugs reales y no solo ejercitan rutas de código. El feedback de pasa/falla, con contexto, vuelve al agente para reintentar.

El estándar abierto AGENTS.md, publicado en 2025, le da al agente contexto estructurado del proyecto. El contexto por sí solo no es un harness. La mayoría de los equipos con los que trabajamos ya tiene alguna versión de AGENTS.md o CLAUDE.md cuando llegamos. El archivo suele listar el stack, esbozar algunas convenciones y sumar un puñado de "no hagas esto".

Ese es un punto de partida, no un sistema de restricciones. Un AGENTS.md bien diseñado incluye límites arquitectónicos que se traducen a chequeos de CI aplicables, requisitos de testing ligados a gates específicos de verificación, reglas de seguridad que referencian configuraciones reales de escaneo y política de dependencias alineada con la configuración de su package manager. Deja de ser una lista de sugerencias y se convierte en un contrato entre humanos y agentes.

Escribimos AGENTS.md que se comportan como especificaciones ejecutables. Cada restricción en el archivo mapea a un chequeo de CI que la aplica. Cada requisito de testing mapea a un gate de verificación. Cuando el archivo dice "todas las consultas a base pasan por el ORM", hay una regla de análisis estático que atrapa SQL directo. Cuando dice "tests de integración obligatorios para rutas de API", el pipeline bloquea merges que no los tengan.

Fase 1: Auditoría del uso de agentes (semanas 1-2)

Mapeamos el uso real de agentes entre equipos y repositorios. ¿Qué herramientas están usando realmente sus desarrolladores (no cuáles fueron "aprobadas")? ¿Qué porcentaje de commits recientes involucró asistencia de IA? ¿Dónde se concentran las fallas? Medimos métricas base: tasa de resolución de tareas, tasa de rework, drift arquitectónico. La salida es un inventario priorizado de requisitos del harness más un plan de implementación que puede socializar con liderazgo.

Fase 2: Diseño del harness (semanas 3-5)

Con la auditoría en la mano, diseñamos la arquitectura de restricciones. ¿Qué límites requieren enforcement duro? ¿Dónde van los gates de verificación en el pipeline? ¿Qué nivel de supervisión humana corresponde a cada clase de riesgo? ¿Cómo se coordinan los flujos multi-agente? Tomamos esas decisiones con su equipo en la sala. Un harness impuesto desde afuera no sobrevive a la primera semana de uso real.

Fase 3: Construcción e integración (semanas 5-10)

La fase de implementación. AGENTS.md y archivos de reglas por repositorio. Infraestructura del loop PEV. Configuración de gates de CI. Sandboxing de agentes. Dashboards de observabilidad. Calibración de umbrales. Cada componente se ejercita contra flujos reales de agentes, no hipotéticos. Los umbrales se ajustan para evitar sobre-restricción: un harness que bloquea demasiado trabajo válido es peor que no tener harness.

Fase 4: Handoff y entrenamiento (semanas 10-14)

Documentación, runbooks, workshops de escritura de specs y entrenamiento hands-on para mantener el harness mientras evolucionan su base de código y su stack de agentes. Formamos al equipo para actualizar restricciones, ajustar gates de verificación e interpretar los datos de observabilidad. El resultado por defecto es transferencia total de ownership. El soporte continuo es opcional, no asumido.

El contexto

Una plataforma SaaS Serie B con cerca de 70 ingenieros distribuidos entre Miami, Buenos Aires y Ciudad de México nos contactó a comienzos de 2026 tras chocar contra un techo en la adopción de herramientas de código IA. El equipo había desplegado Claude Code y Cursor Agent seis meses antes. El throughput por desarrollador subió alrededor de un 40 por ciento según su tracking interno. El liderazgo estaba contento con los números.

Entonces pasaron tres cosas en el mismo mes. Un incidente de producción se rastreó hasta una migración generada por IA que salteó el ORM y rompió la integridad de datos para unos 12.000 registros de clientes. Una auditoría de seguridad detectó inconsistencias en el manejo de credenciales en 8 de sus 14 repositorios, todas en módulos generados por agentes. Y su arquitecto principal se dio cuenta de que el monorepo había desarrollado dos patrones de API competidores porque distintos agentes habían introducido convenciones distintas en servicios distintos, y nadie lo notó hasta que aparecieron fallas de integración.

Intentaron resolverlo con mejores prompts e instrucciones de sistema más elaboradas. Funcionó aproximadamente dos semanas. Después aparecieron instancias nuevas del mismo patrón en otros lugares. Su VP de Ingeniería lo dijo sin vueltas: "no podemos devolver la velocidad, pero tampoco podemos seguir shipeando con esta tasa de defectos".

Qué construimos

Montamos un squad de cinco personas desde Córdoba durante 12 semanas: dos platform engineers, dos especialistas en DevOps y un arquitecto de harness liderando el engagement. Nuestro equipo superpuso cuatro horas diarias con los leads de Miami, algo que importó más de lo esperado cuando hubo que ajustar umbrales de restricción en tiempo real.

Las decisiones centrales:

• AGENTS.md por repositorio con límites arquitectónicos aplicables. La restricción de "solo ORM" quedó respaldada por una regla de Semgrep que bloquea SQL directo en CI. El patrón duplicado de API se resolvió con una guía de estilo compartida que los agentes deben consultar antes de planificar.
• Loops PEV en GitHub Actions que obligan a los PRs generados por agente a pasar validación del plan, testing automatizado en tres niveles y chequeos de conformidad arquitectónica antes de permitir el merge.
• Una capa de coordinación multi-agente que asignó Claude Code a refactors complejos y Cursor a trabajo de features rutinario, con descomposición de tareas para evitar choques entre sesiones concurrentes.
• Dashboards de observabilidad que trackean tasa de éxito del agente, rework y detección de drift en los 14 repositorios, conectados a su Datadog existente.

Seis meses después del despliegue el equipo sostuvo la mejora del 40 por ciento de throughput y llevó la tasa de defectos por debajo de la línea base pre-agente. Su VP de Ingeniería lo resumió como "dejamos de pelear con los agentes y empezamos a trabajar con ellos". Para ver más casos, visite nuestra página de casos de éxito.

La mayoría de las empresas aborda el harness engineering como un problema puramente técnico. Construir los gates de CI, escribir los archivos de reglas, parar dashboards. Listo. El modo de falla más duro no es técnico. Es la deuda cognitiva: la brecha creciente entre lo que su código hace y lo que su equipo entiende sobre él.

Cuando los agentes generan el 60 o el 70 por ciento del código, los desarrolladores pierden contacto con detalles de implementación que antes sabían de memoria. Un ingeniero senior que antes conocía cada esquina del módulo de autenticación ahora revisa cambios generados por agentes sin el mismo modelo mental. El código funciona. Los tests pasan. La comprensión se erosiona en silencio. Seis meses después, cuando algo se rompe de una forma que los tests no cubrían, nadie en el equipo tiene el contexto para depurarlo rápido.

Por eso nuestros engagements siempre incluyen el componente de enablement del equipo. Ayudamos a los managers a decidir qué partes del código demandan comprensión humana profunda (rutas críticas de seguridad, lógica de integridad de datos, flujos de pagos de cara al cliente) y qué partes pueden volverse con seguridad "territorio mantenido por agentes" con supervisión más liviana. El objetivo no es maximizar la autonomía del agente. Es encontrar el balance correcto entre velocidad y comprensión para cada equipo.

Tercerizar tiene sentido cuando

• No tiene platform engineers con experiencia en confiabilidad de agentes en planta (la mayoría no los tiene; la disciplina casi no existía hace 18 meses).
• El código generado por agentes ya está causando problemas en producción y necesita harnesses operativos en semanas, no en trimestres.
• Su equipo usa varias herramientas de IA y necesita harnesses coherentes entre todas ellas.
• Quiere que el harness se construya una vez, afinado a su código, y se entregue al equipo interno para mantenerlo.
• Tiene más de 30 ingenieros usando agentes y la sobrecarga de coordinación ya no se resuelve por revisión ad-hoc.
• Prefiere entrega nearshore con traslape horario con EE. UU. Este, en lugar del ida y vuelta de 12 horas con APAC.

Construirlo in-house tiene más sentido cuando

• Ya tiene un equipo de platform engineering sólido que solo necesita una arquitectura de referencia y alguien con quien discutir.
• Su equipo es lo suficientemente chico (menos de 15 ingenieros) como para que la revisión informal siga atrapando la mayoría de los problemas.
• Usa una sola herramienta de IA y sus necesidades de restricción son acotadas y bien definidas.
• Tiene entre 6 y 9 meses de pista para iterar sobre el harness sin presión urgente de producción.

Tasa de resolución de tareas. Porcentaje de tareas que el agente resuelve correctamente, verificado contra tests automatizados. Investigación tipo DORA sugiere que los mejores agentes en entornos bien harnessados alcanzan el 65 a 77 por ciento. Sin harness, la mayoría de los equipos queda entre 25 y 40.

Tasa pass@1. Si el agente acierta al primer intento, sin reintentos. Importa porque los reintentos consumen presupuesto de cómputo y atención humana. Un harness bien calibrado empuja pass@1 arriba del 60 por ciento en tareas rutinarias.

Tasa de rework. Qué porcentaje de los PRs generados por agentes requieren intervención humana después del primer pase de verificación. Antes del harness, tasas del 50 a 60 por ciento son comunes. Post-despliegue apuntamos a menos del 15.

Drift arquitectónico. Con qué frecuencia el código generado por agente viola patrones arquitectónicos establecidos. Esta es la métrica que expone la degradación lenta que la revisión PR por PR se pierde. Integramos la detección de drift con su stack de observabilidad existente.

Desarrollo
con IA

Seguridad
de código con IA

Testing
asistido por IA

Desarrollo
de agentes IA

Desarrollo
MCP

Ingeniería
de plataformas