Claude Fable 5.2 elimina código duplicado con más frecuencia si se le asigna la responsabilidad del proyecto

Le pides a una IA que añada un nuevo método de pago. El proyecto ya tiene una validación del importe, pero el agente escribe otra casi idéntica. Formalmente, la tarea está terminada, las pruebas pasan y ahora hay que mantener dos versiones de la misma validación. Anthropic propone una forma curiosa de influir en este comportamiento de Claude Fable 5.2: decirle explícitamente al modelo que es responsable del código base y que seguirá encargándose de su mantenimiento.

Es una pista útil para quienes configuran agentes de desarrollo. La forma de definir el rol puede cambiar el alcance de las modificaciones. Por eso, conviene evaluar esta instrucción junto con la calidad del resultado, el coste de la ejecución y el tiempo de revisión.

Qué descubrió Anthropic

En la publicación original, Simon Willison cita la documentación de Anthropic: una frase que atribuía al modelo la propiedad del proyecto elevaba la frecuencia de eliminación de código duplicado de menos del 10% a aproximadamente el 50%. Sin embargo, al consultar la fuente original apareció una discrepancia: ahora incluye una instrucción redactada de otra manera y un resultado de alrededor del 75%, frente a un nivel inicial inferior al 10%. No se pueden tratar estas cifras como si correspondieran a un único experimento sin cambios.

La recomendación actual viene a decir: «Eres el propietario y el responsable del mantenimiento de este código base a largo plazo; tú decides cómo se estructura». La empresa describe pruebas con tareas pequeñas de programación. Estos resultados no permiten deducir cuánto mejor rendirá el agente en tu repositorio de gran tamaño. Fuente: documentación de Anthropic.

Para un desarrollador, lo interesante es la propia cuestión que se está poniendo a prueba. Solemos describir con detalle la funcionalidad que queremos, pero podemos dejar sin definir la relación del agente con la arquitectura existente. ¿Debe integrar cuidadosamente un controlador más? ¿Puede proponer una función compartida? ¿Dónde termina la ejecución de la tarea y empieza una remodelación del proyecto por iniciativa propia? Conviene aclarar estas decisiones antes de iniciar la ejecución.

Cómo se ve en una tarea habitual

Imaginemos una tienda en línea con dos controladores de descuentos. Ambos comprueban la fecha de caducidad del código promocional y el importe mínimo del pedido. Hay que añadir un tercer controlador para una promoción de un socio comercial.

Una solución aceptable consiste en copiar las comprobaciones en el nuevo controlador. Otra es extraer la parte común a una función y utilizarla en los tres lugares. La segunda opción puede facilitar los cambios futuros: cuando cambie la regla del importe mínimo, solo habrá que modificar un punto. Pero antes hay que asegurarse de que las comprobaciones realmente tienen el mismo significado.

Por ejemplo, la promoción del socio puede incluir los gastos de envío en el importe del pedido, mientras que un código promocional normal los excluye. En ese caso, no se deben unificar sin más fragmentos que solo se parecen a simple vista. Durante la revisión, es importante comprobar si se han conservado las diferencias entre las reglas. Reducir las líneas repetidas no demuestra, por sí solo, la calidad de la solución.

Para hacer tu propio experimento, elige varias tareas ya resueltas en las que se conozcan este tipo de diferencias. Ejecuta los mismos encargos con una instrucción habitual y con el rol de responsable de mantenimiento. Comprueba que se conserva el comportamiento, que los cambios se entienden y cuánto cuesta revisarlos. Define de antemano qué cambios considerarás útiles, para que un diff atractivo no sustituya al resultado.

El precio de la autonomía

Este enfoque tiene una salvedad importante. En su documentación actual, Anthropic informa de un aumento de los tokens de salida de aproximadamente un 70–80%, modificaciones adicionales no solicitadas y algunos cambios en el comportamiento de funciones existentes. La empresa también advierte de que el resumen final del trabajo podía omitir cambios pequeños. Es un motivo para leer el propio diff. Fuente: Anthropic.

La conclusión práctica depende de la tarea. Si quieres replantear la estructura de un módulo, merece la pena experimentar con el rol de responsable de mantenimiento a largo plazo. Si estás corrigiendo un único error antes de un lanzamiento, es mejor describir explícitamente el cambio necesario, los criterios de aceptación y los límites permitidos del trabajo.

Un responsable de producto o un fundador que elija la configuración del agente para su equipo debería evaluar todo el proceso hasta la aceptación del cambio. ¿Cuánto tiempo dedicó el desarrollador a revisarlo? ¿Hubo que revertir modificaciones innecesarias? ¿Resultó más sencilla la siguiente tarea? Las respuestas mostrarán si la nueva instrucción ayuda a tu proceso concreto.