dxdt.ru: занимательный интернет-журнал

Программный код, генерируемый при помощи LLM, и автоматическое применение средств анализа кода (но не тех, которые уже есть в LLM-сервисе) – принесут забавные результаты. А главное – массовые. О чём тут речь: например, если у вас внедрено что-то типа “безопасной разработки ПО”, то использование, как минимум, статического анализатора кода – оказывается обязательным; кроме того, понятно, есть ещё автоматические тесты разных типов.

Теперь предположим, что внедрена и новомодная (пусть и вымышленная) схема, в которой “разработчиков заменяет ИИ/LLM”. Тогда получается, что если для создания тестов и исправления кода по результатам тестирования используется одна и та же LLM, – как внешний сервис (и это, скорее всего, так и есть), – то эта LLM будет приспосабливаться к прохождению тестов ради прохождения тестов. Потому что провайдер свою систему “улучшает”. На очередной итерации такого приспособления – LLM сгенерирует код, который все тесты успешно пройдёт, но работать правильно не будет.

Как такое вообще возможно? Это возможно, так сказать, по определению, так как задача генератора кода – генерировать код, проходящий тесты, а не решать высокоуровневые задачи при помощи программирования. Чтобы применять программирование к высокоуровневым задачам, а не просто генерировать код, демонстрируя последнюю стадию “кодерства”, нужна та самая “ментальная модель” системы. А в случае применения новомодных LLM – такой модели нет ни у кого, так как задача, еще раз, состоит в генерировании кода. Её так и понимают апологеты перевода разработки ПО на LLM. Типа, если преподаватель студентам задал написать эссе, то, мол, преподавателю нужно эссе и именно эссе составляет смысл процесса обучения, поэтому, раз эссе может сгенерировать LLM, то нужно такое упражнение убрать из курсов. (Сейчас, кстати, вообще совсем не модно понимать картину, которая больше, чем некоторая деталь механизма, кем-то предоставленного.)

Вернёмся к “безопасной разработке” и LLM-кодогенераторам. Первый этап преодоления проблем – статический анализатор. Здесь речь про внешний инструмент, применяемый отдельно, а не про анализатор, встроенный на стороне выдачи сервиса кодогенерации. Казалось бы, пусть возможности статических анализаторов сильно ограничены, но какую-то пользу они могут же принести? Могут, да. Вот только LLM-генератору “энергетически выгоднее” обфусцировать код так, чтобы его пропускал статический анализатор, а не удалить реальные ошибки. Это, вообще говоря, подтверждается общим очень низким качеством “патчей”, которые генерируют LLM-инструменты для исправления дефектов кода, найденных этими же LLM.

Второй этап – тесты. Unit-тесты, допустим, пишутся до разработки самого кода. Как же может не работать правильно код, который прошёл тесты? Тесты же для того и написаны, чтобы логически строго сформулировать требования к правильной работе. Да-да, всё так и могло бы быть, если бы написание тестов, как и код, не отдали на откуп LLM-генератору. Это ключевой момент. Кроме того, в тестах, в том числе, написанных человеком, нередко бывают ошибки. Тестам свойственна существенная неполнота, пусть и задумывались они как почти полные. Это нормально. Вот только LLM натренирована на преодоление тестов, пусть и через обнаружение в них ошибок и через выявление неполноты, а не на создание корректно работающего ПО. В случае, когда ИИ/LLM везде, такому преодолению эта LLM помогает с двух направлений, корректируя тесты под дефекты генератора кода, а код – под вносимые дефекты тестов.

И это кроме того, что сервис LLM ещё и объединяет весь код в общую “базу” для всех пользователей: на результаты разработки компании “Имярек А” влияют тесты компании “Имярек Б”, которые компании друг о друге не знают, но используют один и тот же новомодный ИИ/LLM-сервис.

Адрес записки: https://dxdt.ru/2026/02/05/17278/