Как и зачем появился LEM

Можно работать в Codex, Claude Code, OpenCode, редакторе кода или небольшой локальной агентской оболочке. Сильная облачная модель выполнит больше действий самостоятельно, а компактной локальной модели потребуется более строгий маршрут. Но в 1С обеим нужны одни и те же основания: актуальные исходники, процедуры и функции платформы, точная версия БСП, внутренние стандарты, связи кода и возможность проверить результат.

Поэтому практика быстро выходит за пределы диалога с моделью. Возникают выгрузки из конфигуратора или EDT, статический анализ BSL, поиск по нескольким версиям, загрузка документации, проверка расширений и запуск платформы. Отдельные инструменты хорошо решают свои задачи, но разработчику всё равно приходится вручную собирать их в один процесс.

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

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

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

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

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

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

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

Эта работа повторяется на каждом обновлении. В проектном корпусе LEM может сузить область проверки: показать изменившиеся элементы, найденные связи, известные версии и вероятно затронутые участки. Проектный корпус — отдельное направление и не входит в публичный демонабор библиотек. Решение об объединении и проверка поведения остаются за специалистом.

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

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

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

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

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

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

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

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

Для 1С таким контуром может быть Vanessa Automation MCP. Агент сначала использует LEM, чтобы найти причину и подготовить ограниченное изменение, затем в разрешённой тестовой базе через Vanessa воспроизводит сценарий, запускает проверку и читает результат. Если проверка не подтверждает гипотезу, новое наблюдение возвращается в анализ. Так поиск, изменение и приёмка становятся одним прослеживаемым циклом.

Эта связка подготовлена как пилотная практика, а не объявлена завершённым промышленным внедрением. Для неё отдельно подтверждаются версии, защищённый MCP-доступ, тестовая база и устойчивость сценариев. Открытый демонабор LEM остаётся только для чтения и не запускает 1С.