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

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

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

Методология

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

Проекты охватывают серверные части корпоративных систем, кроссплатформенные мобильные приложения, веб-порталы и системы с интеграцией машинного обучения. В сумме — более 200 000 строк кода, более 1400 автоматических тестов и более 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 раза выше. Методология работает, когда участвующий в процессе человек серьёзно относится к своей обязанности проверять код.

Вывод 3: документация позволяет сопровождать код другим инженерам

Сопровождаемость — тот параметр, о котором клиенты спрашивают реже всего, а платят за него дольше всего. Система удобна в сопровождении, если инженер, который её не создавал, может быстро в ней разобраться и безопасно внести изменения.

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

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