Я сделал 1С:ERP-инструмент за 8 часов. Обычно такие задачи оценивают в 80+

Последние пару месяцев я активно экспериментирую с no1C-подходом и разработкой 1С:ERP-инструментов с помощью ИИ.

Главный вопрос, который хотелось проверить на практике:

можно ли пройти полный цикл 1С:ERP-разработки через пайплайн c ИИ-генерацией, а не просто "сгенерировать кусок кода"?

Для эксперимента решил взять не абстрактный CRUD-сервис, а вполне реальную ERP-задачу:

диагностика резервов и доступности товаров в 1С:ERP

И неожиданно именно эта задача оказалась очень показательной.

Думаю, многие, кто работал с 1С:ERP, сталкивались с ситуацией:

товар физически лежит на складе, но система не дает его продать или списать

Например, менеджер пытается оформить продажу 20 штук товара “Тумбочка под обувь”, а ERP отвечает:

По организации Промресурс на складе Склад готовой продукции не хватает 10 шт товара Тумбочка под обувь

При этом в ведомости по товарам на складах:

остаток = 100 шт

А в отчете “Остатки и доступность товаров”:

доступно = 10 шт

Но почему остальные 90 недоступны – типовой отчет быстро не объясняет. Да и вообще поля в Разделе «Всего», что обычно ассоциируется с суммой, никак не совпадают с полями в разделах «Сейчас» и «Ожидается», и понять, что значит «К обеспечению» и «Дефицит» и как они считаются не просто оказалось даже мне.

После моей дополнительной диагностики выяснилось:

Жесткий резерв = 90

То есть проблема была не в остатках.

Проблема была в механизме резервирования.

Изначально задача была не “сделать еще один отчет по резервированию”.

Хотелось проверить сам подход:

можно ли резко удешевить ERP-инженерные итерации через пайплайн с ИИ ассистентом

Причем именно на реальной ERP-задаче:

В эксперименте использовался примерно такой пайплайн:

1. Автоматическая генерация бизнес-ТЗ

2. Автоматическая генерация архитектурного ТЗ

3. Автогенерация no1C кода

4. Автогенерация тестов

5. Автоисправление 1С-запросов

6. Проверка кода «на лету»

7. Автоисправление кода и повторные итерации

Причем это был не “один большой промпт”.

Наоборот – пайплайн оказался довольно фрагментированным:

→ пользовательские требования

→ декомпозиция требований

→ архитектурное решение

→ генерация кода

→ исполнение кода

→ тестирование

→ исправление

Сейчас ИИ-генерацией CRUD-сервисов уже сложно кого-то удивить.

Но 1С:ERP-задачи – это совершенно другой уровень сложности.

Например:

Очень быстро стало понятно:

главная проблема 1С:ERP – не отсутствие данных, а сложность понимания причинно-следственной связи между механизмами системы

Перед началом эксперимента решили примерно оценить задачу “по классике”.

Оценка классической разработки (включая составление ТЗ, рзработку, отладку, тестирование):

Минимальный вариант — в среднем 50 часов
Рабочий вариант — в среднем 127 часов
Готовый вариант — в среднем 250 часов

Понятно, что это приблизительные оценки, но усредненная оценка практически совпала с моей собственной (80/120/240).

При этом даже “рабочий” вариант – это: 120+ часов разработки.
Если оценка вызывает сомнение - оцените и затем реализуйте сами и можете добавить свою оценку и время реализации стандартным путем в комментарии. Исходники требований лежат тут.

Рабочий MVP-инструмент (среднее между минимальным и рабочим вариантом) удалось получить примерно за: 8 часов

И это, пожалуй, оказалось самым интересным результатом.

Если честно, главный вывод эксперимента оказался совсем не таким, как ожидалось.

Сначала казалось, что ИИ больше всего помогает:

писать код.

Но на практике выяснилось:

основное ускорение дает резкое снижение стоимости инженерной итерации.

То есть ускорение возникало не потому, что:

"ИИ все написал сам"

А потому что цикл:

Идея → генерация → ошибка → исправление → проверка → повторная генерация

стал намного дешевле.

Отдельным приключением оказались запросы к 1С:ERP.

Особенно когда в одном сценарии пересекаются:

Мы все в курсе, что именно тут теряется огромное количество времени обычной 1С:ERP-разработки.

Поэтому в пайплайн появился отдельный слой автоисправления запросов с помощью ИИ.

Он:

Например, отдельно пришлось учитывать:

Очень быстро выяснилось еще одно ограничение.

1С:ERP-задачи практически невозможно стабильно решать “в лоб” через обычный LLM.

Без дополнительного контекста модель начинала:

Особенно это проявлялось в:

В результате в пайплайн появился отдельный knowledge/RAG-контур:

Документация по 1С:ERP + реальные примеры запросов + карта объектов конфигурации + правила no1C кодинга+ накопленные исправления

И только после этого генерация стала относительно стабильной.

По сути оказалось, что для ИИ оркестрации в 1С:ERP гораздо важнее не “умение писать код”, а наличие:

инженерной памяти и приземленного контекста

Отдельно удивило, насколько плохо работают даже с топ ИИ моделями (ChatGPT 5/Gemini3/Grok4) “большие ИИ рекомпиляции текстов”.

Например, попытка просто:

"переписать большое но неоднородное ТЗ красиво"

приводила к потере:

В итоге пайплайн пришлось строить как:

Компилятор требований

а не как:

В результате у меня получился рабочий web-инструмент разработанный не в среде 1С:ERP, который умеет:

И главное:

отвечать не только на вопрос: "сколько доступно?"

но и: "почему именно недоступно?" и "как это исправить?"

В итоге архитектура получилась довольно простой:

1С = транзакционное учетное ядро

Python = внешний интеллектуальный контур

API = интеграционный слой

ERP продолжает выполнять:

А внешний контур берет на себя:

Похоже, ИИ действительно начинает менять разработку.

Но не совсем так, как многие ожидали.

Самое важное изменение – не “автоматическое написание кода”.

Главное изменение – это:

снижение стоимости инженерной итерации

Особенно в сложных ERP-задачах, где основное время обычно уходит не на кодинг, а на:

И именно здесь пайплайн с ИИ ассистентом оказался неожиданно полезным.

Дополнительно чтобы убрать «эффект магии» можно посмотреть мое видео о том, как я это делаю по этой ссылке https://youtu.be/W6ZPVX_T9WA.