Как мы за 5 месяцев внедрили ИИ в 1С-разработку: от провального ChatGPT до рабочего контура

Декабрь 2025 — первая попытка и первое разочарование

В декабре мы начали с самого простого сценария: открыли ChatGPT и попросили помочь с 1С. Задача была несложная: по описанию, книге или статье составить обработку. Ожидание было примерно такое: «сейчас нейросеть быстро напишет код, мы его проверим, немного поправим — и получим ускорение».

Реальность оказалась другой. На небольшом фрагменте кода примерно в 50 строк AI сделал несколько ошибок. Где-то не те методы, где-то не та логика, где-то код выглядел правдоподобно, но в 1С нормально не работал. И главное — у него не было контекста. Он не знал:

• какая у нас конфигурация;
• какие объекты реально есть в базе;
• какие реквизиты называются именно так, а не «примерно так»;
• какие типовые механизмы используются;
• какие ограничения есть в платформе;
• как эту обработку потом проверять.

В этот момент стало понятно: просто открыть ChatGPT и попросить «напиши код 1С» — это не AI-разработка. Это скорее генератор черновиков, которые надо долго разбирать.

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

Январь 2026 — пауза, в которой стало понятно, что проблема никуда не ушла

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

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

То есть мы пытались использовать AI как программиста, но не дали ему рабочее место программиста. У человека-разработчика есть конфигурация, код, отладка, документация, опыт, примеры, тестовая база, понимание проекта. У AI в декабре был только наш текстовый запрос. Поэтому результат и был слабым.

Февраль 2026 — боль стала сильнее экспериментов

В феврале ситуация изменилась. Стало понятно, что программисты не справляются с объёмом так, как хотелось бы. Не потому что они плохие. Наоборот: сильные специалисты были перегружены, а типовых задач становилось всё больше.

Проблемы были знакомые любой 1С-команде:

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

В этот момент вопрос стал не «интересно ли нам попробовать AI», а иначе: как нам ускорить 1С-разработку, если просто нанимать новых программистов долго, дорого и не всегда возможно?

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

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

Готового ответа мы не нашли. Поэтому начали собирать свой.

Февраль 2026 — база: 1C:EDT, Git и код в файлах

Первое, что стало понятно: если AI должен помогать с разработкой, ему нужны файлы. Классический Конфигуратор удобен для привычной 1С-разработки, но для AI-агента он неудобен. AI не может нормально «думать» в интерфейсе, где всё завязано на клики, окна и ручные действия.

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

Поэтому мы начали разбираться с 1C:EDT. Это был отдельный этап боли. EDT вроде бы существует давно, но в реальности среди знакомых 1С-специалистов и партнёров почти никто уверенно им не пользовался. Документации много, но практического опыта вокруг мало. У многих первое ощущение было простое: «в Конфигураторе быстрее».

И это нормальная реакция. Конфигуратор у 1С-разработчика — это не просто инструмент. Это привычка, моторика, десятилетия опыта. Переход в EDT нельзя сделать за один день только потому, что «так надо для AI».

Но для AI-контура EDT оказался важным фундаментом. Наш вывод: если вы хотите использовать AI в 1С серьёзно, а не как чат в браузере, нужно переводить разработку в файловый и управляемый процесс: EDT, Git, история изменений, ревью, тестовые базы. Иначе AI будет всё время работать вслепую.

Февраль–март 2026 — появилась идея MCP-серверов для 1С

После первых экспериментов стало понятно: даже если AI видит файлы проекта, этого всё равно мало. 1С — это не просто код. Это метаданные, типовые конфигурации, регистры, справочники, документы, общие модули, БСП, расширения, настройки, права, проведение, движения, подписки, обмены.

Если AI не знает, какие объекты реально есть в конфигурации, он начинает придумывать. Например: несуществующий реквизит; неправильный метод; неверное имя объекта; типовую функцию, которой в этой конфигурации нет; логику, которая похожа на правду, но не подходит под конкретную базу.

