# Claude Fable 5.2 рефакторит в 5 раз чаще, если назвать код его собственным
Каноническая страница: https://plainews.ru/posts/claude-fable-code-ownership
Опубликовано: 2026-11-10T07:02:04.003Z

Один абзац о владении кодом помог Claude Fable 5.2 чаще объединять дубли в тестах Anthropic. Разбираем промпт, проверку и риски.
Anthropic проверила Claude Fable 5.2 на небольших задачах по программированию и обнаружила неожиданную зависимость: формулировка о владении репозиторием влияет на то, будет ли модель улучшать структуру кода. Когда промпт не говорил о владельце проекта, модель обычно дописывала код в существующую архитектуру — даже если это создавало повторения.

В тестах Anthropic фраза о том, что кодовая база принадлежит модели, привела к объединению дублирующегося кода примерно в половине попыток. Без такой установки это происходило менее чем в одной десятой попыток. Для разработчика это не гарантия хорошего рефакторинга, но полезный рычаг: промпт может задавать не только задачу, но и степень ответственности за результат.

## Модель копирует структуру, когда считает репозиторий чужим

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

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

В тестах Anthropic речь идёт именно о небольших coding-задачах. Поэтому нельзя переносить результат на большой монорепозиторий, критичный production-сервис или миграцию с десятками зависимостей. Однако сам механизм полезен: прежде чем просить модель «добавить функцию», нужно решить, ожидаете вы локальный патч или улучшение устройства системы.

| Режим работы | Как описать репозиторий | Ожидаемая стратегия модели |
| --- | --- | --- |
| Локальная доработка | Код принадлежит команде, менять нужно только необходимое | Сохранить структуру и минимизировать вмешательство |
| Рефакторинг | Модель отвечает за дальнейшее развитие кодовой базы | Искать дубли и улучшать внутреннюю организацию |
| Аудит без правок | Модель анализирует чужой код и предлагает план | Описать проблемы, но не переписывать код автоматически |

В этом подходе важно разделять «право менять» и «обязанность переписать всё». Даже если вы просите Claude Fable 5.2 считать проект своим, задача не превращается в разрешение на бесконечный рефакторинг. Модели всё ещё нужны границы: что нельзя ломать, какие интерфейсы стабильны и по каким критериям оценивать готовый результат.

## Добавьте в промпт ответственность за архитектуру

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

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

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

```plain
Считай эту кодовую базу своей: ты определяешь её назначение и устройство
и продолжишь развивать её дальше.

Задача: [опишите новую функцию или исправление].

Перед изменениями:
1. Найди код, который уже решает похожую задачу.
2. Проверь, не появится ли дублирование логики.
3. Выбери структуру, которую будет проще поддерживать дальше.

Ограничения:
- не меняй [публичные API, формат данных, критичные модули];
- сохрани поведение [конкретного сценария];
- объясни, какие дубли были объединены и почему.

В ответе сначала дай краткий план, затем покажи изменения.
```

Практическая ценность шаблона — не в магической формуле про владение, а в сочетании трёх сигналов. Вы разрешаете модели принимать структурные решения, требуете проверить дублирование и явно ограничиваете область риска. Без последних двух пунктов модель может понять «это твой код» слишком широко, особенно в проекте с неочевидными зависимостями.

> **Важно.** Результат Anthropic относится к объединению повторяющегося кода в небольших задачах. Формулировка о владении не доказывает, что любое архитектурное решение Claude Fable 5.2 будет верным.

## Проверьте промпт на одной задаче, а не на всём репозитории

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

Сделайте два запуска с одинаковым описанием задачи. В первом не задавайте модели статус владельца кодовой базы. Во втором добавьте установку из предыдущего раздела и остальные одинаковые ограничения. Сравнивать нужно не красоту объяснения, а конкретный diff: какие файлы изменены, появился ли общий компонент и не изменилось ли внешнее поведение.

| Что сравнить после двух запусков | Признак полезного результата | Признак риска |
| --- | --- | --- |
| Число новых реализаций | Модель переиспользовала существующую логику | Появилась третья версия той же функции |
| Область изменений | Меняются только связанные части кода | Затронуты несвязанные модули без причины |
| Поведение системы | Существующие сценарии сохранены | Изменены контракты или форматы данных |
| Объяснение решения | Названы найденные дубли и компромиссы | Есть общие слова без связи с кодом |

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

Если Claude Fable 5.2 предлагает объединить части кода, попросите отдельно показать, что именно было одинаковым до изменения. Это снижает риск ложного обобщения: две функции могут выглядеть похожими, но различаться бизнес-правилами, обработкой ошибок или требованиями к производительности.

## Не путайте право на рефакторинг с правом ломать контракты

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

Сформулируйте инварианты — свойства, которые не должны измениться после работы модели. Это могут быть публичные имена функций, HTTP-ответы, схема базы данных, формат событий или время выполнения критичного участка. Необязательно перечислять весь проект: достаточно назвать границы конкретной задачи и попросить явно подтвердить их соблюдение.

```plain
Считай кодовую базу своей и улучши структуру там, где это нужно для задачи.

Но следующие контракты нельзя менять:
- [перечень API или функций];
- [формат входных и выходных данных];
- [обязательные сценарии].

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

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

## Где ломается подход с «собственным» кодом

Главный риск — принять экспериментальный результат за универсальное правило. Anthropic сообщила о тестах на небольших coding-задачах и измеряла частоту объединения повторов, а не качество архитектуры, скорость работы программы или отсутствие регрессий. Поэтому проверка кода остаётся обязанностью разработчика, даже если объяснение модели выглядит убедительно.

Второй риск — не дать модели контекст. Установка о владении не заменяет описание архитектуры, требований и ограничений. Если в запросе нет сведений о том, какие модули считаются стабильными, Claude Fable 5.2 может выбрать структурно аккуратное решение, несовместимое с вашей реальной дорожной картой.

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

## Что попробовать дальше

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

Если второй вариант действительно объединяет код без регрессий, закрепите удачную формулировку в шаблоне задач для команды. Если модель слишком агрессивно меняет проект, не отказывайтесь от подхода полностью: сузьте область разрешённого рефакторинга и точнее опишите неизменяемые контракты.

## FAQ

### Почему Claude Fable 5.2 начинает чаще объединять дубли?

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

### Насколько заметна разница в тестах Anthropic?

С формулировкой о владении Claude Fable 5.2 объединяла повторяющийся код примерно в половине попыток. Без неё это происходило менее чем в одной десятой попыток на небольших coding-задачах.

### Нужно ли всегда добавлять такую установку в промпт?

Нет. Для срочного исправления, точечного патча или чужого проекта безопаснее явно попросить сохранить существующую структуру и не делать широкий рефакторинг.

### Чем ограничить модель при рефакторинге?

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

## Источники

- Simon Willison: Quoting Prompting Claude Fable 5.2