Код, сгенерированный ИИ, может хорошо работать и при этом оставаться трудным для объяснения инженерами. Это полезно ровно до того момента, когда кому-то нужно проверить изменение, разобрать сбой или решить, что системе строить дальше.
От написания кода к надзору за ним
Джереми Никсон, основатель Infinity, говорит, что программисты всё чаще теряют из виду то, что порождают языковые модели. По его словам, разработчики уходят от сборки продуктов строка за строкой и переходят к надзору за работой модели.
Яркий пример связан с OpenAI. Джордан Нанос, технический сотрудник SemiAnalysis, описал, как инженеры там проверяли код GPU-ядер, написанный для повышения производительности. По его словам, им было трудно проследить, что делает этот код, хотя ядра давали корректные и весьма эффективные результаты.
Нанос видит в этом не доказательство неспособности инженеров, а изменение того, как распределяется работа. Разработчики задают архитектуру и решают, что считать приемлемым результатом, а ИИ берёт на себя всё большую часть реализации. Код может проходить тесты, даже если ответственные за него люди не могут сходу объяснить каждую часть.
Такое устройство меняет смысл технического надзора. Проверка результата не совсем то же самое, что понимание того, как он был получен, хотя при успешной работе эти вещи могут выглядеть похоже.
Риск для продакшена
Работающий код не становится безопасным автоматически. ИИ-системы могут ошибаться или выдавать правдоподобные, но ложные результаты, и эти ошибки могут попасть в продакшен, если инженеры их не поймают.
Ранее в этом году Amazon ввела 90-дневный тест безопасности кода после серии сбоев, нарушивших обработку заказов. Компания отрицала, что виноват ИИ. Внутренние логи и заметки, однако, показывали, что менеджеры обеспокоены большим потенциальным влиянием изменений, сгенерированных ИИ.
В этом рассказе также приводятся цифры софтверной компании Undo. Её анализ показал, что 35% кода, сгенерированного ИИ, попадает в продакшен без полного понимания со стороны инженеров. В том же анализе 29% разработчиков сказали, что несколько раз в месяц теряют продуктивность, распутывая код, написанный ИИ, а 94% сказали, что сталкивались с этим хотя бы раз за предыдущие шесть месяцев.
Эти цифры указывают на различие, которое легко смазать: генерация кода может сэкономить усилия на одном этапе и создать больше работы позже. Объём этой дополнительной работы и то, как собирались цифры, в отчёте не раскрыты.
Вопрос навыков, а не только инструментов
Обеспокоенность выходит за рамки того, безопасен ли конкретный код. Отчёт также ссылается на исследования, описывающие когнитивный спад и утрату навыков у специалистов, которые перестают писать код вручную, не развивая при этом умения, нужные для проектирования более крупных систем.
Это оставляет разработчикам трудный баланс. Если они больше полагаются на модели в реализации, у них может появиться больше времени на архитектуру и критерии приёмки. Но эти обязанности требуют достаточного технического понимания, чтобы судить, надёжен ли вывод модели, особенно когда тесты не выявляют проблему.
Практическая трудность не в том, что инженеры обязаны лично набирать каждую строку. Она в том, что ответственность не исчезает, когда авторство переходит к модели. Командам по-прежнему нужны способы проверять изменения, замечать сбои и сохранять знания, необходимые для решений о сложных системах.
ИИ, возможно, меняет программирование: от написания инструкций к тому, чтобы направлять и проверять их. Неудобная часть в том, что программа может быть корректной сегодня и при этом плохо понятой теми, кому завтра её чинить.