От ассистирующей к автономной генерации программного кода: архитектура независимого контроля качества

Введение

Инструменты генерации программного кода на основе больших языковых моделей (БЯМ) за несколько лет прошли путь от экспериментальных прототипов до повседневной практики разработки. Контролируемые исследования показывают, что применение ассистента ускоряет выполнение типовых задач программирования: разработчики, использовавшие GitHub Copilot, справлялись с эталонной задачей в среднем на 55% быстрее контрольной группы [6]. Уже модели 2021 года демонстрировали способность решать заметную долю стандартных задач программирования [2], а современные автономные агенты решают часть реальных задач сопровождения программных проектов, что фиксируется специализированными бенчмарками [4].

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

Автономный режим – при котором система получает постановку задачи и возвращает завершённый, проверенный результат, – несмотря на прогресс агентных систем [4, 7], упирается в проблему приёмки: у принимающей стороны нет способа доверять результату без построчной проверки, стоимость которой обесценивает автоматизацию. Известные подходы к самопроверке, в частности итеративное самоулучшение по собственной обратной связи [5] и рефлексивные агентные схемы [7], повышают качество результата, однако не решают задачу доверия: система, оценивающая собственную работу по собственным критериям, не даёт внешнему наблюдателю независимого свидетельства качества.

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

Уточним операциональное отличие от распространённой схемы «ассистент, открывающий запрос на включение изменений при зелёной сборке». В такой схеме единственные свидетельства качества – компиляция и тесты, происхождение которых не отделено от генератора; содержательную проверку результата целиком выполняет ревьюер. В предлагаемой архитектуре результат приходит на ревью с независимо вычисленной количественной оценкой качества на данных, недоступных генератору. Человек при этом не устраняется из процесса, а перераспределяется: его участие смещается с построчной проверки середины цикла к постановке задачи на входе и приёмке по предъявленным свидетельствам на выходе.

Отметим, что вклад работы состоит не в самой схеме «генератор + проверяющий» – раздельные роли генерации и критики известны в агентных системах [7], – а в протоколе изоляции проверочных данных от генератора и в ограниченной форме обратной связи, переносящих в контур агентной генерации дисциплину, принятую при оценке обучаемых моделей.

Объекты и методы исследования

Объектом исследования является система автоматической генерации формальных грамматик распознавания голосовых команд и сопутствующего программного кода для сценариев диалоговой системы (голосового ассистента). Задача выбрана как представительная для класса задач с формализуемым критерием качества: корректность грамматики измерима на выборке примеров пользовательских запросов. Под полнотой здесь понимается доля целевых запросов, которые грамматика распознала; под точностью – доля распознанных запросов, действительно являющихся целевыми:

, (1)

, (2)

Где Nц – число целевых запросов в выборке; Nрц – число целевых запросов, распознанных грамматикой; Nр – общее число запросов, распознанных грамматикой (включая ложные срабатывания на отрицательных примерах).

Предложенная архитектура включает три компонента с разделёнными зонами ответственности (рис. 1).

Оркестратор – управляющий компонент, координирующий цикл. Он принимает на вход эталонную выборку – размеченные множества положительных примеров (запросы, которые должны распознаваться) и отрицательных (запросы, которые распознаваться не должны) – и разделяет её детерминированной процедурой с фиксированным зерном случайности в соотношении 80/20 на обучающую и отложенную (held-out) проверочную части. Отложенная часть скрыта от генерирующего компонента: она удерживается исключительно в оперативной памяти процесса оркестрации, не сохраняется на диск и недоступна генератору на протяжении всего цикла; перед фиксацией результата выполняется автоматическая проверка отсутствия проверочных данных в изменениях.

Генерирующий агент («автор», generator) на основе постановки задачи и обучающей части выборки порождает грамматику и программный код, итеративно доводя их до заданных порогов качества на доступной ему обучающей части (в текущей конфигурации – не ниже 95% полноты и точности). Автору предъявляется набор явных правил приёмки (требования к структуре, стилю, покрытию тестами и запрещённым конструкциям); правила фиксируются до начала генерации, и автор не имеет возможности их изменять.

