El titular que va a circular hoy es que una IA ha demostrado el Último Teorema de Fermat. No es cierto, y conviene decirlo antes de nada: el teorema lo demostraron Andrew Wiles y Richard Taylor hace treinta años. Lo que Claude ha hecho es traducir esa demostración a un lenguaje que una máquina puede comprobar línea por línea. Es un trabajo enorme y es una noticia de verdad, pero no es la noticia que cuenta el titular.
Y aun así llevo todo el día dándole vueltas a este anuncio, porque lo importante no está en el resultado matemático. Está enterrado en la letra pequeña del propio post de Anthropic, en la parte donde explican qué falló antes de que funcionara. Mi postura es esta: lo que desbloqueó once días de trabajo autónomo no fue un modelo más listo, fue tener enfrente un juez que no negocia. Y esa distinción cambia por completo qué debería hacer mañana cualquiera que esté encadenando agentes para trabajos largos.
Los primeros intentos no fallaron por matemáticas
Este es el dato que me parece más valioso de todo el anuncio, y es el que nadie va a tuitear. Los intentos iniciales de formalización no se atascaron porque al modelo le faltara nivel matemático. Se atascaron porque los agentes perdían el hilo del estado del proyecto: qué estaba ya probado, qué quedaba pendiente, qué lema dependía de cuál, qué rama había que abandonar. El fallo no era de razonamiento, era de contabilidad.
Lo que arregló eso fue infraestructura. Prove2Me, el sistema que coordina a varios agentes trabajando en paralelo y les mantiene el mapa de la demostración: el árbol de objetivos, lo que ya está cerrado, lo que sigue abierto. Con esa capa por debajo, el mismo tipo de modelo pasó de perderse a sostener once días de trabajo mayoritariamente autónomo, 13 millones de líneas de Lean y 30.300 teoremas intermedios demostrados, de los cuales 29.500 acabaron formando parte de la prueba final.
Si esto te suena, es porque es exactamente la pared contra la que choca cualquiera que monte un flujo largo con Claude Code y n8n. El modelo aguanta perfectamente el razonamiento de cada paso. Lo que se rompe es la memoria compartida entre pasos: el nodo siete no sabe qué decidió el nodo tres, el subagente no sabe que otro subagente ya tocó ese archivo, y a la vuelta de veinte minutos tienes dos ramas de trabajo que se contradicen. No es un problema de inteligencia. Es un problema de estado, y se resuelve con arquitectura, no cambiando de modelo.
Lean no negocia, y ahí está la trampa
Ahora la segunda mitad, que es la incómoda. Todo esto funcionó por una razón muy concreta: existía un verificador externo, objetivo y barato de ejecutar. El kernel de Lean acepta una prueba o no la acepta. No tiene un mal día, no se deja convencer por un argumento bien redactado, no aprueba algo porque suene razonable. Es un juez binario, instantáneo y disponible las veinticuatro horas.
Por eso Claude pudo quemar unos 6.000 millones de tokens de salida sin que un humano revisara el camino. Cada intento fallido se detectaba solo, en segundos, y el agente volvía atrás. La supervisión humana existió —el trabajo lo dirigió Tianyi Peng y lo revisó Kevin Buzzard, que mantiene el proyecto FLT en el Imperial College London—, pero no estaba en el bucle de cada iteración. Estaba en el diseño y en la revisión final.
La autonomía de un agente no la fija lo listo que sea el modelo. La fija la calidad del juez que tiene enfrente.
Quítale el kernel a esa historia y no queda nada. Un agente iterando seis mil millones de tokens sin verificador no es autonomía, es un generador de trabajo pendiente de revisión. Y revisar trece millones de líneas de cualquier cosa a mano no lo hace nadie.
En un pipeline de WordPress no hay kernel, hay un cliente
Aquí es donde esto me toca directamente, y donde creo que la mayoría de la cobertura de hoy se equivoca de conclusión. Cuando yo dejo un flujo publicando contenido en WordPress desde n8n, no tengo ningún kernel que me diga que el resultado está mal. Tengo un cliente que abre el portal el lunes. Ese es mi verificador: humano, lento, caro y con opinión.
Por eso mis flujos aguantan bien diez minutos y regular una hora. No porque el modelo se canse, sino porque el error no tiene forma de salir a la superficie hasta que ya está publicado. Cada paso sin comprobación automática es un paso donde el agente puede desviarse y seguir corriendo tan convencido como antes. La deriva no se detecta: se acumula.
Y eso cambia la pregunta que llevo meses oyendo en presupuestos y en conversaciones de clientes. La pregunta no es ¿cuándo podrá Claude hacer mi proyecto entero solo?. La pregunta útil, la que sí tiene respuesta hoy, es qué parte de mi trabajo puedo convertir en algo que una máquina sepa comprobar sin mí. Cada trozo que consigas mover a esa columna es un trozo donde el agente puede correr solo. El resto seguirá necesitando que estés delante, por muy bueno que sea el modelo del año que viene.
🔍 Tu lista de verificadores, hoy
Antes de dejar un agente corriendo más de una hora, comprueba qué tiene enfrente que le diga que algo está mal sin ti: tests que se ejecuten solos y fallen de verdad, un linter y un formateador con reglas estrictas, validación de esquema en las respuestas del modelo, un entorno de staging que reviente si el build no compila, y una comprobación de enlaces rotos y campos obligatorios antes de publicar. Si la respuesta a todo eso es que no hay nada, tu agente no es autónomo: es un borrador rápido con la revisión pendiente.
Once días de cómputo para un teorema ya demostrado
Toca también el matiz honesto, porque me irrita la extrapolación fácil en la dirección contraria. Esto no es barato ni es rápido. Once días de trabajo y del orden de seis mil millones de tokens de salida para formalizar una demostración que ya existía desde los años noventa es una cifra que conviene mirar de frente antes de sacar conclusiones alegres sobre el coste de la autonomía.
Hay un detalle más que merece la pena registrar: el modelo que hizo el trabajo no fue Fable 5.1, sino un modelo interno de investigación que Anthropic describe como aproximadamente comparable. Es decir, esto no es algo que puedas reproducir mañana con tu suscripción. Lo cual, curiosamente, refuerza mi tesis en lugar de debilitarla: si ni con un modelo de ese nivel y un dominio perfectamente verificable la cosa salió a la primera, la idea de que el próximo salto de capacidades va a resolver por sí solo la autonomía de tus flujos es, como mínimo, optimista.
Lo que yo voy a cambiar esta semana
Voy a dejar de medir mis automatizaciones por lo listo que es el modelo que las mueve y a medirlas por otra cosa: cuánto tarda un error en hacerse visible sin que yo mire. En los flujos donde ese número es de segundos, puedo alargar la correa. En los que ese número es hasta que lo vea el cliente, el agente no se queda solo, por mucho que la demo funcione.
Formalizar Fermat en Lean es una proeza de ingeniería que merece el titular que se ha ganado, no el que le están poniendo. Pero la lección práctica que deja no va de matemáticas ni de modelos frontera. Va de que llevamos dos años pidiendo agentes más inteligentes cuando lo que nos falta son jueces automáticos. Anthropic tuvo el suyo prácticamente gratis, cortesía de décadas de trabajo sobre asistentes de demostración. Nosotros tenemos que construírnoslo, y esa parte no la escribe Claude por nosotros.
Así que la pregunta con la que cierro, y que te dejo a ti: ¿qué verificador automático le falta hoy a tu stack para que puedas irte a comer dejando un agente trabajando? Si tienes la respuesta clara, ya sabes cuál es tu siguiente tarea. Si no la tienes, esa es exactamente la tarea.
