The post has been translated automatically. Original language: Russian
In 1975, Fred Brooks published the book The Mythical Man-Month, which is still considered one of the most important works on software engineering.
Most people know her from her famous thought: if a project is behind schedule, adding new developers makes it even later.
But there is another idea of Brooks, which, in my opinion, turned out to be much more important.
He called it conceptual integrity.
The most difficult part of the system
Brooks argued that good engineering systems should look like they were created by one person.
Not because one engineer is capable of writing millions of lines of code.
This is because the system must have a single architectural design.
Each new solution should continue the existing architecture, rather than create its own.
When this principle is violated, the system begins to gradually disintegrate.
Each change looks reasonable on its own.
But after a few years, it turns out that the architecture consists of dozens of locally correct solutions that don't mix well with each other.
We came across this during the development of Memora8.
We are developing our own Memora8 processor, the Reganta OS operating system, the Sekura JS programming language, and related tools.
At first glance, it seems that these are several separate projects.
It's actually a single computing platform.
Changing the processor instruction may affect the compiler.
Change the compiler to the language.
The language change is to the Firmware Kernel.
Changing the core to the application execution model.
As a result, one architectural solution runs through the entire platform.
That is why it is not enough for us to store only the source code.
The code does not store the intent
A year after the implementation of the new processor instruction, you can open the repository and see how it works.
But it is impossible to understand:
Why did you choose this option?
What alternatives were discussed?
Why were they abandoned?
What restrictions appeared after this decision?
What architectural principles should not be violated in the future?
The source code rarely answers such questions.
But they determine the development of the project.
Why the Wiki wasn't enough
Like many teams, we used Markdown, Wiki, specifications, and technical documentation.
There were more and more documents.
But that didn't mean there was more understanding.
Different versions of the same idea appeared.
Drafts.
Outdated solutions.
Conflicting articles.
At some point, the developers started asking each other instead of the documentation.
We realized that the problem is not the amount of knowledge.
The problem is that there is no single canon.
That's how Noda appeared.
Noda was originally created as an internal development tool for Memora8, Reganta OS, and Sekura JS.
Her task was unexpectedly simple.
Do not store all documents.
And keep only current knowledge.
Every important architectural idea is discussed.
After that, one canonical article appears.
It becomes the official description of the architectural solution.
If the decision changes, the canon changes.
If an article is outdated, it is no longer valid.
This turned out to be much more important than the ability to search thousands of documents at once.
A new generation expert system
Classical expert systems were built around a proven knowledge base.
Modern large language models are able to understand natural language, conduct a dialogue and explain complex things.
We decided to combine these approaches.
In Noda, the language model does not try to independently determine which of several versions of the documentation is correct.
She gets access only to approved canonical knowledge.
It turns out to be a kind of new-generation expert system.
The expert still makes architectural decisions.
The team is still validating the knowledge.
LLM makes this knowledge available to developers and AI tools through ordinary natural language conversation.
Conceptual integrity in the age of AI
Today, more and more code is being created using AI.
It really speeds up development.
But a new problem arises.
If the AI gets a contradictory context, it starts generating contradictory solutions.
The faster code generation becomes, the more important the quality of the knowledge on which this code is based becomes.
Therefore, we do not consider Noda as a documentation search engine.
Its task is to maintain the conceptual integrity of the entire platform.
When a developer or AI asks why Reganta OS uses a modular execution model or why Memora8 implements instructions in this way, the answer is based not on random documents, but on approved architectural knowledge.
Brooks was right.
Reading Fred Brooks today, you realize how modern his ideas sound.
He wrote about conceptual integrity long before the advent of Git, cloud services, and large language models.
But the problem itself has not changed.
Complex engineering systems don't fall apart because developers don't write code well.
They fall apart when the team ceases to understand the architecture equally.
Instead of output
When developing Memora8, Reganta OS, and Sekura JS, we came to an unexpected conclusion.
The most valuable asset of a project is not the source code.
And not even the documentation.
The most valuable asset is a unified understanding of the system by the whole team.
It is this understanding that allows us to maintain the conceptual integrity that Fred Brooks wrote about.
For us, Noda has become a way to make this architectural concept explicit, testable, and accessible to both engineers and modern AI tools.
Half a century has passed since the release The Mythical Man-Month, but Fred Brooks' main conclusion remains relevant: it's not the amount of code that holds a complex system together, but the integrity of the ideas it's built on.
В 1975 году Фред Брукс опубликовал книгу The Mythical Man-Month, которая до сих пор считается одной из важнейших работ по инженерии программного обеспечения.
Большинство знает ее по знаменитой мысли: если проект отстает от графика, добавление новых разработчиков делает его еще более поздним.
Но есть другая идея Брукса, которая, на мой взгляд, оказалась гораздо важнее.
Он называл ее концептуальной целостностью.
Самая сложная часть системы
Брукс утверждал, что хорошие инженерные системы должны выглядеть так, словно их создал один человек.
Не потому, что один инженер способен написать миллионы строк кода.
А потому, что у системы должен существовать единый архитектурный замысел.
Каждое новое решение должно продолжать уже существующую архитектуру, а не создавать собственную.
Когда этот принцип нарушается, система начинает постепенно распадаться.
Каждое изменение выглядит разумным само по себе.
Но через несколько лет оказывается, что архитектура состоит из десятков локально правильных решений, которые плохо сочетаются друг с другом.
Мы столкнулись с этим при разработке Memora8
Мы разрабатываем собственный процессор Memora8, операционную систему Reganta OS, язык программирования Sekura JS и сопутствующие инструменты.
На первый взгляд кажется, что это несколько отдельных проектов.
На самом деле это одна вычислительная платформа.
Изменение инструкции процессора может повлиять на компилятор.
Изменение компилятора — на язык.
Изменение языка — на Firmware Kernel.
Изменение ядра — на модель исполнения приложений.
В результате одно архитектурное решение проходит через всю платформу.
Именно поэтому нам недостаточно хранить только исходный код.
Код не хранит замысел
Через год после реализации новой инструкции процессора можно открыть репозиторий и увидеть, как она работает.
Но невозможно понять:
Почему выбрали именно этот вариант?
Какие альтернативы обсуждались?
Почему от них отказались?
Какие ограничения появились после этого решения?
Какие архитектурные принципы нельзя нарушать в будущем?
Исходный код редко отвечает на подобные вопросы.
А ведь именно они определяют развитие проекта.
Почему Wiki оказалось недостаточно
Мы, как и многие команды, использовали Markdown, Wiki, спецификации и техническую документацию.
Документов становилось все больше.
Но это не означало, что становилось больше понимания.
Появлялись разные версии одной идеи.
Черновики.
Устаревшие решения.
Противоречащие друг другу статьи.
В какой-то момент разработчики начинали спрашивать не документацию, а друг друга.
Мы поняли, что проблема не в количестве знаний.
Проблема в отсутствии единого канона.
Так появилась Noda
Изначально Noda создавалась как внутренний инструмент для разработки Memora8, Reganta OS и Sekura JS.
Ее задача оказалась неожиданно простой.
Не хранить все документы.
А хранить только действующие знания.
Каждая важная архитектурная идея проходит обсуждение.
После этого появляется одна каноническая статья.
Именно она становится официальным описанием архитектурного решения.
Если решение меняется, меняется канон.
Если статья устарела, она перестает быть действующей.
Это оказалось гораздо важнее, чем возможность искать сразу по тысячам документов.
Экспертная система нового поколения
Классические экспертные системы строились вокруг проверенной базы знаний.
Современные большие языковые модели умеют понимать естественный язык, вести диалог и объяснять сложные вещи.
Мы решили объединить эти подходы.
В Noda языковая модель не пытается самостоятельно определить, какая из нескольких версий документации правильная.
Она получает доступ только к утвержденным каноническим знаниям.
Получается своеобразная экспертная система нового поколения.
Эксперт по-прежнему принимает архитектурные решения.
Команда по-прежнему утверждает знания.
LLM делает эти знания доступными разработчикам и AI-инструментам через обычный разговор на естественном языке.
Концептуальная целостность в эпоху AI
Сегодня все больше кода создается с помощью AI.
Это действительно ускоряет разработку.
Но возникает новая проблема.
Если AI получает противоречивый контекст, он начинает генерировать противоречивые решения.
Чем быстрее становится генерация кода, тем важнее становится качество знаний, на которых этот код основывается.
Поэтому мы рассматриваем Noda не как систему поиска по документации.
Ее задача — сохранять концептуальную целостность всей платформы.
Когда разработчик или AI спрашивает, почему Reganta OS использует модульную модель исполнения или почему в Memora8 инструкция реализована именно таким образом, ответ строится не из случайных документов, а из утвержденного архитектурного знания.
Брукс оказался прав
Читая Фреда Брукса сегодня, понимаешь, насколько современно звучат его идеи.
Он писал о концептуальной целостности задолго до появления Git, облачных сервисов и больших языковых моделей.
Но сама проблема не изменилась.
Сложные инженерные системы разваливаются не потому, что разработчики плохо пишут код.
Они разваливаются тогда, когда команда перестает одинаково понимать архитектуру.
Вместо вывода
При разработке Memora8, Reganta OS и Sekura JS мы пришли к неожиданному выводу.
Самым ценным активом проекта является не исходный код.
И даже не документация.
Самым ценным активом является единое понимание системы всей командой.
Именно это понимание позволяет сохранять концептуальную целостность, о которой писал Фред Брукс.
Для нас Noda стала способом сделать этот архитектурный замысел явным, проверяемым и доступным как инженерам, так и современным AI-инструментам.
Прошло полвека после выхода The Mythical Man-Month, но главный вывод Фреда Брукса остается актуальным: сложную систему удерживает вместе не количество кода, а целостность идей, на которых она построена.
Share
