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

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

Начнем с описания функций, существующих в разработке. Далее они понадобятся для понимания написанного. В любом зрелом процессе разработки присутствуют:

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

• Системный анализ. Здесь мы переводим бизнес-требования в описание того, как должна работать система после изменений, включая функциональные и нефункциональные требования.

• Подготовка к разработке. Техническое задание разбивается на задачи, уточняется с учетом текущего состояния проекта и наложенных ограничений. Сформированный набор задач попадает в бэклог и планируется к реализации. Тут же проводятся груминги, технические исследования и оценки, необходимые для определения сроков и объема реализации.

• Разработка. Здесь мы превращаем подготовленные требования и технические решения в работающий программный продукт.

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

• Тестирование. Проверяется соответствие реализации требованиям и выявляются ошибки в работе нового функционала.

• Релиз. Проверенная реализация доставляется в production и становится доступна пользователям.

Для простоты рассуждения представим разработку как линейный процесс. В крупных, конвеерных командах, за каждой из этих функции стоит конкретный ответственный человек.

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

Эксперимент №1

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

Мы получаем максимальное ускорение, и наше единственное ограничение это подготовка самих задач и требований к ним. В крупных командах этот процесс может занимать недели, а значит в системе все равно будет серьезное ограничение в виде подготовительных работ. Отдать и эти работы агентам означало бы разработку ради разработки. Но вместе с максимальной скоростью мы получаем уже две значимые неясности: мы не только не знаем как работает наша система, мы даже не знаем получили ли мы нужный результат. То-есть фактически получаем “кота в мешке”. В крупных проектах первое допущение уже недопустимо, второе может грозить потерей бизнеса. Ситуация выглядит даже комично, ведь в этом случае о том как работает наша система мы узнаем от ее пользователей. Так точно поступать не стоит.

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

Эксперимент №2

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

При таком подходе то что разработчик делает за день, машина делает за час. Но несмотря на скорость выпуска новых фич, появляется бутылочное горлышко в виде QA инженера. Хорошее тестирование это не просто “тык на кнопку”. Это вдумчивое чтение задачи или спецификации, анализ соответствия требований к реализации, проверка смежных функций и описание найденных неверных кейсов. Если предположить что QA инженер на проверку каждой фичи тратит один час, значит один человек способен проверить не более 8 функций в день. Это значимое ограничение. Скорость выпуска новых фич ограничивается количеством QA инженеров. При этом сам код, становиться для нас черным ящиком. Утрачивается важное инженерное знание о системе. Мы больше не знаем что там происходит, мы просто догадываемся как это работает. Догадываемся, потому что всех фоновых процессов мы не видим.

Дополнительно возникают сложности с разбиром инцидентов. Хорошо если час простоя обходиться в 1000-1500 рублей, а если в 100 000, а в 500 000. А таких компаний не мало. Разобраться в проблеме, не понимая как работает система — задача не простоя. Это как привезти ваш электромобиль на ремонт к человеку, которые впервые такие видит. А любой сбой отражается не только на деньгах, но и на лояльности клиентов. Подобная экономия на разработке делает очень дорогим каждый сбой.

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

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

Эксперимент №3

Первые два эксперимента показали нам проблемы и ограничения, с которыми мы неизбежно столкнемся, если попробуем полностью заменить этап агентом. Как же тогда ускорить разработку, или хотя бы сократить ее стоимость? Первое на что можно подумать: нанять менее компетентных разработчиков за меньшие деньги, ведь AI поможет! Не поможет. ИИ снижает стоимость выполнения отдельных инженерных задач, но не снижает стоимость инженерной компетенции. Это основа, на которой строятся стабильные программные продукты. Получаеться лучше чем в экспериментах №1 и №2- но все равно плохо.

Как же может выглядеть выстроенный процесс разработки с AI агентами или LLM, чтобы и результат был понятным и кодовая база могла поддерживаться и скорость была разумная. Давайте попробуем к каждой роли добавить помощника в виде агента. Что получиться?

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

Если допустить что внедрение агента на каждый этап даст нам средний выигрыш всего в 3% — мы получим экономию в 21% на всем процессе. Это уже 1/5 времени, без потери качества! 2,5 месяца экономии в год. И сокращение стоимости разработки до ~20%. Уже звучит хорошо.

Чуть-чуть сокращая трудозатраты на каждом этапе, мы существенно экономим на всем процессе.

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

Резюме

Тут как с передвижением. Сначала первые человеки ходили пешком. Долго добирались из одного поселения в другое отдаленное. Потом пересели на лошадей, гужевые повозки. Скорость передвижения возросла, потому что изменился сам способ перемещения. Затем появились первые автомобили, но скорость перемещения особо не выросла, а скорее даже упала, — первые автомобили двигались 15-20 км/ч. А настоящий скачек произошел позже, когда вместе с автомобилями появились дороги и инфраструктура. Ты больше не мог поехать в любом направлении, но ты быстро перемещался там где это возможно. И только когда появился кардинально новый способ перемещения, самолеты, мы по настоящему быстро начали перемещаться по планете.

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

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