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

О том, как переход от экспериментов с AI к его системному использованию меняет выпуск MVP, требования к процессам и роль разработчика в команде, рассказывает Сергей Востриков, руководитель «Битрикс24 Маркетплейс».

Почему классическая модель упирается в экономику гипотез

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

Чтобы разобраться в природе этих ограничений, достаточно обратиться к конкретному примеру. Команда, работающая с «Битрикс24», разрабатывает тиражные и региональные приложения через публичный REST API. По сути, она работает так же, как независимые разработчики маркетплейса: создает приложения, выводит их на рынок и проверяет спрос на реальных пользователях.

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

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

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

Так возникает идея попробовать снять ограничение за счет ИИ. Но у этого есть свои нюансы.

ИИ нельзя встроить в старые процессы

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

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

Технологически это означало переход от общей монолитной структуры к независимым приложениям с явными границами. Произошел переход на официальный SDK для бэка и UI Kit для фронта, унифицированные интерфейсы, изолированные фронтенд- и бэкенд-контракты, инструменты, удобные для генерации и повторной сборки.

Код перестает быть центром накопления ценности

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

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

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

Так фокус команды смещается с производства кода на проектирование и формализацию. Документация перестает восприниматься как сопроводительный материал и превращается в основной инженерный актив, который переживает конкретные версии инструментов и моделей.

Меняется профиль разработчика

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

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

ИИ требует более зрелых процессов

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

Code review становится обязательным, а не желательным. Автотесты — не «когда успеем», а постоянная часть процесса, включая модульные и интеграционные проверки. Критерии качества должны быть сформулированы заранее, иначе непонятно, что считать корректным результатом. CI/CD должен работать стабильно, деплой — быть воспроизводимым.

Причина кроется в том, что ответственность за результат все еще лежит на человеке. Модель генерирует код, но не отвечает за продакшн.

ИИ — это стратегический выбор

Когда ИИ становится частью разработки, сначала меняется то, что считалось самым ценным. Центром перестает быть сам код. Его можно переписать или пересобрать. Значение получает описание системы — требования, спецификации, ограничения. Именно они удерживают логику продукта и позволяют воспроизводить его поведение независимо от инструмента. 

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