Если агенту дать среду, правила и инструменты, он перестает быть собеседником и начинает работать как часть инженерного контура.

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

Для 1С это болезненно вдвойне. Здесь мало знать синтаксис языка. Нужно понимать состав метаданных, правила именования, версию платформы, режим совместимости, наличие БСП, служебные команды и сам способ загрузки изменений обратно в базу. Пока всего этого нет рядом с агентом, он остается дорогим помощником по переписке, а не рабочим инструментом разработки.

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

Почему обычная переписка с ИИ не решает проблему

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

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

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

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

Как выглядит контур, в котором агент делает больше, чем просто отвечает

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

Минимальный автономный конвейер ценен не отдельным ответом, а повторяемым циклом от задачи до проверки результата.

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

Такой подход меняет и роль человека. Разработчик больше не обязан быть оператором бесконечного копирования и вставки. Его задача смещается в сторону настройки среды, постановки ограничений и финальной оценки результата.

Почему одного промта мало: что нужно агенту для 1С

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

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

Структура проекта: рабочее место агента

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

Структурированный проект превращает набор файлов в рабочее место агента и удерживает контекст рядом с задачей

Минимально рядом с задачей должны лежать каталог doc с постановкой и пояснениями, каталог src с выгруженными файлами 1С, каталог со skill, файл настройки базы и служебные markdown-файлы, в которых фиксируются правила и результат. Проще говоря, мы заранее собираем для агента рабочий стол.

Если эта среда не собрана, агент начинает блуждать между файлами и уточнениями. Если собрана аккуратно, он тратит меньше токенов на навигацию и больше ресурсов на саму задачу.

Зачем нужна спецификация

Файл spec.md показан как одна из ключевых опор. Это не бюрократия и не лишний документ, а компактное описание границ проекта, внутри которых агенту разрешено принимать решения.

Spec.md и memory bank работают в паре: задают правила, удерживают прогресс и стабилизируют длинные задачи.

В спецификации имеет смысл фиксировать как минимум:

• версию платформы и режим совместимости;
• наличие или отсутствие БСП;
• правила именования и общие стандарты кода;
• договоренности по оформлению запросов и структуре изменений;
• порядок обновления памяти проекта и фиксации результата.

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

Memory bank: внешняя память вместо повторных объяснений

Даже на средней по длине задаче агент начинает забывать: что уже проверяли, какие файлы меняли, почему был выбран текущий путь и какая ошибка уже встречалась раньше. Это не аномалия, а нормальное ограничение любой длинной сессии. Поэтому внешний memory bank вынесен в отдельную опору.

Минимальный набор памяти проекта можно держать в нескольких простых файлах:

• контекст проекта: что за система, какая задача решается, какие ограничения нельзя нарушать;
• текущий прогресс: какие шаги уже выполнены и что еще осталось;
• активные решения: какие гипотезы приняты, какие варианты отброшены и почему;
• result.md: краткая фиксация промежуточного и финального результата.

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

Что меняется на практике: от промта до result.md

Практика показывает именно полный маршрут работы агента. Сначала готовится среда: каталог проекта, настройки базы, spec.md, result.md и вспомогательные файлы памяти. Затем агент получает компактную, но проверяемую задачу и начинает работать не с догадками, а с реальными артефактами проекта.

1. Планирует шаги и определяет, какие инструменты и файлы ему понадобятся.
2. Формирует или уточняет spec.md, чтобы зафиксировать технические рамки.
3. Выгружает конфигурацию и получает доступ к XML, BSL и связанным артефактам.
4. Анализирует структуру файлов, находит нужную логику и вносит изменения.
5. Загружает обратно измененные файлы, а не гоняет без нужды всю конфигурацию целиком.
6. Запускает проверку, фиксирует результат в result.md и при необходимости проходит еще одну итерацию.

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

Типовые ошибки агента и как их контролировать

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

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

С чего начать первый пилот

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

1. Собрать минимальный рабочий контур и прогнать на нем небольшую типовую задачу с понятным результатом.
2. Создать отдельный каталог проекта и разложить в нем doc, src и служебные файлы.
3. Подготовить файл настройки базы и рабочие команды для пакетного режима.
4. Подключить skill и завести заготовки spec.md и result.md.
5. Выбрать короткую задачу: реквизит, команду, простую печатную форму или небольшую проверочную обработку.
6. Дать агенту пройти полный цикл выгрузка -> анализ -> код -> загрузка -> тест.
7. Сравнить фактический выигрыш по времени и количеству ручных шагов с обычной работой без подготовленной среды.
8. Такой пилот быстро показывает, где агент действительно снимает техническую рутину, а где пока только создает видимость автономности.

Границы подхода и роль разработчика

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

Именно разработчик проверяет, что изменения действительно загрузились, временные тестовые костыли убраны, нужный объект работает как ожидалось, а итог зафиксирован в result.md. Без этого автономность остается только красивой идеей на уровне демо.

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

Выводы

• Автономная работа агента в 1С начинается не с модели, а со среды: каталогов, настроек, skill и пакетного режима.
• Spec.md ограничивает фантазии агента и снижает цену лишних итераций.
• Memory bank нужен не для красоты, а для сохранения контекста, прогресса и уже принятых решений.
• Практическая ценность появляется там, где агент проходит полный цикл от анализа до проверки, а не просто пишет фрагмент кода.
• Ошибки агента не повод скрывать демонстрацию, а источник информации о том, какие ограничения и проверки еще нужны.

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