Три частые проблемы агентного кодинга
Работая над кодом самостоятельно, модель иногда сбивается по одному из трёх частых сценариев. Первый - переинжиниринг: решение обрастает абстракциями, конфигурируемостью и обработкой ошибок, которых никто не просил. Второй - подгонка под тесты: код проходит конкретные тестовые случаи, но не решает задачу в общем виде. Третий - уверенные утверждения о коде, который на самом деле не был прочитан. На все три случая у Anthropic есть готовые формулировки промптов, которые заметно снижают частоту таких сбоев.
Против переинжиниринга
Модели иногда склонны создавать лишние файлы, добавлять ненужные абстракции или строить гибкость, которую никто не запрашивал. Если это заметно в работе, стоит добавить прямое указание держать решение минимальным:
Избегай переинжиниринга. Делай только те изменения, которые прямо запрошены
или явно необходимы. Держи решения простыми и сфокусированными:
- Объём: не добавляй функции, не рефактори код и не делай «улучшения»
сверх того, что было запрошено. Исправление бага не требует попутной
уборки кода. Простая функция не требует лишней настраиваемости.
- Документация: не добавляй докстринги, комментарии или аннотации типов
к коду, который ты не менял. Добавляй комментарии только там, где логика
не самоочевидна.
- Защитное программирование: не добавляй обработку ошибок, запасные
варианты или валидацию для сценариев, которые не могут произойти.
Доверяй внутренним гарантиям кода и фреймворка. Валидируй только на
границах системы (пользовательский ввод, внешние API).
- Абстракции: не создавай хелперы, утилиты или абстракции для
одноразовых операций. Не проектируй под гипотетические будущие
требования. Правильный уровень сложности - минимум, необходимый для
текущей задачи.Против подгонки решения под тесты
Иногда модель слишком сильно фокусируется на том, чтобы тесты проходили, в ущерб более общему решению, или использует обходные пути вроде вспомогательных скриптов вместо прямого применения стандартных инструментов. Чтобы получить решение, которое действительно обобщается на все случаи, а не только на тестовые:
Напиши качественное решение общего назначения, используя стандартные
доступные инструменты. Не создавай вспомогательные скрипты или обходные
пути, чтобы выполнить задачу «эффективнее». Реализуй решение, которое
корректно работает для всех допустимых входных данных, а не только для
тестовых случаев. Не зашивай значения в код и не создавай решения,
которые работают только для конкретных тестовых входных данных. Вместо
этого реализуй саму логику, которая решает задачу в общем виде.
Сфокусируйся на понимании требований задачи и реализации правильного
алгоритма. Тесты нужны, чтобы проверить корректность, а не чтобы
определять само решение. Дай продуманную реализацию, которая следует
лучшим практикам и принципам разработки.
Если задача невыполнима или некорректна, или если какие-то тесты
неправильные, сообщи мне об этом, а не обходи их. Решение должно быть
устойчивым, поддерживаемым и расширяемым.Против выдуманных фактов о коде
Современные модели Claude уже менее склонны к выдумыванию фактов и дают более обоснованные, приземлённые к реальному коду ответы. Чтобы усилить это поведение ещё сильнее:
<investigate_before_answering>
Никогда не строй предположения о коде, который ты не открывал. Если
пользователь ссылается на конкретный файл, ты ОБЯЗАН прочитать файл
перед ответом. Обязательно исследуй и читай нужные файлы ПЕРЕД тем,
как отвечать на вопросы о кодовой базе. Никогда не делай заявлений о
коде до исследования, если только ты не уверен в правильном ответе - давай обоснованные ответы без выдумывания фактов.
</investigate_before_answering>Уборка временных файлов
Отдельная, более мелкая привычка - создание временных файлов для итерации: модель может использовать их как черновик перед сохранением финального результата, и это часто улучшает результат в агентном кодинге. Если временные файлы мешают, а не помогают, их можно попросить убирать за собой:
Если ты создаёшь временные новые файлы, скрипты или вспомогательные
файлы для итерации, убери эти файлы в конце задачи.Куда добавлять эти инструкции
Если проблема повторяется в каждой сессии на конкретном проекте, инструкцию стоит держать в CLAUDE.md - тогда она применяется автоматически. Если поведение нужно только для конкретной задачи, достаточно добавить формулировку прямо в разовый промпт. Комбинировать несколько инструкций из этой статьи в одном системном файле совершенно нормально - они закрывают разные проблемы и не конфликтуют друг с другом.
Чек-лист
- Замечен паттерн переинжиниринга - добавлена инструкция про минимальные решения
- Замечена подгонка под тесты - добавлена инструкция про общее решение
- Замечены заявления о непрочитанном коде - добавлена инструкция investigate_before_answering
- Повторяющиеся инструкции вынесены в CLAUDE.md, а не повторяются вручную каждый раз
- Временные файлы убираются за собой, если они не нужны в финальном результате