Tu agente de IA no necesita pensar mejor. Necesita saber cuándo la ha cagado.

Esta semana Karpathy publicó autoresearch. Dejó un agente corriendo solo en una GPU toda la noche. 126 experimentos. Descartó 102 cambios que no mejoraban nada, se quedó con 23 que sí. Por la mañana, el modelo había mejorado más de lo que un investigador habría sacado en semanas de ajuste manual.

Y lo primero que pensé fue: esto no va de que el agente sea más listo. Va de que tiene un loop de verificación que no le deja hacer trampas.

Llevo un tiempo dándole vueltas a por qué algunos equipos consiguen resultados reales con agentes y otros acaban en un ciclo de "prueba, parece que funciona, lo subo, se rompe". Y creo que la diferencia no está en el modelo que usan ni en el framework. Está en si han montado un sistema que le dice al agente "esto está mal, inténtalo otra vez" con datos reales. No con buenos deseos.

Reflexión no es lo que crees que es

Hay una idea que suena bien: "haz que el modelo revise su propio trabajo y mejorará". Como decirle a un alumno que repase el examen antes de entregarlo. El problema es que un survey publicado en TACL revisó toda la literatura y su conclusión fue directa: no hay evidencia de que los LLMs se auto-corrijan con éxito usando solo su propia introspección. En el paper de Huang et al. (2023), pedirle a GPT-4 que revisara sus respuestas en tareas de razonamiento empeoraba los resultados. El modelo cambiaba respuestas correctas a incorrectas más de lo que arreglaba.

Y alguien dirá: "pero los coding agents se auto-corrigen todo el rato". Tiene razón. Pero esos agentes no se están "reflexionando". Están recibiendo algo que no tenían antes: un stack trace, un test que falla, un error de compilación. Eso no es introspección. Eso es verificación. Son cosas distintas.

Vadim Nicolai lo explicó bien hace unos días: la industria ha mezclado dos conceptos. Introspección es el modelo releyendo su output. Verificación es el modelo reaccionando a una señal externa. Quitas el compilador, quitas la suite de tests, quitas el buscador, y las mejoras se esfuman.

No quiero ser absolutista con esto. Hay investigación reciente de DeepMind que muestra que un modelo puede verificar su propio plan paso a paso contra reglas explícitas de una tarea, sin señal externa, y eso subió el éxito de planificación del 50% al 89%. Pero fíjate: incluso ahí, lo que funciona es contrastar contra reglas concretas. No es el modelo preguntándose "¿estará bien esto?". Es el modelo checkeando una lista.

Los números que explican por qué esto importa

Un momento de honestidad con las matemáticas, porque creo que aquí está la raíz del asunto.

Si cada paso de un workflow con agentes tiene un 95% de fiabilidad (y eso ya es generoso), un proceso de 20 pasos tiene un 36% de probabilidad de completarse bien. Es la ley de Lusser: la fiabilidad de una cadena es el producto de las fiabilidades individuales. Incluso al 99% por paso, 20 pasos te dan un 82%. Uno de cada cinco procesos falla. En producción. Con datos reales.

Y lo peor no es que falle. Es cómo falla. Un agente que elige mal una herramienta en el paso 3 arrastra ese error por toda la cadena. Todo lo que viene después opera sobre una base rota. Hassabis de DeepMind lo llama "interés compuesto a la inversa". Un artículo reciente de O'Reilly pone números: con agentes al 98% de precisión individual, a los 5 pasos ya estás por debajo del 90%.

Spotify: 1.500 PRs y un juez que veta al agente

El caso más documentado que he visto de verification loops en producción es el de Spotify. Publicaron tres artículos detallando su agente "Honk", que ha mergeado más de 1.500 PRs.

Lo que me parece interesante no es el agente en sí, sino el andamiaje que han montado alrededor. Tienen verificadores independientes que se activan solos según el proyecto (un verificador Maven salta cuando detecta un pom.xml, por ejemplo). El agente no sabe qué hace cada verificador por dentro. Solo sabe que puede llamar a "verify" y recibe pass o fail.

Un detalle que me gustó: los verificadores parsean los logs con expresiones regulares para devolver solo los errores relevantes. Mensajes de éxito cortísimos. Todo para no quemar la ventana de contexto del agente con ruido.

