Планирование и фичи
Сначала план, потом код. Почему стоит дробить работу на маленькие законченные куски и сверять подход до правок — а не просить «сделай всё сразу».
Две привычки отделяют тех, у кого агент реально ускоряет работу, от тех, у кого он «навертел и всё сломал»: сначала планировать и строить по фичам.
Сначала план, потом код
На сложной или рискованной задаче дешевле сверить план на берегу, чем разгребать поспешные правки. Для этого есть plan mode: агент анализирует задачу и предлагает план, ничего не меняя. Ты читаешь, правишь, одобряешь — и только потом он пишет код.
Зачем это нужно:
- видно, как агент вообще понял задачу, до того как он наломал;
- ты ловишь неверные допущения за секунды, а не за час отладки;
- план становится чек-листом, по которому потом удобно проверять результат.
Правило простое: чем дороже ошибка, тем раньше нужен план. Поправить опечатку — пиши сразу. Трогать миграцию БД или авторизацию — сначала план.
Строй по фичам, а не «всё сразу»
Большая расплывчатая задача — худшее, что можно дать агенту. Он забивает контекст-окно, теряет нить и копит ошибки.
❌ «сделай всю систему авторизации»
✅ шаг 1: форма логина + валидация → проверил → коммит
шаг 2: хранение сессии → проверил → коммит
шаг 3: сброс пароля → проверил → коммитПочему мелкие куски работают лучше:
- меньше контекста на каждый шаг — агент точнее;
- легче проверять — маленький дифф читается глазами, большой нет;
- легче откатить — сломалось на шаге 2, шаг 1 уже закоммичен и цел;
- ошибки не накапливаются — каждый кусок закрыт до начала следующего.
Для нас в тестировании аналогия прямая: одна фича — это один сценарий за раз, а не «покрой весь продукт одним промптом».
Нужно вести несколько фич параллельно, не мешая их в одной сессии — для этого есть git worktree и параллельные агенты.
Проверь себя
1. Когда особенно стоит сначала попросить план, а не сразу код?
2. Почему «сделай всё сразу» работает хуже, чем дробление на фичи?
3. Чем удобен план как побочный эффект?
Дисциплина промптов
Inputs определяют outputs. Как ставить задачу агенту — контекст, конкретика, примеры, итерации — чтобы получать то, что нужно, а не правдоподобную воду.
Ревью и безопасность
Агент уверенно ошибается, поэтому результат всегда проверяется. Три уровня контроля — верификация, код-ревью, безопасность — и что ревьюить особенно внимательно.