The post has been translated automatically. Original language: Russian
When people talk about AI in development, they often imagine a scenario where the AI simply writes code instead of the programmer.
In practice, it looks different here.
We use Noda as a working knowledge base to develop Sekura JS, our own system programming language within the Jupiter Soft ecosystem. Sekura JS is linked to our Memora8 and Reganta stack, so there are many architectural solutions in the project: how modules are designed, how compilation goes, what artifacts are created, how errors are described, and what limitations runtime has.
It's impossible to keep all this securely only in your head or in correspondence.
Therefore, we began to record the key decisions in Noda in the form of canonical articles.
A canonical article is not just a “show-off” documentation. This is a short, human-verified description of how the system should work. For example: how the Sekura JS module works, what files appear after compilation, what artifacts should be called, what errors the compiler must find, where is the boundary between the language, compiler and runtime.
Then these articles become a working context for AI.
Instead of explaining the project anew in the chat every time, we connect the AI to Noda via MCP. The AI sees not random notes, but the accepted canons of the project. After that, he can help with real engineering work.:
- check the Sekura JS source code for canonical articles;
- find discrepancies between documentation and implementation;
- show where the article is outdated;
- show where the code does not match the decision made.;
- suggest changes to the canons;
- suggest edits to the source code.
The important point is that the decision is up to the person.
AI does not become the main architect. He doesn't “decide for himself” how the language should work. A person formulates an architectural idea, verifies the conclusions, makes a final decision and approves the changes. In this process, Noda plays the role of the project's shared memory, and AI plays the role of an attentive engineering assistant who quickly compares the code and the accepted rules.
In practice, the cycle looks like this:
a person makes a decision → the decision is fixed in Noda → The AI checks the source code → deviations are found → the person decides what to change → the canons and code are updated → the cycle repeats
This is how we currently use the Noda <-> Sekura JS bundle.
For example, if the canon describes that compiling the .sjs module should lead to the creation of certain artifacts, the AI can compare this description with the current implementation of the compiler. If the behavior of the code is different, it does not always mean an error. Sometimes the code is incorrect. Sometimes the article is outdated. Sometimes the solution has already changed, but has not yet been fixed in Noda.
This is the value of the process: discrepancies become visible.
For a small project, this may seem redundant. But as soon as several layers appear — language, compiler, runtime, processor model, operating system, documentation, tests — without a canonical source of truth, the project quickly begins to spread.
Noda helps to keep architecture in one place.
In this sense, Sekura JS has become not only a programming language for us, but also a real test of Noda itself. We test Noda not on abstract demos, but on a live project, where new solutions, refinements and changes appear every day.
This is an important principle of AI-native development for us.:
AI should not operate in a chaotic context. AI should work according to canonical knowledge that has been verified by humans.
Then AI becomes not a random code generator, but part of the engineering cycle.
The documentation is no longer an archive.
The code is no longer the only source of truth.
And a person gets a tool that helps them to quickly see the discrepancies between the idea, canons and implementation.
We call this iterative development through canonical articles.
This is exactly the approach we are currently testing on a bundle of Noda and Sekura JS.
Когда говорят про ИИ в разработке, часто представляют себе сценарий, где ИИ просто пишет код вместо программиста.
На практике у нас это выглядит иначе.
Мы используем Noda как рабочую базу знаний для разработки Sekura JS — собственного системного языка программирования внутри экосистемы Jupiter Soft. Sekura JS связан с нашим стеком Memora8 и Reganta, поэтому в проекте много архитектурных решений: как устроены модули, как проходит компиляция, какие артефакты создаются, как описываются ошибки, какие ограничения есть у рантайма.
Все это невозможно надежно держать только в голове или в переписках.
Поэтому мы начали фиксировать ключевые решения в Noda в виде канонических статей.
Каноническая статья — это не просто документация “для галочки”. Это короткое, проверенное человеком описание того, как система должна работать. Например: как устроен модуль Sekura JS, какие файлы появляются после компиляции, как должны называться артефакты, какие ошибки компилятор обязан находить, где граница между языком, компилятором и рантаймом.
Дальше эти статьи становятся рабочим контекстом для ИИ.
Вместо того чтобы каждый раз заново объяснять проект в чате, мы подключаем ИИ к Noda через MCP. ИИ видит не случайные заметки, а принятые каноны проекта. После этого он может помогать в реальной инженерной работе:
- проверить исходный код Sekura JS относительно канонических статей;
- найти расхождения между документацией и реализацией;
- показать, где статья устарела;
- показать, где код не соответствует принятому решению;
- предложить правки в каноны;
- предложить правки в исходный код.
Важный момент: решение остается за человеком.
ИИ не становится главным архитектором. Он не “сам решает”, как должен работать язык. Человек формулирует архитектурную идею, проверяет выводы, принимает финальное решение и утверждает изменения. Noda в этом процессе играет роль общей памяти проекта, а ИИ — роль внимательного инженерного помощника, который быстро сопоставляет код и принятые правила.
На практике цикл выглядит так:
человек принимает решение → решение фиксируется в Noda → ИИ проверяет исходный код → находятся отклонения → человек решает, что менять → обновляются каноны и код → цикл повторяется
Именно так мы сейчас используем связку Noda <-> Sekura JS.
Например, если в каноне описано, что компиляция .sjs модуля должна приводить к созданию определенных артефактов, ИИ может сравнить это описание с текущей реализацией компилятора. Если поведение кода отличается, это не всегда означает ошибку. Иногда код неправильный. Иногда статья устарела. Иногда решение уже изменилось, но еще не было зафиксировано в Noda.
Это и есть ценность процесса: расхождения становятся видимыми.
Для небольшого проекта это может казаться избыточным. Но как только появляется несколько слоев — язык, компилятор, рантайм, процессорная модель, операционная система, документация, тесты — без канонического источника истины проект быстро начинает расползаться.
Noda помогает удерживать архитектуру в одном месте.
Sekura JS для нас в этом смысле стал не только языком программирования, но и реальным тестом самой Noda. Мы проверяем Noda не на абстрактных демо, а на живом проекте, где каждый день появляются новые решения, уточнения и изменения.
Для нас это важный принцип AI-native разработки:
ИИ не должен работать по хаотичному контексту. ИИ должен работать по каноническому знанию, которое проверено человеком.
Тогда ИИ становится не генератором случайного кода, а частью инженерного цикла.
Документация перестает быть архивом.
Код перестает быть единственным источником правды.
А человек получает инструмент, который помогает быстрее видеть несоответствия между идеей, канонами и реализацией.
Мы называем это итеративной разработкой через канонические статьи.
Именно такой подход сейчас тестируем на связке Noda и Sekura JS.
Share
