Два инженера против сроков: чему нас научили два месяца агентной разработки

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

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

За два месяца мы довели продукт до стадии пилота и на собственном опыте узнали, чего на самом деле стоит агентная разработка. Этим опытом и хотим поделиться. Под катом — как устроен наш процесс работы с агентами, с какими сложностями мы столкнулись и чему нас научил этот эксперимент.

Что мы строили

Кратко о нашем «дано». Есть задача: собрать систему автоматизации бизнес-процессов, внутри которой завязаны локальная LLM, интеграции с внешними сервисами и разветвленная логика обработки запросов. Есть мы: двое инженеров с релевантным, но однозначно не исчерпывающим для задачи такого объема набором навыков. И есть условие эксперимента: пройти этот путь таким составом, не привлекая полноценную команду разработки.

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

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

Эти доработки вместе со всем остальным, что предстояло довести до ума, и составляли объем работ, который в четыре руки было не вытянуть. Так что мы вооружились Codex и взялись за дело.

Механика работы с агентами

От классического процесса у нас остались разве что стартовые созвоны и базовый гит-флоу. Мы точно так же собираемся, обсуждаем, что нужно сделать, и набрасываем роадмап текущего этапа. Разделения на фронт и бэк в привычном понимании у нас нет, поэтому задачки делим пополам без оглядки на специализацию. Друг другу при этом не мешаем. Codex каждый запускает у себя, разработка идет в личной папке на сервере, а готовые фичи мы по старинке пушим в общую dev-ветку и там мержим.

Для работы выбрали GPT-5.6 Sol. Возможно, модель где-то уступает в способностях тому же Opus 5.5, но по соотношению цена — качество ощутимо выигрывает, плюс позволяет гибко настраивать уровень ризонинга под разные задачи.

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

Поэтому сначала мы описываем, что нужно сделать, и просим разложить задачу на мелкие шаги. Нередко получается простыня из десятка пунктов, в каждом из которых еще по 10–15 подпунктов, и не все из них толковые: агент любит перестраховываться, добавлять избыточные проверки или вписывать бесполезные шаги. Такие сомнительные места мы оспариваем и просим убрать до тех пор, пока план не придет в рабочий вид. По сути, план становится спецификацией: еще до первой строчки кода зафиксировано, что и в каком порядке делаем и с помощью чего.

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

Начинается всё с AGENTS.md, основного файла агента, который Codex подгружает в начале каждой сессии. Раз этот файл попадает в контекст всегда, складывать в него всю документацию было бы расточительно. Поэтому в нем мы прописываем линки на все остальные мини-доки: нужна архитектура проекта — смотри вот этот документ, нужна информация по серверу — открывай этот. Сама документация мало отличается от той, что ведут в классической разработке, просто разбита на небольшие файлы по темам.

Следом агент открывает файл с прогрессом. В нем он отмечает, на каком пункте плана остановился и что успел сделать на предыдущем шаге, так что держать всю историю в памяти ему не нужно. Отсюда он узнает номер следующего пункта и загружает его из плана. 

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

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

Что мы точно не рискуем делегировать, так это тестирование. Теоретически проверять UI мог бы и сам агент. Для этого достаточно подключить Playwright через MCP, и он сам откроет браузер, прокликает интерфейс и снимет скриншоты. Каждый такой прогон, конечно, заметно подъест токены, но это только полбеды.

Главная проблема в том, что агент проверяет чисто функционально. Если кнопка не нажимается или ничего не делает, он это заметит. А вот сопутствующие баги может пропустить: например, функция по нажатию отрабатывает, но сама кнопка визуально никак не реагирует, или элемент съехал и стоит криво. Человек замечает такие вещи сразу, даже если специально их не ищет, так что плотность покрытия у ручной проверки всё равно выше. Получается и надежнее, и быстрее. 

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

Цена вопроса

Хоть мы и выстроили процесс с умом, идеализировать его не будем. У агентной разработки есть обратная сторона и своя цена за все возможности, которые она открывает. 

Самое болезненное — ты расплачиваешься знанием своего проекта. Когда пишешь код сам, со временем начинаешь ориентироваться в нем чуть ли не с закрытыми глазами и можешь с ходу назвать модуль, а иногда и строчку, где происходит то, что тебе нужно. Здесь же кодовая база формируется без твоего прямого участия. Мы хорошо представляем, из каких блоков состоит система и за что каждый отвечает. Но что именно происходит внутри, например, конкретного модуля, с ходу сказать уже не можем. Даже саму задачу агенту порой формулируешь менее точно, чем мог бы при полном погружении в код.

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

