The post has been translated automatically. Original language: Russian
When they talk about Agile, most people imagine Scrum boards, daily phone calls, and endless meetings.
But the ideas of Robert Martin, known as Uncle Bob, were not about processes for the sake of processes. Agile is the ability to quickly change a system without losing quality, integrity, and understanding of its architecture.
Therefore, Robert Martin focuses not so much on ceremonies as on engineering practices: clean code, refactoring, testing, simple design and constant feedback.
We are developing our own Memora8 64-bit processor, the Reganta OS operating system, the Sekura JS programming language and tools around them. On such a project, it quickly becomes obvious that the main problem is not writing the code. The main problem is to preserve the team's knowledge.
The code is just the tip of the iceberg.
Imagine changing a single processor instruction.
At first glance, it seems that only the HDL code needs to be changed.
In practice, the change may affect:
- the ISA specification;
- the Memora8 architecture;
- the compiler;
- Sekura JS language;
- Firmware Kernel;
- Reganta OS;
- documentation;
- tests;
- usage examples;
- related architectural solutions.
After a few months, it's hard to remember why the instructions were implemented the way they were, what alternatives were considered, and why they were abandoned.
If knowledge lives only in the heads of developers, correspondence, or Git history, the project gradually begins to slow down.
This is where Agile transforms from a task management methodology into an engineering knowledge management system.
We have come to Noda
During development, we encountered an unexpected problem.
The documentation existed.
The markdown files existed.
The wiki existed.
Comments in the code also existed.
But the answers to important architectural questions still had to be sought from people.
We realized that the problem wasn't the lack of documentation. The problem is the lack of a canonical source of knowledge.
That's how Noda appeared.
It was originally created as an internal development tool for the Memora8 processor, Reganta OS and Sekura JS.
Today we consider Noda as a new generation expert system.
It combines the most powerful aspects of modern large language models and the principles of classical expert systems.
From LLM, Noda gets the ability to understand natural language, take into account the context of a question, explain complex ideas, and formulate answers in a human-friendly way.
It takes another fundamental principle from classical expert systems: answers should not be based on a random array of documents or on model guesses, but on a controlled, structured and verified knowledge base.
The LLM is responsible for understanding and dialogue.
Canonical knowledge is responsible for meaning and authenticity.
What has changed
Today, almost any significant architectural decision is first fixed in Noda.
For example:
- why is the Memora8 architecture designed this way?;
- why did Reganta OS abandon the classical process model;
- why is the Sekura JS module the execution unit?;
- how the Firmware Kernel works;
- how the module scheduler works;
- how modules use processor memory;
- what should be the module lifecycle?;
- what are the limitations of ISA Memora8;
- why alternative architectural approaches were rejected.
After discussion, the article is approved and becomes canonical.
From now on, she is the source of knowledge for developers and connected AI tools.
This is important because in a complex project it is not enough to know that the system works in a certain way.
We need to understand why the team made this decision.
AI doesn't search — it turns to knowledge.
Most modern corporate AI systems are built around searching through a large array of documents.
Wiki pages, correspondence, PDF files, old specifications and drafts are uploaded to the repository. Then the system tries to find the most suitable fragments and form an answer based on them.
The problem is that the materials found may contain outdated versions, conflicting documents, and decisions that have already been canceled.
We went the other way.
AI gets access not to a random archive, but to approved canonical articles.
If there is one valid article about the Reganta OS scheduler in the knowledge base, the AI does not start collecting an answer from several conflicting versions of the documentation.
He uses a solution that the team considers valid.
In this sense, Noda is closer not to intelligent search, but to a modern expert system.
But unlike the old expert systems, the user does not need to study a special interface, select a rule from a list, or formulate an accurate machine query.
He asks a common question in natural language.
LLM understands the user's intention, accesses controlled knowledge, and forms an understandable response.
The strengths of the two generations of systems
Classical expert systems had an important feature: they worked with explicitly defined knowledge.
The experts formed the rules, determined the acceptable conclusions and controlled the area of competence of the system.
Such systems could be reliable in a narrow subject area, but they were difficult to implement and inconvenient to interact with.
Modern LLMs have solved the interface problem.
They are able to understand inaccurate questions, maintain a dialogue, explain, compare and adapt the answer to the user.
But by themselves, they do not guarantee that the answer corresponds to the actual decision of a particular team.
Noda connects these approaches.
An expert or a team controls the content of knowledge.
LLM provides natural access to this knowledge.
The result is a system in which the intelligence of the model does not replace the expert, but makes expert knowledge available to people and software tools.
Agile turned out to be not about Scrum
The most interesting discovery came later.
When knowledge becomes part of the development process, many Agile practices begin to work naturally.
Any important change goes through a simple cycle.:
- an architectural idea or problem arises;
- The team is discussing possible solutions;
- the canonical article is being updated;
- the solution is implemented in code or HDL;
- the tests are running;
- the compliance of the implementation with the accepted architecture is checked;
- knowledge is refined based on the results of development.
There is a continuous feedback between the idea, knowledge, implementation and verification.
Not because Scrum requires it.
This is because without such a cycle, it is impossible to consistently develop a complex architecture.
Processor development is a constant learning process
When creating your own Memora8 processor, it is impossible to open one textbook and find all the ready-made answers.
Every decision raises new questions.
Why this particular instruction?
Why is this the format of the command?
Why is there such a memory model?
Why this particular Memora8 architecture?
Why is the unit of execution a module?
Why doesn't the system use traditional processes?
Why is the Firmware Kernel designed this way?
The answers appear in the process of research, experimentation and implementation.
But after six months, the team may no longer remember all the details of the discussion.
If this knowledge has not been preserved, it has to be restored or acquired anew.
This means repeated arguments, repeated research, and the risk of making a decision that contradicts the existing architecture.
We try to avoid this.
Therefore, an important architectural idea first becomes knowledge, and then code.
Canonical knowledge as a part of architecture
Documentation is usually perceived as a description of an already written system.
In our case, it becomes part of the architecture itself.
The canonical article defines not only the current behavior of the component, but also the limits of acceptable changes.
For example, if it is fixed that the unit of execution of Reganta OS is the Sekura JS module, the new solution must either comply with this principle or explicitly change the canon.
This makes the architectural changes visible.
A developer or an AI tool should not independently guess which of several solutions is relevant.
He turns to the approved knowledge.
This is how Noda becomes the connecting layer between the architectural design, the development team, and AI tools.
Instead of output
After several years of development, we came to an unexpected conclusion.
The team's most expensive resource is not code.
And not even the time itself.
The most expensive resource is accumulated engineering knowledge: decisions made, rejected alternatives, limitations, and an understanding of the reasons why the system works that way.
That is why Noda has become for us not just another Wiki or a document search.
This is a new generation expert system that combines the best ideas of classical expert systems with the capabilities of modern LLMs. Instead of trying to extract the truth from a chaotic array of documents, Noda provides AI with access to canonical knowledge that is generated and validated by the engineering team itself. LLM is responsible for natural language understanding and user—friendly interaction, while the expert knowledge base is responsible for accuracy, consistency, and compliance with accepted architectural solutions.
Today, Noda is evolving with the Memora8 processor, Reganta OS, and Sekura JS, preserving architectural knowledge that cannot be recovered from source code alone.
Perhaps this approach is the modern interpretation of Robert Martin's ideas.
Agile is not a set of ceremonies.
This is the team's ability to quickly change the system without losing its quality, architectural integrity, and understanding of why it works the way it does.
Когда говорят об Agile, большинство представляет Scrum-доски, ежедневные созвоны и бесконечные встречи.
Но идеи Роберта Мартина, известного как Uncle Bob, были не про процессы ради процессов. Agile — это способность быстро менять систему без потери качества, целостности и понимания ее архитектуры.
Поэтому Роберт Мартин делает акцент не столько на церемониях, сколько на инженерных практиках: чистом коде, рефакторинге, тестировании, простом дизайне и постоянной обратной связи.
Мы разрабатываем собственный 64-разрядный процессор Memora8, операционную систему Reganta OS, язык программирования Sekura JS и инструменты вокруг них. На таком проекте быстро становится очевидно: главная проблема — не написать код. Главная проблема — сохранить знания команды.
Код — это лишь вершина айсберга
Представьте изменение одной инструкции процессора.
На первый взгляд кажется, что нужно изменить только HDL-код.
На практике изменение может затронуть:
- спецификацию ISA;
- архитектуру Memora8;
- компилятор;
- язык Sekura JS;
- Firmware Kernel;
- Reganta OS;
- документацию;
- тесты;
- примеры использования;
- связанные архитектурные решения.
Через несколько месяцев уже сложно вспомнить, почему инструкция была реализована именно так, какие альтернативы рассматривались и почему от них отказались.
Если знания живут только в головах разработчиков, переписках или истории Git, проект постепенно начинает замедляться.
Именно здесь Agile превращается из методологии управления задачами в систему управления инженерными знаниями.
Мы пришли к Noda
Во время разработки мы столкнулись с неожиданной проблемой.
Документация существовала.
Markdown-файлы существовали.
Wiki существовала.
Комментарии в коде тоже существовали.
Но ответы на важные архитектурные вопросы все равно приходилось искать у людей.
Мы поняли, что проблема не в отсутствии документации. Проблема в отсутствии канонического источника знаний.
Так появилась Noda.
Изначально она создавалась как внутренний инструмент для разработки процессора Memora8, Reganta OS и Sekura JS.
Сегодня мы рассматриваем Noda как экспертную систему нового поколения.
Она объединяет наиболее сильные стороны современных больших языковых моделей и принципы классических экспертных систем.
От LLM Noda получает способность понимать естественный язык, учитывать контекст вопроса, объяснять сложные идеи и формулировать ответы в удобной для человека форме.
От классических экспертных систем она берет другой фундаментальный принцип: ответы должны строиться не на случайном массиве документов и не на догадках модели, а на контролируемой, структурированной и проверенной базе знаний.
LLM отвечает за понимание и диалог.
Канонические знания отвечают за смысл и достоверность.
Что изменилось
Сегодня практически любое значимое архитектурное решение сначала фиксируется в Noda.
Например:
- почему архитектура Memora8 устроена именно так;
- почему Reganta OS отказалась от классической модели процессов;
- почему единицей исполнения является модуль Sekura JS;
- как работает Firmware Kernel;
- как устроен планировщик модулей;
- как модули используют память процессора;
- каким должен быть жизненный цикл модуля;
- какие ограничения существуют у ISA Memora8;
- почему были отвергнуты альтернативные архитектурные подходы.
После обсуждения статья утверждается и становится канонической.
С этого момента именно она является источником знаний для разработчиков и подключенных AI-инструментов.
Это важно, потому что в сложном проекте недостаточно знать, что система работает определенным образом.
Нужно понимать, почему команда приняла именно такое решение.
AI не ищет — он обращается к знаниям
Большинство современных корпоративных AI-систем строится вокруг поиска по большому массиву документов.
В хранилище загружаются Wiki-страницы, переписки, PDF-файлы, старые спецификации и черновики. Затем система пытается найти наиболее подходящие фрагменты и на их основе сформировать ответ.
Проблема в том, что среди найденных материалов могут находиться устаревшие версии, противоречащие друг другу документы и решения, которые уже были отменены.
Мы пошли другим путем.
AI получает доступ не к случайному архиву, а к утвержденным каноническим статьям.
Если в базе знаний есть одна действующая статья о планировщике Reganta OS, AI не начинает собирать ответ из нескольких противоречивых версий документации.
Он использует решение, которое команда считает действующим.
В этом смысле Noda ближе не к интеллектуальному поиску, а к современной экспертной системе.
Но в отличие от старых экспертных систем пользователю не нужно изучать специальный интерфейс, выбирать правило из списка или формулировать точный машинный запрос.
Он задает обычный вопрос на естественном языке.
LLM понимает намерение пользователя, обращается к контролируемым знаниям и формирует понятный ответ.
Сильные стороны двух поколений систем
У классических экспертных систем была важная особенность: они работали с явно заданными знаниями.
Эксперты формировали правила, определяли допустимые выводы и контролировали область компетенции системы.
Такие системы могли быть надежными в узкой предметной области, но были сложными в наполнении и неудобными во взаимодействии.
Современные LLM решили проблему интерфейса.
Они умеют понимать неточные вопросы, поддерживать диалог, объяснять, сравнивать и адаптировать ответ под пользователя.
Но сами по себе они не гарантируют, что ответ соответствует актуальному решению конкретной команды.
Noda соединяет эти подходы.
Эксперт или команда контролирует содержание знаний.
LLM обеспечивает естественный доступ к этим знаниям.
Получается система, в которой интеллект модели не заменяет эксперта, а делает экспертные знания доступными для людей и программных инструментов.
Agile оказался не про Scrum
Самое интересное открытие произошло позже.
Когда знания становятся частью процесса разработки, многие Agile-практики начинают работать естественным образом.
Любое важное изменение проходит простой цикл:
- возникает архитектурная идея или проблема;
- команда обсуждает возможные решения;
- обновляется каноническая статья;
- решение реализуется в коде или HDL;
- запускаются тесты;
- проверяется соответствие реализации принятой архитектуре;
- знания уточняются по результатам разработки.
Получается непрерывная обратная связь между идеей, знанием, реализацией и проверкой.
Не потому, что этого требует Scrum.
А потому, что без такого цикла невозможно последовательно развивать сложную архитектуру.
Разработка процессора — это постоянное обучение
При создании собственного процессора Memora8 невозможно открыть один учебник и найти все готовые ответы.
Каждое решение рождает новые вопросы.
Почему именно такая инструкция?
Почему именно такой формат команды?
Почему такая модель памяти?
Почему именно такая архитектура Memora8?
Почему единицей исполнения является модуль?
Почему система не использует традиционные процессы?
Почему Firmware Kernel устроен именно так?
Ответы появляются в процессе исследований, экспериментов и реализации.
Но через полгода команда уже может не помнить всех деталей обсуждения.
Если эти знания не были сохранены, их приходится восстанавливать или получать заново.
Это означает повторные споры, повторные исследования и риск принять решение, которое противоречит уже существующей архитектуре.
Мы стараемся этого избегать.
Поэтому важная архитектурная идея сначала становится знанием, а затем — кодом.
Канонические знания как часть архитектуры
Обычно документацию воспринимают как описание уже написанной системы.
В нашем случае она становится частью самой архитектуры.
Каноническая статья определяет не только текущее поведение компонента, но и границы допустимых изменений.
Например, если зафиксировано, что единицей исполнения Reganta OS является модуль Sekura JS, новое решение должно либо соответствовать этому принципу, либо явно изменить канон.
Это делает архитектурные изменения видимыми.
Разработчик или AI-инструмент не должен самостоятельно догадываться, какое из нескольких решений является актуальным.
Он обращается к утвержденному знанию.
Так Noda становится связующим слоем между архитектурным замыслом, командой разработчиков и AI-инструментами.
Вместо вывода
После нескольких лет разработки мы пришли к неожиданному выводу.
Самый дорогой ресурс команды — не код.
И даже не время само по себе.
Самый дорогой ресурс — накопленные инженерные знания: принятые решения, отвергнутые альтернативы, ограничения и понимание причин, по которым система устроена именно так.
Именно поэтому Noda стала для нас не очередной Wiki и не поиском по документам.
Это экспертная система нового поколения, в которой лучшие идеи классических экспертных систем сочетаются с возможностями современных LLM. Вместо того чтобы пытаться извлечь истину из хаотичного массива документов, Noda предоставляет AI доступ к каноническим знаниям, которые формируются и утверждаются самой инженерной командой. LLM отвечает за понимание естественного языка и удобное взаимодействие с пользователем, а экспертная база знаний — за точность, последовательность и соответствие принятым архитектурным решениям.
Сегодня Noda развивается вместе с процессором Memora8, Reganta OS и Sekura JS, сохраняя архитектурные знания, которые невозможно восстановить только по исходному коду.
Возможно, именно такой подход и является современной интерпретацией идей Роберта Мартина.
Agile — это не набор церемоний.
Это способность команды быстро менять систему, не теряя качество, архитектурную целостность и понимание того, почему она устроена именно так.
Share
