Un agente termina una tarea y te responde: «Hecho. Todos los tests pasan». No lo has visto ejecutar nada. Tienes un diff, una frase segura y una decisión que tomar. ¿Te lo crees?
Multiplícalo por ocho sesiones en paralelo, una docena de tareas cada una y una cola que se llena más rápido de lo que puedes leerla. Esta es la forma real de construir con agentes en 2026. El código llega. La pregunta nunca es si el modelo sabe escribirlo. La pregunta es si puedes fiarte de lo que ha vuelto, y cuánto de tu día te cuesta ya esa confianza.
Este es el artículo que ata todo lo demás. La generación está resuelta. El cuello de botella es la confianza, no el output. Todo lo que viene debajo es una sola idea vista desde seis ángulos: deja de verificar con sensaciones y empieza a verificar con evidencia.
Las sensaciones no son evidencia
Hay una forma cómoda de trabajar con agentes, y es silenciosamente peligrosa. El agente suena seguro. La prosa es limpia. El plan se lee bien. Así que apruebas, integras y sigues. No has verificado nada. Has sentido algo.
Una sensación es una señal sobre la superficie del output: parece correcto, se lee como código que escribiría alguien competente, los nombres de variable tienen sentido. La evidencia es una señal sobre el comportamiento del output: este test se ejecutó, contra esta versión, y esto es lo que imprimió. En el hueco entre ambas es donde el software roto se publica con una marca verde encima.
El replanteamiento que recorre todo este cluster es sencillo. El informe de un agente es una afirmación. Una afirmación no es una prueba. La verificación es el trabajo de convertir una en la otra, y es un trabajo que tienes que diseñar, porque el agente no lo hará por ti a menos que le fuerces la forma de la respuesta.
Haz concreta la distinción. «La lógica de reintentos está implementada y testeada» es una afirmación. Podría ser cierta. También es exactamente lo que el agente escribiría si implementó la lógica y no ejecutó ni un test, porque esa frase es el final natural de una tarea que pedía lógica de reintentos testeada. Ahora compara: «ejecuté pytest tests/retry_test.py, 14 pasaron, 0 fallaron, contra los criterios de aceptación v3». Eso es evidencia. Puedes leerla, puedes re-ejecutarla y nombra la versión del contrato contra la que se comprobó. La primera frase te pide confianza. La segunda se la gana, o falla a gritos. Toda la verificación consiste en mover tus decisiones del primer tipo de frase al segundo.
Por qué se dice «los tests pasan» cuando no se ejecutó nada
Empieza por el fallo que más sorprende: el agente dice que los tests pasan y no se ejecutó ni uno.
Ayuda ver el mecanismo en vez de enfadarse con la máquina. Un modelo de lenguaje completa texto. Cuando el contexto que lo rodea es una implementación terminada y una tarea que pedía tests en verde, la continuación más probable es una frase que informa de éxito. «Los tests pasan» es como suelen acabar esas situaciones en los datos de entrenamiento, así que eso es lo que se escribe. El modelo no miente en ningún sentido humano. Produce la frase probable, y la frase probable y la frase verdadera no son lo mismo.
Esta es la anatomía de un éxito falso: un informe generado por probabilidad, desconectado de cualquier ejecución. No es maldad y no es estupidez. Es el comportamiento por defecto de la herramienta, y en cuanto lo ves dejas de sorprenderte y empiezas a diseñar alrededor.
El arreglo no es un prompt mejor suplicándole al agente que diga la verdad. El arreglo es estructural: que el agente no sea quien informa del éxito. Que el éxito sea algo que un paso aparte observa y registra.
Hecho tiene que significar hecho
Si una afirmación es barata, la compleción tiene que ser cara. Tiene que costarle al agente una demostración.
«Hecho» es una de las palabras más sobrecargadas de este trabajo. Para un agente, hecho puede significar «escribí código que parece cumplir lo que se pedía». Para ti, hecho significa que el comportamiento cambió, que el comportamiento antiguo no se rompió, y que hay algo que puedes señalar para probar ambas cosas. Son definiciones distintas, y toda la disciplina de hacer que hecho signifique hecho consiste en cerrar la distancia entre ellas.
¿Qué cuenta como prueba? No una casilla. No el resumen del agente. Un comando que se ejecutó, su salida y la versión del contrato contra la que se ejecutó. Cuando hecho exige una demostración, el agente deja de ser el juez de su propio trabajo y pasa a ser la parte que tiene que aportar pruebas. Ese solo movimiento elimina casi toda la clase de fallo en la que la prosa segura tapa un resultado vacío. El build en verde nunca fue el objetivo. Como no se cansa de repetir el desarrollo guiado por especificaciones, un build en verde no es una feature correcta; que el build pase y que la feature esté bien son dos afirmaciones, y normalmente solo se comprueba una, sobre todo cuando el agente escribió los tests en la misma tirada que el código.
No puedes leerlo todo, así que lee en los momentos correctos
Aun cuando la evidencia es real, hay demasiada. Los agentes escriben más rápido de lo que lee ningún humano. Las encuestas a desarrolladores repiten lo que el día ya te dice: revisar código generado por IA suele costar más atención que revisar el de un colega, porque nada de la intención del autor vino con él. Esto es la fatiga de revisión, y no es un defecto de carácter. Es un desajuste de caudal.
La respuesta no es leer con más fuerza. Es leer en los momentos que llevan más información por minuto invertido. Aprueba el alcance antes de que el agente construya, para dirigir la intención en vez de auditar un hecho consumado. Comprueba el diff contra ese alcance, no contra tu recuerdo vago de lo que querías. Mira al final la evidencia: qué se ejecutó, qué pasó, contra qué contrato. Revisar en ese orden convierte una tarea de lectura sin límites en unos pocos puntos de control de alto apalancamiento. La misma lógica explica por qué la revisión más barata es la que haces sobre la spec, antes de que exista una sola línea, y conecta directo con para qué sirve el desarrollo guiado por especificaciones.
El cuello de botella se movió de producir a asegurar
Aléjate un paso y el patrón es económico. Durante décadas, la parte escasa y cara del software fue producirlo: escribir el código, hacerlo compilar, conseguir que funcionara siquiera. Los agentes hundieron el coste de esa parte. Lo que no se abarató es saber que lo producido es correcto, seguro y coherente con todo lo que lo rodea.
Así que el cuello de botella se movió. Pasó de producir a asegurar. La estación cara de la línea ya no es la que escribe código, es la que decide si fiarse de él. Si tu proceso sigue tratando la producción como la parte difícil y el aseguramiento como un sello de goma al final, has optimizado la estación equivocada, y se nota en una base de código que crece rápido y se pudre más rápido. Es el mismo desplazamiento que convierte cada cambio aislado y plausible en un sistema localmente correcto y globalmente incoherente cuando nadie asegura el conjunto.
Cierra el trabajo con la prueba adjunta
El último ángulo es donde aterriza todo esto: qué te quedas cuando una tarea termina. La mayoría de los flujos se quedan el diff y tiran la evidencia. El test se ejecutó, imprimió verde, y la salida se perdió en un scrollback de terminal que nadie volverá a encontrar. Tres semanas después no sabes si aquel verde llegó a existir ni contra qué versión.
El desarrollo basado en evidencia es la práctica de cerrar el trabajo con su prueba adjunta: el cambio, y junto a él qué se ejecutó, qué pasó y contra qué contrato, guardado donde la siguiente persona y el siguiente agente puedan encontrarlo. Una casilla marcada es estado. No es evidencia. Cuando la implementación abunda y el autor es a menudo un modelo, la prueba duradera deja de ser papeleo y se convierte en lo único que te deja fiarte del estado del sistema sin volver a verificarlo a mano. Por eso una especificación es solo la mitad de la historia si la prueba no viaja con ella, que es el argumento de las especificaciones de software portables.
La cadena, de la afirmación a la prueba
Leídos como un solo flujo, los seis ángulos son un pipeline por el que una afirmación baja hasta salir por el otro extremo convertida en algo de lo que puedes fiarte. El agente hace una afirmación. La compleción se niega a aceptarla bajo su palabra y exige una demostración. La demostración tiene que ser una ejecución real, no una frase generada, y por eso importa entender el éxito falso: te dice que la afirmación y la ejecución nunca estuvieron conectadas de entrada. La ejecución produce evidencia, y esa evidencia se captura y se conserva junto al cambio en vez de evaporarse. La revisión ocurre entonces en los momentos que llevan más información, leyendo la evidencia capturada en vez de reconstruirla. Y toda la línea la dimensiona su estación más lenta, el aseguramiento, porque es ahora la restricción.
Falla cualquier eslabón y la cadena gotea. Exige una demostración pero deja que el agente la narre, y el éxito falso pasa de largo. Captura evidencia pero tírala al integrar, y la revisión no tiene nada que leer. Asegura con diligencia pero solo al final, y has optimizado la estación equivocada mientras el trabajo sin verificar se amontonaba delante. El sentido de un hub es hacer visibles los eslabones, porque en la práctica los equipos arreglan uno y dejan los demás abiertos, y luego se preguntan por qué la confianza nunca llega.
El cuello de botella es la confianza, no el output
Junta los seis ángulos y sale una sola afirmación. Construir software con agentes no lo frena cuánto código puedes generar. Lo frena cuánto de ese código puedes creer sin pararte a comprobarlo a mano. Cada hora gastada en re-verificar un trabajo que el agente ya dijo terminar es el impuesto de la evidencia que falta.
La verificación con evidencia es cómo amortizas ese impuesto. No confiando más, ni leyéndolo todo, sino haciendo que el sistema produzca prueba como subproducto de hacer el trabajo, para que la confianza sea algo que puedas inspeccionar en vez de algo que tengas que sentir.
Dónde encaja PaellaDoc
Construyo PaellaDoc porque este problema es el que más me cuesta cada día. El movimiento que hace es negarse al éxito auto-declarado. Nada llega a «hecho» con una frase. Llega a hecho cuando el contrato de aceptación fijado antes de empezar se ha ejecutado contra el resultado real y la evidencia se ha capturado junto al cambio. El agente deja de ser el juez y pasa a ser la parte que aporta pruebas. La confianza deja de ser una sensación y pasa a ser una carpeta que puedes abrir.
Los agentes seguirán mejorando en escribir código. Eso nunca fue lo difícil. Lo difícil es saber que acertaron, y saberlo lo bastante rápido para seguir avanzando.
Preguntas frecuentes
¿Qué significa verificar código generado por IA? Sustituir la afirmación de éxito del agente por una prueba comprobable: un comando que se ejecutó, su salida y la versión del contrato de aceptación contra la que corrió, guardada junto al cambio. El agente informa; un paso aparte verifica y registra.
¿Por qué los agentes dicen que los tests pasan si no los ejecutaron? Porque un modelo de lenguaje completa el texto más probable para la situación, y tras una implementación terminada la continuación probable es una frase de éxito. Genera el informe probable, no observa una ejecución real. El arreglo es estructural: que el agente no sea quien declara el éxito.
¿No es revisarlo todo la respuesta segura? No, no escala. Los agentes producen más de lo que nadie puede leer a fondo. La respuesta duradera es revisar en los momentos de alto apalancamiento (alcance, luego diff, luego evidencia) y hacer que el sistema capture la prueba de forma automática, para que la confianza descanse en la evidencia y no en una lectura exhaustiva.