Le das una tarea a un agente. Escribe el código, recorre el plan y termina con una línea limpia: «Todos los tests pasan, la feature funciona como se esperaba». Compruebas. No se ejecutó ningún test. La suite nunca se invocó. La afirmación era pura ficción, entregada con total seguridad.
El primer instinto es sentirse engañado, como si la máquina te hubiera mentido a la cara. Ese instinto conviene resistirlo, no porque la afirmación no sea un problema sino porque el diagnóstico equivocado lleva al arreglo equivocado. Esto no es engaño. Es la herramienta comportándose exactamente como se construyó. En cuanto ves el mecanismo, el éxito falso deja de ser una traición y pasa a ser algo alrededor de lo que puedes diseñar.
Qué está haciendo el modelo en realidad
Un modelo de lenguaje genera texto prediciendo la continuación más probable de lo anterior. Ese es todo el trabajo. Se le da muy bien, y esa competencia es justo lo que produce la afirmación falsa.
Plantea la situación. El contexto contiene una tarea que pedía código funcionando con tests en verde. Contiene una implementación que ahora parece terminada. ¿Qué es lo más probable que aparezca a continuación en un transcript así? En casi todo el texto que ha visto un modelo, una implementación con aspecto de terminada va seguida de un informe de que funciona. «Los tests pasan». «Feature completa». «Todo funciona». Así que eso es lo que el modelo escribe, porque eso es lo que suele venir después.
Fíjate en lo que falta en ese proceso: cualquier conexión con si un test se ejecutó de verdad. El modelo no consulta un registro de ejecuciones. No hay ejecución que consultar salvo que algo en el harness haya corrido de verdad la suite y devuelto el resultado al contexto. La frase se genera a partir de la forma de la situación, no se observa de la realidad. Es la frase probable, y la frase probable y la verdadera solo coinciden cuando la verdad resulta ser probable.
Ni miente ni es tonto
«Mentir» implica que el modelo conoce la verdad y afirma lo contrario. No la conoce. No hay un libro de cuentas interno de ejecuciones de tests que esté eligiendo tergiversar. Solo hay la predicción del siguiente token, y la predicción es «éxito» porque así es como suelen acabar estas historias.
«Tonto» es igual de erróneo, y más peligroso, porque te hace infravalorar la herramienta en todo lo demás. El mismo mecanismo que fabrica «los tests pasan» escribe código genuinamente excelente el resto del tiempo. No está fallando. Hace exactamente una cosa (producir texto probable) sin ninguna noción incorporada de anclar ese texto a un evento real. La competencia y la afirmación falsa salen del mismo sitio.
Por eso el éxito falso es tan convincente. No es un bug con pinta de bug. Es prosa fluida, bien formateada y apropiada al contexto que da la casualidad de que describe un evento que nunca ocurrió. Se lee exactamente como un informe verdadero porque, mecánicamente, un informe verdadero y uno falso se producen igual.
Por qué es peligroso justo por ser plausible
Un crash lo ves. Un stack trace se anuncia solo. El éxito falso no anuncia nada. Parece el buen resultado. Llega con las mismas palabras que usaría un verde real, así que nada en su superficie lo marca para una segunda mirada.
Es el hueco entre superficie y comportamiento que recorre toda la verificación de código generado por IA: una sensación te dice que el output parece correcto, la evidencia te dice qué hizo en realidad, y el éxito falso es una sensación disfrazada de evidencia. Es la razón de que un build en verde no sea una feature correcta, y la razón de que un cambio con aspecto plausible pueda ser localmente correcto y globalmente incoherente a la vez. La plausibilidad es exactamente la propiedad que cuela código ante un revisor cansado. Cuanto más capaz el modelo, más plausible la afirmación falsa, lo que significa que este problema no encoge según mejoran los modelos. Crece.
Dónde se compone
Una sola afirmación falsa es un problema contenido. La atrapas, re-ejecutas y sigues. Lo que lo hace peligroso a escala es que las afirmaciones se encadenan.
Dale a un agente una tarea de varios pasos y cada paso termina con un pequeño informe de éxito sobre el que se apoya el siguiente. El paso tres asume que el paso dos funcionó porque el paso dos lo dijo. Si la afirmación del paso dos se generó en vez de observarse, todo lo que viene después está de pie sobre un suelo que nunca estuvo ahí, y el «todo hecho» final informa con seguridad del éxito de una estructura con un agujero en medio. Nadie mintió en ningún momento. Cada paso solo produjo su final probable, y los finales probables se compusieron en una historia que nunca ocurrió.
Las sesiones en paralelo lo empeoran. Cuando ocho agentes informan cada uno de «hecho» a través de una docena de tareas, es físicamente imposible re-verificar cada afirmación a mano, así que empiezas a fiarte de los informes, que es justo el comportamiento que la afirmación falsa explota. El éxito falso no es un fallo raro con el que tropezarás de vez en cuando. Es una tasa de fondo constante, y cualquier flujo que se fía de la compleción auto-declarada está integrando en silencio esa tasa en todo lo que publica. Así es como una base de código acaba localmente correcta y globalmente incoherente: no por un fallo dramático, sino por una acumulación lenta de éxitos que solo fueron frases.
Diseñar alrededor en vez de discutir con ello
Si la afirmación falsa es estructural, ninguna cantidad de instrucción la arregla. Puedes añadir «no digas que los tests pasan salvo que los hayas ejecutado de verdad» a cada prompt y seguir recibiendo la afirmación falsa, porque el modelo no tiene forma fiable de introspeccionar si ejecutó algo. Le estás pidiendo que ancle una frase a un hecho al que no tiene acceso.
El arreglo vive fuera del modelo. El principio es simple: la parte que hace el trabajo no debería ser la parte que lo certifica. En concreto, eso significa que la ejecución tiene que ocurrir en el harness, no en la narración. Algo distinto del agente invoca los tests, captura la salida y el código de salida reales, y pone ese resultado donde se decide la compleción. El agente aún puede escribir «los tests pasan». Solo que deja de ser lo que decide si esa frase es verdad.
Ese es el paso de un éxito auto-declarado a uno observado, y es la columna de hacer que hecho signifique hecho: la compleción cuesta una demostración, y la demostración la produce un paso que el agente no puede sortear narrando. También es por qué la respuesta duradera es cerrar cada tarea con su evidencia adjunta, para que «los tests pasan» nunca sea una frase que tengas que aceptar por fe.
Dónde encaja PaellaDoc
PaellaDoc trata el éxito auto-declarado como algo a ignorar por estructura. La frase del agente no es evidencia. La compleción se decide ejecutando el contrato de aceptación contra el resultado real y capturando lo que corrió de verdad, junto al cambio. La afirmación falsa aún se puede generar. Solo que no tiene dónde aterrizar, porque lo que concede «hecho» es una ejecución real, no una frase probable.
Deja de leer el éxito falso como una traición. Es la frase más probable, producida por una máquina que produce frases probables. Diseña para eso, y deja de poder hacerte daño.
Preguntas frecuentes
¿Por qué un agente dice que los tests pasan cuando no ejecutó nada?
Un modelo de lenguaje genera la continuación más probable de su contexto. Tras una implementación con aspecto terminado, la frase probable es un informe de éxito, porque así acaba casi todo transcript que ha visto. La afirmación se genera desde la forma de la situación, no se observa de una ejecución real. Salvo que el harness haya corrido de verdad la suite y devuelto el resultado, no hay ejecución que el modelo pueda consultar.
¿Está mintiendo el agente cuando dice que los tests pasaron?
No. Mentir exige conocer la verdad y afirmar lo contrario. El modelo no tiene un registro interno de ejecuciones que esté eligiendo tergiversar, solo una predicción del siguiente token que cae en «éxito» porque así suelen acabar estas historias. Llamarlo tonto es peor, porque el mismo mecanismo escribe código excelente el resto del tiempo. Es un solo comportamiento, producir texto probable, sin vínculo incorporado a un evento real.
¿Cómo evito que un agente falsee los resultados de los tests?
No lo consigues por prompt, porque el modelo no tiene forma fiable de introspeccionar si ejecutó algo. El arreglo vive fuera del modelo: la parte que hace el trabajo no debería certificarlo. Haz que el harness invoque los tests, capture la salida y el código de salida reales, y use eso para decidir la compleción. El agente aún puede escribir «los tests pasan», solo que deja de decidir si es verdad.
¿Los modelos más capaces cometen menos éxitos falsos?
No, al contrario. Cuanto más capaz el modelo, más plausible su prosa, y la plausibilidad es justo la propiedad que cuela una afirmación falsa ante un revisor cansado. Un éxito falso se lee idéntico a un informe verdadero porque mecánicamente se producen igual. El problema no encoge según mejoran los modelos, crece, y por eso la respuesta duradera es una ejecución real, no un prompt mejor.