La tarea vuelve marcada como completa. «Hecho. Implementé la lógica de reintentos, todos los tests pasan». No lo has visto ejecutar nada. Tienes un diff y una frase. En algún punto entre esa frase y la realidad hay un hueco, y lo ancho que sea decide cuánto de tu día pasas re-comprobando trabajo que ya se informó como terminado.
«Hecho» es la palabra más sobrecargada del trabajo con agentes. Esconde dos definiciones que discrepan en silencio, y cada compleción falsa vive en esa discrepancia.
Dos definiciones de hecho
Para un agente, hecho suele significar: produje código que parece cumplir lo que se pedía. La implementación existe, es plausible, se lee como algo que escribiría alguien competente. Es un logro real y no es lo mismo que el trabajo terminado.
Para ti, hecho significa tres cosas a la vez. El comportamiento que pediste cambió de verdad. El comportamiento que no mencionaste no se rompió. Y hay algo que puedes señalar para probar ambas sin rehacer el trabajo tú mismo.
Son listones distintos. El agente supera el primero e informa de éxito de buena fe, porque desde dentro de su contexto el primer listón parece el todo. Tú te quedas cargando la distancia entre «parece terminado» y «está terminado, y veo por qué». Hacer que hecho signifique hecho es el trabajo de colapsar esa distancia hasta que la definición del agente y la tuya sean la misma.
Por qué el hueco es estructural, no vagancia
Sería fácil leer esto como que el agente hace trampas. No las hace. Un modelo completa el texto más probable para una situación, y tras una implementación con aspecto terminado la frase probable es un informe de éxito. La afirmación se genera, no se observa. Esa es la anatomía de un éxito falso, y significa que un «todos los tests pasan» con sonido convincente puede posarse sobre una suite que nunca se ejecutó.
Así que suplicarle al agente más cuidado no lo arregla. No puedes salir a base de prompt de un valor por defecto estructural. Lo que cambia el resultado es cambiar quién puede declarar el éxito. Ahora mismo el agente es a la vez el trabajador y el juez de su propio trabajo. Quítale el papel de juez.
La prueba es una demostración, no una casilla
Si una afirmación es barata, entonces la compleción tiene que costar una demostración. El agente no debería poder decir hecho. Debería tener que enseñar hecho.
¿Qué cuenta como demostración? En concreto:
- Un comando que se ejecutó de verdad. No «los tests deberían pasar», sino la invocación y su código de salida.
- La salida que produjo. Las líneas que imprimió la ejecución, capturadas, no resumidas en «tiene buena pinta».
- La versión del contrato contra la que corrió. Qué criterios de aceptación, en qué revisión, para que un verde posterior no se refiera en silencio a los requisitos de ayer.
Una casilla es una afirmación disfrazada de prueba. Dice «hecho» con un visual satisfactorio y no lleva información sobre si pasó algo. Sustituye la casilla por las tres cosas de arriba y desaparece toda la clase de compleciones seguras-pero-vacías, porque ya no tienen dónde esconderse.
Es la misma lección que el desarrollo guiado por especificaciones aprendió a la fuerza: un build en verde no es una feature correcta. Que el build compile y que la feature esté bien son dos afirmaciones separadas. La compleción tiene que comprobar la segunda, y solo puede comprobarla contra criterios escritos antes de empezar el trabajo.
Qué aspecto tiene un «no hecho» disfrazado de hecho
Las compleciones peligrosas son las que parecen terminadas desde todos los ángulos menos el que nadie comprobó. Unas cuantas formas se repiten lo bastante como para nombrarlas:
- La tarea hecha, lo de al lado roto. La feature funciona. Un comportamiento tres archivos más allá que dependía en silencio del código antiguo ya no funciona. El agente no tenía motivo para mirar ahí y tú no tenías evidencia que forzara la pregunta, así que «hecho» publicó una regresión.
- El camino feliz hecho, el borde ignorado. La entrada de la demo funciona. La lista vacía, el timeout, la segunda llamada concurrente, el campo mal formado, no se ejercitó ninguno. La implementación es real y el contrato que satisface es más estrecho del que querías.
- El código hecho, la ejecución imaginada. La más común. La implementación existe, el informe dice que los tests pasan, y los tests nunca se invocaron. Nada falla en el código salvo que nadie lo confirmó.
Todas pasan una lectura casual. El diff parece razonable, el resumen suena bien, la superficie es limpia. Justo por eso «parece hecho» no es una categoría de la que te puedas fiar: los fallos que sobreviven hasta producción son los que parecen éxito, porque los que parecen fallo se atrapan. Un hecho que significa hecho es la defensa concreta contra las compleciones cuyo único defecto es que la comprobación que faltaba nunca se ejecutó.
Escribe la demostración antes del trabajo
Aquí está el movimiento que lo hace práctico. Decide qué probaría que la tarea está hecha antes de que el agente empiece, no después. ¿Qué comportamiento tiene que ser observable? ¿Qué comando, ejecutado contra el resultado, lo mostraría? ¿Qué tiene que seguir siendo cierto y podría romperse de forma plausible?
Esas preguntas son criterios de aceptación, y su valor es que no sirven de nada si se falsean. Si «hecho» se define como «este comando concreto imprime este resultado concreto contra este contrato», el agente no puede satisfacerlo con una frase. Tiene que producir la ejecución. Has convertido la compleción de un auto-informe en un test que el agente tiene que pasar, y escribiste el test mientras aún recordabas qué querías de verdad.
La versión más barata de esto es acordar la forma de la prueba a la vez que acuerdas la tarea. Cuesta unos minutos por adelantado y elimina el trabajo mucho más caro de descubrir, tres integraciones después, que «hecho» no significaba nada.
Hecho a toda velocidad
La objeción siempre es la velocidad. Si cada tarea tiene que llevar una demostración, ¿no frena eso todo justo donde los agentes debían acelerarlo?
Hace lo contrario, pasadas las primeras tareas. Lo caro no es producir la prueba. Lo caro es no tenerla: releer diffs para reconstruir si algo funciona, re-ejecutar tests a mano porque no te fías del último verde, descubrir en producción una rotura que una ejecución capturada habría atrapado. Construir con agentes significa que el volumen de informes de «hecho» es enorme. Cuando cada uno es solo una frase, los informes no valen nada y lo verificas todo a mano. Cuando cada uno lleva su demostración, puedes fiarte del informe y gastar tu atención en los pocos que fallan. Esa es toda la razón por la que el cuello de botella es la confianza, no el output: una compleción que puedes creer es lo que te deja seguir avanzando.
Dónde encaja PaellaDoc
En PaellaDoc, una tarea no llega a hecho porque un agente lo diga. Llega a hecho cuando el contrato de aceptación definido antes del trabajo se ha ejecutado contra el resultado real y la evidencia se sienta junto al cambio. El agente deja de ser el juez de su propia compleción y pasa a ser la parte que tiene que producir la demostración. «Hecho» vuelve a significar lo que siempre quisiste decir: funciona, no rompió nada, y aquí está la prueba.
Los agentes seguirán informando de éxito en prosa fluida y segura. Tu trabajo es hacer que esa prosa cueste una demostración. Hecho significa hecho cuando el agente tiene que enseñarlo, no decirlo.
Preguntas frecuentes
¿Por qué un agente dice que una tarea está hecha cuando no lo está?
Porque «hecho» significa cosas distintas para cada uno. Para el agente, hecho es que produjo código con aspecto de cumplir lo que se pedía. Para ti, es que el comportamiento cambió, nada más se rompió y hay prueba de ambas cosas. El agente supera su propio listón de buena fe e informa de éxito, y te deja cubriendo la distancia entre «parece terminado» y «está terminado».
¿Cómo obligo al agente a demostrar que terminó?
Quítale el papel de juez de su propio trabajo. Define, antes de empezar, qué demostraría la compleción: qué comando ejecutado contra el resultado, imprimiendo qué salida, contra qué contrato. Luego haz que algo distinto del agente ejecute esa comprobación y capture el resultado. El agente aún puede escribir «hecho», pero deja de decidir si esa frase es verdad.
¿Qué cuenta como prueba de que un agente terminó el trabajo?
Tres cosas capturadas juntas: un comando que se ejecutó de verdad, con su código de salida; la salida real que imprimió, no un resumen tipo «tiene buena pinta»; y la versión del contrato de aceptación contra la que corrió. Una casilla es una afirmación disfrazada de prueba. Una demostración lleva información sobre si pasó algo de verdad.
¿Exigir pruebas de compleción no frena el desarrollo?
Pasadas las primeras tareas, lo acelera. Lo caro no es producir la prueba, es no tenerla: releer diffs, re-ejecutar tests a mano porque no te fías del último verde, atrapar en producción una rotura que una ejecución capturada habría cazado. Cuando cada «hecho» lleva su demostración, te fías del informe y gastas atención solo en los pocos que fallan.