Проверяющий агент («критик», critic) оценивает результат независимо. Существенно, что проверка состоит из двух актов разной природы. Во-первых, полнота и точность сгенерированной грамматики на скрытой выборке вычисляются инструментально – прогоном грамматики штатными средствами тестирования, без участия языковой модели; пороговые значения приёмки зафиксированы в конфигурации системы (в текущей конфигурации – не ниже 80% полноты и 80% точности на скрытой выборке) и, как и правила, недоступны для изменения автором. Во-вторых, языковая модель критика формулирует по вычисленным ошибкам обобщённые наблюдения для доработки. Ко второму акту применимы известные ограничения оценок, выполняемых языковыми моделями [9], однако ключевая числовая метрика от суждения модели не зависит.

Протокол обратной связи устроен следующим образом. Пусть при проверке на скрытой выборке не распознана часть запросов. Возврат автору самих запросов недопустим: серия таких возвратов эквивалентна постепенной передаче проверочной выборки генерирующему компоненту. Вместо этого критик формирует наблюдение об общем свойстве класса ошибок – например, «не распознаются формулировки с изменённым порядком слов» или «ложные срабатывания на запросах смежной тематики, не содержащих целевого действия», – достаточное для целенаправленной доработки, но не позволяющее подогнать решение под конкретные проверочные примеры. Протокол закреплён разделением ролей: перечни конкретных ошибочных примеров остаются на уровне оркестратора и в цикл доработки не передаются. Тем самым адаптация генерации к проверочным данным – эффект, аналогичный переобучению под проверочную выборку при адаптивном анализе данных – существенно ограничивается, хотя и не исключается полностью: многократная оценка на одной и той же отложенной выборке с любой формой обратной связи сопряжена с остаточной утечкой информации. Идея ограничения информации, извлекаемой из проверочного множества при адаптивных итерациях, восходит к подходу reusable holdout [3, с. 636-638]; оценка бюджета остаточной утечки и периодическое обновление проверочной выборки отнесены к дальнейшей работе.

Цикл «генерация – независимая проверка – доработка» повторяется до достижения порога качества либо до исчерпания лимита итераций (в текущей конфигурации – пять итераций для грамматики и три для сопутствующего кода). Основные параметры конфигурации сведены в таблице 1.

Таблица 1

Параметры конфигурации системы

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

Завершённый результат оформляется как запрос на включение изменений (pull request) вместе со значениями метрик и передаётся на ревью инженеру – единственную точку участия человека внутри цикла доработки; постановка задачи и подготовка эталонной выборки выполняются человеком до запуска цикла.

Общая схема архитектуры приведена на рисунке 1.

Рис. 1. Архитектура системы автономной генерации с независимым контролем качества

Методологически архитектура опирается на три принципа: (1) изоляция проверочных данных от генерирующего компонента; (2) фиксация критериев и порогов приёмки до начала работы; (3) наличие объективного внешнего контроля, независимого от языковых моделей. Читателю, знакомому с практикой промышленных испытаний, эта конструкция узнаваема: она воспроизводит логику независимой приёмки – программу испытаний, которую не сообщают изготовителю заранее, чтобы изделие не подгонялось под испытательный стенд, и приёмку по зафиксированным до начала работ критериям. Отличие лишь в том, что здесь и «изготовитель», и часть «приёмочной комиссии» – программные агенты.

Результаты и их обсуждение

Хронология внедрения: система разработана в мае 2026 года; отдельные результаты, полученные прототипом конвейера на этапе отладки, прошли штатное ревью и приняты в основную ветку репозитория весной 2026 года; с августа 2026 года система находится в опытно-промышленной эксплуатации. Данные ниже охватывают период отладки и начальной эксплуатации по 27.08.2026.

По данным журналов системы выполнено 30 запусков; запуском считается полный цикл от постановки задачи до сформированного результата; запусков, прервавшихся до формирования результата, за период не зафиксировано. Из них 25 (83%) приняты на финальном ревью без содержательных правок; под содержательной правкой понимается изменение, затрагивающее поведение результата, в отличие от стилистического или оформительского. Оставшиеся пять результатов были возвращены агенту с точечным указанием несоответствия ожидаемой бизнес-логике сценария и приняты после доработки. Исходы запусков сведены в таблице 2.

