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

В разборе участвуют пять ролей. «Главный дирижёр», он же роутер, распределяет задачи и торопится, потому что у него горят метрики по скорости ответа. «Универсальный кодер» — мультиязычный джуниор, воспитанный на Python, JavaScript и веб-дизайне, громкий и самоуверенный. «Старый гуру 1С» — внедренец эпохи 7.7 и обычных форм 8.1, для которого всё, что появилось после 2003 года, подозрительно. «Архитектор управляемого приложения» знает стандарты БСП, клиент-серверный веб-интерфейс и оптимизацию, а «лингвист» отвечает за вежливые комментарии и смайлики даже в неработающем коде. Каждая роль тянет генерацию в свою сторону, и итоговый текст оказывается компромиссом, а не цельным решением.

Первый сценарий — запрос новичка: сделать кнопку на форме, которая считает итоги и красиво выводит результат. «Универсальный кодер» предлагает HTML-вставку, CSS-анимацию и смену цвета фона кнопки через конструктор цвета, «старый гуру» настаивает на цикле по всей таблице и модальном вводе пароля через ВвестиЗначение, а «архитектор» напоминает, что модальные вызовы вроде ВвестиЗначение и Предупреждение заблокированы в современных конфигурациях уже более десяти лет. В итоге дирижёр склеивает фрагменты, ориентируясь на то, что новичок запустит код в учебной файловой базе и не заметит различий между клиентом и сервером. Так рождается код, который выглядит солидно, содержит комментарии на английском и переменные вроде «СуперРезультатФиналВ2», но в реальной «Бухгалтерии 3.0» приведёт к критической ошибке о запрете модальных вызовов.

Второй сценарий касается внешней обработки, которая загружает файл и выводит итоги, причём пользователь жёстко требует директиву &НаСервереБезКонтекста. Здесь сталкиваются три подхода к чтению файла: вызов open() в духе Python, создание COM-объекта Excel.Application и использование платформенного объекта ТабличныйДокумент с методом Прочитать(). Архитектор указывает, что COM-объект аварийно завершит работу в Linux-сервере или в облаке 1С:Фреш, а прямая запись в элементы формы из процедуры без контекста невозможна, потому что серверный вызов не имеет доступа к реквизитам и элементам самой формы. Корректное решение — вернуть сумму через Возврат в клиентскую процедуру и вывести её на экран уже на клиенте, однако дирижёр в целях экономии времени смешивает все варианты в один ответ. Третий эпизод — функция, которая принимает текстовую строку, разбирает из неё JSON с массивом возвратов маркетплейса и агрегирует данные на сервере без контекста; этот сценарий ближе всего к реальным задачам интеграции, где важны не только синтаксис, но и совместимость с БСП, корректная работа с сериализацией и соблюдение клиент-серверной границы.

Контекст публикации усиливает картину: в дополнительных материалах того же потока обсуждается, как вайбкодинг удешевляет разработку, но порождает код, на который «невозможно смотреть без слёз», а также опыт запуска бесплатных LLM из России через Cloudflare с ошибкой 403 Access denied by security policy. Оба сюжета показывают, что доступность модели и качество её ответа — разные вещи, и для прикладных платформ вроде 1С разрыв между ними особенно заметен. Для российского рынка это имеет прямое значение: 1С остаётся одной из самых распространённых платформ автоматизации учёта, и интерес к ИИ-ассистентам внутри экосистемы растёт. Отраслевая реакция в публикации сформулирована через понятие регламента КОРП-ядра: чтобы модель не смешивала роли, нужен управляемый набор правил, ограничений и проверок, а не один универсальный чат.

Сравнение с альтернативами показывает, что генераторы кода на Python и JavaScript выигрывают за счёт обилия открытых примеров и единообразных соглашений, тогда как в 1С исторически сосуществуют обычные и управляемые формы, файловые и клиент-серверные базы, разные версии БСП. Без явного регламента модель усредняет эти практики и выдаёт смесь, которая не проходит компиляцию. Дальнейшее развитие видится в разделении генерации на этапы: определение контекста выполнения, выбор допустимых API, проверка директив и только затем синтез кода. Открытыми остаются вопросы, как измерять качество таких ответов, кто отвечает за ошибки в сгенерированном коде и насколько применимы зарубежные методики оценки к российской платформе. Пока же практический вывод прост: ИИ-ассистент в 1С полезен как черновик и подсказка, но итоговую ответственность за архитектуру, совместимость и безопасность несёт разработчик, а регламент КОРП-ядра остаётся способом удержать эту ответственность в явных границах.