Мой ИИ-агент написал 11 000 строк кода, которые работают, и я ни разу не открыл конфигуратор

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

Через семь дней агент исследовал структуру базы, поднял интеграцию, научился ставить точки останова через собственный отладчик и написал тысячи строк рабочего кода. Я за это время ни разу не открыл конфигуратор.

Ну ладно. Открыл только для того, чтобы "посмотреть". Интересно же, что там нагородил агент. Я был приятно удивлен.

Продолжение тут: Мой ИИ-агент пишет 100 000 строк кода в неделю, которые работают, и я ни разу не открыл конфигуратор

[Тут будут остальные ссылки на статьи с подробностями, когда я их напишу]

С чего всё началось

Первая неделя — это не «поговорили с чатом и получили скрипт». Я в роли старшего брата ставил задачи, направлял, если робот выбирал не верный путь.

В итоге 160 коммитов в ядре агента и ещё 230 в MCP-инструменте, через который он управляет 1С.

К концу недели у него был целый инструментальный пояс:

• 🔌 рабочий OData-слой поверх боевой конфигурации — с поиском объектов без полного парсинга схемы и с тулом «найди Ref_Key по бизнес-полю» вместо самодельного питона поверх фильтров;
• 🐞 собственный отладчик - рабочий протокол RDBG, который сам себе починиL9;л (об этом ниже) и подключение через внешнюю обработку, без танцев с конфигуратором;
• 📚 база знаний по BSL и кэшированная документация ИТС/Синтакс помошника - чтобы не выдумывать код, а сверяться с фактами;
• 🗂 задача-трекер (tasksDB) - общая база задач, куда робот сам пишет, что сделал, что заблокировано и почему;
• 🧳 механизм передачи файлов между агентом и сервером 1С - вместо того чтобы гонять абсолютные серверные пути и содержимое файлов через диалог, тулы processor_push_file/processor_pull_file кладут и забирают файлы напрямую, не засоряя контекст;
• MCP-сервер, спроектированный так, чтобы экономить токены и общаться с инструментарием 1с проверенным способом
• 🧬 базовая функциональность добавления и модификации метаданных прямо руками агента - и это не абстракция ради красивого слова: модули объектов, общие модули, константы, подсистемы, макеты, внешние обработки — всё это агент умеет создавать и дорабатывать сам, без ручного похода в конфигуратор. Одна команда с параметрами со стороны ИИ-агента - и на выходе новая структура метаданных, которая тут же загружается в базу;
• 🧭 сценарий оркестрации, который держит весь этот процесс в рамках: планирование, исследование, контроль результата, документирование, проверка кода на соответствие стандартам - с блоками обратной связи и повторными попытками там, где с первого раза не получилось.

Большая часть кода — это BSL, код самой платформы 1С: модули расширений, обработчики, обёртки для OData, генераторы XML-разметки для табличных документов. Я лично оцениваю объём написанного за неделю в 11 000 строк — часть этого живёт прямо в конфигурации боевой базы как объекты метаданных, а не только в текстовых файлах в git, поэтому точный подсчёт «построчно» тут не такая простая штука, как для обычного репозитория на Python. Но по ощущениям от объёма проделанной работы — это она и есть, 11 тысяч строк рабочего, протестированного кода.

Где робот путался:

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

История 1. Тотальный хардкод

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

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

История 2. «Эти замечания BSL-анализатора не мои»

Тут робот повёл себя как студент, которого отчитывают за чужую парту. При завершении работы агент увидел, что в коде остались предупреждения BSL-анализатора, и решил, что это нормально - ведь эти замечания были «не от меня». Формально логично, по существу - нет: код с любыми незакрытыми замечаниями BSL-анализатора не считается готовым, вне зависимости от того, кто их туда внёс.

Пришлось вмешаться и явно, жёстко зафиксировать правило: «чистый прогон» - это ноль замечаний, точка, без исключений «эти не мои».

Правило теперь прописано в регламенте оркестрации агента, чтобы больше не возникало соблазна закрыть глаза на чужой мусор в коде.

История 3. Монопольная блокировка на весь лес ради одной ветки

У агента было правило «никогда не открывать два конфигуратора одновременно», введённое, чтобы избежать конфликтов записи в базу. Проблема в том, что робот трактовал это правило слишком буквально - блокировал вообще ЛЮБУЮ параллельную работу с базой целиком, хотя монопольный доступ реально нужен только для конкретных операций в конфигураторе, а не для всего вообще. Это тормозило параллельную работу нескольких субагентов там, где реального конфликта не было.

Правило сейчас пересматривается, четкого решения пока нет.

История 4. Ложный тупик, придуманный самим агентом

Задача была прикладная — собрать макет табличного документа как внешнюю обработку.

Агент собирал .epf из BSL-модуля, получал битые символы в исходнике и добросовестно перепробовал два варианта кодировки — оба падали по-разному. После этого он остановился и записал в задачу вывод: похоже на дефект собственного тула сборки .epf.

Разумно, но неверно: причина оказалась в другом месте - в диалоге агент копировал гигантскую base64-строку модуля, а не отправляли её напрямую через файл. Именно вставка длинной base64-строки в чат и резала символы.

Диагноз «дефект тула» был снят только тогда, когда прогнали то же самое в обход диалога - собрали JSON-тело на диске и отправили его curl'ом напрямую.

Показательно, что это не разовая случайность: то же самое скрытое усечение base64 при копировании повторилось ещё раз в отдельной задаче (сборка внешней обработки роли) - тул при этом рапортовал {"ok": true}, хотя результат был нерабочим.

После второго повторения правило «не копировать base64 руками в диалог, только через файл на диске» закрепили как обязательное - не потому что стало любопытно, а потому что один и тот же ложный след возник дважды независимо.

История 5. Настоящий баг там, где агент сам был автором

Не всегда путаница агента - это неверный диагноз.

Иногда диагноз верный, а виноват сам агент: в генераторе XML-разметки колонок табличного документа обнаружился баг - ширина колонки записывалась напрямую в тег <column>, хотя платформа ожидает её только через палитру форматов (<format>/<formatIndex>), а размер палитры вообще всегда прописывался как «1», игнорируя реальное число колонок.

Результат - макет собирался без ошибок, но выглядел не так, как задумано. Никакой статический анализ такое не ловит, потому что XML был синтаксически валидным - просто платформа не читала ширину оттуда, где её искал агент.

Нашли и починили только прогоном реального макета и сверкой с ожидаемым видом. Урок практический: генератор разметки - это код, который нужно гонять на реальных данных, а не только проверять по формальным правилам Сонара.

Главная фишка: агент, который сам себя достраивает

Всё перечисленное выше - это не разовые правки от меня в код агента.

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

У него есть собственная база знаний по BSL, которую он сам пополняет по мере того, как натыкается на неочевидные вещи платформы.

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

Что дальше

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

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

Именно в этом, а не в скорости написания кода, я вижу главный результат недели: агент, который умеет вовремя сказать «стоп, тут нужно решение человека» — гораздо ценнее агента, который бодро генерирует код, не понимая, где кончается его компетенция.