Привет, Хабр!

Я Дмитрий Старов, директор департамента «Инструменты и технологии разработки» компании «Диасофт».

 Еще относительно недавно вопрос звучал так: сможет ли искусственный интеллект писать код?

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

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

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

Это наблюдение заставило нас в «Диасофт» по-другому посмотреть на роль AI. Мы не считаем, что основные усилия должны быть направлены на то, чтобы модель писала код еще лучше. Все гораздо серьезнее, потому что использование AI полностью перестраивает процесс разработки и даже сам состав инженерной команды. 7 октября я вместе со своими коллегами в прямом эфире покажу как устроена наша AI SDLC архитектура (cсылка - в конце статьи). 

AI уже научился писать код. И что дальше?

Развитие AI в разработке последние несколько лет идет вполне предсказуемо.

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

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

При этом требования к корпоративному ПО остались прежними: надежность, стабильность, производительность, безопасность.

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

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

Производство ПО – это больше, чем написание кода

Есть простая аналогия.

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

С разработкой программного обеспечения происходит примерно то же самое.

IDE – это рабочее место инженера. SDLC – производственная система, которая связывает требования, архитектуру, разработку, тестирование, выпуск и сопровождение продукта.

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

Но жизненный цикл разработки остается прежним.

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

Языковая модель видит только часть этой картины. Поэтому вопрос сегодня ставится  уже немного иначе. Дело не в том, насколько хороша конкретная LLM. Гораздо важнее, в какой инженерной среде она работает и какие знания доступны ей в момент принятия решения.

Почему AI-ассистента недостаточно

После первых экспериментов с AI возникает вполне закономерный вопрос: если современные модели уже умеют писать код, искать ошибки и работать с репозиториями, почему бы просто не поручить им разработку целиком?

На практике все оказывается сложнее. Современные LLM действительно стали намного сильнее, чем два-три года назад. Но в enterprise-разработке проблема редко сводится к тому, чтобы написать очередной класс или метод. Основная сложность в другом: принять решение, которое не сломает систему через полгода.

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

Проблема в том, что этот контекст почти никогда не хранится в одном месте.

Информация распределена между спецификациями, архитектурной документацией, кодом и корпоративной базой знаний. Что-то вообще существует только в голове у архитекторов и ведущих разработчиков.

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

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

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

Отсюда и начинается разговор об организации процесса.

Мы начали менять не инструменты, а сам процесс разработки

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

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

Работая над развитием продуктов Digital Q, мы решили посмотреть на роль AI иначе.

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

Этот вопрос постепенно привел нас к архитектуре AI-Native SDLC (или просто AI SDLC). Здесь важна одна деталь: это не абстрактная архитектура поверх произвольного стека. Мы строим ее поверх low-code экосистемы Digital Q, которую разрабатываем больше десяти лет и в которой уже реализованы сотни типовых сервисов и компонентов корпоративного класса. Это принципиально: agentic-подход в чистом поле и agentic-подход поверх зрелой платформы – это два разных по надежности и экономике процесса, и ниже я объясню это.

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

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

Три вывода, к которым мы пришли

Работая над архитектурой AI SDLC, мы не пытались найти «идеальную» языковую модель. Скорее наоборот: хотелось понять, какие принципы останутся актуальными вне зависимости от того, какая LLM используется сегодня и какая появится через год.

В результате сформировались три базовых принципа.

Первый – спецификация должна сопровождать весь жизненный цикл разработки.

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

Второй вывод касается роли самой модели.

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

На практике мы все чаще приходим к другой мысли. Намного большее значение имеет не сама модель, а harness – среда, в которой она работает. Значение имеет то, какие данные ей доступны, как она проверяет свои выводы, каким ограничениям обязана следовать и что происходит, если результат разошелся со спецификацией.

От ответов на эти вопросы качество системы зависит сильнее, чем от очередного обновления конкретной модели.

Это можно проверить эмпирически. Мы прогоняем через один и тот же harness разные модели (открытые и закрытые) и держим большинство из них на собственных серверах, а не в публичном облаке. Разброс в качестве результата между разными моделями оказывается заметно меньше, чем разброс между хорошо и плохо настроенной обвязкой: гейтами, валидаторами, политиками безопасности, средой исполнения. Это не значит, что модель не имеет значения. Harness определяет, сможет ли модель вообще раскрыть свой потенциал в конкретной инженерной задаче.

