ГК Softline: почему разработка с ИИ становится настоящей инженерией

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

Роман Смирнов, коммерческий директор компании по заказной разработке «Девелоника» (fabricaONE.AI, акционер — ГК Softline) уверен, что нужна — новая инженерная культура: с ИИ-помощниками, «памятью» проекта, проверяемыми результатами и иначе устроенными командами.

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

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

Softline: Строки кода больше ничего не доказывают

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

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

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

У любого ответа должно быть подтверждение, уверены эксперты Softline

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

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

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

Softline: Критика результата — не опция, а часть процесса

Ещё один способ повысить качество — не принимать первый ответ за окончательный, но простой команды «подумай ещё раз» обычно недостаточно. В наших экспериментах проверка устроена как отдельный этап: одна модель формирует результат, другая выступает критиком, ищет пропуски, противоречия, слабые места. После этого исходный запрос уточняется, и анализ запускается заново. Для разных этапов можно использовать разные модели, самая мощная и дорогая модель не всегда нужна, чтобы что-то классифицировать, проверить формат или найти простое несоответствие. Архитектура должна сама распределять задачи по сложности. В проекте по анализу техзаданий повторная проверка находила дополнительные риски, которые ускользали при первом проходе, примерно в 10–20% случаев. Это не универсальная цифра для любых документов, она хорошо показывает: одно-единственное обращение к модели не должно становиться основанием для важного решения.

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

Тестирование превращается в обучение системы

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

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

У проекта должна появиться собственная память

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

Особенно перспективен такой подход для старых, плохо документированных систем, уверены в Softline, даже запущенный проект можно постепенно описать с помощью ИИ, превратив код, историю изменений и разрозненные материалы в связанную базу знаний, это поможет заметно снизить зависимость компании от памяти отдельных сотрудников. Сегодня контекст проекта обычно разорван между десятком источников. Требования, в одной системе, задачи — в другой, код — в третьей, результаты тестов — в четвёртой, а значительная часть решений вообще осела в переписке, протоколах и заметках со встреч. Человеку такая раздробленность просто неудобна, для ИИ она критична, модель принимает толковые решения только тогда, когда видит всю историю: что попросил бизнес, как требование было понято, почему выбрана именно такая архитектура, какие ограничения всплыли и на какие компромиссы пошли. Это не значит, что все компании должны перейти на одну программу учёта, но данные должны стать связанными и понятными машине. Изменение бизнес-требования нужно уметь проследить до архитектурного решения, кода и тестового сценария. Тогда ИИ сможет оценить, как новое пожелание заказчика повлияет на всю систему. Именно здесь скрыт один из самых заметных экономических эффектов технологии, в снижении стоимости изменений, особенно на поздних этапах проекта. При этом скорость доработок не должна создавать у бизнеса иллюзию, будто требования можно менять бесконечно и без последствий. ИИ ускоряет реализацию, но не отменяет необходимости управлять объёмом проекта, приоритетами и ответственностью за принятые решения.

Нельзя строить продукт вокруг одной модели

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

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

Softline: Исчезнет не разработчик, а привычное разделение труда

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

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

В Softline специалисты уверены, в ближайшие годы разработка с участием ИИ станет нормой, возможно, само модное словечко «вайб-кодинг» — написание кода «на интуиции», по ощущению, без строгого плана — исчезнет так же быстро, как появилось: работа с ИИ-помощниками станет обычной частью профессии и перестанет нуждаться в отдельном названии. Но между прототипом, собранным за вечер, и промышленной системой останется огромная дистанция, её не преодолеть одним удачным запросом к нейросети. Преимущество получат те, кто сумеет выстроить управляемую среду: объединить знания о проекте, обеспечить прослеживаемость требований, встроить автоматические проверки, научиться измерять неопределенность и постоянно улучшать поведение ИИ-помощников на основе тестов. ИИ действительно позволяет писать быстрее, но куда важнее другое: он заставляет нас наконец разобраться, как именно мы разрабатываем программное обеспечение, где теряем время и почему дорогие ошибки обнаруживаются слишком поздно. Так что главный эффект новой технологии в том, что у индустрии появился шанс заново спроектировать сам процесс создания цифровых продуктов.