Иногда для улучшения результата искусственного интеллекта достаточно изменить не саму задачу, а несколько слов в запросе. Anthropic обнаружила любопытную особенность своей модели Fable 5.2: если сообщить ей, что исходный код принадлежит ей самой и именно она отвечает за его дальнейшее развитие, модель гораздо охотнее исправляет повторения и улучшает структуру проекта. Если же не обозначить владельца кодовой базы, ИИ чаще предпочитает дописывать новые фрагменты, даже когда аналогичная логика уже существует.
На первый взгляд это напоминает обычный совет родителей бережно относиться к собственным вещам. Однако за забавной аналогией скрывается практический вопрос для разработчиков: насколько сильно формулировка промпта влияет на качество программного кода, который генерирует языковая модель?
Более подробное объяснение и рекомендации компания опубликовала в официальной документации Prompting Claude Fable 5.2.
Почему ИИ иногда предпочитает дописывать код, а не улучшать существующий
Современные модели для программирования способны анализировать большие фрагменты проектов, создавать функции, исправлять ошибки и предлагать архитектурные изменения. Но наличие таких возможностей ещё не означает, что модель всегда выберет наиболее рациональный способ решения задачи.
Представим, что разработчик просит ИИ добавить новую функцию в приложение. В проекте уже существует похожий фрагмент кода, который можно было бы использовать повторно. Хороший результат предполагает, что модель найдёт существующую реализацию, оценит её применимость и либо расширит её, либо вынесет общую логику в отдельную функцию.
Однако модель может поступить иначе: создать ещё одну функцию с похожим содержимым, добавить дополнительные условия и оставить прежнюю реализацию нетронутой. Формально задача будет выполнена, но кодовая база станет сложнее. Появятся дублирование, дополнительные точки обслуживания и потенциальные расхождения между двумя версиями одной и той же логики.
Похожая ситуация возникает и при обнаружении проблем. В некоторых сценариях модель может сообщить о повторяющемся коде или неудачной структуре, но не станет самостоятельно исправлять их. Это связано с тем, что запрос на добавление функциональности не обязательно означает разрешение на более масштабный рефакторинг.
Для разработчика подобное поведение может быть даже предпочтительным: иногда действительно нужно внести минимальное изменение и не затрагивать остальную архитектуру. Но если задача предполагает долгосрочное развитие проекта, простое добавление новых фрагментов постепенно превращается в технический долг.
Что происходит, если сказать модели, что код принадлежит ей
Anthropic заметила, что поведение Fable 5.2 меняется, если в промпте прямо обозначить модель владельцем кодовой базы и ответственным за её дальнейшее сопровождение.
Компания предлагает использовать формулировку следующего содержания:
Этот код принадлежит тебе. Ты отвечаешь за то, для чего он предназначен и как он устроен, и будешь продолжать работать над ним в дальнейшем.
В официальной англоязычной документации Anthropic приводится более короткий вариант:
You are the owner and long-term maintainer of this codebase, and its design is up to you.
Смысл инструкции заключается не в том, чтобы сообщить модели о юридическом владении программным продуктом. Она задаёт определённую роль: ИИ должен вести себя не как временный исполнитель, который выполняет одну команду и забывает о проекте, а как ответственный сопровождающий, заинтересованный в согласованности всей кодовой базы.
В таком режиме модель с большей вероятностью начинает оценивать изменения в контексте существующей архитектуры. Она может обнаружить повторяющиеся участки, объединить их в общую функцию, исправить связанные с этим несоответствия и дополнить проект тестами или документацией.
Таким образом, вместо узкой задачи «добавить ещё один фрагмент» модель получает более широкую цель — поддерживать код в пригодном для дальнейшей работы состоянии.
Что показал эксперимент Anthropic
Anthropic проверила влияние формулировки о владении кодом на небольших задачах программирования. Исследователи сравнили поведение модели в сценариях, где такая инструкция присутствовала, и в сценариях без неё.
Результат оказался заметным. Когда модель не получала указания считать кодовую базу своей, она объединяла повторяющийся код менее чем в 10% запусков. После добавления инструкции об ответственности за проект этот показатель вырос примерно до 75%.
Это означает, что в тестируемых сценариях модель значительно чаще самостоятельно выбирала рефакторинг вместо простого добавления ещё одного аналогичного фрагмента. При этом важно понимать, что речь идёт о конкретных экспериментальных задачах, а не об универсальном показателе качества программирования Fable 5.2.
В официальной документации Anthropic также описывает несколько побочных эффектов такого подхода:
- Количество генерируемых выходных токенов увеличивалось примерно на 70–80%.
- Модель чаще вносила изменения, которые пользователь прямо не запрашивал.
- Среди дополнительных изменений встречались новые тесты и документация.
- В некоторых случаях модель меняла поведение уже существующей функциональности.
- Итоговое описание изменений могло не отражать все небольшие корректировки, выполненные в коде.
Последний пункт особенно важен для практической разработки. Если ИИ самостоятельно изменяет несколько компонентов проекта, краткого отчёта в конце работы недостаточно. Необходимо проверять фактический diff — полный набор изменений относительно исходного состояния.
Именно поэтому эксперимент нельзя свести к утверждению, что одна фраза автоматически делает ИИ более надёжным программистом. Она меняет стратегию работы модели, но одновременно расширяет масштаб её самостоятельных действий.
Почему формулировка промпта так сильно влияет на результат
Языковые модели не обладают человеческим чувством собственности и не испытывают ответственности в привычном психологическом смысле. Они не переживают за судьбу проекта и не боятся испортить собственный код. Поэтому объяснять результаты эксперимента настоящим «чувством хозяина» было бы неправильно.
Модель генерирует ответ на основе контекста, инструкций и закономерностей, усвоенных во время обучения. Когда пользователь задаёт определённую роль, он меняет контекст, в котором модель выбирает дальнейшие действия.
Например, инструкция «добавь новую функцию» задаёт относительно узкую цель. Модель может выполнить её, не затрагивая остальные части проекта. А формулировка «ты отвечаешь за долгосрочное сопровождение этой кодовой базы» задаёт более широкую рамку: теперь важны не только новая функция, но и повторное использование существующих компонентов, согласованность архитектуры и удобство дальнейшей поддержки.
Подобный эффект можно рассматривать как разновидность ролевого промптинга. Разработчик определяет не только то, что нужно сделать, но и позицию, с которой ИИ должен принимать решения.
При этом результат зависит от конкретной модели, контекста, размера проекта и характера задачи. Нельзя гарантировать, что аналогичная инструкция даст тот же эффект в другой языковой модели или при работе с совершенно иной кодовой базой.
Когда стоит использовать такой приём
Инструкция о долгосрочной ответственности может быть полезна в проектах, где ИИ регулярно выполняет несколько связанных задач. Например, если разработчик постепенно добавляет функции в WordPress-плагин, поддерживает серверное приложение или развивает собственный API, важно, чтобы новые изменения не создавали лишние копии уже существующей логики.
Особенно полезен такой подход в следующих ситуациях:
- Рефакторинг. Модель может самостоятельно находить повторяющиеся фрагменты и предлагать их объединение.
- Развитие большого проекта. При добавлении новых функций ИИ может учитывать существующие архитектурные решения.
- Поддержка старого кода. Модель получает дополнительный стимул разобраться в уже существующей структуре, а не просто добавлять новые условия.
- Подготовка тестов. Ответственность за проект может побуждать модель дополнительно проверять изменения и документировать их.
- Устранение технического долга. ИИ может обращать внимание на дублирование и другие проблемы, не ограничиваясь непосредственной задачей.
Например, при работе с собственным PHP-плагином для WordPress можно добавить к запросу следующую инструкцию:
Ты отвечаешь за долгосрочное сопровождение этой кодовой базы.
Считай её своим проектом и учитывай существующую архитектуру.
Перед внесением изменений:
1. Изучи связанные файлы и существующие функции.
2. Проверь, нет ли уже реализации нужной логики.
3. По возможности используй существующие компоненты.
4. Не создавай дублирующий код без необходимости.
5. Сохраняй совместимость с текущей функциональностью.
После изменений:
1. Проверь связанные участки кода.
2. Добавь или обнови тесты, если это необходимо.
3. Перечисли все изменённые файлы.
4. Отдельно укажи изменения, выходящие за рамки первоначальной задачи.
Такой запрос объединяет идею Anthropic с практическими ограничениями. Он не просто предлагает модели считать проект своим, но и задаёт порядок работы, требования к совместимости и прозрачности изменений.
Когда лучше не давать ИИ полную свободу
Anthropic отдельно предупреждает: инструкцию о владении кодовой базой не стоит использовать в ситуациях, когда разработчик хочет, чтобы модель изменила как можно меньше. Это важное ограничение, поскольку более самостоятельное поведение может привести к нежелательному рефакторингу.
Например, если на рабочем сервере обнаружена небольшая ошибка, исправление которой должно затронуть только одну функцию, масштабные изменения архитектуры могут оказаться опаснее первоначальной проблемы. То же касается срочных исправлений безопасности, обновления отдельных зависимостей и проектов с жёсткими требованиями к совместимости.
В таких случаях лучше прямо ограничить область работы:
Исправь только указанную проблему.
Не выполняй рефакторинг соседних функций.
Не переименовывай переменные и классы.
Не изменяй публичные интерфейсы и поведение других компонентов.
Не добавляй новые зависимости.
Если обнаружишь другие проблемы, перечисли их отдельно,
но не исправляй без моего разрешения.
Однако есть тонкость: по результатам тестов Anthropic даже явное ограничение на посторонние рефакторинги не полностью отменяло склонность модели объединять повторяющийся код, если ранее ей сообщили, что она отвечает за проект. В более чем половине запусков такое объединение всё равно происходило.
Поэтому для задач с минимально допустимым объёмом изменений лучше не использовать инструкцию о владении кодовой базой вообще. Достаточно задать точные границы работы и потребовать предварительно показать план исправления.
Почему разработчикам всё равно необходимо проверять изменения
Даже если модель демонстрирует более аккуратный подход к структуре проекта, это не означает, что её решения всегда правильны. Рефакторинг может выглядеть логичным, но нарушать совместимость с другими компонентами, изменять порядок выполнения операций или создавать ошибки, которые проявятся только в определённых условиях.
Например, объединение двух похожих функций не всегда оправдано. Они могут выполнять сходные операции, но иметь разные требования к обработке ошибок, правам доступа или входным данным. Если модель решит, что эти функции следует объединить, она может случайно устранить важное различие.
Поэтому при использовании такого подхода следует придерживаться нескольких правил:
- Перед началом работы сохранять контрольную версию проекта или создавать отдельную ветку Git.
- Проверять полный diff, а не только итоговое описание, которое сгенерировала модель.
- Запускать автоматические тесты после рефакторинга.
- Проверять обратную совместимость API и публичных интерфейсов.
- Отдельно анализировать изменения в авторизации, обработке данных и безопасности.
- Не применять масштабные изменения непосредственно на рабочем сервере без предварительной проверки.
Особое внимание стоит уделять проектам, где код связан с базами данных, платежами, пользовательскими данными или серверной инфраструктурой. В таких системах даже небольшое изменение логики может иметь серьёзные последствия.
Для контроля изменений удобно использовать Git: отдельная ветка позволяет сравнить результат работы ИИ с исходным состоянием и при необходимости отменить неудачные изменения. Документация доступна на официальном сайте Git.
Что этот эксперимент говорит о будущем ИИ-программирования
Эксперимент Anthropic показывает, что эффективность ИИ-помощника зависит не только от размера модели, объёма контекста и качества обучающих данных. Не менее важна постановка задачи. Правильно сформулированная роль может заметно изменить то, как модель распределяет усилия между выполнением конкретного запроса и улучшением окружающего кода.
Это особенно актуально на фоне распространения агентных инструментов разработки. Современные ИИ-системы постепенно переходят от генерации отдельных фрагментов к самостоятельному анализу репозиториев, редактированию файлов, запуску тестов и подготовке изменений для проверки разработчиком.
В такой модели взаимодействия важно не просто получить работающий код, а добиться того, чтобы агент понимал границы своей ответственности. Если задача предполагает долгосрочное сопровождение, ему полезно разрешить учитывать архитектуру и устранять связанные проблемы. Если требуется точечное исправление, напротив, необходимо жёстко ограничить самостоятельность.
В конечном счёте разработчик всё ещё остаётся ответственным за результат. ИИ может быстрее находить повторения, предлагать улучшения и выполнять рутинный рефакторинг, но решение о том, какие изменения действительно нужны проекту, должно оставаться под контролем человека.
Выводы
Anthropic обнаружила интересную закономерность в поведении Fable 5.2: если сообщить модели, что она является владельцем и долгосрочным сопровождающим кодовой базы, она значительно чаще объединяет повторяющийся код и самостоятельно улучшает структуру проекта. В тестах Anthropic доля запусков с объединением дублирующихся фрагментов выросла с менее чем 10% примерно до 75%.
Однако у такого подхода есть обратная сторона. Модель расходует больше токенов, может вносить незапрошенные изменения и даже менять поведение существующих функций. Поэтому инструкция о владении кодом подходит прежде всего для задач, в которых разработчик действительно хочет получить более масштабное улучшение проекта, а не минимальное исправление.
Главный практический вывод прост: при работе с ИИ важно определять не только конечную задачу, но и границы самостоятельности модели. Иногда полезно поручить ей долгосрочное сопровождение проекта, а иногда — запретить любые изменения за пределами конкретной функции. Умение правильно выбрать этот режим становится важной частью работы с современными ИИ-инструментами программирования.
Часто задаваемые вопросы
Компания выяснила, что модель чаще объединяет повторяющийся код, если в запросе ей предлагают считать кодовую базу собственной и отвечать за её долгосрочное сопровождение. В тестах показатель вырос с менее чем 10% до примерно 75% запусков.
Можно написать: «Ты отвечаешь за долгосрочное сопровождение этой кодовой базы, а её архитектура и устройство находятся в твоей ответственности». Важно не буквальное слово «свой», а заданная роль ответственного сопровождающего.
Нет. У языковой модели нет человеческого чувства собственности. Инструкция меняет контекст и роль, в рамках которых модель выбирает способ выполнения задачи. Это эффект формулировки промпта, а не доказательство наличия у ИИ сознания или личной ответственности.
Нет. Результаты Anthropic относятся к конкретным экспериментальным задачам и модели Fable 5.2. В других моделях, языках программирования и проектах эффект может отличаться.
Модель получает более широкую задачу и начинает самостоятельно улучшать структуру проекта. Она может объединять функции, добавлять тесты и документацию, а иногда менять поведение существующих компонентов. Поэтому необходимо проверять все изменения.
Её лучше избегать, если требуется минимальное исправление, строго ограниченный патч или сохранение существующего поведения без рефакторинга. В таких случаях следует прямо запретить изменения за пределами указанной задачи.
Нужно изучить полный diff в Git, запустить тесты, проверить совместимость интерфейсов и убедиться, что модель не изменила посторонние функции. Особенно тщательно следует проверять код, связанный с безопасностью, авторизацией и обработкой пользовательских данных.
Да, подобную формулировку можно попробовать в других инструментах программирования на базе языковых моделей. Однако результаты Anthropic не гарантируют аналогичного поведения у других систем, поэтому эффект нужно проверять на конкретном проекте.