Третий принцип связан с архитектурой агентской системы.

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

Пока мы не видим, что такой подход работает в крупных корпоративных системах.

Разработка давно устроена иначе. Аналитики, архитекторы, разработчики, тестировщики, специалисты по информационной безопасности решают разные задачи и работают с разным уровнем контекста.

Логично, что применение AI развивается в том же направлении. Есть и более практическая причина не поручать разработку и проверку одному и тому же агенту. Агент, который только что написал код, неизбежно несет в контексте предпочтения, сложившиеся по ходу написания.  Это плохой фон для объективной проверки. Поэтому агент-критик у нас – это, как правило, отдельный экземпляр с чистым контекстом, который собирает нужные ему знания заново, под задачу проверки, а не наследует их от того, кто писал код.

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

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

Low-code – не инструмент, а фундамент

Здесь стоит сказать отдельно о роли low-code платформы, потому что без этого архитектура AI-Native SDLC выглядит неполной.

Идея в том, что агент почти никогда не должен писать сервис с нуля. Для подавляющего большинства типовых задач (аутентификация, работа со справочниками, интеграция с очередями сообщений, работа с BPMN-процессами) в экосистеме Digital Q уже есть готовые, годами обкатанные компоненты. Задача агента чаще сводится не к тому, чтобы изобрести решение, а к тому, чтобы сконфигурировать существующий сервис или дописать в нем несколько десятков строк.

Это дает два эффекта сразу. Во-первых, резко снижается риск галлюцинаций: агенту ни к чему выдумывать несуществующий метод, внешний контракт API или запрос к базе данных, если рядом лежит готовый, уже проверенный компонент для реиспользования. Во-вторых, меняется экономика генерации. Если каждый запрос на новый компонент требует писать инфраструктурный код заново, счет токенов быстро уходит в область, которую сложно назвать рентабельной. Переиспользование готовых компонентов – это, в принципе, то же самое, что делала наша low-code платформа и до появления агентов; агенты просто ускорили и связали этот процесс напрямую со спецификацией.

В одном из недавних кейсов два человека (аналитик и фронтенд-разработчик, даже не из основной команды разработки) за три дня по довольно поверхностному техническому заданию в Excel получили из конвейера рабочий прототип: 27 экранных форм и пять бизнес-сценариев корпоративного класса. В другом кейсе все начиналось с многочасовой записи разговора с клиентом, где вслух проговаривались сценарии работы устаревшей системы, которую нужно было модернизировать. Из этой записи конвейер собрал спецификацию, а уже по ней – несколько десятков бизнес-сценариев в low-code, на новой микросервисной архитектуре.

От отдельных AI-инструментов – к AI-производству

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

Самый простой ответ: создать одного универсального AI-агента, который будет последовательно выполнять все этапы разработки. Но, как мы уже говорили, этот путь плохо работает в enterprise-среде. Универсальный агент быстро теряет контекст, ему сложнее принимать правильные архитектурные решения, а ошибки, допущенные на ранних этапах, начинают распространяться по всей цепочке разработки.

Есть и вторая причина, менее очевидная на первый взгляд, но не менее важная – токеномика. У универсального агента волей-неволей один harness на все случаи жизни: одна LLM, один контекст, один набор инструментов – и все это рассчитано на самую сложную задачу, которая ему может встретиться. В итоге на банальную операцию тратится тот же дорогой инструмент, что и на сложное архитектурное решение.

У каждого специализированного агента может быть свой harness, своя LLM, ровно той мощности, которая нужна для его задачи, а не самая мощная «на всякий случай», свой набор MCP-инструментов и детерминированных скриптов, а часть работы агент вообще выполняет без LLM. Контекст он набирает тот, что нужен для выполнения его этапа, а не тащит за собой всю историю проекта. Это в разы экономит токены.

В Digital Q мы рассматриваем процесс создания программного обеспечения как последовательность специализированных этапов, каждый из которых имеет свои входные данные, критерии качества и результат. Аналогичным образом организована и работа AI: вместо одного универсального агента используется система специализированных агентов, каждый из которых отвечает за свою область работы.

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

По сути, речь идет о переходе от AI-исполнителя отдельных задач к AI как ядру производственного процесса.

Архитектура AI-Native SDLC

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

