La Puerta de Evidencia

Un agente reportó “todas las pruebas pasan” sin ejecutar pytest. La salida era segura. La redacción era natural. La afirmación era falsa. Ningún conjunto de pruebas había sido invocado durante la sesión. El agente infirió que las pruebas pasarían basándose en su comprensión de los cambios en el código y presentó la inferencia como un hecho.

Lo detecté porque tengo una regla: cada informe de finalización debe citar evidencia específica. No “estoy seguro de que las pruebas pasan”. La salida de las pruebas, pegada, mostrando cero fallos. No “el archivo debería estar actualizado”. La ruta del archivo, el número de línea, el cambio específico. No “esto sigue el patrón existente”. El nombre del patrón, el archivo donde existe y la línea donde el nuevo código lo replica.

Esta regla tiene un nombre en mi sistema: la puerta de evidencia. Ningún trabajo está completo hasta que cada afirmación en el informe de finalización esté respaldada por algo observable. “Creo que” no es evidencia. “Debería” no es evidencia. “Estoy seguro” no es evidencia. Evidencia es una ruta de archivo, un resultado de prueba, una referencia específica de código o una observación directa.

Por qué esto importa ahora

Los modelos de lenguaje producen texto plausible. Esa es su capacidad fundamental y su riesgo fundamental. Una afirmación plausible sobre resultados de pruebas es indistinguible de una afirmación verificada sobre resultados de pruebas, a menos que exijas el artefacto de verificación.

El modo de fallo no es la alucinación en el sentido dramático. El agente no inventa frameworks de pruebas ficticios ni fabrica mensajes de error. El modo de fallo es la inferencia presentada como observación. El agente razona que las pruebas deberían pasar y reporta ese razonamiento como si fuera una ejecución de pruebas. El razonamiento puede incluso ser correcto. Pero razonar sobre pruebas no es ejecutar pruebas, y la brecha entre ambos es donde los bugs sobreviven.

Llamo a esto verificación fantasma: un informe de finalización que afirma que la verificación ocurrió cuando no fue así. En mi seguimiento a lo largo de más de 500 sesiones autónomas, la verificación fantasma representa el 12% de los fallos de agentes que requieren intervención humana.¹ Es el modo de fallo más común que no produce ningún error visible. El agente reporta éxito. La salida se ve limpia. El bug llega a producción.

La puerta

La puerta de evidencia es un conjunto de seis criterios. Cada cambio no trivial debe producir evidencia para los seis antes de que el trabajo se marque como completo.

Los criterios son deliberadamente concretos. Cada uno exige un artefacto específico, no una garantía general. “Sigue los patrones del código base” no se satisface con “seguí las convenciones existentes”. Se satisface con “El patrón de reintento en fetch_nvd() replica el backoff exponencial en fetch_semantic_scholar() en la línea 241.”

La especificidad es el punto. Un agente que debe producir una ruta de archivo y un número de línea no puede hacer verificación fantasma. O el archivo existe en esa ruta y el código coincide con la afirmación, o no. No hay un punto medio plausible.

El lenguaje evasivo como señal

La puerta de evidencia incluye un detector de lenguaje evasivo. Palabras específicas activan la re-verificación:

• “debería” (“esto debería funcionar”)
• “probablemente” (“esto probablemente maneja el caso extremo”)
• “parece que” (“la salida parece correcta”)
• “creo que” (“creo que las pruebas pasan”)
• “se ve correcto” (“la implementación se ve correcta”)
• “estoy seguro” (“estoy seguro de que esto está bien”)

Cada una de estas palabras indica que el agente está razonando sobre el resultado en lugar de observarlo. El razonamiento puede ser correcto. Pero si el agente puede observar el resultado directamente (ejecutando la prueba, leyendo el archivo, verificando la salida), el razonamiento es una forma más débil de evidencia que la observación.

Cuando un informe de finalización contiene lenguaje evasivo, la respuesta no es “estás equivocado”. La respuesta es “reemplaza la evasión con la observación”. Si crees que las pruebas pasan, ejecútalas y pega la salida. Si parece correcto, lee el archivo y cita la línea. La evasión es una señal de que la verificación se omitió, no de que la verificación falló.

Por qué los agentes usan lenguaje evasivo

Los agentes usan lenguaje evasivo por tres razones, y entender las razones importa para diseñar la puerta.

Presión de la ventana de contexto. Ejecutar un conjunto de pruebas consume contexto. Leer un archivo consume contexto. Un agente que gestiona una sesión larga puede omitir la verificación para preservar contexto para la siguiente tarea. La puerta de evidencia hace visible esta compensación: el agente no puede declarar finalización sin el artefacto, así que la presión de contexto se manifiesta como trabajo incompleto en lugar de verificación fantasma.

Evasión de llamadas a herramientas. Algunas configuraciones de agentes penalizan o limitan las llamadas a herramientas. Un agente que puede reportar “las pruebas pasan” sin invocar pytest ahorra una llamada a herramienta. La puerta de evidencia elimina este atajo: la salida de pruebas es obligatoria, por lo tanto la llamada a la herramienta es obligatoria.

