90% кодинга с участием AI-агентов: как мы перестроили разработку 1С

На одном из действующих проектов Гардариона около 90% объёма кодинга выполняется с участием нашего агентного модуля «AI Engineering для 1С». Смелое заявление, соглашусь. Но результат такой, какой есть, и он более чем впечатляющий. Немного деталей: проект по миграции на 1С:ERP. Назвать заказчика и раскрыть детали мы не можем из-за NDA, но уже можем рассказать, какой процесс стоит за этой цифрой и почему полученный опыт мы решили оформить в отдельное продуктовое направление.

Мы назвали его агентный модуль «AI Engineering для 1С». Это управляемый агентный контур генеративной разработки, который разворачивается вокруг конкретной конфигурации инструментов и принятого у заказчика процесса разработки.

Что именно означает показатель 90%

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

Цифра также не означает, что срок или бюджет всего проекта сокращается на 90%. По мере ускорения кодинга больше времени занимает подготовка работы: нужно точнее описать задачу, заранее определить слой изменения, разобрать зависимости и сформулировать проверяемые критерии результата. Затем код проходит тесты и независимое ревью.

Именно поэтому мы измеряем принятый результат. Сгенерированный модуль, который лежит в папке проекта, ещё ничего не доказывает. Для рабочей статистики изменение должно собраться, выполниться в тестовой базе, пройти проверки и быть принято инженером.

Почему 1С потребовала отдельного подхода

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

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

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

Как устроен рабочий контур

Работа начинается с постановки и проектирования. Инженер определяет цель, ограничения, архитектуру и критерии приёмки. После этого задача проходит через специализированные роли.

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

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

Размещение зависит от ограничений проекта. В гибридной схеме индекс, исходники и тестовая база остаются внутри инфраструктуры заказчика, а внешняя модель получает минимальный контекст по задаче. Для закрытого контура модель и инструменты можно развернуть локально. Возможен и изолированный контур на инфраструктуре Гардариона с согласованными каналами доступа.

Что меняется в работе инженера

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

Инженеры участвуют в проектировании, берут на себя сложные и критичные изменения, проводят содержательное ревью и принимают результат. Агенты выполняют основной объём исполнения внутри установленных границ. Такая схема соответствует принципу human-in-the-loop: на контрольных точках решение принимает человек, который отвечает за систему.

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

Что входит в AI Engineering для 1С

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

• индекс метаданных, кода и связей;
• роли агентов, правила и ограничения;
• процедуры выгрузки, сборки и версионирования;
• интеграцию с Git или хранилищем 1С;
• тестовую базу и автоматизированные проверки;
• журнал задач, изменений и версий поставки;
• обучение команды;
• поддержку и обновление компонентов контура.

Первым этапом станет пилот на одной конфигурации. После обследования мы выбираем 8–12 сопоставимых задач, разворачиваем индекс и рабочие роли, настраиваем тестовую среду и вместе со специалистами заказчика проходим полный цикл. Обычно такой пилот занимает 3–4 недели после предоставления инфраструктуры и доступов.

В отчёте фиксируются время от согласованной постановки до принятого изменения, доля принятого AI-кода, число возвратов с ревью и найденные дефекты. Эти данные показывают реальный эффект на конкретной конфигурации и дают основание для решения о промышленном внедрении.

Из внутренней практики в продукт

Сейчас мы используем модуль на собственных проектах и выходим на пилотные внедрения у заказчиков. В текущем проекте контур уже подтвердил, что может брать на себя основную долю кодинга, сохраняя архитектурное управление, тестирование и инженерную ответственность.

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