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

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

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

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

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

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

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

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

Сейчас тема развилась так хорошо, что на сторону провайдера ИИ/LLM-сервиса в онлайн-режиме передаётся исходный код программых продуктов, в том числе, внутренних корпоративных программных продуктов и экспериментальных версий. Да не просто код, а сведения о процессе подготовки этого кода. Заметьте, что провайдер обязательно использует этот новый код для “обучения” своих систем. А это прямо означает, что этот же код может быть передан другим пользователям сервиса. То есть, не просто провайдер получит код (тут можно вспомнить “социальную сеть” Github и пр.), но провайдер передаст этот код другим. (Тут вовсе не нужно вспоминать “копирайт” и прочие “бумажные соглашения”: как показала практика, поставщики ИИ/LLM на это внимания не обращают, списывая всё на добросовестное использование “в обучении” LLM.)

Казалось бы, какая разница, что исходный код уходит наружу? Код должен быть так написан, чтобы его утечка не приводила к проблемам с безопасностью самого ПО. Это верно. Но не нужно упускать такой момент: по коду нетрудно сказать, что за ПО разрабатывает компания, соответственно, нетрудно надёжно выявить список коммерческих проектов и текущий статус их разработки – а это уже весьма ценные сведения для конкурентной разведки.