Эта статья про то, как работая над продуктом “AI для 1С” (комплексная AI-система для аналитиков и разработчиков 1С), я сначала прикрутил Vanessa Automation, а потом решил реализовать нативный TestClient протокол на Python, но ничего не вышло.

А потом внезапно сильно продвинулся с помощью новой модели от Антропик - Fable 5. В итоге получился быстрый и функциональный qa-mcp - собственный контур тестирования для AI-разработки в 1С.

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

Эта статья — про один из таких практических шагов. Я хочу рассказать, как мы у себя в компании автоматизировали процессное управление на базе BPMN 2.0 моделей, Camunda и Битрикс24 и получили операционный контур, в котором процесс — это не регламент и не картинка BPMN, а исполняемый маршрут с задачами, контекстом, переменными процесса и передачей контекста между шагами.

На первый взгляд AI-native звучит как очередной красивый ярлык для компаний, где всем выдали ChatGPT, Claude Code, Cursor и пару внутренних ботов. Но если смотреть не на инструменты, а на то, как реально работает компания, картина становится интереснее.

Оказывается, значительная часть нашей работы — это не создание продукта и даже не принятие решений. Это перенос контекста. Клиент что-то сказал. Аналитик понял и оформил. РП пересказал. Разработчик уточнил. QA нашёл неоднозначность. Архитектор вспомнил, что три года назад похожее решение уже ломалось. Новичок спросил, где это описано. Все снова собрались на встречу, потому что в Jira непонятно, в Confluence устарело, а “без Пети никто этот модуль не понимает”.

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

На первый взгляд миграция из Kaiten в Bitrix24 выглядит как обычная интеграционная задача: прочитать данные из одного REST API и записать в другой REST API.

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

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

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

В этой статье расскажу, как мы построили мигратор на Python, где помог асинхронный подход, почему маппинг ID оказался центральной частью архитектуры, какие ограничения обнаружились в коробочном Bitrix24 и почему часть задач пришлось решать не только через REST API, но и через отдельные серверные скрипты.

Репозиторий с кодом: https://github.com/vlikhobabin/kaiten-to-bitrix

Я руководитель проектов и у меня есть команда разработки продуктов. Аналитики исследуют и анализирует новые фичи, пишут спецификации. Есть разработчики и тестировщики. Есть DevOps, который чинит CI и выкатывает релизы. И даже есть технический писатель анализирует изменения и обновляет документацию.

Обычная продуктовая команда разработки.

Только людей в этой команде нет.

Все исполнители - AI-агенты…

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

Современные AI-агенты способны выполнять работу разных инженерных ролей, так почему бы не управлять ими как полноценной командой? А для управления использовать те же подходы, которыми мы давно управляем человеческими командами: Kanban, Scrum, Agile, Definition of Done, декомпозиция, pipeline, review, escalation.

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