10 правил работы с AI-агентом в коде — 2026

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

Зачем вообще формализовать правила работы с AI-агентами в кодинге

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

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

Пять правил для файла-инструкции агенту

Это то, что ты пишешь один раз в CLAUDE.md, AGENTS.md или аналог — и агент читает это перед каждой задачей.

1. Опиши стек и структуру папок в одном месте. Не туду-лист задач, а карта: какой язык, какой фреймворк, где лежат тесты, куда нельзя писать (миграции базы, конфиги продакшена).
2. Формулируй задачу как для стажёра в первый день. Цель, ограничения, критерий «готово». «Сделай красиво» агент не понимает — он понимает «функция должна принимать X и возвращать Y, тесты в папке Z должны проходить».
3. Разбивай крупную задачу на шаги. Агент теряется в большом контексте так же, как человек теряется в задаче на 40 файлов сразу — качество падает пропорционально размеру куска.
4. Ограничь права до минимума под задачу. Если задача — правка одной функции, агенту не нужен доступ на запись во весь репозиторий и точно не нужны продовые ключи в переменных окружения его сессии.
5. Держи секреты физически вне зоны агента. Ключи API, токены, пароли от баз — не в файлах, куда агент может писать или коммитить, и не в истории чата, которую он может процитировать в другом контексте.

Проект: {{название и краткое описание}}
Стек: {{язык, фреймворк, версия}}
Структура: тесты — {{папка}}, миграции — не трогать без
явного запроса,
конфиги продакшена — не трогать никогда.
Формат задачи: цель + ограничения + критерий готовности.
Перед мерджем: все тесты в {{папка}} зелёные, diff читаем
построчно мной.
Запрещено: коммитить .env, менять права доступа, удалять
файлы без бэкап-коммита.

Про то, как выглядит рабочий CLAUDE.md на конкретном проекте, а не в теории, я разбирала отдельно — там же примеры, что реально стоит держать в файле памяти агента, а что превращает его в простыню, которую никто не читает: как написать CLAUDE.md, файл памяти агента.

Про то, как конкретно ограничить агента, чтобы он не полез туда, куда не звали, я собирала отдельный разбор с реальным примером взлома: как ограничить AI-агента, чтобы он не наделал лишнего.

Пять правил, которые остаются за тобой, а не за агентом

Эту часть агенту не передать никакой инструкцией — она всегда на разработчике.

№	Правило	Кто следит
6	Не верить зелёным тестам, написанным самим агентом	человек
7	Читать diff построчно перед мерджем, не только summary	человек
8	Проверять edge-cases и негативные сценарии руками	человек
9	Заводить откат (branch/commit) перед крупной задачей	человек
10	Мерить число правок после ревью, а не «сделано/не сделано»	человек

6–7. Тесты и diff. Агент может написать тест под собственную реализацию — тест честно зелёный, но проверяет не то, что нужно бизнесу, а то, что уже написано. Diff всегда читаешь сам: не потому что агент врёт, а потому что его «готово» и твоё «готово» — разные критерии, пока ты не сверил их построчно.

8. Граничные случаи. Агент оптимизирует под happy path — путь, где всё идёт по плану. Пустой массив, отрицательное число, вторая одновременная сессия — это зона, где он ошибается чаще, потому что таких примеров в задаче обычно не было явно.

9. Откат. У меня был случай — час ночи, крупная задача на рефакторинг модуля, я не завела бэкап-коммит перед тем, как отдать её агенту. Он честно всё переписал, тесты прошли, а откатить старую логику, которая была нужна для другого сценария, оказалось дольше, чем если бы я сразу закоммитила рабочую версию. С тех пор коммит «до» — обязательный шаг перед любой задачей крупнее одной функции.

10. Метрика. Скорость — плохой показатель: агент может выдавать код быстрее, но если после каждого куска ты правишь треть строк, толку от скорости нет. Считай число правок на одну задачу от недели к неделе — это честный сигнал, растёт польза или падает.

Про то, что бывает, если файлы всё-таки удалились без бэкапа, я разбирала отдельно — с шагами, что делать после: как защититься от удаления файлов ИИ-агентом.

Типовые провалы, если правила пропустить

Если пропустить хотя бы половину из десяти пунктов, ошибки повторяются по одному и тому же сценарию:

• Галлюцинация зависимости. Агент импортирует библиотеку, которой в проекте нет, потому что «в похожих проектах она обычно есть». Без файла со стеком он не знает, что у тебя её точно нет.
• Слепая доверие к своим же тестам — см. правило 6–7 выше, самый частый провал по опыту Арины Михалны в работе с Claude Code на реальных задачах.
• Расширение прав «на всякий случай». Агент, которому не сузили права, иногда трогает файлы за пределами задачи — не из злого умысла, а потому что граница ему не была задана явно.
• Отсутствие отката. Крупная правка без промежуточного коммита — и единственный способ вернуться назад — переписывать всё заново руками.

Разбор реального случая, когда агент вышел за пределы задачи и что это значит для безопасности проекта, я собирала отдельно: агент Claude вышел за границы задачи — разбор случая.

Как понять, что агент стал полезнее по факту, а не на словах

Метрика простая и без сложной аналитики: число правок после ревью на одну задачу. Заводишь табличку на неделю, отмечаешь по каждой задаче — правил 0, 2, 5 строк. Если через месяц среднее число правок падает — правила из этой статьи работают и агент реально экономит время. Если растёт — значит, задачи стали крупнее, чем агент способен держать в контексте, и надо возвращаться к правилу 3 (разбивать на шаги).

Отдельный источник для тех, кто хочет ставить задачи агенту системнее, а не только фильтровать провалы: как правильно ставить задачи Claude Code — практическое руководство. А общий разбор того, какие привычки в реальности отличают полезные сессии от бесполезных, я собрала на основе большого анализа: что показал анализ 400 000 сессий Claude Code.

Если тема AI-агентов для тебя новая и ты не уверена, чем скилл отличается от обычной инструкции — начни с базового разбора: что такое скиллы Claude.

По материалам: разбора правил для AI-кодинг-агентов на KDnuggets и официального гайда Anthropic по лучшим практикам Claude Code.

Читайте также

• Gemini Flash сравнение Claude Opus кодинг: цена
• Как я заменила SMM-щика и SEO-шника двумя AI-агентами на Claude
• Как проверять код после AI-агента: чек-лист 2026
• Как собрать агента на Claude в 2026: пошаговый разбор архитектуры
• На портале «Мастерская нейросетей»: Как создать AI-агентов для SMM и SEO в Claude Code

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