doc/AI/dev/DSL/DSL_AI.md
2026-03-16 17:26:04 +03:00

42 lines
6.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

### DSL & program language
Как будет развиваться vibe coding? Code Review (CR) глазами человека на "много букф" JS/Java etc? Точно нет.
Краткие промты (issue) vs детальные спецификации (многостраничные требования)? Один агент пишет код (Pull Request, PR), второй за ним делает CR?
Может быть даже:
- первый агент ставит общую задачу проекта \ типа аван-проект (привет от ГОСТ 24.). Агент формирует общий замысел, разбивает всю систему на части, пишет бизнес-требования и т.п.
- второй детализирует требования к каждой части (ТЗ) и формирует проектное решение - как потом собрать все эти части, но уже в коде (бизнес-логики) снова в одну систему, но уже "закодированную" (исполняемую)
- третий будет solution architect (технологческий концепт, выбор технологического стека, интегации и т.п.), data architect
- четвертый формирует issue для отдельной подзадачи, пятый делае PR, шестой по нему CR, седьмой - тестер и т.д.
Только все эти этапы - это повтор классики system \ software engineering (SE\SWE), а для AI-coding нужен видимо "более свежий" концепт разработки.
### revision
Полагаю, что нужно идти параллельно двумя путями:
- DSL для каждого класса ПО
- верхнеуровнеывый JS/Java (условно) для каждого языка програмрования - возможно единая оболочка, транслирующая верхнеуровневый код в язык програмирования, как и компилятор в машинный код \ bytecode. Назовем его macro code (MC)
Общий вариант: человек (DSL-програмист \ DSL промпт-инженер) пишет на DSL, далее агент генерит MC-код, человек его CR и далее только человек участвует только в User testing.
Как варинт, упрощенный DSL - это связка Онтологии (на каком либо языке, например, OWL/RDF, т.е. формальная онтология) и языка запросов, например, SPARQL. Такая связка показана в проекте [Semantic BPM\VAD](https://github.com/bpmbpm/rdf-grapher/tree/main/ver9d), оетология [в частности](https://github.com/bpmbpm/rdf-grapher/tree/main/ver9d/ontology).
Общий подход [SPARQL-driven Programming Guide](https://github.com/bpmbpm/rdf-grapher/blob/main/ver9d/requirements/sparql-driven-programming_min1.md) - лишь как демонстрация. Далее его бы развить до аналога PL\SQL, т.е. добавить процедурного расширение для получения PL\SPARQL.
PL\SPARQL - это только в части обработки данных (сама модель данных в OWL\RDF).
Блок workflow - как уже устоявшаяся практика в задачах "управления задачами" - BPMN-engine. Только конечно более совершенный, чем BPMN 2.0, но вектор верный "Программирование без програмирования": от Model-Based Design до Model Based Software Development (MBSE), где по модели генерируется весь код. BPMN 2.0 до этого еще далеко, там **no-code** только для примитивов типа [Hello Calculator](https://habr.com/ru/articles/866822/). Графическая визуализация - это основа для MC.
Полагаю, что отдельным направлением будет "vibe coding по аналогии" - это когда даешь ссылку на сервис (в идеале open source) и он тебе этот сервис переделывает под твои предпочтения, например, другой стек или добавляет новые функции. Или просто далае "один в один" - для обхода блокировок.
Фактически "по кнопке" были сделаны сервисы:
- on-line сервис: https://www.ldf.fi/service/rdf-grapher см. https://github.com/bpmbpm/rdf-grapher/tree/main/ver1
- graphviz-online см. https://github.com/bpmbpm/graphviz-online/tree/main/ver1 - удивительно, в оригинальном graphviz-online не было поддержки тега image
- https://github.com/bpmbpm/excel-online/tree/main/ver1
и другие
С учетом грандиозных возможностей AI реализовать "DSL для каждого класса ПО" и macro code (BPMN Next) - вопрос только постановки задачи и ... оплаченных токенов (бесплатные модели не особо хороши, точнее только в последние месяцы своей бесплатности, например, Grok Code Fast 1, kimi etc).
Фактически индустрия програмирования как когда-то при переходе с Ассемблера на С (и далее С++) должна "взять новую высоту", где уже более верхнеуровневый код будет представлять собой **конструктор смыслов** (условно RDF - триплетов, точнее их конструктор) и "писать на нем" будет простой (смертный) бизнес-пользователь, а "продвинутый бизнес-пользователь" даже сможет делать CR, проверять (условно) ключевые BPMN - Next и PL\SPARQL конструкции.