12 правил Claude MD для создания самовосстанавливающихся ИИ-агентов

Статья рассказывает, как настроить Claude MD-файл, чтобы автономный ИИ-агент мог стабильно работать часами, исправлять собственные ошибки и выдавать качественный код. Основная идея — не относиться к этому файлу как к статичной конфигурации. Его предлагают воспринимать как живой документ: после каждой ошибки или неудачного запуска в него добавляется новое правило, которое не даёт агенту повторить тот же сбой. Такой подход автор связывает с примером Митчелла Хасимото, создателя Terraform и Vagrant: тот ведёт файл инструкций как журнал отказов, где каждая запись — это урок из конкретной прошлой ошибки. Со временем агент становится точнее и реже требует ручного вмешательства. Чтобы улучшения не терялись, желательно делать обновления программными, с версионированием, тогда накопленные правила можно переиспользовать в команде. Первый блок правил касается разработки через тестирование. Агенту запрещают просто писать код «по ощущениям» и требуют сначала определить, что считается готовым результатом, а затем систематически создавать код и тесты под это определение. Такой цикл помогает отличить профессиональную работу от любительского vibe-кодинга: модель перестаёт лишь уверенно утверждать, что решение корректно, и вынуждена доказывать это тестами. В статье приводится пример PG Rust-проекта, где для переписывания Postgres при помощи агентов использовали набор из 46 тысяч тестов. Отдельно советуют включать строгую проверку типов и явно запрещать any в TypeScript. Это ловит целые классы ошибок ещё до запуска дополнительных тестов. Ещё одно правило — при любой неоднозначности агент должен задать уточняющий вопрос, а не строить опасные предположения. Следующий блок — это чёткие ограничения. Нужно фиксировать строгие правила именования функций, переменных и пользовательского текста: такая последовательность упрощает и чтение кода, и рассуждения модели о кодовой базе. В файл стоит записать точную структуру проекта, чтобы агенту не приходилось сканировать всё дерево файлов ради каждого решения. Также рекомендуется ограничить список доступных пакетов только проверенными, активно поддерживаемыми библиотеками с большим числом загрузок и свежими обновлениями. Это снижает риск попадания непроверенного или вредоносного кода. Наконец, статья советует проверять не только модули, но и реальное поведение приложения. Агенту можно дать роль пользователя: пусть он ходит по интерфейсу, нажимает элементы и делает скриншоты. Такие end-to-end и UI-тесты выявляют гонки, ошибки стилей и редкие сценарии, которые юнит-тесты часто пропускают. Полезно задавать и жёсткие лимиты производительности, например время ответа конечной точки не более 200 миллисекунд. Это заставляет модель оптимизировать запросы, не таскать лишние данные и использовать индексы. Ошибки предлагается обрабатывать по принципу «падай рано и громко»: сразу возвращать понятное сообщение, а не молча проглатывать исключение. В итоге агент лучше понимает свои ограничения и прозрачно сообщает о проблемах, что делает его работу более предсказуемой для разработчика.