Los agentes no se revisan solos

Grawwww — un estudio pequeño de ingeniería

Transparencia: vendemos sistemas de agentes y diagnósticos, y usamos los sistemas que describimos. La oferta está al final, marcada como tal. El resto se sostiene sin ella. Las cifras salen de nuestros registros; cuando una cifra es un recuento tras exclusiones, de una sola ejecución o de dos, lo decimos.

Los tests ocultos estaban en verde. La especificación había pasado el control a la primera. Y aun así, una etapa de revisión rechazó el código.

Fue en una ejecución real de nuestra fábrica de software con agentes, sobre una pequeña CLI de facturas de demostración, propia. Un juez de fusión comparó el cambio con la petición original y encontró un fallo que ningún test cubría: la herramienta aceptaba nan e inf como importes y producía una salida JSON inválida. El agente lo corrigió en la segunda iteración, la segunda revisión pasó, se fusionó y la prueba posterior a la fusión salió verde. La ejecución entera costó unos 0,53 USD.

Es un solo caso. No es una tasa ni una promesa. Pero enseña lo que queremos contar: un agente puede entregar algo que parece correcto, pasa lo que se le pide comprobar y sigue estando mal.

Por qué los agentes solos no entregan

Un agente produce texto plausible. El código compila, el informe tiene buen aspecto, la web queda bonita. Lo que falla suele ser lo que nadie pidió comprobar. Si el mismo agente escribe y se aprueba, lo normal es que se apruebe.

Por eso lo que vendemos no es un agente. Es un sistema alrededor de los agentes, y una persona al final.

Las capas, y lo que cazó cada una

1. Especificación primero, con puerta. Antes de escribir código, la petición se convierte en criterios del tipo "dado / cuando / entonces", y un control comprueba que cada criterio tiene tests y que los criterios nuevos fallan sobre el código actual. En nuestra única ejecución completa, la puerta de especificación se pasó al primer intento. Hasta hoy solo lo hemos visto rechazar en tests unitarios, no en una ejecución real.

2. Tests ocultos que el agente que programa no ve. Quien escribe los tests no es quien implementa. Hay dos conjuntos: uno que devuelve "esperado / obtenido" y otro sellado que solo dice pasa o falla. Tenemos un test donde un implementador tramposo memoriza las respuestas del primer conjunto, y el sellado lo caza. De nuevo es un test, no una estadística.

3. Juez de fusión. Un script bloquea cambios que tocan la configuración del propio sistema, secretos, migraciones o más de 800 líneas. Después un juez compara el cambio con la petición original, no con los tests. Es la capa del caso del principio: en esa ejecución el juez rechazó la primera de dos revisiones.

4. Verificador de afirmaciones. Cuando un agente redacta texto, otro agente comprueba cada afirmación contra una fuente. En una revisión de los borradores de nuestro artículo técnico anterior y de sus publicaciones, 18 de 61 afirmaciones no tenían respaldo en el repositorio de origen. El resto: 40 verificadas, 2 derivadas por aritmética y 1 contradicha (un título de 61 caracteres que el borrador daba como de 66). Varias se reescribieron antes de publicar; las demás se mantuvieron porque otra fuente las respaldaba.

5. Escéptico. En nuestro equipo de investigación con agentes, un agente tiene como único trabajo intentar matar la idea. En una ficha, la puntuación pasó de 56 a 37 en la ronda en que la revisó el escéptico, junto con un veto de canal (un caso). De 26 oportunidades investigadas a fondo, 0 superaron nuestro umbral de 70 sobre 100 (la mejor llegó a 59). Ninguna de las 26 alcanzó el umbral de 70 puntos.

6. Revisión legal. Un agente de revisión legal repasó nuestra propia web y un borrador de una de sus páginas. Señaló 10 afirmaciones numeradas en el borrador, 5 de ellas como riesgo legal a corregir antes de publicar. Eran, entre otras, de dos tipos: promesas absolutas que no podemos cumplir y comparaciones que nadie podría verificar. Sonaban bien y eran nuestras.

7. La persona. Un ingeniero sénior revisa y responde de cada entrega. Es lo que ninguna capa anterior sustituye. Un ejemplo de nuestro propio trabajo: la web de este estudio se ha hecho con agentes. En la revisión humana se rechazaron seis conceptos de portada antes de aprobar uno. Se detectó que la barra de navegación cambiaba de una página a otra ("es molesto"). Al revisar el móvil se vio que por debajo de 860 px los enlaces estaban ocultos y no había menú.

