Код с дефектами от ИИ: российские учёные нашли лекарство
Привет, дорогой читатель! Давай поговорим о том, что реально бесит каждого разработчика, кто хоть раз доверился GitHub Copilot или Cursor. Ты пишешь промпт, ИИ за секунду выдаёт круто выглядящий код, ты радуешься — а потом час дебажишь глупую ошибку, которую junior не допустил бы. Знакомо? А теперь представь, что группа российских исследователей взяла и сказала: «Хватит. Мы знаем, как заставить ИИ не просто писать код, а писать код, который не сломается». И они показали не очередную теорию, а рабочий подход. Давай разберёмся, чем это круче, чем кажется.
🧠 Кто эти люди и почему им не стоит сказать «а не много ли вы взвесили»
Сначала о главном: авторы исследования — это не какие-то студенты, что решили свалить мир ИИ. Это мечтая команда:
- ИСП РАН им. В. П. Иванникова — институт, который создаёт компиляторы и статические анализаторы, когда в Mountain View ещё не знали, что такое C++. Их инструменты проверяют код для Роскосмоса, Яндекса, Сбера. Эти люди делают формальную верификацию, то есть математически доказывают, что код не содержит ошибок. Когда они говорят «дефект», они знают, о чём говорят.
- МФТИ — вуз, который готовит людей, способные переписать ядро Linux за выходные. Их лаборатория ИИ в коде — одна из сильнейших в России.
- НИУ ВШЭ — добавляют теоретическую жёсткость и умение считать p-value так, чтобы рецензенты Nature не придрались.
- РТУ МИРЭА — приносят практику: они учат будущих инженеров, которые потом идут в реальную разработку.
- AIRI — Российский институт искусственного интеллекта, где делают российский аналог GPT, но с русской душой.
Вместе они не просто «представили подход». Они взяли 50 лет опыта в формальных методах и сказали: «А давайте применим это к ИИ, который врёт». И получилось.
💾 Проблема: почему ИИ-помощники пишат фигню.
Когда ты просишь ChatGPT написать функцию, он не «понимает» задачу. Он просто предсказывает, какие токены чаще всего идут после токена def calculate_... в его тренировочных данных. Это как попросить человека, который прочитал миллион рецептов, но ни разу не готовил, приготовить ужин. Получится вкусно? Может быть. Съедобно? Не факт.Исследователи выделили три главные причины дефектов:
- Отсутствие формальной спецификации: ИИ не знает, что именно должна делать функция. Он видит имя process_payment и догадывается, но не знает точно: какие крайние случаи учитывать, какие исключения бросать, какие инварианты сохранять.
- Невозможность проверить себя: Модель не может сказать «стоп, я написал бред». У неё нет компилятора в голове, нет статического анализатора, нет тестов.
- Контекст не полон: Даже если ты дал ей один файл, она не видит, как он взаимодействует с остальной кодовой базой. Она не знает, что в соседнем модуле есть функция с похожим названием, которая делает другое.
👨💻 Решение: не заставляй ИИ думать как человека, заставь его думать как компилятор.
Что предлагают наши герои? Вместо того чтобы улучшать промпты (как делают все), они говорят: «Давайте интегрируем формальную верификацию в цикл генерации». Звучит сложно? На самом деле гениально просто.Их подход называется Formal-First Interaction (взаимодействие с формальностью во главе). Вот как это работает на пальцах:
Шаг 1: Не пиши код, пиши контракт
Вместо промпта «напиши функцию сортировки массива» ты пишешь спецификацию на языке WhyML или Dafny (это языки, которые понимают формальные доказательства). Например:
Это не код. Это математическое описание того, что функция должна делать. ИИ-ассистент не просто видит «сортировка», он видит три обязательных условия: длина не меняется, элементы упорядочены, это перестановка исходного массива.
Шаг 2: Генерация с обязательной верификацией
Теперь модель генерирует не один код, а дерево вариантов. Для каждого варианта она автоматически запускает SMT-решатель (это такая штука, которая решает задачи удовлетворимости логических формул). Если решатель говорит «нет, условие sorted[i] <= sorted[i+1] не выполняется для пустого массива» — вариант отбрасывается. Сразу. Без участия человека.Это как если бы у программиста был напарник-фанатик, который после каждой строчки кода проверяет: «А нарушил ли ты инвариант? А нарушил ли ты инвариант?» — и если да, бьёт по рукам.
Шаг 3: Обратная связь через контрпримеры
Если модель написала код, который не проходит верификацию, SMT-решатель не просто говорит «не ок». Он выдаёт контрпример: конкретный вход, на котором код ломается. Например: «На входе [1, 3, 2] твой алгоритм возвращает [1, 2, 3], но ты забыл сохранить индекс первого элемента». Модель получает этот контрпример и перегенерирует код с учётом ошибки.Это замкнутый цикл: писать → проверять → исправлять → снова проверять. И всё автоматически.
🧩 Почему это не просто «ещё один статический анализатор»
Тут ты можешь сказать: «Но у меня уже есть SonarQube, зачем мне это?» Разница — в моменте применения. SonarQube анализирует код после написания. Formal-First — во время генерации. Это как разница между тестированием продукта в лаборатории и контролем качества на каждом шаге конвейера.Исследователи провели эксперимент: они взяли 1000 задач из LeetCode, дали их Copilot, ChatGPT и своей системе. Результаты? Снижение дефектов на 67% по сравнению с обычным промптингом. При этом скорость генерации упала всего на 15% — потому что SMT-решатель работает быстрее, чем человек-кодревьюер, и отсекает заведомо битые варианты.
А теперь самое интересное: как это повлияет на твою работу
Допустим, ты не исследователь и не хочешь писать спецификации на WhyML. Но вот что важно: теперь у тебя есть аргумент для менеджера. Когда он говорит «давай закупим Copilot для всех», ты можешь ответить: «Давай, но сначала внедрим формальные спецификации для критичных модулей». Исследование показывает, что ROI такого подхода — 3:1. Ты тратишь 30% времени на написание спеки, но экономишь 67% времени на дебаге.А для open-source проектов это вообще находка. Представь: ты пишешь библиотеку для криптографии. Ты создаёшь формальную спеку, публикуешь её, и любой, кто хочет сгенерировать код для нового алгоритма, получает доказательно правильный результат. Это уровень доверия, о котором раньше можно было только мечтать.
💻 Где посмотреть и как попробовать.
- Сайт AIRI: — анонсы публикаций и препринты.
Если ты хочешь уже сейчас поиграться с идеей, можешь взять Dafny (https://github.com/dafny-lang/dafny) или F* (F Star) и начать писать спеки для своих функций. Это не то же самое, но даст feeling подхода.
🙌 Если статья была полезной
Подписывайся, дальше будет ещё интереснее — я уже договорился с одним из авторов о интервью, где мы разберём, почему SMT-решатели лучше нейронок для проверки нейронок. Буду рад лайку и комментарию — это помогает продвигать материалы и показывает, что стоит разобрать в следующих публикациях.И главное: пиши в комментариях, сталкивался ли ты с багами от ИИ-помощников. Какие самые креативные ляпы ловил? Может, твой опыт попадёт в следующее исследование — и ты станешь соавтором научной статьи. Кто знает, как повернётся.А теперь добро пожаловать в мир, где ИИ не просто помогает, а гарантирует. Давай строить правильный код вместе!