ИИ в разработке на 1С: не чат, а процесс

Я разработчик 1С. Сообщество сейчас в основном пишет скиллы для агентов, собирает библиотеки промптов, подключает агентов к EDT по MCP через плагин и дает им локальные инструменты для работы с конфигуратором. Я тоже этим занимаюсь, и польза есть. А рабочий день почти не изменился.

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

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

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

Сразу оговорюсь: я не специалист по CI/CD и DevOps. От меня идея и описание процесса. Скрипты, конвейер и интеграции собирал ИИ-агент по моим требованиям, и это тоже часть эксперимента. Разработчик 1С без опыта в DevOps поднял работающий стенд за один день.

Агент в процессе, люди в точках решения

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

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

Между утверждениями агент работает сам: пишет код и тесты, запускает проверки, открывает Merge Request. Человек видит задачу на доске и получает ее, когда нужно его решение. Не согласен – пишет комментарий, и агент переделывает свой этап.

Новой методологии тут нет. Обычная команда так и работает: аналитик пишет ТЗ, архитектор согласует решение, разработчик делает. Меняется одно. Черновую работу на каждом этапе делает агент, а люди проверяют и утверждают.

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

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

Что это меняет в работе команды

Оркестрация идет сама. Разработчик больше не ищет, кто аналитик по этой задаче, и не несет вопросы архитектору. Не нужно писать в мессенджер «посмотри, пожалуйста» и собирать созвон, чтобы проверить, одинаково ли все поняли задачу. Статус сам призывает того, чья очередь. Ответ — это комментарий в задаче и нажатая кнопка, после чего следующий этап стартует без диспетчера.

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

Модель процесса

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

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

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

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

Роли заведены полями задачи «Аналитик», «Архитектор» и «Разработчик». Агент призывает в комментарии того, чей сейчас ход, и трекер присылает этому человеку уведомление.

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

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

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

Демонстрационный стенд

Все работает на одной машине разработчика под Windows. Снаружи к ней никто не подключается, стенд сам ходит в трекер и в GitLab.

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

Подопытная — маленькая конфигурация с двумя справочниками, документом «Заказ клиента» и одним общим модулем. Рабочий код компании на стенд не попадает.

Инструменты здесь просто те, что были под рукой. От них схема не зависит: трекер хранит статусы и роли, CI запускает агента, агент работает с исходниками и тестами. Этапов и статусов тоже может быть сколько угодно, я взял минимальный набор, чтобы показать принцип.

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

Исходники стенда открыты: 1c-ai-pipeline.

Агент на стенде — заменяемая деталь, а не часть процесса. Сначала этапы проходил один CLI-агент, потом тот же конвейер без смены статусов и job запустил другой. Поменялась команда запуска, а спека, архитектура, план и ревью остались на своих местах.

Как это работает изнутри

Управляющий сигнал — статус задачи в трекере. Статусы вида «AI: …» значат, что ход агента, все остальные — что ход человека.

1. Оркестратор раз в минуту запрашивает у трекера задачи в статусах «AI: …». Вебхук не используется: облачный трекер до локальной машины не достучится, а открывать ее в интернет ради демо я не хочу.

2. На каждую такую задачу он запускает pipeline в GitLab через API и передает ключ задачи и этап.

3. Job на локальном runner читает задачу со всеми комментариями и запускает агента на один этап.

4. Агент публикует результат комментарием, призывает человека из поля роли и переводит задачу дальше.

5. Человек отвечает в комментарии и нажимает кнопку перехода. Задача снова попадает в статус «AI: …», и цикл повторяется.

Между запусками агент ничего не помнит. Состояние хранится в задаче и в ветке: спека, архитектура и план лежат комментариями для людей и файлами для следующего этапа. Поэтому между этапами может пройти день, и ничего не потеряется.

Рабочий процесс трекера описан в репозитории JSON-файлом с ролями, статусами и переходами. По нему скрипт через API создает статусы, рабочий процесс, очередь и поля ролей. Процесс правится через Merge Request, как код.

