В эпоху активного распространения ИИ агентов распространенным мнением является то, что ИИ всегда напишет код быстрее, чем разработчик сделает это руками. Если напрямую сравнивать количество написанных строк кода — это будет абсолютной правдой. Единственная проблема — такой код не всегда будет полностью корректным.
Для многих задач — прототипов, одноразовых скриптов, кусков шаблонного кода — немного некорректный код не является проблемой. Человек увидит ошибку и попросит обновить прототип. Скрипт завершится с ошибкой — она передается в ИИ и это быстро исправляется.
Хуже, когда ошибки проявляются в так называемых пограничных кейсах. Они не являются ошибками с точки зрения программы — просто кто-то вдруг сможет выполнить то, чего не должен был. Если такая ошибка произойдет на фронтенде, то пользователь, например, может увидеть недоступный ему раздел, или нажать на кнопку, которая должна быть неактивной. Неприятно, но не критично — в правильно спроектированной системе интерфейс не содержит данных и запрашивает их с серверной части, поэтому в открытом разделе пользователь не увидит защищённых данных, если бэкенд проверяет права.
В плохом варианте подобные ошибки могут появиться на бэкенде. Например, обычный пользователь сможет назначить себе права администратора из-за отсутствия проверки в методе. Или увидеть данные, которые ему не принадлежат. Вариантов — бесконечное множество.
Но ведь люди тоже ошибаются
От ошибок при написании кода не застрахован никто — даже самые опытные инженеры их допускают. Годами практики разработки совершенствовались, пока не эволюционировали до схемы с обязательным ревью от человека, который не занимался конкретной задачей. Это отлично работало, потому что была некоторая ротация между разработчиками: один пишет, второй ревьювит, потом они меняются. Каждый остается в контексте, почему решения приняты определенным образом.
Человек не может заниматься ревью кода целыми днями
В эпоху ИИ некоторые компании решили, что роль разработчика изменилась, и в его зоны ответственности не должно входить написание кода (ведь он пишет его слишком медленно). Теперь инженер скорее должен отвечать за правильную постановку задач агентам и контролировать ее корректное исполнение.
Правда с этим возникает проблема. При ручном написании разработчик постоянно смотрит на получаемый код и задается вопросами о том, как это будет работать, что будет, если объект окажется null, может ли он оказаться null и так далее. Он пишет код, задумывается о том, что где-то уже это видел, задает вопросы бизнесу, выполняет рефакторинг, пишет дальше. Он знает, зачем появилось каждое ветвление, какие входные данные возможны и почему крайние случаи обработаны именно так — в процессе написания было решено очень много вопросов.
Но если разработчик теперь только читает чужой код, то все меняется. Замысел приходится восстанавливать из одного только кода, без рассуждений, которые его породили. ИИ написал правдоподобный код и выбросил все рассуждения, что за ним стояли.
Убедиться, что незнакомая функция обрабатывает все случаи, — задача намного более тяжёлая, чем ее самостоятельное написание. Мозгу тяжело дается реверс-инжиниринг кода, который отображается в окне ревью обычным текстом. Функции вызывают функции, написанные ранее; ревьюверу необходимо либо довериться ИИ в правильности их вызова, либо идти в исходные коды методов, чтобы убедиться, что вызовы корректны.
Код от ИИ выглядит корректным — и в этом проблема.
Сгенерированный ИИ код обычно компилируется, корректно работает в простейших сценариях и неплохо читается. То есть проблема не в том, что ИИ пишет код плохо, а в том, что он пишет его очень хорошо. Внешняя правдоподобность провоцирует поверхностное ревью.
Ошибки абсолютно случайны, внимание нельзя ослаблять
Нельзя утверждать, что до появления ИИ с ревью не было проблем. Но у человека есть понятие ответственности и обучаемости: со временем он ошибается все меньше, ревьювер знает, что полная проверка всего PR не нужна. С ИИ это не так. Сложнейшая функция может быть реализована идеально, но лишь потому, что была в обучающем датасете. При этом легко поймать ошибку в тривиальном коде. Другими словами, ревьювер не может быть уверен ни в чем, его концентрация всегда находится на пределе.
То есть модель может корректно реализовать по-настоящему сложный случай с корректным порядком транзакций и через три строки перепутать >= в сравнении, которое junior никогда бы не допустил.
Внимание человека — далеко не безграничный ресурс. Больше 2-х часов сосредотачиваться на проверке PR в день осилит далеко не каждый. Поэтому приходится выбирать — либо доверять ИИ и надеяться, что ничего не сломается, либо количество открытых PR от ИИ будет копиться, а количество реализованных фич не увеличится.
Когда выбор ИИ для написания кода оправдан
Перечисленное выше не делает ИИ бесполезным — оно просто расставляет границы, где допустимо его использование. Необходимо четко понимать, что важнее для конкретной задачи — сделать быстро с возможной потерей качества или сделать медленно, но с большим продумыванием деталей.
Например, мы любим использовать ИИ при работе с фронтендом. Баг в компоненте виден сразу, когда смотришь на экран (это про случаи, когда фронтенд не содержит сложной логики). Прототипирование экранов стало намного приятнее: если раньше приходилось проводить время в Figma, чтобы накидать вариант интерфейса, то теперь пара строк позволяет сделать то же самое за несколько минут.
Но вот в бэкенде ИИ мы используем редко. Неверная миграция, некорректная проверка прав, сервисный метод, обновляющий не те строки — цена ошибки слишком высока. Поэтому мы стараемся использовать здесь ИИ только в конкретных вопросах. Не "Реализуй функцию X, используя спецификации", а "Почему я получаю ошибку компиляции Y".
Как пользоваться ИИ, не теряя навыков разработки
Разработчики, перестающие писать код, постепенно перестают понимать, когда ИИ отработал некорректно. Зависимость получается замкнутой: чем больше используешь ИИ, тем меньше остается хард-скиллов. Чем меньше хард-скиллов, тем труднее правильно делать ревью. В конце концов инженер, прежде вкапывавшийся в суть кода, начинает слепо доверять ИИ.
Поэтому выбор, когда стоит использовать интеллектуального помощника, должен быть осознанным. ИИ должен убирать рутину, которая не приносила ничего, кроме раздражения, но оставлять пространство для творчества, чтобы инженер мог продолжать развиваться. Это поможет добиться оптимального баланса между скоростью разработки и качеством кода и сохранить этот баланс на долгое время.