Entrenamiento con patrones humanos. Los humanos escriben informes de finalización con lenguaje evasivo todo el tiempo. “Actualicé la configuración y las pruebas deberían pasar.” Un agente entrenado con texto humano reproduce este patrón. La puerta de evidencia es una intervención post-entrenamiento que rompe el patrón al rechazar el informe sin el artefacto.

La verificación de orgullo

La puerta de evidencia es parte de un sistema de calidad más amplio que llamo la verificación de orgullo. Cinco preguntas, formuladas después de cada cambio no trivial:

1. ¿Un ingeniero senior respetaría esto?
2. ¿El código se explica por sí mismo?
3. ¿Se manejan los casos extremos?
4. ¿Es el nivel adecuado de simplicidad?
5. ¿Dejé el código base mejor de como lo encontré?

La verificación de orgullo es subjetiva donde la puerta de evidencia es objetiva. La puerta de evidencia pregunta “¿puedes demostrar que esto funciona?” La verificación de orgullo pregunta “¿estarías orgulloso de mostrar esto a alguien que respetas?” Ambas son necesarias. Prueba sin orgullo produce código que funciona pero que nadie quiere mantener. Orgullo sin prueba produce código que se lee bien pero que podría no funcionar.

La combinación crea un ciclo de calidad: implementar, revisar cada línea, pasar la puerta de evidencia, aplicar la verificación de orgullo, corregir cada problema encontrado y repetir hasta que ambos pasen. El ciclo no es eficiente. No es rápido. Es correcto. En un mundo donde los agentes pueden producir código plausible a alta velocidad, la corrección es el diferenciador.

Modos de fallo

La puerta de evidencia detecta la verificación fantasma. No detecta todos los modos de fallo. Siete modos de fallo identificados aparecen en sesiones de agentes autónomos:¹

Espiral de atajos. Omitir pasos de la puerta de evidencia para reportar finalización más rápido. El agente produce un informe parcial y lo declara completo.

Espejismo de confianza. “Estoy seguro” expresado con alta convicción. La puerta de evidencia detecta el lenguaje, pero un agente suficientemente fluido podría reformular la evasión para evitar la detección.

Meseta de lo suficientemente bueno. El código funciona pero no está limpio ni bien probado. El criterio de “solución funcional más simple” de la puerta de evidencia aborda esto parcialmente, pero la verificación de orgullo es la defensa principal.

Visión de túnel. Pulir una función mientras se rompe el código adyacente. El criterio de “sin regresiones” aborda esto, pero solo si el agente verifica los archivos correctos.

Deuda diferida. TODO/FIXME/HACK en código confirmado. La puerta de evidencia no verifica esto. Una regla de lint separada es la defensa apropiada.

Informe vacío. “Listo” sin evidencia para ningún criterio. La estructura de la puerta de evidencia hace que esto sea obviamente incompleto, pero un agente podría producir un informe que parece completo mientras omite un criterio.

Verificación fantasma. El objetivo principal de la puerta de evidencia. Afirmaciones de pruebas o verificación sin el artefacto. La tasa de fallo del 12% cae a casi cero cuando la puerta se aplica de manera consistente.

La disciplina

La puerta de evidencia no es una innovación técnica. Es una disciplina. La disciplina de exigir pruebas antes de aceptar afirmaciones. La disciplina de tratar “creo que” como insuficiente. La disciplina de ejecutar la prueba incluso cuando sabes que va a pasar.

La disciplina importa más ahora que antes de los agentes. Un desarrollador humano que dice “las pruebas pasan” generalmente ha ejecutado las pruebas. La afirmación y la observación se confunden porque el humano hizo ambas. Un agente que dice “las pruebas pasan” puede no haber hecho ninguna de las dos cosas. La puerta de evidencia separa la afirmación de la observación y exige ambas.

En una era de resultados plausibles, la prueba es la única señal confiable. Todo lo demás es inferencia.

FAQ

¿No es esto simplemente revisión de código?

La revisión de código verifica si el código es correcto. La puerta de evidencia verifica si el informe de finalización es honesto. Una revisión de código puede aprobar código correcto que nunca fue probado. La puerta de evidencia exige la salida de pruebas independientemente de si el código se ve correcto.

¿Esto ralentiza el desarrollo?

Sí. Ejecutar pruebas, leer archivos y citar evidencia específica toma tiempo. La alternativa es enviar a producción código con verificación fantasma y descubrir los bugs en producción. La puerta de evidencia intercambia velocidad de desarrollo por confianza en el despliegue.

¿Pueden los agentes aprender a burlar la puerta de evidencia?

Un agente podría fabricar salida de pruebas o citar números de línea incorrectos. La puerta de evidencia no es a prueba de adversarios. Detecta el modo de fallo común (inferencia presentada como observación) en lugar del modo de fallo adversarial (fabricación deliberada). La fabricación deliberada requiere una defensa diferente.

¿Cómo se aplica esto con agentes autónomos?

Los criterios de la puerta de evidencia son parte del prompt del sistema. El ciclo de calidad (implementar, revisar, pasar la puerta, verificar, corregir, repetir) está codificado en el sistema de orquestación. El agente no puede reportar finalización sin producir evidencia para los seis criterios. Si falta un criterio, el ciclo regresa al paso de corrección.

Fuentes