ИИ для программирования: где помогает, а где вредит

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

Что получается хорошо

Типовой код. Разбор аргументов, работа с файлами, запросы к API, тесты, регулярные выражения. Всё, что вы писали сто раз и не хотите писать в сто первый.

Объяснение чужого кода. Кинуть функцию на незнакомом языке и получить пересказ логики — задача, где машина экономит часы.

Перевод между языками. Скрипт с одного языка на другой, запрос из одного диалекта SQL в другой.

Поиск ошибки по сообщению. Вставить трассировку и получить гипотезу. Не всегда верную, но обычно сокращающую поиск.

Черновик тестов. Модели хорошо придумывают граничные случаи, о которых автор кода не подумал именно потому, что он автор.

Документация и комментарии. Скучная работа, которую все откладывают.

Где стабильно ошибается

Придумывает библиотеки и методы. Самая частая ошибка: код выглядит правильно, а функции, которую он вызывает, не существует. Проверяется запуском за минуту, но пугает тем, насколько уверенно это написано.

Устаревшие версии. Модель обучалась на коде разных лет и смешивает синтаксис старых и новых версий. Особенно заметно во фреймворках, которые быстро меняются.

Безопасность. Сгенерированный код часто небрежен: подстановка данных в запрос без экранирования, секреты прямо в коде, отсутствие проверки входных данных.

Производительность. Решение будет рабочим и наивным. На десяти записях всё летает, на миллионе встаёт.

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

Как проверять

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

Прочитайте импорты и вызовы. Существуют ли эти функции в вашей версии библиотеки.

Проверьте границы. Пустой список, ноль, отрицательное число, очень большой ввод.

Посмотрите на данные пользователя. Всё, что приходит снаружи, должно проверяться.

Спросите модель о её же коде. «Какие тут есть уязвимости и что сломается при большом объёме» — она часто честно перечисляет собственные огрехи.

Кому это даёт больше пользы

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

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

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

Что не изменилось

Ответственность за код остаётся на том, кто его отправил в работу. Формулировка «так написала нейросеть» не работает ни в одной команде.

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

С чего начать

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