Привет, Хабр! Меня зовут Платон Малюгин, я разработчик в Garage Eight. Сегодня поговорим с вами об агентской разработке. Хотим мы этого или нет, ИИ меняет нашу работу и сами подходы к ней. Сгенерированный код может стать большой проблемой, а может, наоборот, усилить нас как технарей. Особенно это чувствуется внутри работающего продукта: агент опирается на существующий код, и любой костыль в нём тянется дальше — в новый результат.
Важно понять, что агенты могут кодить быстро, но только человек обладает насмотренностью и может адекватно оценить результат и улучшить его. Вот как это было у меня.
Как менялся мой подход к разработке с ИИ
Работу я делил на три этапа:
Этап 1. Пишу код сам. С ИИ иногда советуюсь, но не доверяю ему и уверен: качественный код он написать не способен.
Этап 2. Plan → Act. Сначала долго собираю план, проверяю его и, когда план уже похож на спецификацию, отдаю агенту писать код. Потом смотрю результат вручную, сам провожу локальное ревью. Если всё хорошо — коммичу, если нет — запускаю цикл Plan → Act заново, и так по несколько раз. Код-ревью в итоге всё равно на мне, да и те, кто смотрит мой код, ревьюят руками.
Этап 3. Весь Delivery на агенте. Задачу целиком отдаю агенту, а сам подключаюсь только на ключевых точках цикла. Здесь становится критично, какой контекст вы даете агенту: чем больше отдаете ему, тем выше требования к входным данным — постановке, спеке, референсам.
Под капотом у третьего этапа один цикл, который агент проходит сам: спека → разработка → ревью → тесты → публикация. Весь цикл зашит в skill — переиспользуемый набор инструкций для Claude или Codex, который агент подхватывает под конкретный тип задач. Я выложил его в открытый доступ: aiteam-delivery — пайплайн не привязан к вендору и трекеру.
Вот что происходит на каждой стадии:
Спека. Формулирую задачу и требования сам. Это по-прежнему во многом ручная работа: чем детальнее вход, тем предсказуемее выход.
Разработка. Агент пишет код по спеке — сам, без меня.
Ревью. Замечания оставляю прямо в merge request и там же обсуждаю правки с агентом.
Тесты. Быстрые тесты гоняю вручную, а зеленый CI — жесткое условие: нет зеленых тестов — нет PR.
Публикация. Агент доводит задачу до готового MR. По умолчанию merge за человеком, но настраивается: при зеленых тестах агенту можно разрешить мержить самому.
На такую задачу у разработчика ушло бы день-два; агент закрывает ее примерно за час. А запускать можно несколько агентов сразу, поэтому в удачные дни выходит до 20 задач. Цифра подкупает, но не обольщайтесь: дальше расскажу, почему «продукт за вечер» из этого не следует.
Как всё работает на практике
Теперь давайте перейдем к конкретному примеру. Допустим, мы показываем продукт пользователям и собираем фидбэк, а агент превращает эту сырую обратную связь в структурированный список хотелок: чего людям не хватает и что они просят добавить.
Задача проходит тот же цикл:
Спеку с форматом входа (сырой фидбэк) и выхода (список хотелок) я собираю сам.
Агент пишет обработку.
Я оставляю замечания в MR.
Прогоняю быстрые тесты вручную.
Агент мержит готовый результат.
Вручную с моей стороны — только постановка и финальная проверка, всё между ними делает агент.
При отлаженном цикле:
Рутина уходит за минуты. Однотипный код, обвязка, скучные правки — всё то, на что раньше уходили часы, теперь делается за один прогон.
Думаешь о задаче, а не о синтаксисе. Голова занята тем, что надо сделать, а не тем, как это написать. Это, пожалуй, главное изменение.
Один человек ведет несколько агентов. Пока один пишет тесты, другой правит баг. Успеваешь больше без дополнительного найма.
Но без минусов и рисков никуда:
Высокая стоимость. Я сижу на топовом тарифе — Claude Max, для Codex нужен сопоставимый верхний план ChatGPT. Токены сгорают быстро, и если бюджет маленький, автономный режим пока не для вас. Считайте деньги заранее.
Чужой код тяжело поддерживать. Агент написал 500 строк, а потом без него в этих строках тяжело разбираться. Чем больше отдаешь машине, тем выше риск получить код, который никто в команде толком не знает.
Агент любит переусложнить. Например, раздувает Structured-output схему ответа модели, тащит названия полей в имена переменных, наслаивает несколько вариантов решения в один. Каждый такой случай ловишь на ревью и гоняешь упрощать.
Тесты и откаты теперь обязательны. Без них любой автодеплой превращается в игру в рулетку. Зеленые тесты перестают быть «хорошим тоном» и становятся условием, без которого агента нельзя пускать дальше.
Опасные операции только руками. Агент не должен сам лезть в боевую базу или в платежи. Точка.
Что я перестроил для себя
Чтобы эффективно управлять агентом, я четко разделил обязанности.
Сама роль разработчика сводится в итоге к трем вещам:
Define — собрать спеку. Главная проблема была не в модели, а в том, как я ставлю задачу. Я свел все задачи к одному формату (блоки «цель» и «контекст») и доработал skill агента так, чтобы он писал понятно и без лишних усложнений: не плодил абстракции, а делал ровно то, что просили. Требования при этом всё еще во многом пишу руками: ИИ помогает формулировать, но ручной работы остается много.
## Цель Что должно получиться и как понять, что готово. ## Контекст Ссылки на код, спеки, референсы; ограничения и чего делать не надо.
Validate — проверить результат. Если задачу можно быстро проверить глазами, проверяю сам, не перекладываю на агента: доверяю ему ровно до того места, где еще могу всё быстро перепроверить.
Maintain — держать процесс в форме. В основном беру Claude, но то же самое можно собрать и на Codex. Главное — обвязка вокруг, которую надо поддерживать изо дня в день: формат задач, правила в CI, четкое деление «агент/человек».
Контекст — это всё
Чем меньше контекста даешь агенту, тем больше он галлюцинирует. Именно поэтому всё держу в одном месте — в LLM-вики: доки, код, спеки, дизайны, обратную связь и рисёрч. Эти артефакты полезны и для отладки, и как контекст для будущих задач.
Вики становится общей памятью для людей и агентов. Команда складывает туда решения, риски и фидбэк, проекты дают референсы и отчеты, а Codex или Claude берут оттуда контекст для работы. Кстати, эта статья тоже живет в такой вики.
Реально ли собрать стартап за вечер
Нет. Пару фич за вечер собрать реально, но продукт — это не набор фич, а ценность для пользователя, и она так быстро не собирается. Плюс до запуска цикла доставки есть подготовка: постановка, контекст, инфраструктура — всё это само по себе может занять больше дня.
Полной цепочки «задача в трекере → код → деплой без меня» у меня нет. И мешает не техника, а то, что в одиночку это не закрыть:
требования надо писать под агента, а это работа всей команды, не только моя;
нужна инфраструктура: быстрые откаты, фича-флаги, защита опасных операций;
нужно менять привычки команды, а это долго и требует дисциплины.
То есть последний шаг — это уже не про мой личный процесс, а про то, насколько готовы команда и платформа.
Куда это всё ведет
ИИ нас не заменит, но заставит измениться и нас самих, и наши процессы. Мне кажется, команды двигаются к модели agentic-инженеров: люди формулируют PRD и спеки, headless-цикл доставки катит инкременты, обратная связь команды возвращается в цикл на доработку.
Команда мечты в таком мире выглядит так:
проверяет гипотезу или выкатывает инкремент меньше чем за неделю;
сама закрывает полный цикл HADI (гипотеза → действие → данные → выводы) и по продукту, и по маркетингу;
работает на полностью автоматизированных процессах от и до;
укладывается в заранее одобренные бюджеты, без лишних согласований.
Вывод
Агенты — это мощный инструмент, но не источник халявы. Шансы, что получится настроить эффективную работу, выше, если:
Внедрять агентов в работу по шагам. Начните с того, что легко проверить: тесты, ревью, рутинный код. К полной автоматизации идите, когда команда будет готова.
Сначала выставить ограничители. Зеленый CI и ручной стоп-кран на опасных операциях ставьте до того, как агент начнет катить сам.
Заранее готовить бюджет. Потому что дешево точно не будет.
Робота можно приручить, если выстроить вокруг него понятные рамки.
Как у вас обстоят дела с ИИ? Какую часть рутины доверяете агентам? Может, удалось полностью автоматизировать процессы?
