Hay un patrón en el que casi todos caemos con los agentes de programación, y socava en silencio todo el sentido de usar uno. El agente produce un cambio y le haces la pregunta obvia: "¿Esto funciona?". El agente dice que sí. Le crees, porque suena seguro y normalmente acierta. Y cada tanto se equivoca con total seguridad, por completo, y te enteras en producción.
El problema no es que el agente mienta. El problema es la pregunta.
Por qué "¿esto funciona?" es la pregunta equivocada
Cuando le preguntas a un agente si su propio cambio funciona, le estás pidiendo que evalúe su salida con exactamente el mismo razonamiento que la produjo. Corrige su propio examen con la misma pluma. Si se le escapó un caso límite al escribir el código, se le escapará el mismo caso límite al juzgarlo, porque nada nuevo ha entrado en escena: es el mismo modelo, el mismo contexto, los mismos puntos ciegos.
Peor aún, los modelos de lenguaje tienden a estar de acuerdo. Formula la pregunta como "esto maneja bien los correos nulos, ¿verdad?" y no has pedido una evaluación: has ofrecido una conclusión e invitado al agente a confirmarla. Normalmente lo hará. Lo que recibes no es verificación. Es un eco muy fluido de tu propia esperanza.
Pide pruebas en su lugar
La solución es pequeña y lo cambia todo: deja de pedirle al agente que afirme que el cambio funciona y empieza a pedirle que te lo muestre. Una prueba es un artefacto que puedes revisar tú mismo, producido por el sistema y no por la opinión que el agente tiene del sistema. No todas las pruebas valen lo mismo; hay una jerarquía aproximada:
- La prueba de ejecución es la más fuerte: el agente realmente ejecutó el código y te muestra la salida real: la prueba que pasó, el comando que devolvió lo que debía.
- La prueba de antes y después es casi igual de buena: un cambio concreto en el estado observable. El conteo de consultas pasó de 47 a 2; la petición que fallaba ahora devuelve 200.
- Una prueba que el agente escribió es más débil, porque el mismo punto ciego que se saltó el bug puede saltárselo en la prueba, pero una prueba que puedes leer y ejecutar sigue siendo mucho mejor que una afirmación.
- Una explicación verbal es la más débil. A veces es todo lo que puedes conseguir, pero "este es mi razonamiento" no es evidencia; es aquello que la evidencia se supone que debe comprobar.
La jugada, en todos los casos, es la misma: convertir la pregunta de sí o no en una petición de algo observable.
Cómo se ve esto
En vez de "¿esta migración manejará los correos nulos?", pídele que inserte una fila con un correo nulo, ejecute la migración y te muestre la salida. En vez de "¿esto arregló la consulta N+1?", pídele que añada logging de consultas, golpee el endpoint y te muestre el conteo de antes y después. En vez de "¿el rate limiter se reinicia?", pídele que alcance el límite, espere, lo intente de nuevo y te muestre la petición teniendo éxito. En cada caso has reemplazado una afirmación que tendrías que creer por un resultado que puedes leer.
Por eso nuestro agente vive en un sandbox
Las pruebas solo funcionan si el agente puede ejecutar cosas de verdad, y eso es una decisión de diseño, no una ocurrencia tardía. Cada ejecución de TaskGoblin ocurre en un sandbox con el repositorio clonado y el toolchain disponible, así que el agente no razona sobre lo que el código haría: puede ejecutar las pruebas, correr los comandos y observar el resultado real. Cuando revisa un merge request, sus hallazgos apuntan a comportamiento concreto, y cuando respondes @taskgoblin fix, el cambio es uno que puede ejercitar en vez de solo defender.
Por eso también un buen entorno de desarrollo rinde más que nunca. Un agente que puede levantar tus servicios, cargar datos de prueba y ejecutar tu suite produce pruebas reales; un agente que solo puede leer el código solo puede darte una opinión. Cuanto más ejecutable sea tu proyecto, más salida del agente podrás verificar en lugar de creer.
La versión de una frase
No le preguntes a un agente si su trabajo es correcto. Pídele que te muestre que lo es, y prefiere las formas de mostrar que tú mismo puedes comprobar. El agente que ejecuta el código y te entrega la salida hace lo único que el agente que da fe del código nunca podrá: darte algo en qué creer que no sea su propia seguridad.
