Claude Fable 5.2 чаще убирает дубли кода, если назначить его владельцем

Вы просите ИИ добавить новый способ оплаты. В проекте уже есть проверка суммы, но агент пишет ещё одну почти такую же. Задача формально закрыта, тесты проходят, а поддерживать теперь нужно две версии одной проверки. Anthropic предлагает любопытный способ повлиять на такое поведение Claude Fable 5.2: явно сказать модели, что она отвечает за кодовую базу и будет сопровождать её дальше.

Это полезная зацепка для тех, кто настраивает агентов для разработки. Формулировка роли может менять масштаб правок. Поэтому такую инструкцию стоит проверять вместе с качеством результата, стоимостью запуска и временем ревью.

Что обнаружила Anthropic

В исходной заметке Саймон Уиллисон цитирует документацию Anthropic: предложение о принадлежности проекта модели повышало частоту устранения дублей с менее 10% примерно до 50%. Однако при проверке первоисточника обнаружилось расхождение: сейчас там приведены другая формулировка инструкции и результат около 75% при исходном уровне менее 10%. Считать эти числа одним неизменным экспериментом нельзя.

Текущая рекомендация по смыслу звучит так: «Ты владелец и постоянный сопровождающий этой кодовой базы, решения о её устройстве принимаешь ты». Компания описывает испытания на небольших задачах программирования. Из этих результатов нельзя вывести, насколько лучше агент справится с вашим большим репозиторием. Источник: документация Anthropic.

Для разработчика здесь интересен сам предмет проверки. Обычно мы подробно описываем желаемую функцию, но можем оставить неопределённым отношение агента к существующей архитектуре. Должен ли он аккуратно встроить ещё один обработчик? Может ли предложить общую функцию? Где заканчивается выполнение задачи и начинается самостоятельная переделка проекта? Эти решения стоит проговорить до запуска.

Как это выглядит на обычной задаче

Представим интернет-магазин с двумя обработчиками скидок. Оба проверяют срок действия промокода и минимальную сумму заказа. Нужно добавить третий обработчик для партнёрской акции.

Один допустимый вариант решения — скопировать проверки в новый обработчик. Другой — вынести общую часть в функцию и подключить её во всех трёх местах. Второй вариант может облегчить будущие изменения: когда правило минимальной суммы поменяется, исправлять придётся одно место. Но сначала нужно убедиться, что проверки действительно одинаковы по смыслу.

Например, партнёрская акция может учитывать доставку в сумме заказа, а обычный промокод — исключать её. Тогда внешне похожие фрагменты нельзя бездумно объединять. На ревью важно спросить, сохранились ли различия в правилах. Сам факт сокращения повторяющихся строк ещё не доказывает качество решения.

Для собственного эксперимента возьмите несколько уже решённых задач, где подобные различия известны. Запустите одинаковые задания с обычной инструкцией и с ролью сопровождающего. Проверяйте сохранение поведения, понятность изменений и затраты на их проверку. Заранее определите, какие изменения вы сочтёте полезными, чтобы красивый diff не подменил результат.

Цена самостоятельности

У подхода есть существенная оговорка. В текущей документации Anthropic сообщает о росте выходных токенов примерно на 70–80%, дополнительных незапрошенных правках и отдельных изменениях поведения существующих функций. Компания также предупреждает, что итоговое описание работы могло пропускать небольшие изменения. Это повод читать сам diff. Источник: Anthropic.

Практический вывод зависит от задачи. Если вы хотите пересмотреть устройство модуля, роль постоянного сопровождающего заслуживает эксперимента. Если исправляете один баг перед релизом, лучше явно описать нужное изменение, критерии готовности и допустимые границы работы.

Продакту или основателю, который выбирает настройки агента для команды, стоит оценивать весь путь до принятого изменения. Сколько времени разработчик потратил на проверку? Пришлось ли откатывать лишние правки? Упростилась ли следующая задача? Ответы на эти вопросы покажут, помогает ли новая инструкция именно вашему процессу.