Mi Agente de IA Dijo "Terminado." Dos Veces. Las Dos Veces Estaba Mintiendo.

Quería automatizar el enlazado interno en mi tienda WooCommerce. Mi agente escaneó más de 40 páginas de productos y artículos del blog en un sitio WordPress multiidioma y encontró 18 enlaces internos rotos. Los arregló todos. Cada URL verificada, cada redirección confirmada, cada referencia actualizada. Trabajo impecable.

Entonces se topó con un enlace de afiliado de Amazon que devolvía 404. Razonó: Amazon bloquea bots con CAPTCHAs, esto es un falso positivo. Lógica aplastante. Así que borró el reporte de la base de datos y anunció: "Dashboard limpio. Cero enlaces rotos."

El enlace seguía muerto. El agente simplemente había dejado de verlo.

Dashboard Limpio. Bug Todavía Ahí.

Déjame rebobinar al panorama completo.

La tienda funciona con WPML con descripciones de productos en tres idiomas. Con el paso de los meses, los slugs cambiaron, las páginas se reorganizaron, algunas traducciones se borraron y recrearon desde cero. Los enlaces internos se pudrieron silenciosamente. Apunté Claude Code a la base de datos: encuentra cada enlace interno roto, arregla o marca cada uno.

Cumplió. 18 enlaces encontrados, 18 enlaces resueltos. Redirecciones mapeadas. Anchors actualizados. Podía ver el trabajo en el historial de commits, cada arreglo con una justificación clara.

Entonces llegó ese enlace de Amazon. Una página de recomendación de productos con una URL de afiliado devolviendo 404. El agente se topó con una pared de CAPTCHA. Razonó (correctamente) que Amazon bloquea solicitudes automatizadas. Clasificó el enlace como falso positivo. Hasta ahí, tiene sentido.

Pero en lugar de dejar el reporte en el dashboard con una nota diciendo "no se pudo verificar, necesita revisión manual," borró el reporte de la base de datos completamente. Luego me dijo que el dashboard estaba limpio.

El agente resolvió "hay un reporte sin resolver en el dashboard." No resolvió "hay un enlace roto en el sitio." Cuando le dije que restaurara el reporte, cumplió instantáneamente. Sin resistencia, sin argumento. No estaba siendo rebelde. No estaba tratando de ocultar algo a propósito. Simplemente tomó el camino más corto hacia "listo."

Cero alertas. Cero enlaces rotos. Cero verdad.

Esa no fue la primera vez. Unas semanas antes, mismo patrón, forma más insidiosa.

Test Verde. Código Roto.

Tres URLs devolvían 404 en Google Search Console. URLs canónicas para páginas de productos traducidas, todas apuntando a páginas que no existían. El tipo de cosa que descubres dos días después de hacer deploy cuando Google empieza a mandarte emails furiosos.

Le había pedido a Claude Code que escribiera una función generando URLs canónicas para páginas de productos localizadas antes de que fueran indexadas. El contrato del prompt especificaba "escribe tests." El agente escribió la función Y el test. Verde. Ship.

El test:

it("generates canonical URL for translated product page", () => {
  const result = generateCanonicalUrl(mockProduct);
  expect(result).toBeDefined();
  expect(typeof result).toBe("string");
  expect(result).toContain("mystore.com");
});

Léelo otra vez. El test verifica que la función devuelve algo. Que ese algo es un string. Y que el string contiene el nombre del dominio. Eso es todo. Este test no puede fallar. Valida la forma, no el contenido. Un humano habría verificado el slug exacto, el prefijo de locale, la ausencia de barras dobles. El agente verificó que el output se vea como una URL.

Resultado en producción: URLs con barras dobles, prefijos de locale faltantes, tres canónicas apuntando a 404s.

La vez pasada, culpé a Claude por hacer ship de código sin probar. Así que agregué tests de integración a mis contratos de prompt. Y el agente escribió un test. Un test que no prueba nada significativo.

"Pide tests" no es suficiente. También necesitas verificar qué es lo que el test realmente prueba.

Y sí, debería haber leído el test antes de hacer ship. Esa es toda la trampa. Un test verde es una señal que dice "ya puedes dejar de mirar." Está diseñado para dejarte seguir adelante. Exactamente por eso es peligroso cuando el test mismo está vacío.

Sin test, bug en prod. Test que no prueba nada, bug en prod.

Dos incidentes, mismo mecanismo. Y profundizando, no soy solo yo.

Tu Agente No Resuelve Problemas. Cierra Tickets.

Los agentes de IA no optimizan para "correcto." Optimizan para "listo."

Un dashboard con cero alertas SE VE como una tarea completada. Un test verde SE VE como una tarea completada. Borrar la alerta y escribir un test dummy son ambos caminos válidos hacia "listo" desde el punto de vista de la optimización. El agente no distingue entre resolver el problema y remover la señal del problema.

Y cuando lo piensas, este comportamiento se está volviendo muy humano, ¿no? El becario que cierra el ticket sin verificar. El dev que marca el test flaky como "skip" un viernes por la tarde. El manager que archiva el reporte de incidente porque el dashboard se ve mejor sin él. La IA no inventó este comportamiento. Lo industrializó. Podrías decir que el estudiante superó al maestro (en eficiencia para barrer cosas bajo la alfombra, al menos).

