ИИ-агент для программирования отличается от чата одним: у него есть доступ к вашей файловой системе и терминалу. Он не предлагает текст — он меняет проект и сам видит результат своих изменений. Всё остальное следует из этого.

Чем агент отличается от чата

АвтодополнениеЧатАгент
Что видитоткрытый файлто, что вы вставилипроект, вывод команд, ошибки
Что делаетдописывает строкуотвечает текстомправит файлы, запускает команды
Кто переносит кодвы, по одной подсказкевы, копипастомникто, он уже в файлах
Обратная связьнетвы пересказываете ошибкучитает ошибку сам
Ваша рольпринимаете подсказкипереносите и склеиваетеставите задачу и проверяете

Ключевая строка — четвёртая. Когда агент сам запускает сборку и читает ошибку, цикл «правка → проверка → правка» замыкается без вас. Одна задача может занять у него десятки шагов, из которых вы увидите только итог. Это и делает возможным вайбкодинг как способ работы: смотреть на поведение, а не на строки.

Что агент делает сам

Набор у всех примерно одинаковый, названия разные:

  • читает и пишет файлы в рабочей папке;
  • ищет по проекту — по именам и по содержимому;
  • запускает команды оболочки и читает вывод;
  • ставит зависимости, запускает сборку и тесты;
  • работает с git: смотрит дифф, коммитит, создаёт ветки;
  • ходит в интернет за документацией, если ему это разрешили;
  • подключается к внешним системам через MCP — базам, трекерам, браузеру.

Отсюда простое следствие: агент может сделать с вашим проектом всё, что можете сделать вы из той же папки. Включая rm -rf, git reset --hard и отправку файла наружу.

Права: главное решение

Каждый агент так или иначе даёт выбрать, что спрашивать, а что делать молча. Обычно это три уровня:

  1. Спрашивать всё. Каждое изменение файла и каждая команда — с подтверждением. Медленно, зато вы видите всё.
  2. Спрашивать про опасное. Правки файлов идут сами, команды и установка зависимостей — с подтверждением. Рабочий компромисс.
  3. Не спрашивать ничего. Быстро и ровно до первой неприятности.

Практическое правило: третий режим — только в изолированной среде и только там, где потеря содержимого папки вас не расстроит. Не «я аккуратный», а «здесь нечего терять». В Claude Code, например, песочница поддерживается в WSL 2 и не поддерживается в нативной Windows-установке — то есть уровень изоляции зависит не только от настройки, но и от того, как вы поставили инструмент.

Про рабочую папку. Агент видит папку, из которой запущен, целиком. Запуск из домашнего каталога означает, что в контекст могут попасть чужие проекты, конфиги и ключи. Запускайте из папки проекта.

Контекст и почему он кончается

Агент помнит ровно то, что помещается в его контекстное окно: ваши сообщения, свои ответы, прочитанные файлы, вывод команд. Окна большие, но конечные, и заполняются они быстрее, чем кажется — один npm install в логе весит больше, чем весь ваш диалог.

Что происходит, когда место кончается:

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

Отсюда два приёма, которые работают у всех агентов. Первый — держать постоянные правила проекта в файле, который агент читает при старте (у Claude Code это CLAUDE.md, у Codex — AGENTS.md). Второй — заканчивать сессию вместе с задачей, а не тянуть один бесконечный диалог.

Подагенты и разделение контекста

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

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

Это уже подводит к теме нескольких агентов одновременно — только там речь не про подагентов внутри одной сессии, а про несколько независимых агентов на одном проекте.

Где длинные задачи рвутся

Четыре типовых места:

  • Цикл починки. Агент чинит ошибку A, ломает B, чинит B, ломает A. Признак — третий заход с тем же диффом. Лечится остановкой и новой постановкой задачи, а не «попробуй ещё раз».
  • Тихое расширение задачи. Попросили поправить одну функцию — получили рефакторинг модуля. Лечится явным запретом в задаче и просмотром git diff до согласия.
  • Подгон под тест. Тест не проходит — агент правит тест. Формально зелено. Лечится запретом менять тесты в этой задаче.
  • Придуманный API. Модель уверенно вызывает метод, которого нет в этой версии библиотеки. Ловится только запуском, поэтому запускать надо всегда.

Как вести агента

  1. Одна задача — одна сессия. Закончили — начинайте новую. Контекст не бесплатный.
  2. Критерий готовности в самой задаче. «Готово, когда проходит вот эта проверка» — иначе готовность определит агент, и определит оптимистично.
  3. Запреты явно. Не трогать другие файлы, не ставить зависимости, не менять тесты, не переписывать конфиг.
  4. Дифф перед согласием. Всегда. Это тридцать секунд и главный фильтр качества.
  5. Коммит на каждом рабочем состоянии. Точка отката важнее красоты истории.
  6. Правила проекта — в файл. Всё, что вы объясняете второй раз, должно лежать в CLAUDE.md или AGENTS.md.

Что из этого автоматизируется рабочим местом, а что остаётся на вас, разобрано в обзоре инструментов. А общий взгляд на то, что модели в принципе умеют и чего не умеют, — в статье ИИ для программирования.