Если этап упал или не запустился, задача уходит в «Нужен человек» с причиной в комментарии. Сломанный этап не крутится по кругу, а сразу виден на доске как задача для человека.

Тестирует не агент, и это сделано намеренно: пересказывая свои результаты, он может ошибиться. После разработки отдельный job собирает чистую базу и гоняет тесты уже без модели. Если тесты падают, задача возвращается агенту с отчетом, а после трех неудачных попыток уходит человеку.

Ревью тоже идет не в чате. Замечания пишутся в Merge Request, к строкам кода. Чтобы вернуть работу агенту, разработчик ставит на MR метку ai-rework или начинает комментарий с @ai. Оркестратор выгружает агенту нерешенные обсуждения из MR, агент правит ту же ветку, отвечает в каждом обсуждении и снова отдает MR на ревью. Вернуть задачу так можно не больше пяти раз, потом она уходит человеку: пусть решает он, а не гоняет агента по одному кругу. Merge делает разработчик, после чего оркестратор сам переводит задачу в «Решена».

Живая задача от заявки до merge

Задача AIDEMO-4: «Нельзя сохранить заказ со строкой без количества». Менеджер написал ее как обычно, без деталей. Все этапы прошли на самой дешевой модели линейки.

Роли в демо играют вымышленные сотрудники: аналитик Елена Соколова, архитектор Андрей Ковалев и разработчик Дмитрий Орлов. Агент пишет от своих учеток: «AI-агент» в трекере и «AI Agent» в GitLab. Дальше весь путь задачи по карточкам, на каждый раунд ход агента и ход человека.

01. Менеджер ставит задачу как обычно

02. Агент разбирает заявку

03. Аналитик отвечает на вопросы агента

04. Агент предлагает архитектуру

05. Архитектор утверждает решение

06. Агент составляет план доработки

07. Разработчик утверждает план

08. Агент пишет код и тесты

09. Разработчик проверяет Merge Request

Когда агент не справился

От агента в процессе нужен не только результат. Не менее важно, чтобы он останавливался, когда работать не по чему. Я проверил это на задаче, которая попала не в ту очередь: менеджер попросил поправить расчет отпускных, а в демо-конфигурации есть только заказы. Агенту хватило 20 секунд, чтобы понять, что зарплаты в этой базе нет. Спецификацию он писать не стал, объяснил, чего не хватает, и перевел задачу в “Нужен человек” с призывом разработчика. Прогон обошелся меньше чем в цент.

Что агенту разрешено

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

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

Сколько времени это экономит

Замерить экономию честно сложно, поэтому время людей ниже примерное. Я прикинул по своему опыту, сколько уходит на небольшую доработку, если работать с агентом в чате, и сколько той же работы остается людям, когда задача идет по процессу. Ожидание ответов в таблицу не входит, считается только время, которое человек тратит руками. Время агента взято из логов AIDEMO-4.

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

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

Сколько это стоит в деньгах

Каждый запуск агента оставляет в артефактах job отчет: время, шаги модели, токены и стоимость. По AIDEMO-4 вся задача обошлась в 68 центов, включая доработку по замечанию ревью. Дороже всего этапы с кодом: там агент много раз перечитывает модули конфигурации.

Цифры посчитал сам Claude CLI по ценам API. На стенде агент работает по подписке, отдельного счета за эти прогоны нет. Сильная модель на этапе архитектуры обойдется дороже. Сравнивать это стоит с часом работы аналитика, архитектора и разработчика, а не с нулем.

Что не решено

Остаются вопросы, на которые стенд пока не отвечает.

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

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

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

Права на кнопки пока не ограничены: “Утвердить архитектуру” может нажать любой участник очереди. В рабочей версии переходы нужно закрепить за ролями.

Итог

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

Инструментов, этапов и статусов может быть сколько угодно. Яндекс Трекер, GitLab и конкретный CLI-агент на стенде взяты для демонстрации, процесс устроен так, чтобы их можно было заменить, не переписывая правила для людей. Исходники стенда: gitlab.com/maxrubtsoff/1c-ai-pipeline.