Отдельная проблема с оценкой сроков. Задача, которая выглядит простой, может занять у агента сутки, и срок легко умножается на два-три. А бывает наоборот: агент быстро и с первого раза выдает ровно то, что нужно. Предсказать заранее, какой из вариантов проиграется, практически невозможно. Например, у нас так случилось со сборками: в какой-то момент агент решил сделать процесс более надежным и принялся после каждой правки заново пересобирать Docker-образ, чтобы в случае чего иметь точку отката. Заметили мы это, когда на мелкий фикс он потратил около трех часов, хотя руками ушло бы от силы полчаса. 

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

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

Почему это всё-таки работает

При всех перечисленных минусах на стороне агентной разработки остается главное, ради чего мы всё это и затевали, — общая скорость работы. Отдельные задачи могут затянуться, но в сумме мы движемся заметно быстрее, чем двигались бы вдвоем по классической схеме. А значит, быстрее собираем MVP, отдаем его на пилот и проверяем гипотезу. И обходится такая проверка дешевле: сил и людей на нее уходит меньше, так что и ошибиться не так дорого.

К тому же сильно падает порог входа в незнакомые технологии. Понятно, что без базового опыта в разработке тут никуда. Но имея этот фундамент, с агентом можно зайти практически в любой язык или фреймворк без долгой раскачки. На нашем примере: опенсорсная основа продукта написана на непрофильном для нас JS. Подтянуть его мы бы, конечно, смогли, но на это ушло бы время. С агентами этот этап практически выпадает, а на распространенных языках, где больше всего примеров и документации, они пишут особенно уверенно.

К слову о смежных задачах. Отдельным открытием для нас стало то, как легко агент закрывает вопросы с версткой и оформлением. Если нужно подогнать продукт под фирменный стиль компании, можно дать агенту ссылки на ее ресурсы и попросить собрать брендбук. А следом поставить задачу: «У тебя есть проект и есть брендбук — приведи интерфейс в соответствие». С этим агент справляется с первого запроса и почти всегда без замечаний.

Ну, и конечно, экономика проекта, куда без нее. Без агентов на этот проект, по нашей прикидке, понадобились бы фронтенд-разработчик, двое на бэкенд, тестировщик и девопс. Мы же справляемся вдвоем с двумя Pro-подписками по 200 долларов. Каждая подписка, по сути, заменяет еще одного человека в команде, только обходится несравнимо дешевле. Будь у нас еще по одной, агентов можно было бы оставлять работать каждую ночь, а не только когда горят сроки, и дело пошло бы еще быстрее. 

Что в итоге?

Эксперимент пока не закончен, и работы впереди еще достаточно. Весь базовый функционал системы уже собран и работает, а мы заканчиваем сборку ролевой модели. Поскольку права доступа затрагивают почти все компоненты, впереди нас ждет большая ручная проверка. Как только смержим эти доработки и закроем мелкие попутные баги, отдадим сборку штатному тестировщику, а следом раскатаем уже на сотрудников внутри нашей компании.

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

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

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

Ну а если вы тоже присматриваетесь к разработке силами ИИ-агентов и хотите провести похожий эксперимент у себя, вот несколько советов:

• Не ждите волшебной палочки. Просто открыть консоль и попросить агента «сделать красиво» в одной бесконечной сессии может сработать разве что для простенького одностраничника на пару дней работы. Поэтому выстройте процесс заранее, продумайте подробный план, подготовьте доки и определитесь, как должен выглядеть ваш конечный результат. 

• Не подпускайте к разработке слабые модели и не снимайте ограничения полностью. Потенциально рискованные действия в терминале лучше всегда оставлять под ручным подтверждением, а для кода брать только старшие, сильные модели. Когда мы еще до старта проекта набивали шишки на своих тестовых задачах, один из нас запустил более слабую модель без ограничений на выполнение команд. В какой-то момент агент просто снес базу данных и невозмутимо отчитался: «Бэкапов у меня нет, но там и данных особо не было, поэтому я решил, что она тебе не нужна». На рабочем проекте такая самодеятельность обойдется слишком дорого.

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

На этом всё! Если у вас есть похожий опыт разработки с агентами или вопросы по нашему процессу — добро пожаловать в комментарии, будем рады обсудить.