Влияние ИИ на разработку 1С: что реально изменилось к 2026 году

Тему нейросетей в разработке 1С за последний год обсудили со всех сторон — от «они заменят всех 1С-ников» до «на BSL они пишут бред и не годятся ни на что». Истина, как обычно, не на полюсах. За прошедший год ИИ из игрушки и генератора курьёзов превратился в рабочий инструмент, но с очень конкретными границами применимости. Ниже — разбор без хайпа: что сегодня реально работает, где ИИ пока буксует и как меняется сама роль разработчика.

Почему «голый» ChatGPT плохо пишет на 1С

Если просто открыть любую LLM и попросить «напиши обработку загрузки прайса из Excel на 1С» — первые впечатления чаще разочаровывают. Причина не в том, что модель «глупая», а в специфике платформы.

Большие языковые модели обучены преимущественно на открытом коде — Python, JavaScript, Java. Кода на BSL в обучающей выборке несопоставимо меньше, а главное — модель в принципе не знает устройства вашей конкретной конфигурации: какие у вас объекты метаданных, реквизиты, регистры, какие доработки уже сделаны.

Отсюда классическая болезнь — галлюцинации в обращениях к платформе:

• выдуманные значения перечислений (хрестоматийный пример — несуществующее ТипРазмещенияТекстаТабличногоДокумента.Перенос);
• методы, которых у типа на самом деле нет;
• неверное количество или порядок аргументов у штатных функций.

Самое коварное здесь — уверенность модели. Код выглядит правдоподобно, компилируется в голове, но падает в реальной базе. И обычный BSL Language Server тут не спасает: он проверяет синтаксис, а не реальный состав API платформы и вашей конфигурации.

Что изменило ситуацию: контекст и MCP

Перелом произошёл не от того, что модели стали «умнее писать на 1С», а от того, что им научились давать правильный контекст. Ключевую роль сыграл протокол MCP (Model Context Protocol) — стандарт, через который ИИ-агент получает доступ к внешним инструментам и данным.

Для 1С это вылилось в несколько практичных решений:

• MCP-серверы, сверяющие код с реальным API. Например, сервер, который на лету проверяет сгенерированный BSL по синтакс-помощнику платформы и отлавливает те самые выдуманные перечисления и методы. Это снимает значительную часть галлюцинаций ещё до запуска.
• MCP для поиска по метаданным конфигурации. Агент видит фактический состав объектов, реквизитов и регистров — и перестаёт «фантазировать» структуру.
• MCP для запуска тестов. Связка с YaXUnit позволяет агенту самому собрать и прогнать тесты, увидеть результат и поправить код.

Плюс к этому — выгрузка конфигурации в файлы (XML + BSL). Современные модели в агентских режимах неплохо понимают эту структуру и аккуратно правят и метаданные, и код, не ломая остального. Именно сочетание «модель + агентский режим + MCP с контекстом платформы» и превратило ИИ из генератора красивых, но нерабочих сниппетов в инструмент, которому можно поручить осмысленную задачу.

Официальные и сторонние инструменты

Экосистема инструментов к 2026 году вполне сложилась.

1С:Напарник — официальный ассистент от фирмы «1С». Существует в двух ипостасях: для разработчиков в среде 1C:EDT (генерация кода, ревью, рефакторинг, комментирование существующей кодовой базы) и для пользователей по ИТС (помощь по порталу). Важный для многих факт: для подписчиков ИТС он доступен бесплатно до 1 октября 2026 года, так что попробовать его в деле можно без отдельных затрат.

Сторонние агенты для Конфигуратора. Поскольку значительная часть прикладной разработки до сих пор идёт в Конфигураторе, а не в EDT, появились инструменты вроде Confaster — по сути аналог Cursor/Copilot, встроенный прямо в Конфигуратор, со своим MCP-сервером, автодополнением, ревью и исправлением ошибок. Такие решения обычно умеют работать с разными моделями (1С:Напарник, ChatGPT, Claude, Gemini, DeepSeek) — выбор зависит от задач, бюджета и требований к данным.

