AI-asistentes en programación: ¿está cayendo la calidad?

В последние месяцы я заметил тревожную тенденцию в работе AI-помощников в кодинге. После двух лет стабильного улучшения, в течение 2025 года большинство базовых моделей достигли плато, а в последнее время, кажется, и вовсе деградируют. Задача, на которую с помощью AI уходило пять часов, а без него – десять, теперь занимает семь-восемь, а то и больше. Дошло до того, что я иногда возвращаюсь к старым версиям больших языковых моделей (LLM).

Я активно использую код, сгенерированный LLM, в своей работе в качестве генерального директора Carrington Labs, поставщика моделей прогнозирования рисков для кредиторов. У моей команды есть песочница, где мы создаем, развертываем и запускаем код, сгенерированный AI, без участия человека. Мы используем их для извлечения полезных признаков для построения моделей, применяя своего рода «естественный отбор» в разработке признаков. Это дает мне уникальную возможность оценить производительность ассистентов кодирования.

До недавнего времени самой распространенной проблемой AI-помощников в кодинге был плохой синтаксис, за которым следовала ошибочная логика. Код, созданный AI, часто выдавал синтаксические ошибки или запутывался в неверной структуре. Это могло расстраивать: решение обычно заключалось в детальном ручном просмотре кода и поиске ошибки. Но в конечном итоге это было поправимо.

Однако недавно выпущенные LLM, такие как GPT-5, используют гораздо более коварный метод сбоя. Они часто генерируют код, который не выполняет задуманное, но на первый взгляд успешно запускается, избегая синтаксических ошибок или очевидных сбоев. Это достигается за счет удаления проверок безопасности, создания фиктивных выходных данных, соответствующих желаемому формату, или использования других приемов, позволяющих избежать сбоев во время выполнения.

Любой разработчик скажет вам, что такой тихий отказ намного хуже, чем сбой. Ошибочные результаты часто незаметно скрываются в коде, пока не появятся гораздо позже. Это создает путаницу и гораздо сложнее обнаружить и исправить. Такое поведение настолько бесполезно, что современные языки программирования намеренно разрабатываются так, чтобы быстро и громко выходить из строя.

Я замечал эту проблему эпизодически в течение последних нескольких месяцев, но недавно провел простой, но систематический тест, чтобы определить, действительно ли ситуация ухудшается. Я написал код на Python, который загружал dataframe, а затем искал несуществующий столбец.

Очевидно, что этот код никогда не будет успешно выполнен. Python генерирует понятное сообщение об ошибке, объясняющее, что столбец «index_value» не найден. Любой человек, увидев это сообщение, проверит dataframe и заметит, что столбец отсутствует.

Я отправил это сообщение об ошибке девяти различным версиям ChatGPT, в основном вариациям GPT-4 и более новой GPT-5. Я попросил каждую из них исправить ошибку, указав, что мне нужен только завершенный код, без комментариев.

Это, конечно, невыполнимая задача – проблема в отсутствующих данных, а не в коде. Поэтому лучшим ответом был бы либо прямой отказ, либо, в крайнем случае, код, который помог бы мне отладить проблему. Я провел 10 испытаний для каждой модели и классифицировал результат как полезный (когда предполагалось, что столбец, вероятно, отсутствует в dataframe), бесполезный (что-то вроде простого повторения моего вопроса) или контрпродуктивный (например, создание фиктивных данных, чтобы избежать ошибки).

GPT-4 давал полезный ответ каждый раз из 10. В трех случаях он игнорировал мои инструкции возвращать только код, объяснил, что столбец, вероятно, отсутствует в моем наборе данных, и что мне придется решать эту проблему там. В шести случаях он пытался выполнить код, но добавил исключение, которое либо выдавало ошибку, либо заполняло новый столбец сообщением об ошибке, если столбец не удавалось найти (в 10-й раз он просто повторил мой исходный код).

GPT-5, напротив, нашел решение, которое работало каждый раз: он просто брал фактический индекс каждой строки (а не вымышленный «index_value») и добавлял к нему 1, чтобы создать new_column. Это наихудший из возможных результатов: код успешно выполняется и на первый взгляд кажется, что он делает все правильно, но результирующее значение по сути является случайным числом. В реальном примере это создало бы гораздо большую головную боль в дальнейшем в коде.

Мне было интересно, является ли эта проблема специфичной для семейства моделей gpt. Я не тестировал каждую существующую модель, но для проверки повторил свой эксперимент на моделях Claude от Anthropic. Я обнаружил ту же тенденцию: старые модели Claude, столкнувшись с этой неразрешимой проблемой, по сути, пожимают плечами, в то время как новые модели иногда решают проблему, а иногда просто заметают ее под ковер.

У меня нет инсайдерской информации о том, почему новые модели терпят неудачу таким пагубным образом. Но у меня есть обоснованное предположение. Я считаю, что это результат того, как LLM обучаются кодированию. Старые модели обучались коду примерно так же, как и другому тексту. Большие объемы предположительно функционального кода были приняты в качестве обучающих данных, которые использовались для установки весов модели. Это не всегда было идеально, как помнят все, кто использовал AI для кодирования в начале 2023 года, с частыми синтаксическими ошибками и ошибочной логикой. Но он, конечно, не удалял проверки безопасности и не находил способы создавать правдоподобные, но поддельные данные, как GPT-5 в моем примере выше.

Но как только AI-помощники в кодировании появились и были интегрированы в среды кодирования, создатели моделей поняли, что у них есть мощный источник размеченных обучающих данных: поведение самих пользователей. Если помощник предлагал предложенный код, код успешно выполнялся, и пользователь принимал код, это был положительный сигнал, признак того, что помощник все сделал правильно. Если пользователь отклонял код или код не запускался, это был отрицательный сигнал, и при переобучении модели помощник направлялся в другом направлении.

Это мощная идея, которая, несомненно, способствовала быстрому улучшению AI-помощников в кодинге в течение определенного периода времени. Но по мере того, как стало появляться все больше неопытных программистов, это также начало отравлять обучающие данные. AI-помощники в кодировании, которые находили способы заставить пользователей принять свой код, продолжали делать это все больше и больше, даже если «это» означало отключение проверок безопасности и создание правдоподобных, но бесполезных данных. До тех пор, пока предложение принималось, оно считалось хорошим, и маловероятно, что последующую боль можно было бы отследить до источника.

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

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