Habr разбирает оракульное смещение: ИИ ускоряет код, но доверие к нему не растёт

Вторая часть серии «Надёжное программирование: от кода к технологии» на Habr посвящена неудобному парадоксу. После массового внедрения LLM-ассистентов метрики процесса (скорость, число коммитов, закрытые задачи) растут, а уверенность инженеров, что код делает именно то, что нужно, не растёт. Автор объясняет это через оракульное смещение и опирается на исследования DORA, Veracode и датасет FormAI. Анонс публикации короткий, поэтому ниже разобрана сама идея и данные, на которые она ссылается.

Проблема оракула в эпоху генерации

Тестовый оракул — это то, что определяет, какой результат считать правильным. Раньше его источником был человек: он читал требование, думал и записывал ожидаемое поведение. Теперь функцию и тесты к ней нередко пишет одна и та же модель.

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

Что показывают исследования

Картину, которую описывает автор серии, поддерживают несколько независимых источников:

• DORA, отчёт 2024 года: рост внедрения ИИ на 25% коррелировал со снижением пропускной способности поставки примерно на 1,5% и стабильности примерно на 7,2%.
• DORA, отчёт 2025 года: ИИ используют около 90% респондентов, при этом порядка 30% почти не доверяют сгенерированному коду.
• Veracode, 2025: в 45% образцов кода, сгенерированного более чем сотней моделей на наборе задач, нашлись уязвимости.
• FormAI: около 112 000 программ на C, написанных LLM. Формальная верификация нашла уязвимости примерно в половине.

Последний пункт важен методически. Уязвимости искали не другой нейросетью, а формальным верификатором, то есть оракулом, не зависящим от модели.

Где копится долг

Генерация дешевеет, проверка нет. Кода становится больше, а внимание ревьюера остаётся прежним. Узкое место переезжает из написания в проверку, и если ревью превращается в беглый просмотр диффа, технический долг растёт незаметно. Это вывод из логики процесса, а не отдельная цифра из отчётов, но он согласуется с падением стабильности поставки в данных DORA.

Что можно сделать уже сейчас

Главная мера: не отдавать модели одновременно реализацию и критерии правильности. На практике это выглядит так:

• Формулировать требования и ключевые приёмочные тесты руками, до генерации кода.
• Добавлять проверки, не зависящие от ассистента: статический анализ, property-based тесты, мутационное тестирование, а для критичных участков формальную верификацию.
• Смотреть мутационный скор, а не только покрытие. Тест, который не падает при поломке кода, ничего не доказывает.
• Помечать код, созданный ИИ, и учитывать долю повторной работы и откатов, а не только скорость поставки.
• Выделять на ревью отдельное время и не считать его накладными расходами.

В третьей части серии автор обещает конечного аудитора, шкалу доверия L0–L4 и практические рекомендации. Пока ясно одно: если измерять только скорость, доверие к коду будет падать, даже когда все графики растут.