ИИ-агенты в разработке на ELMA 365: правила без права на последний клик

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Главный вывод для команд: отдача от ИИ-агентов зависит не от моделей и промптов, а от жёстких регламентов — изоляции задач, read-only прода и независимого ревью, — и это готовый чек-лист для внедрения агентов в SMB-разработку.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

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

Так выглядели первые недели у команды, которая делает бизнес-модули на low-code платформе ELMA 365: договоры, контрагенты, корреспонденция, доверенности, облигации. Руководитель ИТ с опытом больше 20 лет описал в первой из семи статей, как они перестраивали процесс. Самое полезное там — не про модели. Про рамки, в которые агента загоняют.

Спойлер: главное оказалось не в моделях и не в промптах. А в правилах, которые мы писали, наступая на грабли.

Для собственника SMB это важнее, чем кажется. Пока агент — «быстрый разработчик», которого пустили в проект, вы получаете ускорение на ровном месте и неконтролируемый риск на неровном. Разница между этими состояниями измеряется не токенами, а регламентом приёмки.

Четыре правила, на которых всё держится

Изоляция. С октября каждая задача живёт в отдельной ветке и отдельной рабочей копии проекта через git worktree. Все копии лежат в служебной папке внутри проекта, в основной разрешено только смотреть. Плюс журнал: по каждому изменённому объекту (форма, виджет, процесс, файл, тестовая запись, временный доступ) фиксируется состояние до правки, способ правки, что реально легло на сервер и как убрано временное. Скриншот доказательством не считается — нужна выгрузка или ответ сервера. Неудачные и частичные записи в журнал тоже идут.

Прод только на чтение. Распоряжение от 15 октября без вариантов: агенты в рабочей системе не сохраняют, не публикуют, не создают и не удаляют ничего. Даже «просто проверить».

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

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

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

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

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

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

Что здесь нового по сравнению с обычным внедрением

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

Здесь к нему применили ровно те же требования, что к человеку в штате. Отдельная рабочая копия вместо общей папки. Реестр занятых объектов на сервере — потому что worktree изолирует файлы, а живые процессы в ELMA 365 нет. Отдельная приёмка вместо самопроверки. И дважды агенты сами останавливались перед необратимым действием — при применении конфигурации через мастер обновления и при вводе токена доступа — и передавали последний клик человеку.

Вот это и есть главный сдвиг. Агент получает полномочия до определённой черты. За чертой — человек. Не потому, что модель глупая, а потому что откат дороже паузы.

Кому это нужно и как примерить на себя

Чек-лист для SMB-разработки, где уже есть хотя бы один агент:

• своя ветка и своя копия проекта на каждую задачу, в основной копии — только чтение;
• реестр занятых объектов на сервере, если агентов больше одного;
• прод в режиме чтения на уровне техники, а не на честном слове;
• журнал по каждому изменённому объекту с выгрузкой или ответом сервера вместо скриншотов;
• отдельный статус «проверка не завершена» и обязательное прохождение реального бизнес-процесса;
• независимая приёмка с обесцениванием проверки после правки кода;
• матрица случаев для процессов: нормальное завершение, пустой список участников, повторные участники, возврат на доработку, отмена, а для файлов и пользователей — замена файла, переназначение, замещение.

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

Где подвох

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

Ещё два ограничения честно держать в голове. Приёмы заточены под ELMA 365 и её серверы разработки, на другом стеке набор фильтров и мастеров будет свой. И фильтр запросов в браузерной сессии — тонкая прослойка: он защищает от ошибки агента, а не от намеренной атаки, и требует, чтобы кто-то следил за его актуальностью.

Брать или подождать: вердикт за 30 секунд

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

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

Кому точно не подходит — тем, кто ищет в агентах замену контролю. Изоляция, read-only и независимое ревью не ускоряют модель. Они сокращают число сюрпризов, которые вы обнаружите на своём проде.

Вопросы, которые задают первыми

Нужен ли отдельный агент-ревьюер, если код смотрит человек?

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

Можно ли обойтись без git worktree?

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

Сколько времени занимает внедрение?

В источнике сроков нет. Известно, что правила написаны с октября и 15 октября, по итогам нескольких болезненных инцидентов на сервере разработки.

Если коротко: агент приносит пользу там, где у него есть рамка, журнал и принимающий. Всё остальное — ставка на то, что в этот раз ничего не сломается. Начните с запрета на запись в прод и с приёмки чужими руками, а остальное достройте по мере роста числа задач.