Идея, которая казалась бредом
В начале 2025 года я показал коллегам концепцию: «Давайте сделаем Cursor, но для 1С». Реакция была предсказуемой: смех, пожимание плечами и вопросы о моем психическом здоровье. «1С — это же закрытая экосистема, там свой язык, свои правила, свои чудовищные конфигурации. Какой там ИИ?» — говорили они.
Но именно в этом и была фишка. Пока все бегали за очередным релизом GPT-5 или пытались заставить Claude Code работать с русским языком, мы нашли дыру размером с Байкал. Аудитория 1С-разработчиков в России и СНГ — сотни тысяч человек. Каждый из них ежедневно сталкивается с легаси-кодом, написанным еще в нулевые. Каждый тратит часы на то, чтобы разобраться в чужой кастомной логике.
Скептики забывали одну простую вещь: проблемы 1С-разработчиков слишком специфичны, чтобы их решали универсальные инструменты вроде Cursor. Им нужен не просто код-ассистент, а проводник по джунглям кастомных конфигураций.
Почему Cursor проваливается на 1С
Мы взяли свежий Cursor (версия 2025.3 на момент февраля 2026) и попробовали загрузить в него типичную кастомную конфигурацию «Управление торговлей». Результат? Полный провал. И вот почему:
- 1С-синтаксис — это не Python. Конструкции вроде «Если ... Тогда ... ИначеЕсли ... КонецЕсли» или циклы «Для каждого ... Цикл ... КонецЦикла» для Cursor выглядели как инопланетный язык.
- Контекст переполнялся за 5 минут. Стандартные 128К токенов съедались описанием метаданных, а на сам код уже не хватало. Проблема, которую мы уже обсуждали в контексте других проектов.
- Модель не понимала бизнес-логику. Запрос «Найди все места, где списывается товар со склада» возвращал фрагменты кода без понимания, что это часть процедуры «Проведение документа».
Именно тогда стало ясно: нужен не просто wrapper над GPT, а специализированный агент, который знает 1С изнутри.
Архитектура, которая заработала с третьего раза
Первая попытка: fine-tuning GPT-4 на датасете из открытых конфигураций. Провал. Модель научилась генерировать красивый синтаксис 1С, но не понимала смысл.
Вторая попытка: RAG-система с векторной базой фрагментов кода. Лучше, но все равно мимо. Запрос «Как работает механизм резервирования?» возвращал 50 фрагментов кода без связного объяснения.
1 Секретный ингредиент: граф метаданных
Третья попытка сработала. Мы отказались от идеи «скормить ИИ голый код». Вместо этого построили граф зависимостей:
| Узел графа | Что содержит | Зачем нужно |
|---|---|---|
| Объект метаданных | Справочник, документ, обработка | Понимание структуры приложения |
| Реквизит | Поля, типы, ограничения | Понимание данных |
| Метод | Функции, процедуры, обработчики | Понимание логики |
| Связь | Вызовы, ссылки, зависимости | Понимание потока выполнения |
Этот граф стал скелетом, на который ИИ наращивал «мясо» понимания. Когда разработчик спрашивал «Как работает списание товара?», система:
- Находила в графе документ «Реализация товаров»
- Прослеживала связи к модулю проведения документа
- Извлекала конкретные методы списания
- Формировала связное объяснение с ссылками на код
Чем наш ассистент отличается от «больших» AI-инструментов
Когда мы запустили бета-тест, разработчики сразу заметили разницу. Вот что говорят пользователи:
- «Он не предлагает универсальные решения.» Вместо «Вот как сделать цикл в 1С» — «В вашей конфигурации цикл по строкам табличной части реализован в методе ОбходСтрокДокумента, вот конкретный пример из кода».
- «Он знает наш жаргон.» «Заказ клиента», «проведение документа», «объект метаданных» — эти термины не нужно объяснять.
- «Он показывает не только код, но и контекст.» «Этот обработчик вызывается из формы документа при нажатии кнопки «Провести», вот как выглядит эта форма».
Этот опыт подтверждает то, о чем мы писали в обзоре AI-агентов для разработчиков: специализация побеждает универсальность.
Технические костыли, которые стали фичами
Самое интересное в таких проектах — как временные решения становятся ключевыми функциями:
2 Парсер «грязного» кода
Мы столкнулись с тем, что в кастомных конфигурациях код часто нарушает все стандарты: смесь русского и английского, самописные сокращения, комментарии на «албанском». Вместо того чтобы требовать чистый код, мы научили парсер понимать этот хаос. Теперь это наша фича №1: «Работает с любым legacy-кодом, каким бы ужасным он ни был».
3 Контекстный поиск по бизнес-процессам
Изначально мы хотели просто искать код. Но пользователи просили: «Найди все, что связано с процессом “Возврат от покупателя”». Так родился поиск не по ключевым словам, а по бизнес-процессам. Система научилась связывать разрозненные фрагменты кода в единую историю.
Мораль: слушайте, что пользователи делают с вашим продуктом, а не что говорят. Их «костыли» — ваши будущие killer-features.
Кому подойдет такой инструмент (а кому нет)
За год мы поняли, что наш ассистент — не для всех.
Подойдет идеально:
- Разработчикам, которые поддерживают старые кастомные конфигурации (особенно если оригинальный автор давно уволился)
- Командам, где есть junior-разработчики, которым нужно быстро вникнуть в проект
- Фрилансерам, которые берутся за доработку чужих проектов и не хотят тратить недели на изучение кода
Не подойдет:
- Тем, кто работает только со стандартными конфигурациями «из коробки»
- Разработчикам, которые пишут новый код с нуля (им хватит и обычного Cursor с правильными промптами)
- Людям, которые ждут, что ИИ полностью заменит программиста (такого не будет еще лет пять, если вообще будет)
Интересно, что многие наши пользователи пришли из опроса «Какие ИИ-инструменты реально используют 1С-разработчики» — они уже пробовали разные варианты и точно знали, чего хотят.
Экономика нишевого ИИ
Самый частый вопрос: «А это вообще окупается?». Цифры (на февраль 2026):
- Подписок продано: 1,200+ (70% — годовые)
- Средний чек: 8,400 руб/год
- Время на изучение новой конфигурации сократилось с 40 часов до 8 (по отзывам пользователей)
- Количество ошибок из-за непонимания кода упало на 60%
Но главное не деньги. Главное — мы создали инструмент, который решает реальную боль реальных людей. Пока гиганты гоняются за «искусственным общим интеллектом», мы сделали «искусственный интеллект для конкретной работы».
Кстати, если вы только начинаете путь в 1С-разработке, курсы вроде «1С-программист» дают хорошую базу. Но они не научат разбираться в чужом legacy-коде — для этого уже нужны инструменты вроде нашего.
Что дальше? ИИ не заменит 1С-разработчика, но изменит его работу
Наши планы на 2026-2027:
- Интеграция с реальным выполнением кода (не просто анализ, а симуляция)
- Автоматическое обнаружение «мусорного кода» — методов, которые никто не вызывает, но которые все поддерживают
- Генерация документации, которая не устаревает (потому что привязана к живому коду)
Но самое важное — мы доказали, что создавать нишевые ИИ-инструменты не только возможно, но и выгодно. Не нужно пытаться сделать «еще один ChatGPT». Найдите узкую аудиторию с конкретной болью, изучите ее досконально (как мы изучили мир 1С-разработчиков) и создайте инструмент, который решает именно эту проблему.
Как сказал один из наших первых пользователей: «Раньше я тратил полдня на то, чтобы понять, как работает чужой код. Теперь я трачу полчаса на то, чтобы попросить ИИ объяснить его. Разница как между копанием лопатой и экскаватором».
Экскаваторы, кстати, тоже когда-то считали странной игрушкой для инженеров. Пока не изменили всю строительную отрасль.