Qué cuesta, con el sistema de investigación como ejemplo

Es el sistema donde tenemos volumen. Entre sus tres instancias registró 15.019 llamadas a herramientas; 12.639 quedan tras excluir las que no son investigación de negocio. Además, unas 6.600 búsquedas y lecturas web, unos 300 encargos a subagentes (25 de ellos revisiones del escéptico) y 88 candidatos puntuados, tras exclusiones.

Para una ronda completa sin supervisión tenemos coste medido solo de dos: 18,12 USD y 40,8 minutos en una, 19,23 USD y 35,2 minutos en la otra. Es decir, alrededor de 18–19 USD y 35–41 minutos, a partir de dos rondas medidas. Son dos mediciones, no un promedio fiable.

Nuestra lectura, que es una opinión y no una medición: cuando una ronda entera cuesta unos 18–19 USD, lo caro no es ejecutar las capas sino descubrir tarde que algo equivocado parecía correcto.

Límites

Una sola ejecución real completa de la fábrica de software. Hubo al menos 6 ejecuciones: 4 en nuestro entorno de integración el 26 de septiembre (1 completa, 2 bloqueadas antes de empezar por un fallo de configuración, 1 detenida por un fallo de infraestructura), más 2 ejecuciones locales el 27 de septiembre que se detuvieron en "ready" sin fusionar. Por eso no damos tasas ("a la primera", "sin reversiones") ni tiempos medios: con n = 1 serían engañosas.
La reversión automática nunca se ha disparado fuera de los tests. Es la función que más queremos demostrar; hasta ahora no se ha disparado en ninguna ejecución real.
No tenemos la duración por fase ni el total de esa ejecución, y el coste de 0,53 USD es una suma de importes ya redondeados.
El rechazo de la puerta de especificación y de los tests sellados solo está probado en tests unitarios.
Que el sistema de investigación investigue bien no significa que genere ingresos. En las pruebas baratas que abrió hay 0 € registrados.

Lo siguiente que mediremos: un lote de 10 a 20 peticiones reales en 2 o 3 productos propios distintos, para poder dar tasas por capa (aprobadas a la primera, rechazos de cada puerta, reversiones) y tiempos con mediana y percentil 90. Provocaremos una reversión real y la grabaremos. Publicaremos el resultado aunque sea malo.

Qué significa para un equipo que adopta agentes

Separa quien escribe de quien comprueba. Que el agente que implementa no vea los tests de aceptación.
Comprueba contra la petición, no solo contra los tests. Los tests recogen lo que ya pensaste. La revisión busca lo que no.
Pon un tope al gasto y al tamaño del cambio. Un agente atascado debe parar, no gastar.
Haz que el fallo sea reversible. Prueba tras fusionar y revierte solo.
Verifica los textos igual que el código. En una revisión de los borradores de nuestro artículo anterior y sus publicaciones, 18 de 61 afirmaciones no tenían respaldo en el repositorio de origen. Es un caso, pero basta para no publicar sin comprobar.
Pon a una persona que responda. Con nombre, con tiempo para revisar y con autoridad para decir que no.

Este artículo también pasó por el verificador. El primer borrador tenía 4 cifras que contradecían nuestros propios registros (por ejemplo, 95 candidatos puntuados cuando eran 88) y 9 afirmaciones sin respaldo. Las corregimos antes de publicarlo.

Esto lo hacemos para equipos

Sección comercial. Grawwww vende los servicios que describe este artículo.

Sistemas de agentes, desde 1.500 €; empezamos con un diagnóstico de 300 €.

El diagnóstico (300 € + IVA, se descuenta si seguimos) parte de un caso real tuyo: qué tareas darías a agentes, qué puertas hacen falta y dónde estaría la revisión humana. Recibes un informe por escrito y un presupuesto cerrado antes de empezar. El precio "desde" es el de partida; el cerrado va en la propuesta. Si el agente no es la herramienta adecuada para tu caso, el informe lo dice.

En el trabajo posterior, un ingeniero senior revisa y responde de cada entrega.

Envíanos tu caso: https://grawwww.xyz/equipos/