Работа начинается не с генерации кода, а с выявления потребностей заказчика – Discovery Loop.

Здесь можно анализировать различного рода артефакты общения с заказчиками и исследования рынка: видео- и аудиоматериалы, протоколы встреч, письма, документы свободного формата и т. п. Цель – собрать материалы и выявить истинные бизнес-потребности.

Далее формируем намерения – Intent Loop.

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

Здесь мы говорим о SSD (Specification-Driven Development). AI не пытается самостоятельно интерпретировать требования или восстанавливать замысел разработчика по существующему коду. Он работает со спецификацией как с главным артефактом проекта.

После формирования Intent начинается следующий этап – Implementation Loop.

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

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

Такой подход позволяет избежать ситуации, когда каждое новое действие начинается с чистого листа.

Проверка перестает быть финальным этапом

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

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

Для человека это привычный процесс.

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

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

Для этого используются механизмы VERIFY и Gate.

VERIFY отвечает за непредвзятую проверку результата. Как правило, это отдельный агент – ревьюер, критик, который оценивает результат другого агента на предмет соответствия поставленной задаче, выполнения метрик и ограничений.

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

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

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

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

Почему SDD становится центром всей системы

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

Как я уже сказал, архитектура ИИ-разработки в Digital Q основывается на SDD. В качестве базового SDD-фреймворка мы выбрали OpenSpec, обогатив «ванильный» фреймворк собственными командами-навыками и жизненным циклом. Главная задача нашего фреймворка – превратить спецификацию в единое пространство знаний, которое сопровождает весь жизненный цикл разработки. Именно он связывает между собой бизнес-требования, архитектурные решения, описание API, модели данных, ограничения предметной области, результаты реализации и последующие изменения системы. Благодаря этому AI работает не с разрозненными документами, а с целостной моделью проекта.

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

Спецификация в нашем AI SDLC конечно же не переписывается целиком под каждую новую задачу. Новая задача нуждается в дельта-спецификации – точном описании того, что нужно добавить, изменить или удалить в уже существующем описании сервиса. Эта дельта проходит весь конвейер, и только когда код по ней сгенерирован и проверен, она сливается с основной спецификацией. Такой подход снимает главный страх, который обычно связывают с SSD-подходом, что означает месяцы согласований, как в старых ТЗ. На деле цикл «обсудили с клиентом – поправили спецификацию – увидели готовый результат» занимает часы, в крайнем случае – дни.

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

Платформа взаимодействия агентов друг с другом и человеком

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

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

В экосистеме Digital Q роль оркестратора агентского процесса, как и проводника между агентами и человеком, выполняет платформа Digital Q.Agents – мультиагентная среда и единая точка взаимодействия инженера с AI-сервисами. Через платформу разработчик может работать со спецификациями, получать рекомендации, инициировать выполнение отдельных этапов разработки, анализировать результаты работы агентов, создавать новых агентов и управлять жизненным циклом всего процесса.

На практике это выглядит так. Опытный инженер запускает заранее экземпляр SDLC-процесса, чтобы решить свою конкретную задачу. На вход процессу, как правило, подается задача в трекере с приложенными первичными артефактами – md-файлами с замыслом, протоколами обсуждений и другими материалами. Платформа Digital Q.Agents пошагово (последовательно или параллельно) запускает агентов согласно схеме процесса, отслеживает их входы-выходы, разрешает конфликты и нештатные ситуации. А также реализует принцип Human-in-the-Loop – на определенных шагах процесса может потребоваться аппрув человека или его суждения и ответы на вопросы. Для этого к каждому экземпляру процесса привязан собственный чат-канал, в котором удобно вести диалог и подтверждать или уточнять решения, а также остановить либо вернуть процесс к определенному шагу.

Мы стремимся минимизировать общение человека с AI SDLC-процессом. В идеале значительное количество экземпляров процесса должно «пролетать» без HITL-взаимодействия. То есть роль product engineers должна сводиться к функциям наблюдения, измерения и контроля над экземплярами процесса, к подготовке качественной спецификации и навыков для агентов. Тем не менее HITL пока остается важной точкой в процессе.

Таким образом, платформа Digital Q.Agents становится не только оркестратором и чат-интерфейсом к языковой модели, но и полноценным рабочим пространством, в котором человек и AI совместно участвуют в создании программного продукта.

Что это меняет для разработчика