Тогда появилась идея: AI нужен не просто доступ к тексту задачи, а нормальный источник контекста. Так мы начали делать собственные MCP-серверы. Первый смысл MCP был простой: AI должен не угадывать, что есть в конфигурации, а спрашивать это у отдельного инструмента.

Мы начали собирать контекст по 1С: метаданные конфигурации; объекты; реквизиты; регистры; документы; справочники; общие модули; типовые механизмы; диагностические правила; документацию; примеры готовых обработок.

Именно здесь AI начал превращаться из «болтливого помощника» в инструмент, который можно применять к реальной 1С-разработке.

Март 2026 — документация ИТС как источник знаний для AI

Отдельный прорыв случился, когда мы поняли: AI нужно подключить к документации 1С. Не просто к случайным статьям из интернета, не к форумам, не к «среднему знанию по больнице», а к нормальному источнику: документации по платформе, EDT, БСП и типовым механизмам.

Мы начали индексировать документацию ИТС и использовать её как базу знаний для AI. И это сильно изменило качество ответов. До этого AI часто отвечал «в целом правильно», но не всегда по стандартам 1С. После подключения документации он стал чаще объяснять:

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

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

Наш вывод: AI в 1С становится полезным не тогда, когда он «знает всё из интернета», а когда он получает доступ к правильной документации и контексту конкретной конфигурации.

Март–апрель 2026 — первые рабочие сценарии на своих задачах

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

Разбор ошибок в 1С

Например, документ не проводится. Раньше процесс выглядел так: аналитик описывает проблему → программист смотрит → задаёт вопросы → ищет причину → возвращается к аналитику → снова проверка.

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

Посмотри, почему документ может не проводиться. Какие регистры проверить? Какие условия могут блокировать проведение? Где вероятнее всего ошибка? Какие вопросы задать клиенту?

AI не заменяет программиста, но он помогает быстрее выйти на гипотезы. Иногда этого достаточно, чтобы аналитик сам понял проблему. Иногда — чтобы передать программисту уже не «что-то не работает», а нормальное техническое описание.

Подготовка технических заданий

Это стало одним из самых полезных сценариев. Я как аналитик могу описать бизнес-задачу, а AI помогает превратить её в структуру: что хочет клиент; какие объекты 1С могут быть затронуты; какие есть варианты реализации; какие вопросы надо уточнить; какие риски есть; какие проверки нужны; что должен сделать программист; как потом тестировать результат.

В итоге программист получает не сырое «сделайте как-нибудь», а более подготовленную постановку.

Разбор чужого кода

В 1С очень часто проблема не в том, чтобы написать новое, а в том, чтобы понять старое. Кто-то когда-то сделал обработку. Кто-то поменял модуль. Кто-то добавил подписку. Кто-то доработал проведение документа. Теперь это надо понять.

AI помогает: объяснить фрагмент кода; найти, какие данные он меняет; показать возможные ошибки; подсказать, где могут быть проблемы с производительностью; сформировать список проверок; подготовить вопросы к разработчику. Это особенно ценно для аналитика и руководителя, потому что появляется возможность лучше понимать, что происходит в разработке, а не полностью зависеть от фразы «программист сказал».

Черновики обработок и доработок

Да, AI может помогать писать код. Но мы быстро зафиксировали правило: код от AI — это черновик, а не готовое решение. Он может подготовить основу обработки, пример запроса, структуру модуля, логику заполнения табличной части, описание алгоритма. Но дальше человек обязан проверить:

• работает ли это в конкретной конфигурации;
• нет ли несуществующих реквизитов;
• не нарушены ли типовые механизмы;
• не затронуты ли лишние данные;
• нет ли проблем с правами;
• не будет ли ошибок при разных сценариях;
• понятен ли код самому разработчику.

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

