Код от LLM в продакшене: практическое исследование качества на 12 проектах

Большинство споров о коде, который пишет ИИ, крутятся вокруг одного вопроса: работает ли он. Это неверная постановка. Для продуктовых систем важно другое — работает ли он надёжно, могут ли его сопровождать инженеры, которые его не писали, и порождает ли он дефекты с частотой, при которой непрерывная поставка остаётся жизнеспособной.

Мы решили ответить на эти вопросы данными, а не мнениями.

Методология

Мы проанализировали 12 продуктовых проектов, поставленных с июня 2025 по январь 2026 года по методологии ИИ-оркестрированной разработки NOSOTA. Каждый проект создавался одним–тремя старшими инженерами в роли оркестраторов: ИИ-агенты генерировали основную массу кода по структурированным брифам под человеческим контролем.

Проекты охватывают корпоративные бэкенды, кроссплатформенные мобильные приложения, веб-порталы и системы с ML-интеграцией. Суммарно — более 200 000 строк кода, свыше 1 400 автоматических тестов, свыше 350 REST API эндпоинтов. Каждая метрика прослеживается по Git-истории, логам CI/CD и трекерам задач.

Измерялись три параметра: тестовое покрытие (покрытие строк и ветвей по данным CI), плотность дефектов (баги на тысячу строк кода за первые 90 дней после развёртывания) и сопровождаемость (время, которое требуется инженеру, незнакомому с кодовой базой, на реализацию нетривиального изменения).

Результат 1: тестовое покрытие выше отраслевых бенчмарков

По 12 проектам медианное покрытие строк составило 78%, три проекта превысили 85%. Покрытие ветвей — более строгая метрика — в среднем 64%. Для сравнения: отраслевые опросы стабильно фиксируют среднее покрытие строк в диапазоне 40–60% для корпоративных кодовых баз.

Объяснение носит структурный характер, а не героический. ИИ-агенты генерируют тесты как часть стандартного вывода, если бриф задан корректно. Стоимость написания теста стремится к нулю, когда агент порождает его вместе с реализацией. То, что дорого в традиционных процессах — полноценные наборы тестов — в ИИ-оркестрированной разработке становится выходом по умолчанию.

Критический фактор — качество брифа. Проекты, где оркестратор задавал явные критерии приёмки в каждом брифе агенту, показали на 15–20 процентных пунктов более высокое покрытие, чем проекты, где требования к тестированию оставались неявными.

Результат 2: плотность дефектов ниже, и причина — дисциплина ревью

Медианная плотность дефектов по всем 12 проектам — 0,8 бага на тысячу строк кода за первые 90 дней. Отраслевой ориентир для зрелых команд — обычно 1–5 багов на KLOC. Два проекта показали ноль продуктовых дефектов за период измерения.

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

В проектах, где оркестратор пропускал или ускорял ревью — это видно по более коротким временам ревью в метаданных Git — частота дефектов оказывалась в 3–4 раза выше. Методология работает, когда человек в цикле относится к обязательству ревью всерьёз.