Таблица 2

Исходы запусков системы (по журналам на 27.08.2026)

Классификация правок выполнялась автором системы; это ограничение обсуждается ниже. В 90% запусков (27 из 30) порог качества достигался с первой итерации, без цикла доработки; распределение запусков по числу итераций показано на рисунке 2.

Рис. 2. Распределение запусков по числу итераций цикла до достижения порога качества

Типичное время выполнения задачи сократилось с полного рабочего дня инженера (ретроспективная оценка по аналогичным задачам, выполнявшимся вручную) до порядка часа на цикл генерации и финальное ревью. В эту оценку не входит подготовка эталонной выборки и постановки – работа, которая, как показано ниже, остаётся за инженером и составляет существенную часть совокупных трудозатрат; строгий хронометраж полного цикла «постановка – выборка – генерация – приёмка» отнесён к дальнейшей работе.

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

Работоспособность ключевого механизма – оценки на скрытой выборке – наблюдалась непосредственно: зафиксированы случаи, когда результат, достигший порога качества на обучающей части, демонстрировал расхождения на скрытой части; возврат обобщённых наблюдений позволял автору устранить причину без доступа к проверочным примерам. Статистически контролируемое сравнение (в том числе абляция: тот же цикл без отложенной выборки либо с возвратом сырых примеров) не проводилось и остаётся направлением дальнейшей работы.

Ограничения и угрозы валидности. Автор системы, оператор эксплуатации и классификатор правок – одно лицо; независимая классификация исходов не проводилась. Период регулярной эксплуатации на момент подготовки статьи составляет недели; статистика объединяет этапы отладки и начальной эксплуатации. Отбор задач в систему выполнялся инженерами направления; формального правила отбора не было, что допускает смещение в сторону задач, заведомо посильных системе. Наконец, наблюдения относятся к одному домену и одной команде.

Границы применимости. По опыту эксплуатации метод требует: (а) представительной эталонной выборки, качество которой прямо ограничивает качество результата; (б) формализуемой метрики качества – для грамматик ею служат полнота и точность распознавания; (в) внешнего объективного контроля, независимого от языковых моделей; (г) ограниченной цены ошибки, покрываемой финальным ревью. Задачи, удовлетворяющие этим условиям, встречаются за пределами рассмотренного домена: генерация конфигураций оборудования по спецификации, отчётных форм, тестовых наборов по эталону поведения. Напротив, для программного кода с существенной архитектурной новизной, не имеющего формализуемой метрики качества, перенос архитектуры в текущем виде не обоснован.

Полученный опыт согласуется с данными о значимом приросте производительности генеративных систем на массовых формализуемых задачах в организациях [1, с. 889-942].

Заключение

Различие между ассистирующей и автономной генерацией программного кода целесообразно проводить не по возможностям применяемых моделей, а по архитектуре контроля качества. Автономный режим достижим для класса задач, допускающих независимую измеримую проверку результата, и требует трёх архитектурных решений: изоляции проверочных данных от генерирующего компонента, фиксации критериев и порогов приёмки до начала генерации и внешнего объективного контроля, независимого от языковых моделей. Первый опыт промышленного применения предложенной архитектуры при разработке сценариев голосового ассистента подтверждает практическую реализуемость подхода: 25 из 30 запусков приняты на финальном ревью без содержательных правок, а типичное время цикла генерации сократилось с полного рабочего дня инженера до порядка часа.

Дальнейшая работа предполагает накопление статистики эксплуатации на более длительном горизонте, статистически контролируемую оценку качества и издержек (включая абляционное сравнение с циклом без отложенной выборки), периодическое обновление проверочной выборки для ограничения остаточной утечки, исследование переносимости архитектуры на смежные классы задач, а также количественную оценку вклада механизма сверки деревьев поведенческих веток в итоговое качество сопутствующего кода.