Работа с агентами
Главная ошибка начинающих агентных инженеров: запрашивать слишком много за раз.
Почему декомпозиция важна
Section titled “Почему декомпозиция важна”Агенты лучше всего работают с ограниченными, чёткими задачами. Когда вы запрашиваете слишком много:
- Контекст переполняется, и ранние детали теряются
- Ошибки накапливаются, поскольку последующие шаги строятся на ранних ошибках
- Восстановление после сбоев тратит всё, что было сделано до
Маленькие задачи означают более быструю обратную связь, проще отладку, лучшие результаты.
Правило трёх частей
Section titled “Правило трёх частей”Перед промтом спросите: Могу ли я описать это в трёх частях?
- Что — Конкретный результат, который я хочу
- Где — Какие файлы/функции затронуть
- Ограничения — Что не менять
Если вы не можете сформулировать все три, задача, вероятно, слишком большая.
Стратегии декомпозиции
Section titled “Стратегии декомпозиции”Вертикальное разрезание
Section titled “Вертикальное разрезание”Режьте по пути фичи, а не по техническому слою.
Вместо:
- «Создать схему базы данных»
- «Построить API-эндпоинты»
- «Создать фронтенд-формы»
Попробуйте:
- «Создать поток создания пользователя: схема, эндпоинт и базовая форма»
- «Добавить редактирование пользователя: эндпоинт обновления и форма»
- «Добавить удаление пользователя: эндпоинт с подтверждением»
Каждый срез закончен и тестируем.
Порядок по зависимостям
Section titled “Порядок по зависимостям”Когда у задач есть зависимости, сделайте их явными:
- Определите типы модели данных (без внешних зависимостей)
- Постройте слой хранилища (зависит от типов)
- Создайте API (зависит от хранилища)
- Постройте UI (зависит от API)
Каждый шаг должен работать изолированно, прежде чем переходить к следующему.
Размер задач
Section titled “Размер задач”Слишком маленькая: «Добавь точку с запятой в строке 47» — быстрее сделать самому
Слишком большая: «Построй систему аутентификации» — слишком много решений
В самый раз: «Создай форму логина, которая отправляет POST на /api/auth/login и сохраняет токен в localStorage» — чёткая область, тестируемый результат
Шаблон промта
Section titled “Шаблон промта”Задача: [Что нужно сделать]
Контекст:- [Релевантный фон]- [Связанные файлы или паттерны для следования]
Ограничения:- [Что не менять]- [Паттерны для следования]
Критерии успеха:- [Как вы поймёте, что готово]Валидация результатов
Section titled “Валидация результатов”Результат агента выглядит правдоподобно. В этом и опасность. Относитесь к коду агента как к коду от талантливого junior: скорее всего работает для happy path, может пропустить граничные случаи, может не следовать вашим конвенциям.
Чеклист валидации
Section titled “Чеклист валидации”1. Решает ли это проблему? Прочитайте код — не просто запускайте. Адресует ли он реальное требование, а не только промт?
2. Проверьте края:
- Пустые входные данные
- Null/undefined значения
- Граничные условия (off-by-one, макс. значения)
- Случаи ошибок
- Параллельный доступ
3. Ищите галлюцинации:
- API-методы, которые не существуют
- Параметры, которые работают не так, как предполагалось
- Функции, вызванные с неправильными сигнатурами
Если что-то незнакомо — проверьте, существует ли это.
4. Проверка безопасности:
- Есть валидация входных данных?
- Нет SQL/command injection?
- Проверка auth/authorization?
- sensitive данные не логируются?
- Нет захардкоженных секретов?
5. Стиль и конвенции:
- Следует существующим паттернам?
- Имена понятные и последовательные?
- Сообщения об ошибках полезны?
Когда отклонять
Section titled “Когда отклонять”Отклоняйте, когда:
- Подход принципиально неверен (даже если работает)
- Нужно слишком много рефакторинга для соответствия стандартам
- Проблемы с безопасностью, требующие переработки
Принимайте с модификациями, когда:
- Логика верна, но нужен стилистический рефакторинг
- Нужна обработка мелких граничных случаев
Принимайте как есть, когда:
- Удовлетворяет требованиям, обрабатывает края, следует конвенциям, проходит проверку безопасности
Ресурсы
Section titled “Ресурсы”Основные
Section titled “Основные”- Embracing the parallel coding agent lifestyle - Запуск нескольких агентов одновременно
- Spec-Driven Development – Al Harris, Amazon Kiro - Как спеки позволяют воспроизводимую AI-доставку
- Your job is to deliver code you have proven to work - Почему тестирование AI-кода обязательно
Углублённые
Section titled “Углублённые”- Spec Kit - Фреймворк GitHub для spec-driven development
- “I shipped code I don’t understand” – Jake Nations, Netflix - Трёхфазная методология, чтобы избежать «vibecoding to disaster»
- No Vibes Allowed – Dex Horthy, HumanLayer - Частая осознанная декомпозиция для больших кодовых баз