Введение
В этой статье я описываю свое видение и методологию нового вида продуктов - "генерируемые продукты", которые занимают промежуточное положение между "коробочными продуктами" и любым написанием конфигурации "с нуля" включая новомодный вайбкодинг, заимствуя лучшие свойства обоих вариантов. Чтобы раскрыть свою мысль я не теоретизирую, а описываю как работает реальный сервис который создает такие "продукты". Эту идею можно применить собственно к любой платформе, включая 1С, но я сделал на бесплатной открытой платформе - NodaLogic.
Про NoldaLogic и интеграции ее с 1С я писал тут и тут . Платформа доросла до собственных больших типовых решений, таких как WMS, а не только "мобильного фронта для 1С", как было в SimpleUI. А вот способ, которым я эти решения предоставляю пользователю, довольно любопытный и о нем я расскажу в статье.
Как это работает
Вы создаете «решение» выбранного типа. Сейчас выбор типов небогат – это только WMS (система управления складом) и произвольное решение (без методологии). Далее мы будем говорить о WMS. Экземпляр решения – это стапели, из которых в итоге выйдет в свободное плавание конфигурация. В нем фиксируется все: факты о решении, которые агенты от вас получили, переписка, принятые решения, задачи, тесты.
Начинается все с вопросов. Агент анализирует ответы и задает новые вопросы пока все не прояснит. Для этого у него есть «движок вопросов» для того, чтобы собирать факты для технического задания – разные формы вопросов, которые он рисует прямо в чате. Факты – это такой специальный термин, по сути – формализованные ответы на вопросы. Это не произвольный чат, а именно такие объекты в чате, которые агент, пользуясь движком рисует для вас. Факты фиксируются в решении, а визуально для них есть специальное место.
Откуда он знает, что спрашивать? Это агент-методист, он специализируется на WMS-решениях.
Когда агент понимает, что узнал все что хотел он создает 2 вещи для согласования: формализованное текстовое ТЗ и Схему решения. С ТЗ все понятно, просто красиво оформленное (в силу эстетических способностей модели) саммари того, что он понял. А схема интереснее. Это еще один движок – интерактивный редактор в котором вы можете не только просматривать и корректировать, но и полноценно менять архитектуру узлов (классов). Выглядит устрашающе? Ну, там можно отключать лишние слои. Если сказать упрощенно то эта штука описывает данные, взаимодействия между узлами (у меня это называется интенты) и все это скрепляется промптами по каждому элементу. Т.е. например есть класс, он взаимодействует с другим классом и описано что делает это взаимодействие – вызывает функцию такую то, которая делает то-то, возвращает то-то. Т.е. по сути это графическая схема промптов. Но она не только для человека, модель по ней осуществляет контроль целостности ТЗ, перед тем, как начнет генерацию.
Схема решения немного пугает, но не стоит боятся - слои можно отключать
В интентах самое интересное: взаимодействие между узлами
Всё это он предлагает вам на ознакомление и согласование. Если вы согласны с ТЗ, схемой, фактами, паттернами и всем остальным багажом знаний, он делает конфу-кандидат. Можно не согласиться, что-то уточнять, в режиме обычного чата, будут новые вопросы и циклы согласования пока вы не утвердите ТЗ и схему.
Нажав на "Утвердить ТЗ и схему" вы запускаете генерацию.
Сделав конфу он ее вам сразу не отдает, а запускает довольно долгий цикл (может занимать больше часа):
Индикатор показывает, где вы сейчас находитесь
Он сначала проверяет конфу валидатором/ассемблером - синтаксис, логика NodaLogic...
Далее модель оценивает функционал на соответствие техническому заданию именно по учетным аспектам от форм до отчетов: все ли данные вводятся, куда они далее попадают, как отражаются на остатках, как выходят в отчетах, индикаторах и иных выходных формах)
Далее модель придумывает сквозные учётные примеры. Например: внешний документ на приёмку → планирование задания на приёмку → приёмка на ТСД с возможными отклонениями → запуск стратегии размещения. Здесь модель проверяет: всё ли можно разместить при заданных настройках? Заполнены ли ВГХ и зоны? Сработает ли стратегия успешно или завершится ошибкой? → получение задания на размещение → выполнение размещения.
И далее по подобным примерам, а также по примерам не только учётным, но и просто проверяющим функциональность, модель пишет runtime-тесты и их запускает на стороне уже кандидата в «песочнице. По результатам тестов также обнаруживаются ошибки.
Получается сводный список ошибок «соответствие ТЗ/runtime-тесты». В чате вы можете Пропустить некоторые из этих ошибок если считаете их не важными. На самом деле могут быть противоречия в ТЗ из-за которого могут возникать подобные ошибки.
По результатам этих тестов модель делает задание на Repair – исправление кандидата. После чего исправляет и снова контролирует. После всех циклов получается финальный кандидат, который уже можно тестировать самостоятельно.
На самом деле модель деплоит его начиная с прохождения первого технического теста и его можно уже смотреть, пока модель проводит все манипуляции. По мере итераций пайплайн еще несколько раз обновляет конфу в репозитории.
После того как все закончится у вас есть конфа и база которую можно наполнять и гонять как хочется. Есть Начальное заполнение и Помощник по интеграции. Можно подключить мобильные устройства, завести пользователей, настроить интеграцию с внешней системой или просто погонять запросы через Postman. Это этап произвольного тестирования – тут уже не автотесты, а человек в роли тестировщика. Если что-то находим, что нас не устраивает говорим об этом модели просто в чате, она переписывает, деплоит – смотрим. Ну и если все устраивает – скачиваем конфу.
Ах, да в процессе всё-таки можно натыкаться на runtime-ошибки, недобитые автотестами. Например какая то интеграция вернула не то. Бывает. Чтобы смягчить это сделана удобная система отслеживания подобных ошибок и передачи в чат: каждый инцидент запоминается – текст исключения, контекст, данные и передается в чат. Можно по одному или скопом.
Как это устроено
В качестве продолжения предыдущего раздела, расскажу, как конвейер создает конфу. Это строгий пайплайн который гоняет модель до тех пор, пока не получит идеальный результат. Модель сейчас используется DeepSeek v4. Начинается все с того, что у него в распоряжении есть библиотека паттернов (экстракция фич из референсных конфигураций. Кстати, забавный факт – пополнение библиотеки бесконечный процесс, поэтому N-Reactor становится умнее с каждой выпущенной конфой), стандарты решений NodaLogic в целом (что должно быть в конфе по дефолту, что можно и что нельзя для производительности, что нельзя делать в учётных системах (нарушать атомарность, оборачивать широкими попытками и т.д.)) и «стандарты решения» (например «должно быть начальное заполнение демо-примера с тем то и с тем то. Учетный пример должен покрывать такую то логику…»), методология и nGenie Code – агент, который умеет хорошо писать под NL и знает про оптимизацию. Это, вместе с фактами, ТЗ и схемой поступает для изготовления сначала кандидата, а потом и релиза. Схема не заменят ТЗ, а дополняет, кстати.
Получив кандидат он проверяет его на специальных стендах на стороне пайплайна на технину и всякие необходимые штуки, а ля правильный визуал форм и т.д.
Далее модель проводит то что я называю семантическое тестирование – т.е. соответствие бизнес-логики кандидата техническому заданию. В этих тестах модель четко указывает, что надо проверить после того, как перепишешь – что выполнить, какой ожидается результат. Т.е. сразу формализует проверку исправления.
Далее модель обкладывает это тестами, которые сама и придумывает. Она вычисляет цепочки логики и пишет ее имитацию. Андроид не проверяется к сожалению – только синтетические тесты. Тесты исполняются, фиксируется результат и оценивается успех. Для каждого теста создается «песочница» в которой он выполняется и контролируется выполнение по изменению _data, взаимодействию с другими узлами, остатками и т.д.
И собственно это все гоняется по кругу пока не будет получен результат.
Что такое генерируемые продукты
Принцип массового производства в широком смысле появился давно и его цель – снижение себестоимости продукта/изделия, а в случае программных продуктов в росте маржинальности за счет массовой продажи копий, ведь себестоимость ПО одна, продавать можно бесконечно. В области ПО это выглядит так: собрались умные люди – методисты, архитекторы, программисты и сделали некий универсальный продукт, подходящий всем. Точнее часто бывает даже так: сделали кастомный проект под одного, второго, третьего клиента, а потом подумали, а почему бы не пропустить это еще раз (еще много, много раз) через кассу? Немного подшаманив, получается тот же универсальный продукт. Этот коллектив людей имеет опыт реальных внедрений и компетенции, им можно доверять, а значит и их продукту можно доверять. Все логично.
Но есть одна маленькая деталь. Что же такое это универсальный продукт? Для пользователя – это «решение из коробки», где, условно включая и выключая нужные галочки он получает нужный функционал. Все вроде бы как надо. А что такое это для внедренца/программиста? Это огромная кодовая база. Эти продукты гигантские и растут с каждым годом ради того, чтобы покрыть своей функциональностью все больше и больше кейсов. Это километровые запросы, в которых приходится разбираться. Тебя спрашивают "почему стратегия размещения делает не так как ожидает складской логист?", ты лезешь в код и долго мотаешь запрос на несколько экранов, который написан для всех случаев жизни. И в этот момент ты бы очень хотел, чтобы этот запрос учитывал только 1 ветку алгоритма, которая нужна клиенту. И так всё. Сколько процентов кода универсального продукта не нужно клиенту? 70%-80%? Вы скажете, ну и что, он же за это не платит. Как раз платит – внедренцу (без которого разобраться в этом «коробочном» продукте нельзя самому уже очень давно), программисту который это поддерживает и магазину серверного оборудования – ведь прокачивать эти 80% лишнего кода, это не бесплатно, да? Ну еще наверное таким специальным людям, экспертам по производительности, которые заставляют этот конгломерат кода крутиться на этом железа сносно и не тормозить.
Можно написать решение с нуля под хотелки клиента. С появлением LLM это обрело новый смысл и право на жизнь. Решение получится компактным и оптимальным, особенно если это low-code фреймворк. Да даже если не low-code. Например можно писать на чистом SQL – это даст массу преимуществ в плане производительности. Минусы – в поддержке таких решений. Типовые конфы придумали не просто так – когда у тебя десятки проектов, хочется иметь единый смысловой каркас, а не отсебятину на каждом проекте.
Что предлагаю я. Представьте что вышеописанный коллектив умных и компетентных в создании WMS специалистов приходит к клиенту и говорит «У нас есть конфа, проверенная временем. Но она большая, тебе там 2/3 из нее не нужно. Мы сейчас оттуда наковыряем нужных модулей и блоков, вырежем только нужное и шлифанем под твои хотелки» Не «модульный подход», нет. Программист реально пишет кастомную конфу, но используя паттерны продукта. Как вы догадались, этот «коллектив» - коллектив агентов, который сидит в N-Reactor.
В качестве иллюстрации вот такой пример. В стандарты решений NodaLogic входит помимо всего прочего Integration Guide. Это сгенерированные API для внешней системы и для мобильного приложения – инструкция, QR коды, кнопки «Сделать всё». Все для того чтобы настроить обмен с внешней системой, развернуть мобильные рабочие места.
И это настолько удобно, что LLM в «стандартах решения» я говорю "вообще ничего не меняй, даже дизайн, только переделай состав API, эндпоинты, состав выгружаемых в офлайн справочников и т.д." Ведь документы и справочники, их реквизиты, логика запросов — всё это меняется от ТЗ к ТЗ. Логика мобильного приложения может быть разная, а значит туда надо прокачивать разные данные. И вот он берет и делает тоже самое, только под конкретную реализацию. Т.е. пользователь получает продукт с контроллируемыми свойствами.
Совсем без настроек не обойтись. Есть самые необходимые.
Это продукт без всего лишнего. Не то, чтобы там совсем не будет настроек. Вот, например они есть, потому что справочник один (хотя в парадигме NL нормально сделать для каждого вида товара свой класс, это тоже вариант), а условия хранения разные.
Что я называю «ничего лишнего?» Пример сгенерированной WMS имеет 3000 серверных строк, стратегии примерно по 50-90 строк и 1500 строк – мобильный клиент. Для меня это важнейший целевой показатель. Он косвенный, да. Но посмотрите обработчики стратегий в демке, возможно логика будет понятна. Читаемость конфы, легкость поддержки – это важный показатель. Вторая важная вещь – насколько успешно работают с NL модели, особенно слабые. Нехитрая семантика и принцип одного узла и nGenie делает все что угодно в любой конфе с данными, отчетами, обработками.
Когда я создавал NodaLogic я создавал его в расчете на глубокую интеграцию с ИИ-агентами - как на этапе создания решения так и интеграцию агентов в бизнес-логику решений и повседневную эксплуатацию. Я сделал предположение, что научившись строить системы из одного кирпичика "узла" LLM может построить систему любой сложности от простой до бесконечно сложной повторяя одни и те же элементы (точнее элемент-узел) и паттерны. И эта система будет понятна и читаема. Я заметил что все типовые продукты подвержены бесконечному росту, как для расширения функционала, расширения универсальности охватываемой области так и для поддержки легайси. Как внедренец я понимаю цену этого роста для себя, но также я как внедренец не хочу каждый раз приходить на проект написанный с нуля и разбирать очередной велосипед. Конечно же я хочу универсальности и переиспользования одних и тех же паттернов, но не такой ценой. Это этот проект - попытка найти баланс или нишу между "писать с нуля" и "бесконечной свалки кода". Вот в чем смысл.
Обязательно посмотреть перед тем, как начать пользоваться.
Есть режим с демо-продуктами. И там сейчас только один пример - WMS как раз сгенерированная и в некотором роде референсная для этого механизма. Это значит, что в результате генерации вы получите ну вот примерно такую же WMS только с вашими особенностями учета. Она может быть сильно больше или меньше, мобильные клиент может довольно сильно варьироваться и в плане интерфейса и в плане логики, но веб-клиент и сервер будут примерно такие же. Ее можно развернуть под себя и также как кандидат из конвейера гонять в хвост и в гриву, подключив к ней все что можно.
По ней я записал видео, оно не маленькое, но его тоже желательно глянуть:
Что может пойти не так?
Если вы всё-таки посмотрели демку, она вас устроила и решились потратить несколько токенов на генерацию, то нужно понимать, что результат не гарантирован на 100%. Особо стоит обратить внимание на ТЗ. Модель все понимает буквально, а в ТЗ могут быть противоречия. От того, насколько хорошо сделано ТЗ зависит количество итераций и, следовательно, токенов при последующих генерациях. Это банально, но я все таки напишу. ТЗ и схему готовит модель, но желательно изучить и принять участие в процессе, а не просто нажать кнопку «Утвердить».
Если в ТЗ есть внутренние противоречия, есть противоречия с возможностями платформы (хотя подобное модель контролирует на стадии ТЗ) либо противоречия с системными промптами то модель может выйти на «плато» - несколько раз подряд не исправить ошибку. Подобные вещи контролируются чтобы не увести в бесконечный цикл.
Вы можете отправить мне диагностику через специальную кнопку и написать письмо, я по диагностике обязательно постараюсь помочь.
Вступайте в нашу телеграмм-группу Инфостарт