Апрель 2026 — ИИ стал частью рабочего процесса

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

AI оказался полезен не только разработчику. Он оказался полезен всей цепочке: клиент → аналитик → программист → тестирование → внедрение → сопровождение.

Особенно сильно изменилась роль аналитика. Раньше аналитик часто был ограничен: он понимает бизнес, но не всегда может глубоко проверить техническую часть. Теперь аналитик с AI может: быстрее разобраться в логике 1С; понять, какие объекты могут быть затронуты; подготовить более точную задачу; предварительно оценить сложность; увидеть риски; не упустить важные вопросы; говорить с программистом предметнее.

Это не делает аналитика программистом. Но это делает его сильнее.

Май 2026 — подключение программистов и сопротивление команды

В мае мы начали активнее подключать программистов. И здесь появилась ожидаемая проблема: сопротивление.

Один из типовых аргументов звучал так: «зачем мне AI? Он будет решать задачи за меня, а я тогда ничему не научусь». Другой аргумент: «он напишет код, а я не буду знать, что там внутри».

И это нормальные возражения. Программист не обязан радоваться инструменту, который ему подают как «замену». Если сказать разработчику «AI теперь будет писать за тебя», он услышит: «твоя профессия больше не нужна». Это плохая подача.

Мы пришли к другому подходу. AI — не замена программиста. AI — не финальный автор кода. AI — не тот, кому можно слепо доверять. AI — это помощник, который ускоряет подготовку, поиск, разбор, проверку и рутину.

Роль программиста не исчезает. Она становится даже важнее, потому что именно программист отвечает за: архитектуру; качество; ревью; понимание кода; тестирование; безопасность изменений; финальное решение.

Мы сформулировали для себя правило: если разработчик не понимает код, который предложил AI, этот код нельзя принимать. Это сильно меняет отношение. Мы не заставляем программиста «верить нейросети». Мы даём ему инструмент, который можно проверять, критиковать и использовать там, где он реально ускоряет работу. Постепенно программисты начали пробовать. Не везде. Не сразу. Не без сопротивления. Но там, где AI помогал разобрать чужой код, найти ошибку, подготовить тесты, объяснить механизм или убрать рутину, сопротивление снижалось.

Что реально изменилось в процессе

До AI процесс часто выглядел так:

1. Клиент описывает проблему.
2. Аналитик пытается понять и формулирует задачу.
3. Программист получает постановку.
4. Программист уточняет детали.
5. Задача возвращается на доработку.
6. Программист делает.
7. Возникают вопросы и переделки.
8. Все теряют время на уточнения.

Теперь в простых и средних задачах процесс стал другим:

1. Клиент описывает проблему.
2. Аналитик вместе с AI разбирает контекст.
3. AI помогает найти возможные причины, риски и вопросы.
4. Аналитик готовит более точное ТЗ.
5. AI помогает составить варианты реализации и проверки.
6. Программист получает уже подготовленный материал.
7. Программист проверяет, дорабатывает, принимает решение.
8. Изменения проходят тестирование и ревью.

Главное изменение не в том, что AI «пишет код». Главное изменение в том, что вокруг задачи стало больше предварительного анализа. Мы меньше работаем вслепую. Подробно о том, как ставить задачи AI-агенту, расскажем в следующей статье серии.

Где ИИ уже даёт пользу в 1С

1. Разбор ошибок

Документ не проводится; отчёт показывает неправильные данные; обработка падает; обмен не выгружает объект; после доработки сломалась типовая логика. AI помогает собрать гипотезы и список проверок.

2. Подготовка технических заданий

AI помогает аналитику структурировать задачу: цель; объекты; сценарии; исключения; ограничения; вопросы клиенту; критерии приёмки.

3. Оценка доработок

Перед тем как дать клиенту оценку, можно попросить AI помочь проверить: какие объекты могут быть затронуты; где скрытые зависимости; что нужно уточнить; какие риски есть; что программист мог не учесть. Это не заменяет оценку разработчика, но делает её спокойнее и точнее.