ML-сервисы платформы. Отдельно стоит упомянуть, что ИИ в 1С — это не только генерация кода. Есть, например, «1С:Универсальное прогнозирование» с моделями машинного обучения для прогноза бизнес-показателей. Это другой пласт, но он показывает, что вектор у платформы системный.

Где ИИ реально помогает уже сейчас

По опыту — своему и коллег — есть набор сценариев, где выигрыш ощутимый и стабильный:

1. Рутинный код. Обработки загрузки/выгрузки из Excel, типовые формы, заполнение табличных частей, простая валидация — то, что мы и так пишем «по шаблону». Здесь ИИ экономит реальное время.
2. Запросы и СКД. Построение запросов с соединениями, группировками, вложенными подзапросами, виртуальными таблицами — модель хорошо ориентируется в языке запросов, дальше нужно лишь выверить под конкретные данные.
3. Рефакторинг и ревью. Разбить громоздкий метод, унифицировать стиль, найти потенциальные проблемы, объяснить, что делает чужой непрокомментированный код — сильная сторона.
4. Комментирование и документирование. Простановка описаний к процедурам, генерация описания доработки — то, до чего у нас вечно не доходят руки.
5. Генерация тест-кейсов. Типовые сценарии, граничные значения, негативные кейсы «пользователь сделал всё не так» — с последующим прогоном через YaXUnit.
6. Составление ТЗ и разбор задач. Модель с веб-поиском и подгрузкой контекста помогает быстро собрать черновик ТЗ, который раньше отнимал часы.

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

Где ИИ пока не вывозит

Честность важнее восторга, поэтому про границы:

• Сложная бизнес-логика и учётные нюансы. Проведение документов, взаиморасчёты, партионный учёт, корректность движений по регистрам — здесь цена ошибки высока, а модель не несёт ответственности за результат. Это зона разработчика.
• Знание конкретной конфигурации с доработками. Чем больше в базе накопленных кастомизаций, тем чаще «общая эрудиция» модели бьётся о реальность вашего проекта. MCP с метаданными помогает, но не отменяет понимания контекста.
• Безопасность данных. Отправлять фрагменты базы или код клиента во внешние облачные модели — отдельный вопрос, который нужно решать на уровне политики компании и договорённостей с заказчиком.
• Та самая уверенность в ошибках. Сгенерированный код нужно читать. Всегда. ИИ ускоряет написание, но не снимает с разработчика ответственность за то, что уходит в продуктив.

Как меняется роль разработчика

Главное изменение — не в том, что «код пишет нейросеть», а в смещении центра тяжести работы.

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

Появляются и новые рабочие паттерны: agentic-разработка, когда агент выполняет основную черновую часть по описанию, а инженер проверяет и доводит; «вайбкодинг» в EDT с полным циклом от задачи до коммита. Это не отменяет профессию — это поднимает планку. Junior, который умеет только копировать сниппеты, проигрывает; специалист, который умеет ставить задачу, проверять и отвечать за результат, — выигрывает.

Практический вывод: с чего начать

Если вы ещё присматриваетесь, разумный путь такой:

• начните с проверяемых задач — обработки, запросы, ревью, тесты, а не с критичной учётной логики;
• подключите MCP с доступом к API платформы и метаданным — без этого процент галлюцинаций будет высоким;
• сформулируйте для агента правила (стиль кода, соглашения именования, требования БСП) — это заметно повышает качество с первого раунда;
• читайте всё, что генерируется, и прогоняйте через тесты;
• не отправляйте чувствительные данные в инструменты, которые этого не позволяют по политике клиента.

ИИ в разработке 1С — это уже не вопрос «будущего». Это рабочий инструмент настоящего, который при грамотном применении даёт ощутимый прирост скорости на рутине и разборе кода. Но он усиливает разработчика, а не заменяет его: ответственность за архитектуру, учётную корректность и итоговое качество по-прежнему на человеке. И, похоже, это надолго.