Надёжное программирование: от кода к технологии

Целевая аудитория: Разработка и инженерия; Управление; AI и ML
Хабы: Искусственный интеллект; Машинное обучение; Тестирование; Программирование; Управление разработкой
Ключевые слова: оракульное смещение, проблема оракула, LLM-ассистент, генерация кода, DORA, Veracode, FormAI, тестирование, технический долг, доверие к коду

Это второй из трёх постов серии «Надёжное программирование: от кода к технологии». В первом мы разобрали главный тезис и три столпа. Здесь — почему при массовом внедрении ИИ метрики процесса растут, а доверие — нет. В третьем — конечный аудитор, шкала L0–L4 и практические рекомендации. Полная версия статьи — [ссылка].

Наблюдение

Внедряете ИИ-ассистентов. Покрытие тестами растёт. Скорость доставки формально не падает. Метрики процесса выглядят прилично. А доверие к продукту — нет. Инцидентов меньше не становится.

Это не парадокс. Это прямое следствие асимметрии, которую я называю оракульным смещением.

Формально

Обозначим:

• C_gen — предельная стоимость генерации очередного артефакта.

• C_oracle — предельная стоимость суждения о его корректности.

Генерация масштабируется вызовом модели: C_gen → 0 по мере роста корпуса и вычислительных мощностей.

Суждение устроено иначе: ему нужен независимый источник истины, который создаётся человеческим трудом и вызовом модели не масштабируется. Отсюда C_oracle ≥ const > 0.

Разрыв между этими величинами и есть оракульное смещение. Формально — ситуация, когда d(C_gen)/d(scale) < d(C_oracle)/d(scale) при scale → ∞.

Оговорка: C_oracle можно снизить — формальные методы и повторное использование спецификаций работают. Но без целенаправленных инвестиций в оракулы разрыв сохраняется: автоматически он не закрывается.

Практическое следствие

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

Это не баг ИИ. Это следствие того, что мы автоматизировали дешёвую часть работы и оставили дорогую.

Эмпирика последних двух лет

DORA 2024 и 2025

Отчёт DORA 2024: каждые дополнительные 25% внедрения ИИ в разработку сопровождались:

• падением пропускной способности примерно на 1,5%;

• ростом нестабильности на 7,2%.

DORA 2025: пропускная способность вернулась в плюс, нестабильность — нет. ИИ используют около 90% опрошенных, около 30% выражают ему крайне низкое доверие.

Авторы отчёта формулируют вывод, совпадающий с нашим: ИИ не исправляет организацию, а проявляет её слабые места — прежде всего в тестировании и контроле качества.

Veracode 2025

Проверено более 100 моделей на 80 задачах по списку OWASP Top 10. Результат:

• 45% сгенерированного кода содержали хотя бы одну уязвимость;

• для Java доля отказов превышает 70%;

• с ростом модели безопасность значимо не улучшается.

Модели 2023–2025 годов дают примерно тот же уровень, что и предыдущее поколение. Это ровно тот аргумент, который нужен: узкое место — не мощность генератора, а наличие независимого оракула.

FormAI-v2

331 тыс. программ на C, девять моделей, нейтральные zero-shot промпты: не менее 62,07% генераций содержали формально подтверждённые уязвимости.

Оговорка обязательна: язык C, класс свойств ESBMC, отбор по компилируемости. На другой стек это не переносится.

Балансирующий результат

Было бы нечестно обойти стороной исследование 2023 года на языке C, которое не выявило заметного прироста критически опасных дефектов у кода, созданного с ассистентом (Perry et al.).

Корректная формулировка: результаты расходятся по конструкту, языку и способу измерения. Статья, приводящая только негативные данные, методологически уязвима.

Пять механизмов, из-за которых проверка ломается

1. Замыкание оракула

Если тесты и ожидания порождены из того же контекста, что и код, требование независимости нарушено. Проверка превращается в подтверждение. Это риск технологии, а не свойство модели — и лечится он организационно, а не сменой инструмента.

Ранний признак: после генерации все проверки проходят без ручного ревью.
Мера: оракулы фиксируются до генерации; отдельные контексты; ревью оракула отдельно от кода.

2. Самоусиление судьи

LLM-оценщик, проверяющий генерацию той же модели, систематически смещён: в сторону позиции в тексте, длины ответа, собственного вывода. Оценка «своей» генерации собственной моделью независимой не является (Zheng et al., 2023).

Ранний признак: метрика качества растёт, инциденты — тоже.
Мера: человеческая выборка; слепая оценка; рандомизация порядка.

3. Избыточная спецификация

Генератор повторяет несущественные детали. Свобода оптимизации теряется, тесты становятся хрупкими и ломаются при рефакторинге, который не меняет поведения.

Ранний признак: тесты ломаются при рефакторинге без смены поведения.
Мера: разделять контракт и реализацию; специфицировать допущения.

4. Недостаточная спецификация

Допущения берутся из обучающих данных. Демо работает, отказы — на периферии входов.

Ранний признак: демо работает, отказы на периферии входов.
Мера: явные предусловия; фаззинг; метаморфные проверки.

5. Разрыв трассируемости

Требования, код и тесты живут раздельно. Дефекты не связаны с требованиями.

Ранний признак: дефекты не связаны с требованиями.
Мера: автоматическая трассировка; quality gates на связь «требование — тест».

Что делать

1. Оракулы фиксируются до генерации. Если критерий приёмки сформулирован после того, как артефакт сгенерирован, — это уже не критерий, а рационализация.

2. Разделяйте контексты. Тесты не должны порождаться из того же промпта, что и код.

3. Ревью оракула — отдельно от ревью кода. Это разные артефакты, и качество первого важнее.

4. Человеческая выборка при LLM-оценке. Слепая оценка, рандомизация порядка, контроль смещений.

5. Мульти-метрики. SLO + утечки дефектов + mutation score + постмортемы. Покрытие в одиночку — ложный сигнал.

Прочие риски, которые стоит держать в голове

• Лицензионно-загрязнённый код, воспроизведённый из обучающих данных.

• Обращение к устаревшим API.

• Невоспроизводимость результата между запусками.

• Эрозия компетенций: генерация предшествует пониманию, на ревью нельзя объяснить принятый код.

Анонс следующего поста

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

Серия «Надёжное программирование: от кода к технологии»

• Пост 1. Надёжность как свойство технологии, а не кода

• Пост 2. Оракульное смещение: почему ИИ генерирует быстрее, чем мы успеваем проверять (вы здесь)

• Пост 3. Кто отвечает? Конечный аудитор, шкала L0–L4 и практика