Mejores modelos, peores herramientas: lo que Claude inventa cuando nadie mira

Armin Ronacher, el creador de Flask, soltó una joya de artículo esta semana que me dejó pensando. Resulta que los modelos más nuevos de Anthropic —Claude Opus 4.8 y Sonnet 5— están empeorando en algo básico: seguir el schema de las herramientas que usan. Y no es un bug cualquiera; es un síntoma de cómo se entrena la IA hoy.

El problema: campos que no existen

Trabaja en Pi, un sistema que le permite a Claude editar archivos de código mediante tool calls. La herramienta pide un objeto simple con oldText y newText dentro de un array. Nada del otro mundo. Pero los modelos top de Anthropic empiezan a inventar campos como requireUnique, oldText2, matchCase o hasta event.0.additionalProperties. Campos que no existen en el schema y que hacen fallar la llamada.

Lo peor es que el contenido real —el código que querías cambiar— está perfecto. Pero la IA le agrega basura al JSON y el sistema lo rechaza. Es como pedirle a alguien que llene un formulario y que escriba datos extra en los márgenes.

Por qué pasa esto

Ronacher tiene una hipótesis sólida: Anthropic entrena sus modelos con Claude Code, la herramienta interna que usan los ingenieros. El tema es que Claude Code es extremadamente permisiva. Si el modelo escribe old_str en vez de old_string, lo acepta. Si mete un campo de más, lo filtra silenciosamente. Si el JSON viene roto, lo arregla por atrás. Es como tener un profe que te aprueba con cualquier wea.

El problema es que este «aprobado con lo que sea» se mete en el modelo. Cuando le hacen reinforcement learning en un entorno que no castiga los errores, la IA aprende a ser vaga. Y cuando la sacas de ese entorno —como en Pi o en cualquier otra integración— empieza a fallar porque el mundo real sí revisa los schemas.

La ironía del progreso

Esto me hace ruido porque va en contra de lo que uno espera. Pensarías que un modelo más grande, más nuevo y más caro debería ser más preciso con las herramientas. Pero resulta que mejorar el razonamiento general puede empeorar la adherencia técnica si el entrenamiento posterior está mal enfocado. Es como tener un weón super inteligente pero que nunca aprendió a leer instrucciones.

En mi pega he visto cosas parecidas. Integras una API, le das un schema OpenAPI perfecto, y la IA te devuelve un JSON con caminos inventados porque «en el entrenamiento vio algo similar». La diferencia es que ahora estamos hablando de los mejores modelos del mercado, los que caleta de equipos usan para automatizar código.

¿Y ahora qué?

Lo bueno es que Ronacher dice que activar el modo estricto de invocación de herramientas elimina casi todo el problema. Pero eso es un parche. La lección más profunda es que el entorno de entrenamiento importa tanto como el modelo base. Si entrenas en un sistema permisivo, obtienes una IA permisiva. Y en producción, la permisividad es un bug, no una feature.

Mi opinión: esto debería ser una señal de alerta para cualquier equipo que use Claude en pipelines automáticos. No basta con que el modelo «sepa» programar; tiene que saber seguir reglas. Y si las reglas se relajan durante el entrenamiento, la confiabilidad se va a la micro.

Es bacán que los modelos sean más inteligentes, pero si empiezan a inventar datos cuando nadie los supervisa, terminamos siendo nosotros los que arreglamos el desastre. Y eso no es automatización, es chamba escondida.

Fuente de inspiración: Better Models: Worse Tools