В этой статье описан агентный конвейер для полностью автоматизированной разработки учетных бизнес-решений (с веб- и мобильными клиентами) на платформе NodaLogic. Это не вайбкодинг, не spec-to-code и не ассистент написания элементов конфигурации, а автоматизация полного цикла: от формализации ТЗ до написания и прохождения тестов. Используя стандарты и знания методологии предметной области конвейер проводит анкетирование, создает и согласует ТЗ и схему решения, проводит защиту и согласование с использованием интерактивной схемы, опираясь на стандарты и паттерны разрабатывает прототип, проводит семантический анализ соответствия ТЗ, пишет наполнение, придумывает и пишет сквозные runtime тесты, выполняет их и проверяет как ведет себя учетная система и соответствует ли она задачам по функциональности и производительности. При этом полученный результат в виде конфигурации ( для серверной и мобильной платформ используется одна конфигурация) я называю продуктом, только не тиражными типовыми решениями, а их альтернативой – генерируемыми продуктами. Почему продуктами? Об этом — подробно в статье.

Внесем немного ясности

NodaLogic — это полностью бесплатная платформа, не облачная. Её можно качнуть с GitHub. и развернуть под себя. Сервер, разработанные вами конфигурации и данные — всё лежит и крутится у вас. (можно и на nmaker.pw но продовые базы лучше у вас). О ней я писал тут https://habr.com/ru/articles/1011090/ Никаких скрытых подписок и чего-то подобного – полное владение, открытая лицензия.

И если вы решили разработать для своего бизнеса какое-то решение у вас есть 2 пути на выбор :

1. Вы можете сделать это сами: посмотреть документацию и видео, скачать примеры, зайти на nmaker.pw в обычный конфигуратор или развернуть его у себя и сделать конфигурацию, а потом пользоваться получившейся конфигурацией. Я позиционирую NodaLogic как low-code платформу и яростно сражаюсь за то, чтобы это было именно low а не профанация. До этого я 7 лет делал SimpleUI и многим она кажется простой, но я решил доказать, что NL еще гораздо проще и удобнее. В общем хороший путь, советую. На помощь вам могут прийти существующие LLM и многие как я знаю активно пишут конфигурации под NL с помощью ChatGPT и подобного. Это бесплатный вариант.

2. Либо вы можете пойти по пути коммерческого сервиса, которому посвящена эта статья – N-Reactor. Он сделает все под ключ по строгим стандартам методологии, архитектуры и производительности NodaLogic, но за деньги. Так вот, к чему всё это. Я просто хочу прояснить, что в результате взаимодействия с сервисом вы получите такую же конфигурацию на выходе (буквально .nod-файл) как в первом пункте, только все за вас сделает ИИ и хитрые алгоритмы. Это происходит так: конвейер выпускает конфигурацию в облачный деплой, вы ее тестируете, заводите пользователей, разворачиваете на устройстве, проводите нагрузочные тесты или еще какие тесты и ТОЛЬКО убедившись что она вам подходит платите денежку и скачиваете .nod-файл. Это что то наподобие питомника, где я выращиваю для вас не туи, а бизнес-решения на заказ. Точнее это делаю не я, а модель и умные алгоритмы. Я называю это "генерируемым продуктом" (Генерируемый продукт — это не типовая конфигурация, которую потом кастомизируют. Это новая конфигурация, создаваемая под конкретный бизнес, но генерируемая по стандартам и паттернам типового продукта)

Как это работает

На nmaker.pw есть специальный сервис N-Reactor в нем вы создаете «решение» выбранного типа. Сейчас выбор типов небогат – это только 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 делает все что угодно в любой конфе с данными, отчетами, обработками.

Обязательно посмотреть перед тем, как начать пользоваться.

На nmaker.pw есть режим с демо-продуктами. И там сейчас только один пример -  WMS как раз сгенерированная и в некотором роде референсная для этого механизма. Это значит, что в результате генерации вы получите ну вот примерно такую же WMS только с вашими особенностями учета. Она может быть сильно больше или меньше, мобильные клиент может довольно сильно варьироваться и в плане интерфейса и в плане логики, но веб-клиент и сервер будут примерно такие же. Ее можно развернуть под себя и также как кандидат из конвейера гонять в хвост и в гриву, подключив к ней все что можно.

По ней я записал видео, оно не маленькое, но его тоже желательно глянуть:

Что может пойти не так?

Если вы всё-таки посмотрели демку, она вас устроила и решились потратить несколько токенов на генерацию, то нужно понимать, что результат не гарантирован на 100%. Особо стоит обратить внимание на ТЗ. Модель все понимает буквально, а в ТЗ могут быть противоречия. От того, насколько хорошо сделано ТЗ зависит количество итераций и, следовательно, токенов при последующих генерациях. Это банально, но я все таки напишу. ТЗ и схему готовит модель, но желательно изучить и принять участие в процессе, а не просто нажать кнопку «Утвердить».

Если в ТЗ есть внутренние противоречия, есть противоречия с возможностями платформы (хотя подобное модель контролирует на стадии ТЗ) либо противоречия с системными промптами то модель может выйти на «плато» - несколько раз подряд не исправить ошибку. Подобные вещи контролируются чтобы не увести в бесконечный цикл.

Вы можете отправить мне диагностику через специальную кнопку и написать письмо. Диагностика это не только ошибки. Это все данные – что получает и отдает модель, ТЗ, чат, что меняется в кандидате и т.д. Т.е. даже без ошибок может не удовлетворять результат и вы можете написать мне, я по диагностике обязательно постараюсь помочь.

О проекте

Когда я создавал NodaLogic я создавал его в расчете на глубокую интеграцию с ИИ-агентами - как на этапе создания решения так и интеграцию агентов в бизнес-логику решений и повседневную эксплуатацию. Релиз N-Reactor (а до этого помощника уровня работы с данными N-Genie) это своеобразный экзамен всего проекта - годная ли была идея самой платформы и ее реализация. Я сделал предположение, что научившись строить системы из "узлов" LLM может построить систему любой сложности от простой до бесконечно сложной повторяя одни и те же элементы (точнее элемент-узел) и паттерны. И эта система будет понятна и читаема. Для кого то может показаться странным, что я считаю строки кода обработчиков и радуюсь тому, что в 3000 строк уместилась вся WMS. Но я в том числе 1Сник со стажем с 2002 года (в следующем году будет 25 лет) и сейчас я не удивляюсь одной печатной форме в эти 3000 строк (а тогда, в начале пути печатная форма занимала один экран пузатого 15" монитора, выдавая ту же логику). Не хочу ни в коем разе бросать тень на конкретную платформу, такое происходит и в SAP и других платформах - все универсальные типовые решения растут. Это факт. И как внедренец я понимаю цену этого роста, но также я как внедренец не хочу каждый раз приходить на проект написанный с нуля и разбирать очередной велосипед. Конечно же я хочу универсальности и переиспользования одинх и тех же паттернов, но не такой ценой. Это этот проект - попытка найти баланс или нишу между "писать с нуля" и "бесконечной свалки кода". Вот в чем смысл.

Подпишитесь на мой ТГ канал где много всего интересного: https://t.me/thinknodes_ru