Когда говорят о применении AI в разработке, разговор довольно быстро сводится к одному вопросу: заменит ли он программистов, аналитиков, тестировщиков и других специалистов.

Мне кажется, сама постановка вопроса не совсем точна.

Если посмотреть на то, как менялась разработка последние двадцать лет, хорошо видно одну закономерность. Да, каждый новый инструмент забирал у инженеров часть рутинной работы. Но! Тем самым он давал больше возможностей для выполнения творческих, креативных задач. И таких задач тут же становилось больше – рынок сразу начинал требовать автоматизации там, где раньше о ней и мечтать не мог.

Когда появились современные IDE, отпала необходимость помнить наизусть синтаксис и вручную искать ошибки в коде. Затем пришли системы контроля версий, CI/CD, автоматизированное тестирование, инфраструктура как код. Каждый такой этап менял повседневную работу команды, но не делал инженеров менее нужными.

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

С AI происходит примерно то же самое.

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

У нас в компании есть возможность сравнить это не абстрактно, а на своей же истории. В начале карьеры я застал отдел разработки регионального банка из трех-четырех человек. И этого хватало. Когда я пришел в «Диасофт», во флагманской на тот момент линейке продуктов работало около восьми разработчиков. Сегодня в каждом направлении – сотни, и это без учета AI. Дело не в том, что делать то же самое стало сложнее. Причина в том, что задач стало на порядки больше, технологии сами порождают потребности, которые раньше никому не приходили в голову. Похожий эффект известен как парадокс Джевонса, когда удешевление ресурса не снижает, а повышает спрос на него. По нашим предварительным оценкам, команды, которые всерьез внедряют AI SDLC такого типа и грамотно работают с экономикой токенов (в первую очередь за счет переиспользования готовых компонентов, о котором я говорил выше), получают не менее 30% прироста эффективности уже сейчас, а на более длинном горизонте эффект может быть кратным, а не процентным.

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

Здесь же стоит отдельно сказать про доменную экспертизу. Компонентов в экосистеме уже достаточно, чтобы инженерная часть задачи «как собрать систему из готовых кубиков» решалась быстро. А вот то, из каких конкретно кубиков и в какой последовательности собирать продукт, который решит реальную задачу конкретного бизнеса, – это вопрос понимания предметной области, а не конкретного фреймворка. Поэтому в наших командах ценность смещается от «я реакт-разработчик» или «я go-разработчик» к «я понимаю, как устроен этот рынок и что нужно его пользователям». Этот навык AI пока не может взять на себя.

Все больше внимания приходится уделять тому, что пока плохо поддается автоматизации: постановке задачи, проектированию, работе с требованиями, оценке компромиссов и проверке результата.

В этом смысле AI меняет профессию разработчика примерно так же, как когда-то изменили ее современные IDE. Они не отменили инженерную работу. Они освободили время для более сложных задач.

Похоже, сейчас начинается следующий этап этого процесса.

Следующий этап развития AI в разработке ПО – перестройка SDLC

За последние два года индустрия сделала огромный шаг вперед. ИИ научился:

  • писать код;

  • анализировать репозитории;

  • генерировать тесты;

  • выполнять отдельные задачи практически без участия человека.

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

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

Сегодня все чаще возникает ощущение, что мы постепенно перестаем говорить об AI как об инструменте. Он становится частью производственной системы. Так же, как когда-то системы контроля версий, CI/CD, автоматизированное тестирование и DevOps перестали восприниматься как отдельные технологии и превратились в неотъемлемые элементы процесса разработки.

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

Мы в «Диасофт» рассматриваем развитие AI не как добавление еще одного полезного инструмента разработчику, а как возможность переосмыслить весь жизненный цикл разработки программного обеспечения. Мы называем этот подход AI-Native SDLC, или просто AI SDLC. И считаем, что здесь начинается следующий этап эволюции технологий разработки корпоративных систем.

Кстати, 7 октября в 18:00 мы проведем онлайн-показ новой ИИ-версии нашей экосистемы разработки – AI-driven Digital Q. Я и мои коллеги покажем, как ИИ-агенты встраиваются в разные этапы разработки, а также расскажем, как сократить стоимость ИИ-разработки, контролировать расходы на модели и перейти от пилотов с ИИ к промышленному использованию. Для получения ссылки на трансляцию нужно пройти регистрацию.