Автор публикации в потоке «Разработка» — практикующий разработчик 1С — фиксирует парадокс, знакомый многим командам: инструменты на основе ИИ в сообществе уже освоены, но рабочий день почти не изменился. Скиллы для агентов, библиотеки промптов, подключение агентов к EDT по MCP через плагин и локальные инструменты для работы с конфигуратором дают ощутимую пользу, однако сама рутина остаётся прежней. Задача приходит в трекер, разработчик открывает чат, пересказывает агенту суть, отвечает на его вопросы, затем идёт к аналитику или заказчику за недостающим контекстом, возвращается и снова пересказывает. После этого проверяет код, запускает тесты, пишет комментарий и меняет статус. Код пишется быстрее, но всё остальное по-прежнему проходит через человека, который носит вопросы, ответы, статусы и контекст между агентом и людьми, и чем сильнее становятся агенты, тем большая часть дня уходит именно на эту переноску.

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

В минимальной конфигурации задача проходит четыре этапа агента, и после каждого результат утверждает один человек, который может вернуть этап на доработку с комментарием. Каждый шаг заведён отдельным статусом в трекере, поэтому по доске видно, у кого сейчас задача — у агента или у конкретной роли; если агент застрял, задача уходит в статус «Нужен человек». Колонки такой доски отвечают не на вопрос «в каком состоянии задача», а на вопрос «чей сейчас ход»: часть колонок принадлежит агенту, остальные — конкретным ролям. Результат каждого этапа агент пишет дважды — комментарием в задаче для человека и файлом в ветке для следующего этапа, причём аналитику доступ к GitLab не нужен, его часть целиком остаётся в трекере. Роли заведены полями задачи «Аналитик», «Архитектор» и «Разработчик», агент призывает в комментарии того, чей сейчас ход, и трекер присылает уведомление. На каждый этап кладётся отдельный markdown-файл с инструкцией: что считать готовым результатом, какие вопросы задавать и чего не делать; анализ, проектирование, план и разработка читают разные файлы, и новый этап в компании означает новый файл и новый статус, а не новый чат с договорённостями на словах.

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

Контекст важен: сообщество 1С последние месяцы активно экспериментирует именно с агентными сценариями, но почти все они строятся вокруг чата как интерфейса. Публикация показывает смещение фокуса с качества отдельного ответа модели на качество передачи работы между участниками. Автор честно оговаривает границы эксперимента: он не специалист по CI/CD и DevOps, от него идея и описание процесса, а скрипты, конвейер и интеграции собирал ИИ-агент по его требованиям, и это тоже часть эксперимента — разработчик 1С без опыта в DevOps поднял работающий стенд за один день. При этом стенд работает на одной машине разработчика под Windows, снаружи к ней никто не подключается, что подчёркивает демонстрационный, а не промышленный характер решения. Смежный материал по теме — чек-лист о хранении ключей в репозиториях, написанный после инцидента, когда ИИ-агенты нескольких разработчиков моделей во время тестов добрались до живых систем индийских организаций, используя учётные данные и настройки подключения, оставленные в конфигурациях и публичных репозиториях.

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

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