Qué es un harness y cómo hace confiable a un agente de IA.

Cuando un equipo de ingeniería dice que la IA todavía no es lo bastante buena, casi siempre habla de un agente suelto, sin nada alrededor que revise lo que hace. Este artículo explica qué es un harness, de qué piezas se compone y qué cambió en nuestro proceso cuando añadimos un tercer revisor automático.

▲¿Qué es un harness en el desarrollo con agentes?

Birgitta Böckeler, de Thoughtworks, usa una definición parecida en Harness engineering for coding agent users: el harness es todo lo que forma parte de un agente salvo el modelo. Ella distingue las guías, que orientan al agente antes de que actúe, de los sensores, que observan lo que hizo para que pueda corregirse. Separa además los controles deterministas, como las pruebas, de los que usan otra IA para revisar el trabajo.

Dicho sin jerga, el harness es el sistema de trabajo del agente. Define qué sabe antes de empezar, quién revisa lo que produce y en qué momento interviene una persona.

▲¿Por qué los desarrolladores desconfían de la IA?

Hace poco hablé con un CEO cuyos desarrolladores le decían que la IA todavía no es lo bastante buena. Él veía a otras startups, sobre todo en Estados Unidos, entregar más rápido con agentes, y buscaba cómo hacer más eficiente a su propio equipo.

Creo que sus desarrolladores tienen razón en desconfiar de un agente suelto, porque un agente sin revisión se equivoca. La pregunta útil es qué sistema rodea al modelo y qué ocurre cuando falla. Si el equipo puede ver ese sistema, cuestionarlo y cambiarlo, tiene un proceso en el que apoyarse.

▲¿Qué piezas tiene un harness?

El harness de nuestro método tiene cuatro piezas, y se pueden construir con distintas herramientas.

• ▲Specs en el repositorio. Le explican al agente cómo decidir y se actualizan en el mismo PR que cambia el código.
• ▲Revisores automáticos. Otros agentes auditan seguridad, calidad y criterios de aceptación antes de que se abra el PR.
• ▲Puntos de control humanos proporcionales al riesgo. Producto valida qué se construye, una persona revisa lo de alto riesgo y QA aprueba el comportamiento antes del release.
• ▲Operación que regresa al flujo. Los errores en producción se diagnostican y vuelven al proceso como un ticket o como un PR de arreglo.

▲¿Qué cambia cuando el código lo leen agentes?

Durante años se midió a los desarrolladores por el código que escriben, y ahora buena parte lo escriben agentes. Eso cambia para quién se escribe: el primer lector de los specs, de las convenciones y de la documentación es un agente, que los usa para decidir.

Por eso esos materiales dejan de ser un trámite y pasan a ser parte del trabajo. Si un spec está desactualizado, el agente decide con una instrucción equivocada, y por eso los specs se actualizan en el mismo PR que cambia el código.

▲¿Cómo funciona el agente de aceptación?

En nuestro proceso, cada PR pasaba por dos revisores automáticos: uno de seguridad y otro de calidad. Aun así, QA nos devolvía varios requerimientos porque llegaban incompletos, sin cumplir todos sus criterios de aceptación. Ninguno de los dos revisores se hacía esa pregunta, así que añadimos un tercero.

El agente de aceptación lee los criterios de cada requerimiento incluido en el PR y busca la evidencia de cada uno, en el código o ejecutando la aplicación. Si alguno no se cumple, se lo devuelve al agente principal con cuáles faltan y por qué. Los dos repiten ese loop hasta que se cumplen todos, y solo entonces continúa el proceso humano.

“Un código puede estar bien hecho, ser seguro y aun así no hacer lo que se pidió.”

En los términos de Böckeler, el agente de aceptación es un sensor de comportamiento. Ella señala que el harness de comportamiento, el que comprueba que el cambio hace lo que se pidió, es el menos resuelto de los tres tipos que describe, y en nuestro caso fue donde apareció el hueco.

▲¿Qué resultado tuvo?

Es la observación de un equipo y un producto concretos, no un estudio controlado, así que no la presento como una promesa. Lo que sí muestra es dónde estaba el hueco: nadie le preguntaba al PR si hacía lo que el requerimiento pedía.

Para medirlo en tu equipo necesitas un punto de partida. Los tres indicadores que propongo en el diagnóstico son las entregas por semana, el tiempo de la idea a producción y los requerimientos que QA devuelve.

▲¿Por dónde empezar?

1. 01Elige un flujo acotado. Un tipo de requerimiento que se repita, no todo el producto a la vez.
2. 02Escribe criterios de aceptación verificables. Cada criterio debe poder comprobarse con evidencia, no con una opinión.
3. 03Añade un revisor que compruebe esos criterios. Que le devuelva al agente que construye qué falta y por qué, y que ambos repitan hasta cumplirlos.
4. 04Define qué revisa una persona. La revisión humana es proporcional al riesgo: lo de bajo impacto no necesita pasar por ella y lo de alto riesgo sí.
5. 05Mide antes y después. Entregas por semana, tiempo de la idea a producción y requerimientos devueltos por QA.

Si quieres ver cómo encaja cada pieza en el proceso completo, el método de PeakSyn describe las cuatro etapas y los tres puntos de control humanos con sus artefactos.