За последний месяц произошло много событий, но наиболее интересным является использование LLM для программирования на платформе 1С.

В августе я активировал бесплатную неделю для Claude от Antropic и не успел отменить подписку в последний день - так у меня для тестов появился оплаченный месяц Pro.

Итак к интересному.

У меня есть два параллельных проекта на разработку примерно одинаковых по размеру подсистем, но использую LLM я немного по разному. Для первого проекта у меня выгрузка в файлы, где модель по моим указаниям вносит правки, после чего я делаю загрузку из файлов. Во втором проекте у меня конфигурация с расширением развернуты в EDT, куда подключен EDT-MCP с полным доступом.

В обоих вариантах я получаю результаты, но модели при этом ведут себя по разному:

1) Если править файлы на диске, то Sonnet 5 показывает себя крепким мидлом с задатками сеньора - минимум ошибок, интересные предложения для улучшения эффекта от выполнимых задач. Ранее в рамках Google Pro у меня в Antigravity были доступны модели Sonnet 4.6 и Opus 4.6 - так тут просто небо и земля, Sonnet 5 намного-намного превосходит в интеллекте Opus 4.6. И самое восхитительное, что теперь для качественного 1С кода больше не нужно ни доступа к Синтаксис-Помощнику, ни к платформенной проверке на ошибки. Мелкие ошибки быстро исправляются, я о них сообщаю ИИ и тот фиксирует их в памяти сессии и специальном служебном файлике на диске, который я подключаю между сессиями.

2) При редактировании через MCP я использовал сначала Sonnet 5, а потом Opus 5 - не смотря на доступ к документации платформы и продвинутым внутренним механизмам контроля из ядра EDT, у меня стойкое ощущение, что работаю с глуповатым джуном. Я даже попробовал этот же проект на Fable от корпоративной учетки - не сильно лучше.

3) По данным Claude Code из расхода первого проекта 88% уходило на файловые операции, а все остальное на понимание и обсуждение проекта. Во втором проекте на выполнение MCP-вызовов ушло 97%

4) Задачи все же немного разные в проектах и потому некорректно прямое сравнение по токенам, но перерасход в проекте с MCP минимум в 10 раз больше. Я воспользовался встроенным скиллом "/anthropic-skills:explain-usage" и получил ответ: Большая выгрузка метаданных или скриншот формы остаётся в памяти беседы и перечитывается на каждом следующем шаге. Чем длиннее сессия, тем дороже каждый новый шаг.

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

Итоговый вывод.

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

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

#1с #edt #llm #mcp #vibecode