4. Разбор чужого кода

AI помогает быстрее понять: что делает модуль; какие данные меняются; где потенциальные ошибки; какие есть зависимости; что проверить перед изменением.

5. Черновики обработок

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

6. Обучение и объяснение

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

Что мы недооценили

1. Главная сложность — не технология, а привычки

Переход от Конфигуратора к EDT и Git — это не просто поставить программу. Это смена мышления. Разработчик привык работать одним способом. Аналитик привык ставить задачи одним способом. Руководитель привык контролировать результат одним способом. AI ломает этот процесс. Не потому что он плохой, а потому что он требует другого контура работы. Без файлов, Git, истории изменений, тестовой базы, правил проверки, ревью, документации и понятного процесса AI превращается в игрушку.

2. ИИ без контекста бесполезен для серьёзной 1С-разработки

Обычный чат в браузере может помочь объяснить идею или написать простой пример. Но в реальной 1С этого мало. AI должен знать: конфигурацию; метаданные; документацию; типовые механизмы; ограничения платформы; структуру проекта; примеры решений; правила проверки. Иначе он будет придумывать.

3. Аналитик получает огромный прирост

Мы изначально думали, что AI нужен в первую очередь программисту. На практике оказалось, что один из главных получателей пользы — аналитик. Потому что аналитик стоит между клиентом и разработчиком. Если аналитик лучше понимает техническую сторону, задачи становятся качественнее, оценки — точнее, а программисты получают меньше сырого хаоса.

4. Программистов нельзя «продавить»

Если подать AI как замену программисту, команда будет сопротивляться. И будет права. Правильная подача другая: AI не заменяет разработчика. AI снимает рутину, помогает разбираться, предлагает варианты, ищет ошибки и ускоряет подготовку. Но решение, ответственность и качество остаются за человеком.

Какие правила безопасности мы ввели

Чтобы AI не превратился в источник хаоса, мы зафиксировали несколько принципов.

1. AI не работает напрямую с боевой базой

Сначала тестовая база, копия, отдельный контур. Рабочая база — только после проверки человеком.

2. Все изменения должны быть видны

Нужен Git, diff, история изменений. Нельзя просто «AI что-то поменял, вроде работает». Должно быть понятно: что изменилось; где изменилось; зачем изменилось; кто проверил; как тестировали.

3. Код без понимания не принимается

Если человек не может объяснить код, он не должен попадать в рабочую конфигурацию. AI может предложить. Человек должен понять.

4. AI — это черновик и ревизор, а не финальный исполнитель

Лучшие роли AI в нашем процессе: помощник аналитика; помощник программиста; ревизор; объясняющий наставник; генератор черновиков; помощник по документации. Не «автопилот без контроля». О том, как тесты позволяют AI работать автономнее, расскажем в отдельной статье серии.

5. Сложные решения остаются за senior-разработчиком

Архитектура, критичные изменения, безопасность данных, обмены, движения, права, производительность — это зона ответственности человека. AI помогает, но не принимает финальное решение.

Таймлайн: как это было на самом деле

Главный итог

За пять месяцев мы поняли главное: ИИ в 1С-разработке начинает работать не тогда, когда вы покупаете подписку на нейросеть. Он начинает работать тогда, когда вокруг него появляется нормальный инженерный контур: EDT, Git, тестовая база, документация, MCP, правила проверки и команда, которая понимает роли.

AI не сделал нас «компанией без программистов». Он дал другое:

• аналитик стал сильнее в технической подготовке задач;
• программисты получили помощника для рутины и разбора;
• стало проще разбираться в чужом коде;
• стало легче готовить оценки клиентам;
• часть простых задач можно доводить до черновика без постоянного отвлечения senior-разработчика;
• команда начала меньше работать вслепую.

Это не магия. Это процесс.