Pedirle código a una IA es fácil. Confiar en lo que entrega, no. En las últimas semanas construimos un sistema de agentes que lleva un requerimiento hasta código probado, y casi todo lo que aprendimos tuvo poco que ver con el modelo y mucho con lo que lo rodea.
A eso que lo rodea se le llama harness. Este artículo cuenta qué es, qué falló cuando lo construimos y qué cambiamos para que el sistema pudiera correr solo y dejarnos revisar únicamente el resultado final.
Qué es un harness
Un harness es todo el software que rodea a un modelo de IA para convertirlo en un agente útil: qué herramientas puede usar, qué información recibe, cómo se revisa lo que produce y qué pasa cuando falla. La fórmula que se popularizó este año en la comunidad lo resume bien: agente = modelo + harness.
La distinción importa porque el modelo es la parte que menos controlas. Puedes elegir uno mejor, pero no puedes cambiar cómo razona. El harness, en cambio, es código tuyo: lo diseñas, lo pruebas y lo mejoras.
Y hay evidencia de que es ahí donde se juega el resultado. El estudio más riguroso sobre productividad con IA que conocemos, publicado por METR en 2025, encontró que desarrolladores con experiencia fueron un 19 % más lentos usando herramientas de IA, aunque ellos mismos creían haber ido más rápido. Las herramientas han mejorado desde entonces, pero la lección sigue en pie: darle un modelo a un equipo no garantiza nada. Lo que hace la diferencia es el proceso alrededor.
Cinco lecciones de construir uno
Cada una salió de algo que falló en una corrida real.
1. El que hace no puede ser el que aprueba
Un agente que revisa su propio trabajo tiende a darlo por bueno. Por eso separamos los roles: un agente implementa y otros, que no pueden escribir código, lo revisan. Además, el revisor trabaja con una regla simple: nada se aprueba sin evidencia propia. Que el implementador diga “los tests pasan” no cuenta; el revisor tiene que correrlos.
2. Lo que no requiere juicio, que no lo haga la IA
Al principio, el agente revisor también corría los tests. Funcionaba, pero era caro y tenía un riesgo: un modelo puede reportar mal un resultado. Ahora, antes de cualquier revisión con IA, el sistema verifica con código normal que todo compile y que los tests pasen. Si algo falla ahí, se rechaza sin gastar en el revisor. La IA queda para lo que sí necesita criterio: si el código cumple lo que se pidió.
3. Reintentar a ciegas es la forma más cara de fallar
En una de nuestras pruebas, una feature falló tres veces seguidas por el mismo motivo. El agente reintentaba, corregía y volvía a fallar. Al investigar descubrimos que el código funcionaba: el problema era que el revisor exigía un nombre de test exacto que el implementador nunca había recibido. Era un error de nuestro sistema, no del agente.
De ahí salió una pieza que hoy consideramos esencial: antes de reintentar, el sistema diagnostica de quién es la culpa. Si el mismo rechazo se repite, el problema probablemente es la especificación, y el sistema la reescribe. Si el entorno está roto (por ejemplo, falta una herramienta de pruebas), se detiene, porque reintentar no va a servir.
4. Que algo pase no significa que se haya hecho
En otra corrida, una feature pasó todas las revisiones sin escribir un solo archivo. Otra feature ya había hecho su trabajo, así que sus pruebas pasaban igual. No era un error técnico, pero sí una señal de que el plan tenía tareas duplicadas. Si solo hubiéramos mirado el resultado (“aprobado”), no lo habríamos visto. Ahora el reporte final lo marca como alerta.
5. Autónomo no significa infalible
Nuestro objetivo era que el sistema corriera sin que nadie tuviera que vigilarlo. Lo logramos, pero los agentes toman decisiones que una persona quizás no tomaría: qué formato usar, qué hacer ante un dato faltante, qué dejar para después. La respuesta no fue agregar más aprobaciones a mitad de camino, sino registrar cada decisión. Al final, el sistema entrega un reporte con lo que requiere juicio humano: las decisiones que tomaron los agentes, la deuda técnica que declararon y los hallazgos importantes. Se revisa una vez, al final, con todo a la vista.
Cómo se ve el pipeline completo
Un requerimiento pasa por cinco agentes especializados, con controles automáticos entre ellos y un registro de cada paso:
- Planner: divide el requerimiento en features verificables, cada una ligada a la historia de usuario que la originó.
- Spec Writer: convierte cada feature en una especificación técnica y deja registradas las decisiones que tomó.
- Implementer: escribe el código y sus pruebas. No puede dar su trabajo por terminado si los tests fallan.
- Controles automáticos: sin IA, verifican que todo compile y que las pruebas pasen.
- Reviewer: compara el código contra la especificación y clasifica lo que encuentra por gravedad.
- E2E Tester: prueba el comportamiento completo, como lo usaría una persona.
Si algo falla, el sistema diagnostica la causa y decide si reintenta, reescribe la especificación o se detiene. Si un agente se queda repitiendo el mismo error, primero recibe un aviso y, si insiste, se le detiene. Cada paso queda en una bitácora con firmas encadenadas, de modo que cualquier alteración posterior se detecta.
Cuánto cuesta. Estos son los costos de uso del modelo en nuestras pruebas:
| Caso | Features | Costo |
|---|---|---|
| Función de cálculo con sus pruebas | 2 | US$ 1,30 |
| Subsistema de plantillas, auditoría y consentimiento | 7 | US$ 9,50 |
Son dos casos, no un estudio: sirven como orden de magnitud. Lo que sí podemos afirmar es que los controles automáticos y la bitácora no encarecieron el trabajo, y que el gasto más grande que vimos vino de reintentos que un buen diagnóstico habría evitado.
Qué significa para un equipo de software
La pregunta útil ya no es “¿qué modelo usamos?”, sino “¿cómo sabemos que lo que entregó está bien?”. Un harness bien diseñado responde esa pregunta con evidencia: quién hizo qué, qué se revisó, qué falló y por qué, y qué decisiones quedan para una persona.
Para un equipo, eso cambia el trabajo diario. Quien hoy revisa cada resultado a mano pasa a diseñar los criterios con los que el sistema se revisa solo. Quien hoy aprueba por costumbre pasa a decidir dónde hace falta criterio humano y dónde basta un control automático. Las personas siguen en las decisiones importantes; el sistema se encarga de las verificaciones repetitivas.
Si estás evaluando cómo llevar agentes de IA a tu proceso de desarrollo, empieza por ahí: antes de elegir herramientas, define cómo vas a verificar lo que producen. Si quieres construir uno, el programa IA for Developers lo trabaja en 6 semanas con un harness de 5 agentes en Python. También puedes escribirnos para conversar sobre cómo aplicarlo en tu equipo.