Вайб-кодинг в 1С: что это и как работает на практике

Из чего состоит рабочий вайб-кодинг в 1С

Рабочий вайб-кодинг 1С — это не «чат в браузере». Он работает только тогда, когда агент видит проект. Это связка:

• 1С:EDT, чтобы конфигурация и расширение были в текстовом виде;
• Git, чтобы видеть историю, diff и иметь нормальный откат;
• MCP-серверы, чтобы ИИ видел метаданные, документацию, справку платформы и реальные объекты;
• ИИ-агент в рабочей папке проекта, который читает код, запускает проверки и не пишет вслепую.

Ниже пример не с демо-базы. Это реальный розничный проект на отраслевой конфигурации ДАЛИОН/1С. Название клиента, организаций, складов и товаров здесь не раскрывается, но техническая структура задачи сохранена.

Реальная задача: печатная форма кассовой смены по группам

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

Работа шла в существующем расширении. В итоге были затронуты: Document.ОтчетКассовойСмены, макет печатной формы, модуль менеджера документа, формы документа и списка, новый регистр сведений B2C_ПорядокГруппПечатиОКС, подсистема и роль.

По журналу работ основная итерация заняла 1 час 6 минут: перенос логики на группировку, добавление регистра, выгрузка, загрузка через Конфигуратор, /UpdateDBCfg, /CheckConfig, обратная выгрузка и обновление MCP-индекса. Потом короткая правка на 3 минуты.

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

Почему без MCP такой код легко сломать

Хороший пример — ошибка, которая всплыла при печати:

ВыборкаПоТоварам = ТаблицаТоваров.Выбрать();

Проблема в том, что ТаблицаТоваров здесь была не результатом запроса, а ТаблицаЗначений, полученной через Выгрузить(). У РезультатЗапроса есть метод Выбрать(). У ТаблицаЗначений такого метода нет. Ошибка в базе была конкретная: «Метод объекта не обнаружен (Выбрать)».

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

ТаблицаТоваров.Сортировать("B2C_ПорядокГруппы, B2C_ГруппаПечатиНаименование, Количество Убыв, ТоварНаименованиеПолное");

В 1С ошибка часто не в синтаксисе, а в неверном предположении о типе объекта. Без доступа к конфигурации агент не знает, что у него в руках: выборка, таблица значений, данные формы или результат СКД.

Что агент проверил в конфигурации

Перед правкой агент не должен «знать 1С вообще» — он должен смотреть конкретную базу. В этом проекте через MCP-метаданные видно, что основная конфигурация крупная:

Документ ОтчетКассовойСмены имеет табличные части Товары, Оплата, ВозвратыТоваров. Код надо писать под настоящую структуру, а не под память о похожей УТ или Рознице.

Какие MCP-серверы помогают в такой работе

• 1c_metadata — объекты, реквизиты, табличные части, процедуры, зависимости, движения документов, диагностики BSL;
• 1c_edt_docs — документация EDT (~28 тысяч страниц): Git-репозитории, история, патчи;
• 1c_obrabotki — индекс внешних обработок и рабочих примеров;
• 1c_testing — рецепты и API YAxUnit/Smoke;
• frontol — документация Frontol для кассовой логики;
• analytics — методики по аналитике, BI и рознице.

MCP не заменяет разработчика. MCP даёт агенту глаза. Без него ИИ пишет по памяти. С ним он проверяет.

Зачем здесь Git

Правильная связка обязательно включает Git. В этом проекте Git-репозиторий не найден — и это хорошо показывает, зачем он нужен. Вместо истории изменений накопились папки вида load_*, backup_*, check_* — заменитель, а не нормальная история.

С Git задача выглядела бы чище: отдельный diff на каждое изменение, ошибка фиксируется маленьким коммитом, откат — командой, а не поиском нужной папки по времени создания.

Что отличает рабочий вайб-кодинг от игрушечного

Игрушечный вариант: «Напиши код печати по группам» — ИИ отвечает красивым фрагментом, где половина реквизитов может не существовать в этой конфигурации.

Рабочий вариант: агент открывает EDT-проект → проверяет объект через MCP → ищет существующую логику → делает минимальную правку → проверяет платформенные типы → загружает через Конфигуратор → выполняет /CheckConfig → сверяет обратную выгрузку → обновляет MCP-индекс.

Здесь «вайб» становится не хаосом, а ускорением: человек формулирует бизнес-идею словами, агент берёт на себя инженерную часть.

Где граница

Вайб-кодинг в 1С не отменяет программиста. Нормальный режим: агент предлагает и делает техническую реализацию; разработчик или аналитик проверяет бизнес-смысл; база проверяется через Конфигуратор и тесты; изменения фиксируются в Git; секреты не попадают в код и журналы.

Коротко: ChatGPT в браузере для 1С слишком слепой. ИИ-агент с EDT, Git и MCP уже видит проект — и может не только «написать код», но и объяснить, почему именно этот код подходит для этой конфигурации.

Коротко: без EDT+Git+MCP ИИ в 1С пишет по памяти и в среднем ошибается там, где предположение о типе объекта неверно — как в примере с `ТаблицаЗначений` выше. С этой связкой доля таких ошибок падает почти до нуля, потому что агент проверяет конфигурацию перед правкой, а не после.