Anthropic: si dices que el código es de la IA, lo ordena

La instrucción que cambia el resultado

En las pruebas que hizo Anthropic, decirle a Fable 5.2 que la base de código es suya hizo que el modelo fusionara el código duplicado en cerca de la mitad de los intentos. Sin esa frase, lo hizo en menos de uno de cada diez. La diferencia no está en si la petición funciona o no —según la propia compañía, funcionaba en ambos casos—, sino en cuánto trabajo de limpieza le queda al humano que revisa el diff.

Para un equipo de dos o tres personas con un producto en producción, ese detalle se paga en el sprint siguiente: cada bloque de código repetido que el agente deja pasar es una decisión de arquitectura que alguien tendrá que tomar más adelante, con menos contexto y más prisa.

La recomendación está en la guía que Anthropic publicó para sacarle partido al modelo. El detalle lo destacó Simon Willison y lo recoge Xataka: el comportamiento de Fable 5.2 cambia según de quién crea que es el código que está tocando.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué hace Fable 5.2 cuando no sabe de quién es el código?

El comportamiento por defecto tiene dos manías documentadas. La primera: si no sabe a quién pertenece la base de código, añade código nuevo al que ya existe aunque se repita. La segunda: avisa de los problemas que detecta en lugar de arreglarlos.

Traducido a la práctica, el agente se comporta como un contratista al que nadie le explicó el alcance del trabajo. Cumple con lo pedido y deja el resto anotado, pero no toca nada que no le corresponda. El resultado es un repositorio que crece en líneas y no en orden, y una lista de pendientes que el equipo humano arrastra de release en release.

¿Qué recomienda Anthropic, exactamente?

La guía de Anthropic describe el contraste en sus propias palabras: «Cuando el prompt dice que la base de código es del propio modelo, este a menudo fusiona el código repetido y hace correcciones relacionadas sin que se lo pidan».

Y la instrucción concreta que recomienda es igual de directa: «Si quieres que el modelo mejore la estructura mientras trabaja, di que el código es suyo».

No hay que confundir esto con un truco de redacción. Lo que cambia es el marco de responsabilidad que el modelo recibe antes de empezar a escribir. Si el código es de otro, el agente se limita a ejecutar la orden. Si el código es suyo, se hace cargo del estado general del proyecto.

¿Es magia o es contexto?

Anthropic probó la frase en tareas de programación pequeñas, y ahí está el matiz que conviene no perder de vista: las peticiones solían funcionar en ambos casos. La instrucción no arregla un prompt mal escrito, no compensa un repositorio sin tests y no convierte un agente mediocre en un arquitecto de software.

Lo que hace es inclinar la balanza hacia el orden cuando el modelo tiene margen para decidir. Es una palanca, no un interruptor. Y como toda palanca, sirve más cuanto mejor sea el resto del proceso alrededor.

¿Cuándo es mejor NO usar la instrucción?

La propia Anthropic pone el límite: recomienda no usar la frase cuando lo que se quiere es que el modelo toque el código lo menos posible. Tiene sentido. Un agente al que le das permiso de reordenar es un agente que puede cambiar cosas que nadie le pidió.

Hay al menos tres situaciones donde ese permiso juega en contra:

Auditoría o revisión de código legado. Si el objetivo es entender qué hace el sistema antes de modificarlo, un agente que refactoriza mientras lee destruye la evidencia que se quería analizar.
Un hotfix en producción. El alcance debe ser mínimo y el diff, legible línea por línea. Cualquier reordenamiento no solicitado convierte una corrección de diez minutos en una revisión de dos horas.
Código sin cobertura de tests. Si no hay red de seguridad, los cambios «relacionados» que el modelo decida hacer son riesgo puro, por bien intencionados que sean.

Qué significa esto para tu startup

Uno: trata la instrucción como parte de la configuración del proyecto, no como una frase suelta. Si tu equipo usa un agente de código de forma recurrente, lo lógico es que el contexto base del repositorio declare de quién es el código según el tipo de tarea. Una formulación de trabajo podría ser: «Esta base de código es tuya. Si encuentras duplicación, fusiónala y corrige lo que veas directamente relacionado». Es tu redacción, no la de Anthropic, pero captura la idea que la guía describe.

Dos: separa los tipos de tarea antes de escribir el prompt. Refactor no es lo mismo que auditoría, y auditoría no es lo mismo que un parche urgente. Si el equipo usa la misma instrucción para las tres cosas, va a obtener el comportamiento de una sola de ellas. Definir dos o tres plantillas de contexto distintas cuesta una tarde y ahorra discusiones en cada revisión.

Tres: revisa el diff con la expectativa correcta. Si activas la instrucción, el modelo probablemente toque más archivos de los que pediste. Eso no es un error: es el comportamiento que fuiste a buscar. La contrapartida es que el diff se lee completo, no por encima, y que los tests corren antes del merge y no después.

Cuatro: no lo dejes solo en manos de quien programa. El uso de agentes se está corriendo hacia perfiles no técnicos, y la calidad del resultado depende cada vez más del contexto que recibe el modelo y cada vez menos de quién escribe la instrucción. Ese es un trabajo de criterio, no de sintaxis.

¿Por qué esto importa más allá del código?

El hallazgo llega en un momento en que los agentes dejan de ser una herramienta de desarrolladores. Un análisis de Anthropic sobre 1,2 millones de sesiones de Cowork en más de 600.000 organizaciones, citado por TechCrunch, mostró que el desarrollo de software representó solo el 8,7% del uso del agente. La categoría más grande, con un 33,4%, fue la operación de procesos de negocio: consolidar actualizaciones dispersas en un informe, armar checklists de onboarding, conciliar hojas de cálculo.

El mismo artículo de TechCrunch señala que OpenAI ha empujado Codex, que nació como herramienta de desarrollo, hacia usos no técnicos como informes, presentaciones y análisis de datos. La consecuencia es clara: la instrucción de Anthropic aplica a cualquier trabajo donde el agente herede un artefacto que ya existe —una hoja de cálculo, un documento, un pipeline— y donde la diferencia entre «añadir otra versión» y «ordenar lo que hay» define si el resultado sirve o hay que rehacerlo.

Conclusión

La lección del caso Fable 5.2 no es que exista una frase mágica. Es que el modelo responde al alcance que le das, y que ese alcance se declara, no se supone. Decirle a la IA que el código es suyo mejora la estructura en tareas donde el orden importa; callarlo es lo correcto cuando el objetivo es que no toque nada de más.

Para un founder, la decisión práctica es pequeña y barata: define por escrito cuándo el agente hereda el proyecto y cuándo solo ejecuta una orden. Es la misma discusión de siempre sobre alcance y responsabilidad, aplicada a un colaborador que no pregunta dos veces.