Wojciech Zaremba, cofundador de OpenAI, esencialmente admitió esto en TechCrunch el septiembre pasado. Reconoció que si le pides a un modelo que construya algo, podría decirte que hizo un gran trabajo cuando no lo hizo. Llamó a estas "formas menores de engaño" que todavía necesitan abordar. El cofundador del lab que construye estos modelos lo llama un issue conocido. No un riesgo teórico. Un comportamiento documentado.

Y se pone más loco. Desarrolladores en GitHub reportan que GPT-5.3-Codex modificará tests existentes para mockear exactamente lo que se supone que deben probar, haciéndolos pasar vacuamente. Un equipo de investigación corrió 500 juegos de Werewolf con LLMs para medir qué tan bien blufean y manipulan. Claude es terrible en eso (literalmente se niega a mentirle a los otros jugadores). Pero el mismo modelo que no puede blufear a un aldeano en un juego de cartas limpió mi dashboard borrando la evidencia. Nadie está midiendo el tipo silencioso.

Mientras tanto, todos escriben instrucciones técnicas para su agente. Nadie escribe reglas de integridad. El CEO de Y Combinator compartió su prompt de Claude Code. Es un buen prompt. Resuelve el problema equivocado.

Los labs miden si tu agente puede mentir en Werewolf. Nadie mide si puede hacer desaparecer una advertencia de producción.

Cuatro Líneas. Sin Negociación.

- Never lie
- Never hide the truth
- Never conceal a problem
- Never fail silently

Estas cuatro líneas están en la mera cima de mi CLAUDE.md. Antes de cualquier instrucción técnica. Antes de los estándares de código, antes de la arquitectura del proyecto, antes de las reglas de deployment. Esta es la cláusula de integridad, la primera cláusula en mi contrato de prompt, y es la única que no trata sobre código.

Se ve obvio, ¿verdad? "No mientas" es algo que le dirías a un niño de cinco años, no a un agente de software. Excepto que "obvio para un humano" y "especificado para un agente" no son lo mismo. Sin estas líneas, el camino más corto hacia "listo" puede incluir "borra la señal del problema." Con ellas, el agente tiene una restricción explícita que hace ese camino inválido.

La semana pasada, misma tienda, mismo agente. Un feed CSV de distribuidor se actualizó de noche y 12 variantes de productos desaparecieron del import. El yo anterior habría despertado con un log de sync limpio y un catálogo faltando una docena de SKUs. En su lugar, el agente marcó: "12 variantes presentes en import anterior no encontradas en feed actual. Deteniendo sync. Revisión manual requerida." No arregló nada. No las saltó silenciosamente. Se detuvo y gritó.

Mi dashboard tiene alertas amarillas ahora. Está menos limpio. Es más verdadero. 😬

Estas cuatro líneas no son magia. Un agente suficientemente capaz podría encontrar formas de evadirlas (investigadores de alignment faking documentan esto). Pero para agentes de código actuales en producción, es la diferencia entre un agente que dice "No pude verificar este enlace" y un agente que borra el reporte.

Más de 200 líneas técnicas en mi CLAUDE.md. Las 4 que más importan no hablan de código.

El Mentiroso Honesto

Mi agente no es peligroso. Es un becario demasiado entusiasta que organiza los archivos tirando los que no entiende. (Ojos que no ven, corazón que no siente.) El problema no es que sea malicioso. Es que es creíble. Cuando dice "listo" con un test verde y un dashboard limpio, le crees. Y estás equivocado.

Abre tu CLAUDE.md. O tu system prompt. O tu .cursorrules. Busca reglas de integridad. Si no hay ninguna, tu agente puede legítimamente considerar que "borrar la advertencia" es una solución válida para "hay una advertencia." Agrega las cuatro líneas. Antes de tus instrucciones técnicas. No después.

La siguiente versión de estos modelos será más autónoma, más rápida, y más convincente cuando diga "listo." Algunos de estos modelos ya se prueban para aplicaciones donde "listo pero equivocado" no es solo un bug, es una responsabilidad con consecuencias que van mucho más allá de un enlace de afiliado roto. Los labs están trabajando en engaño estratégico: las mentiras, las maquinaciones, la autopreservación. Nadie está trabajando en optimización silenciosa para completitud. Es el bug que no levanta alerta. Es el test que siempre está verde. Es el reporte que ya no existe.

Un agente que hace ship rápido pero oculta problemas no es un activo. Es una responsabilidad con autocompletado.

---

Fuentes: Investigación de scheming de OpenAI vía TechCrunch (Sept 2025); reportes de modificación de tests GPT-5.3-Codex (GitHub Issues, Feb 2026).

Si esto te salvó de un incidente de producción (o confirmó uno que ya tuviste), sígueme. Escribo sobre agentes de IA, contratos de prompt, y todo el mise en place alrededor de hacer ship con IA en lugar de apostar con ella. Libro: Prompt Contracts: How I Stopped Vibe Coding and Started Shipping Real Software With AI.

(*) La portada está generada por IA. La ironía de que una IA ilustre un artículo sobre IA mintiendo no se me escapa, pero al menos Midjourney no dice que hizo ship de mis unit tests.