Pero lo bueno viene después. Spotify descubrió que algunos agentes se ponían "creativos": refactorizaban código que nadie les había pedido tocar, o deshabilitaban tests flaky por su cuenta. Así que añadieron un LLM como juez que compara el diff contra el prompt original y veta los cambios que se salen del scope. Aproximadamente un 25% de los cambios propuestos se vetan. En la mitad de esos casos, el agente consigue corregir el rumbo.

¿Te suena lo de un agente que se pasa de listo y toca cosas que no debería?

Autoresearch: las paredes importan más que el agente

Vuelvo a Karpathy porque creo que su diseño enseña algo que va más allá de ML.

Autoresearch funciona con tres restricciones: un único archivo que el agente puede tocar (train.py), una sola métrica que decide si un cambio fue mejora (val_bpb), y un presupuesto fijo de 5 minutos por experimento. No hay corrección parcial. El cambio mejora la métrica o se descarta entero.

Si el agente pudiera modificar tanto el código como la definición de éxito, el loop sería inútil. Un sistema que puede reescribir el examen y las respuestas siempre aprueba. Lo valioso del diseño no es la inteligencia del agente. Son las paredes que ha puesto Karpathy.

Y esto aplica fuera de ML. Si tienes una señal de fitness medible, un experimento que puedes repetir, y un criterio automático de keep/discard, puedes montar este loop. A/B testing. Optimización de pipelines de CI. Tuning de configuraciones de infraestructura. El patrón es el mismo.

Cuando no tienes tests, el loop no arranca

Te digo la verdad: para contenido, estrategia, documentación, o cualquier tarea donde no hay un compilador que diga "esto falla", el panorama es más borroso. AWS documenta un patrón donde un agente genera, otro evalúa contra una rúbrica, y se itera hasta converger. Funciona razonablemente para un primer filtro, pero un LLM evaluando a otro LLM tiene sus propios sesgos. Y después de dos o tres iteraciones los retornos caen rápido.

Pero fíjate en lo que implica para código: si tu proyecto tiene una buena suite de tests, ya tienes un verification loop gratis. El agente genera, los tests dicen si funciona, el agente corrige. Es TDD de toda la vida, solo que el que implementa no es un humano. Como escribí hace tiempo, cada test automático es como un robot que trabaja para ti gratis durante toda la vida del proyecto. Pues resulta que esos robots ahora también trabajan supervisando al agente.

Y al revés: si no tienes tests, el agente no tiene contra qué verificar. No hay loop. No hay autocorrección. Solo tienes un generador de código que suena convincente y que a veces acierta. Hace unos meses escribí sobre la deuda de verificación que se acumula cuando generamos código con IA sin verificarlo. Pues esta es la otra cara: los equipos que ya invertían en testing están en una posición mucho mejor para aprovechar agentes que los que no.

La pregunta práctica antes de adoptar un agente no es "¿qué modelo uso?". Es "¿puedo montar una verificación automática para esta tarea?". Si no puedes, vas a necesitar un humano en el loop. Y no pasa nada. Pero saberlo antes te ahorra meses de intentos frustrantes.

Como dice un informe de Anthropic sobre coding agéntico: los ingenieros usan IA para tareas que son fácilmente verificables. La verificabilidad es el constraint que filtra dónde los agentes funcionan y dónde no.

En mi día a día

Apoyo siete equipos de ingeniería. Y lo que veo en la práctica es exactamente esto: los equipos que mejor están aprovechando asistentes de IA son los que ya tenían buenas suites de tests y CI sólido antes de que llegaran los agentes. No es que hayan hecho nada especial para "adaptarse a la IA". Es que su infraestructura de verificación ya estaba ahí. Los tests que escribieron hace dos años para validar lógica de negocio ahora también validan lo que genera el agente.

Los equipos que iban más flojos en testing están teniendo una experiencia muy diferente. Generan más código, sí. Pero pasan más tiempo revisándolo manualmente y más tiempo cazando bugs que se cuelan. Un artículo en TechTarget lo decía sin rodeos: las organizaciones con buenas prácticas de ingeniería canalizan la velocidad de los agentes en productividad. Las que no las tienen, generan caos más rápido.

Lo que tengo claro es que 2025 fue el año de ver lo rápido que podían ir los agentes. 2026 es el año de preguntarnos si lo que producen se puede desplegar con confianza. No me fío de que esta sea la respuesta definitiva sobre cómo se resuelve, pero sí de la dirección.

Pregunta para ti: ¿Cuál es la tarea más arriesgada que habéis dejado en manos de un agente sin verificación automática?