Skip to content

Работа с агентами

Главная ошибка начинающих агентных инженеров: запрашивать слишком много за раз.

Почему декомпозиция важна

Section titled “Почему декомпозиция важна”

Агенты лучше всего работают с ограниченными, чёткими задачами. Когда вы запрашиваете слишком много:

  • Контекст переполняется, и ранние детали теряются
  • Ошибки накапливаются, поскольку последующие шаги строятся на ранних ошибках
  • Восстановление после сбоев тратит всё, что было сделано до

Маленькие задачи означают более быструю обратную связь, проще отладку, лучшие результаты.

Перед промтом спросите: Могу ли я описать это в трёх частях?

  1. Что — Конкретный результат, который я хочу
  2. Где — Какие файлы/функции затронуть
  3. Ограничения — Что не менять

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

Стратегии декомпозиции

Section titled “Стратегии декомпозиции”

Вертикальное разрезание

Section titled “Вертикальное разрезание”

Режьте по пути фичи, а не по техническому слою.

Вместо:

  • «Создать схему базы данных»
  • «Построить API-эндпоинты»
  • «Создать фронтенд-формы»

Попробуйте:

  • «Создать поток создания пользователя: схема, эндпоинт и базовая форма»
  • «Добавить редактирование пользователя: эндпоинт обновления и форма»
  • «Добавить удаление пользователя: эндпоинт с подтверждением»

Каждый срез закончен и тестируем.

Порядок по зависимостям

Section titled “Порядок по зависимостям”

Когда у задач есть зависимости, сделайте их явными:

  1. Определите типы модели данных (без внешних зависимостей)
  2. Постройте слой хранилища (зависит от типов)
  3. Создайте API (зависит от хранилища)
  4. Постройте UI (зависит от API)

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

Слишком маленькая: «Добавь точку с запятой в строке 47» — быстрее сделать самому

Слишком большая: «Построй систему аутентификации» — слишком много решений

В самый раз: «Создай форму логина, которая отправляет POST на /api/auth/login и сохраняет токен в localStorage» — чёткая область, тестируемый результат

Задача: [Что нужно сделать]
Контекст:
- [Релевантный фон]
- [Связанные файлы или паттерны для следования]
Ограничения:
- [Что не менять]
- [Паттерны для следования]
Критерии успеха:
- [Как вы поймёте, что готово]

Результат агента выглядит правдоподобно. В этом и опасность. Относитесь к коду агента как к коду от талантливого junior: скорее всего работает для happy path, может пропустить граничные случаи, может не следовать вашим конвенциям.

1. Решает ли это проблему? Прочитайте код — не просто запускайте. Адресует ли он реальное требование, а не только промт?

2. Проверьте края:

  • Пустые входные данные
  • Null/undefined значения
  • Граничные условия (off-by-one, макс. значения)
  • Случаи ошибок
  • Параллельный доступ

3. Ищите галлюцинации:

  • API-методы, которые не существуют
  • Параметры, которые работают не так, как предполагалось
  • Функции, вызванные с неправильными сигнатурами

Если что-то незнакомо — проверьте, существует ли это.

4. Проверка безопасности:

  • Есть валидация входных данных?
  • Нет SQL/command injection?
  • Проверка auth/authorization?
  • sensitive данные не логируются?
  • Нет захардкоженных секретов?

5. Стиль и конвенции:

  • Следует существующим паттернам?
  • Имена понятные и последовательные?
  • Сообщения об ошибках полезны?

Отклоняйте, когда:

  • Подход принципиально неверен (даже если работает)
  • Нужно слишком много рефакторинга для соответствия стандартам
  • Проблемы с безопасностью, требующие переработки

Принимайте с модификациями, когда:

  • Логика верна, но нужен стилистический рефакторинг
  • Нужна обработка мелких граничных случаев

Принимайте как есть, когда:

  • Удовлетворяет требованиям, обрабатывает края, следует конвенциям, проходит проверку безопасности