ГК Softline: разработка с ИИ становится настоящей инженерией
Заказчики просят создавать системы вдвое быстрее и поддерживать старые решения силами, которые в разы меньше прежних. Для этого нужна новая инженерная культура с ИИ-помощниками, «памятью» проекта, проверяемыми результатами и иначе устроенными командами. Об этом сообщает «Код Дурова».
«Еще пару лет назад искусственный интеллект в разработке был личным делом каждого программиста. Открыл чат, написал запрос, получил кусок кода, решил годится или нет. Сегодня эта картина устарела, ИИ перестает быть отдельным окном рядом со средой разработки и становится частью самого производства», — пишет «Код Дурова».
Главная ошибка сейчас — пытаться встроить ИИ в старый производственный конвейер, ничего в нём не меняя. Нельзя просто выдать разработчикам доступ к нейросети и ждать кратного роста производительности. Чтобы получить настоящий, промышленный эффект, придётся пересобрать сам подход к требованиям, проектированию, тестированию, управлению знаниями и оценке результата.
На экспериментальных проектах с помощью ИИ-помощников можно писать около 1600 строк кода в час. Эта цифра звучит эффектно на фоне привычных норм выработки, но сама по себе она почти ничего не говорит о ценности результата. Настоящий эффект от ИИ в разработке измеряется не объемом сгенерированного текста, а в том, насколько быстрее команда проходит путь от бизнес-задачи до работающего решения, сколько ошибок находится ещё до запуска в промышленную эксплуатацию и насколько легко систему потом менять.
ИИ прежде всего снижает стоимость одной попытки, он позволяет быстрее проверить гипотезу, переделать модуль, собрать прототип, написать тесты, разобраться в незнакомом коде или оценить последствия изменившихся требований. Скорость таких попыток становится новой мерой производительности.
Первая волна интереса к генеративному ИИ была сосредоточена вокруг искусства формулировать запросы к модели. Тогда казалось, что стоит найти правильные слова, и нейросеть выдаст качественный результат. Для промышленного продукта этого мало, один запрос — слишком нестабильная штука: результат зависит от контекста, формулировки, настроек модели и десятка других мелочей. Поэтому сегодня фактически происходит переход от одиночных запросов к многоэтапным цепочкам обработки, где несколько моделей и алгоритмов передают задачу друг другу по эстафете.
В качестве эксперимента была собрана система анализа технических заданий. Чтобы обработать один документ, она обращается к нейросетям около 70 раз. Файл разбивается на фрагменты, из них извлекаются требования, ограничения и риски, затем всё это перепроверяется, сопоставляется, анализируется заново, и только после этого превращается в итоговый отчёт. Пользователь видит один документ, но за ним стоит целая система связанных операций. Такая архитектура позволяет стабилизировать результат и управлять его качеством. Единицей работы в ИИ-разработке становится уже не отдельный запрос, а вся цепочка целиком.
Одна из главных проблем нейросетей — умение убедительно формулировать выводы, которые ничем не подкреплены. Поэтому в серьёзных системах мало получить ответ, нужно понимать, на чём он основан. На проектах стараются «заземлять» каждый значимый вывод на конкретный источник. Если система нашла в техническом задании требование или риск, она обязана показать документ, раздел и фрагмент текста, из которого сделан этот вывод. Это важно не только для борьбы с галлюцинациями нейросети, ссылка на источник делает результат проверяемым и превращает ИИ из непрозрачного советчика в рабочий инструмент аналитика.
Сильная сторона языковых моделей — умение работать с неструктурированными, неоднозначными данными. Но дальше результат по возможности должен возвращаться в область обычных, проверяемых алгоритмов. Например, модель может вытащить из документа список функций, интеграций или ограничений, а вот полноту этого списка, допустимые значения, арифметику, связи между элементами и непротиворечивость данных дальше должны проверять уже обычные, детерминированные алгоритмы, без всякой вероятностной магии. Искусственный интеллект не отменяет классическую разработку, наоборот: надёжные ИИ-продукты рождаются на стыке двух подходов.
Ещё один способ повысить качество — не принимать первый ответ за окончательный, но простой команды «подумай ещё раз» обычно недостаточно. В экспериментах проверка устроена как отдельный этап: одна модель формирует результат, другая выступает критиком, ищет пропуски, противоречия, слабые места. После этого исходный запрос уточняется, и анализ запускается заново. Для разных этапов можно использовать разные модели, самая мощная и дорогая модель не всегда нужна, чтобы что-то классифицировать, проверить формат или найти простое несоответствие. Архитектура должна сама распределять задачи по сложности.
Нейросети склонны отвечать уверенно даже тогда, когда данных им явно не хватает, а ещё при оценке проектов они нередко излишне оптимистичны: недооценивают сложность интеграций, организационные ограничения и объем скрытой, невидимой на первый взгляд работы. В экспериментальном анализаторе оценки без дополнительных поправок иногда оказывались занижены в два-три раза. Причина понятна: техническое задание редко описывает реальную среду заказчика исчерпывающе, за его рамками остаются качество данных, состояние старых систем, доступность нужных специалистов, внутренние согласования и ещё десятки факторов. Например, вместо одной-единственной цифры лучше показывать диапазон, степень уверенности и список допущений, и отдельно, какой информации не хватает и как её появление может изменить оценку.
В обычной разработке тестирование прежде всего подтверждает, что программа работает по заданным правилам. В ИИ-продукте у тестов появляется вторая функция: они помогают постепенно формировать нужное поведение системы. Можно ничего не менять в самом коде, но подправить инструкции для ИИ-помощников, порядок операций, контекст, критерии проверки, распределение задач между моделями, и после каждого цикла тестирования система начинает лучше справляться с определенными типами запросов. Поэтому роль тестировщика расширяется, в некоторых проектах именно специалисты по качеству, уже после того как готова базовая логика, «доводят» поведение ИИ-помощников: разбирают ошибки, меняют инструкции, добавляют примеры, придумывают новые проверочные сценарии.
Здесь есть серьёзный риск — натренировать систему на слишком узком наборе тестов. Если помощника учили на документах из финансовой сферы, он может отлично разбираться в банковской терминологии, но плохо в медицине, промышленности или мобильной разработке. Широта тестовой выборки становится одним из главных условий качества. Проектируется не ответ для одного конкретного документа, а система, способная работать в разных областях и не терять устойчивость при смене входных данных.
Одна из самых болезненных задач в корпоративной разработке — поддержка старых систем. Документация устарела, часть архитектурных решений вообще нигде не зафиксирована, авторы кода давно уволились, а нынешняя команда тратит уйму времени просто на то, чтобы восстановить контекст: кто, что и почему когда-то сделал. ИИ-помощники позволяют иначе организовать знания о проекте. Внутри репозитория можно собрать структурированную базу знаний: описание архитектуры, бизнес-правил, зависимостей, ключевых решений и особенностей отдельных модулей. Помощник сначала изучает эту базу, потом выполняет задачу, а после завершения работы сам обновляет знания с учётом того, что изменил. Так возникает постоянно актуальная память проекта.
Особенно перспективен такой подход для старых, плохо документированных систем. Даже запущенный проект можно постепенно описать с помощью ИИ, превратив код, историю изменений и разрозненные материалы в связанную базу знаний. Это поможет заметно снизить зависимость компании от памяти отдельных сотрудников. Сегодня контекст проекта обычно разорван между десятком источников. Требования — в одной системе, задачи — в другой, код — в третьей, результаты тестов — в четвёртой, а значительная часть решений вообще осела в переписке, протоколах и заметках со встреч. Человеку такая раздробленность просто неудобна, для ИИ она критична. Модель принимает толковые решения только тогда, когда видит всю историю: что попросил бизнес, как требование было понято, почему выбрана именно такая архитектура, какие ограничения всплыли и на какие компромиссы пошли.
Рынок нейросетей меняется слишком быстро, чтобы жёстко привязывать архитектуру продукта к одному поставщику. Модель, которая сегодня кажется лучшей, через несколько месяцев может уступить новому решению, подорожать, поменять условия использования или вовсе исчезнуть из инфраструктуры провайдера. Поэтому одна из задач инженера — свести к минимуму зависимость продукта от особенностей конкретной нейросети. Речь не о том, что маленькая локальная модель и крупнейшая коммерческая система дадут одинаковый результат, но решения одного класса должны быть по возможности взаимозаменяемы. Если при переходе между сопоставимыми моделями система полностью меняет поведение, скорее всего, значительная часть логики спрятана не в архитектуре продукта, а в случайных особенностях конкретной модели. Такая зависимость рано или поздно станет источником и технического, и коммерческого риска.
ИИ-помощники уже умеют писать код, проектировать структуру модулей, создавать документацию и тесты. В отдельных задачах результат оказывается сильнее, чем у неопытного специалиста, но из этого не следует, что разработчики станут не нужны, скорее изменится структура команды. Меньше времени будет уходить на механическое выполнение типовых операций, больше на постановку задачи, архитектуру, работу с требованиями, контроль качества, безопасность и понимание бизнес-контекста. Разработчик будет всё меньше напоминать человека, который вручную пишет каждую строчку, и всё больше, инженера, управляющего целой командой специализированных ИИ-помощников. Аналитик станет отвечать не только за описание требований, но и за качество контекста, который получает ИИ, тестировщик — не только искать дефекты, но и формировать поведение системы, архитектор — выстраивать взаимодействие между людьми, моделями, данными и обычным программным кодом. Такой переход окажется куда сложнее, чем покупка очередной лицензии на ИИ-помощника, понадобятся новые стандарты разработки, новые метрики и переобучение специалистов. Именно эта работа определит, получит ли компания реальный экономический эффект, или так и останется на уровне красивой презентации.
В ближайшие годы разработка с участием ИИ станет нормой. Возможно, само модное словечко «вайб-кодинг» — написание кода «на интуиции», по ощущению, без строгого плана — исчезнет так же быстро, как появилось: работа с ИИ-помощниками станет обычной частью профессии и перестанет нуждаться в отдельном названии. Между прототипом, собранным за вечер, и промышленной системой останется огромная дистанция, её не преодолеть одним удачным запросом к нейросети. Преимущество получат те, кто сумеет выстроить управляемую среду: объединить знания о проекте, обеспечить прослеживаемость требований, встроить автоматические проверки, научиться измерять неопределенность и постоянно улучшать поведение ИИ-помощников на основе тестов. ИИ действительно позволяет писать быстрее, но куда важнее другое: он заставляет нас наконец разобраться, как именно мы разрабатываем программное обеспечение, где теряем время и почему дорогие ошибки обнаруживаются слишком поздно. Главный эффект новой технологии в том, что у индустрии появился шанс заново спроектировать сам процесс создания цифровых продуктов.
Подписывайтесь на наш Telegram-канал, чтобы быть в курсе всех новостей и событий Рунета.
