Код на стероидах: как ИИ меняет российскую разработку

Насколько широко российские компании сегодня используют ИИ-ассистентов в разработке? Какие бизнес-задачи чаще всего закрываются с помощью ИИ?

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

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

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

Какие направления автоматизации разработки вы считаете наиболее перспективными в 2026 году?

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

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

Gartner прогнозирует, что к 2027 году до 30% уязвимостей будут связаны с практиками vibe coding — интуитивной генерации кода с помощью ИИ без глубокого понимания. Какова ситуация в России?

Для России это тоже характерно. Проблема не в том, что разработчик использует ИИ, а в том, как именно он это делает. Если ставить машине верхнеуровневую, размытую задачу, она сгенерирует некий «мегакод», разобраться в котором будет крайне сложно. Чем менее детализировано техническое задание, тем менее предсказуем результат.

Какие типы ошибок и уязвимостей наиболее характерны для ИИ-сгенерированного кода?

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

Какие риски вы видите в применении ИИ-генерации для создания критически важных сервисов (финансы, промышленность, госсектор)?

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

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

Насколько велик риск, что автоматические системы проверки (SAST, DAST) пропускают уязвимости в ИИ-коде из-за нестандартных паттернов или избыточной сложности?

Классическому SAST-инструменту всё равно, кто писал код — человек или модель. Уязвимый паттерн, например в конструкции if-else, будет найден вне зависимости от его происхождения. Проблема не в нестандартности кода, а в его объёме и сложности. Если ИИ генерирует огромные, запутанные фрагменты, то даже если инструмент найдёт потенциальные проблемы, разобраться в них и подтвердить их наличие человеку будет очень сложно.

Однако есть нюанс с ML-инструментами анализа. Если для проверки кода, написанного одной нейросетью, использовать анализатор, построенный на другой, есть риск, что они будут «одобрять» друг друга. Машина может посчитать код, сгенерированный другой машиной, корректным, даже если он содержит ошибки. Поэтому для проверки ИИ-кода надёжнее использовать классические анализаторы, основанные на правилах.

Согласно исследованию Sonar, 96% разработчиков не доверяют ИИ-коду, но только 48% его проверяют. Почему так происходит и как можно преодолеть этот разрыв?

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

Выход один: встроить контроль безопасности в сам процесс разработки. Нужны инструменты, чтобы проверять код «на лету», а также выделенные специалисты — AppSec-инженеры, security-чемпионы, которые будут отвечать за анализ результатов и помогать разработчикам исправлять ошибки. Ответственность за безопасность должна лежать не только на разработчике, но и на всей команде и процессах.

Правда ли, что поиск и исправление ошибок в ИИ-сгенерированном коде требуют несоизмеримо больших трудозатрат топ-специалистов, чем код, написанный человеком?

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

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

Как компаниям выстроить надёжный контур безопасности при использовании ИИ? Какие практики вы рекомендуете внедрять?

Назову несколько принципов:

• Первый — по возможности использовать локальные, а не публичные языковые модели, чтобы снизить риск утечек.
• Второй — внедрить практику максимальной декомпозиции: дробить большие задачи на маленькие и чётко сформулированные. Это повышает качество и читаемость кода.
• Третий — тщательно документировать и сами запросы к ИИ, и правила работы с ним.

И, пожалуй, главное — применять классические подходы к безопасной разработке. Весь ИИ-сгенерированный код должен проходить через тот же конвейер контроля, что и написанный человеком: композиционный анализ (SCA) для проверки сторонних библиотек, статический (SAST) и динамический (DAST) анализ. «Доверяй, но проверяй» — этот принцип здесь работает как нельзя лучше.

Какие инструменты и платформы для безопасной разработки с ИИ вы рекомендуете своим клиентам? Какую роль в этой системе безопасности играют решения ГК «Солар»?

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

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