Нейросети в коде: помощник, костыль или новая норма?

Статья написана для ресурса «Бизнес и Информационные технологии — БИТ».

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

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

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

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

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

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