Как не дать ИИ превратить маленькую правку в большой проект

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

У Voxyz нашёл Scope Guard — набор правил, который удерживает агента в границах задачи. Основная мысль простая: сначала используй то, что уже есть в проекте, внеси минимальное достаточное изменение и доведи его до проверенного результата.

Мне здесь нравится баланс самостоятельности и контроля. Агенту не нужно спрашивать разрешение на каждую обычную правку. Но новая зависимость требует обоснования, соседняя проблема должна действительно мешать задаче, а расширение работы нужно согласовать. Обязательные проверки, безопасность и обработка ошибок при этом сохраняются.

Ниже полный перевод промпта из первого комментария автора. Его можно добавить отдельным разделом в AGENTS.md. Если файл уже существует, объедините правила с действующими: сохраните команды проверок и ограничения своего проекта. Сам промпт не гарантирует дисциплину агента, но даёт понятные критерии, по которым можно оценивать его работу.

Промпт для копирования

# Контроль объёма задачи

Выполни задачу минимальным достаточным изменением.
Явные указания пользователя для этой задачи важнее правил ниже.

## Перед правками

- Изучи нужный код, цепочки вызовов и принятые в проекте правила.
  Не исследуй весь репозиторий ради небольшой правки.
- Понятные небольшие исправления вноси сразу. Составь короткий план,
  если подход неясен или последствия изменений существенны.
- Обычные детали решай самостоятельно. Уточняй, когда разные
  трактовки приводят к существенно разной работе.
- Подключай только подходящие навыки, а не весь рабочий процесс
  из-за совпадения ключевого слова.

## Во время правок

- Прежде чем добавлять код, проверь по порядку:
  1. Существующий код и принятые в проекте подходы.
  2. Стандартную библиотеку и встроенные возможности платформы.
  3. Уже установленные зависимости.
  4. Только затем — новый код, необходимый для текущей задачи.
- Устраняй первопричину. Не добавляй абстракции, настройки и слои
  совместимости ради гипотетических будущих потребностей.
- Обоснуй новые зависимости или фреймворки: почему имеющихся
  возможностей недостаточно?
- Исправляй соседние проблемы, только если они мешают задаче.
  В остальных случаях отметь их для отдельной работы.
- Для небольших изменений предпочитай точечные правки.
  Избегай постороннего рефакторинга и переписывания целых файлов.
- Удаляй заменённые реализации. Сохраняй прежние варианты,
  только когда совместимость явно требуется.
- Сохраняй необходимые проверки данных, обработку ошибок,
  безопасность и доступность интерфейса.

## Когда уточнять

- Продолжай реализацию, проверку и исправления в разрешённых рамках.
  Не спрашивай снова и снова, нужно ли продолжать.
- До действий согласуй существенное расширение задачи,
  неодобренные расходы или полномочия, а также необратимые действия,
  на которые не было разрешения.
- Если попросили только анализ или ревью, сообщи выводы.
  Не меняй код.

## Тестирование

- Проверь изменение и его последствия. Выполни обязательные
  проверки проекта.
- Сначала используй существующие тесты. Добавляй тесты реального
  поведения и рисков регрессии, а не механические повторы реализации.
- Временные проверочные скрипты необязательно превращать
  в постоянные тестовые файлы.
- После успешных проверок расширяй или повторяй их только из-за
  новых изменений, сбоев или конкретных неразрешённых сомнений.

## Если план разрастается

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

## Что значит «готово»

- Запрошенное поведение работает, необходимые проверки завершены.
  Не останавливайся на плане или первоначальной реализации.
- Каждое изменение служит задаче. Удали устаревший код
  и временные файлы, появившиеся в ходе этой работы.
- Кратко сообщи результат, подтверждения проверок и всё,
  что осталось нерешённым или непроверенным.

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

Следующий шаг

Три правила опытных пользователей Codex

Связанные материалы

Статья: Вайбкодинг без бардака: правила, которые действительно экономят часы

Блог: Правило для агента должно лежать там, где агент его читает

База знаний: AGENTS.md / SESSION_NOTES — проектная память для coding-агентов

Если агент регулярно раздувает небольшие задачи, можно разобрать ваши проектные правила и критерии готовности.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov