The post has been translated automatically. Original language: Russian
Modern AI tools have learned how to write code in seconds.
They create functions.
They generate tests.
Explain the errors.
They offer architectural options.
Entire modules are being rewritten.
It seems that software development should have accelerated several times.
But in practice, teams still spend days and weeks agreeing on a single architectural change.
The code can already be received almost instantly.
But before you write it, you need to agree on which code is correct.
And after implementation, it is necessary to check whether the integrity of the entire system has been preserved.
Fred Brooks described this problem long before the advent of Git, cloud platforms, and large language models.
He called one of the main qualities of a complex system conceptual integrity.
AI accelerates implementation, but does not create a unified vision.
A large language model can offer several technically working solutions.
Each of them can be reasonable in itself.
But a complex system is not a simple sum of intelligent solutions.
All its parts must follow the same architectural design.
Processor.
The command system.
The compiler.
Programming language.
Firmware Kernel.
The operating system.
Development tools.
Each level can be well designed separately, but the entire platform will remain contradictory.
That is why the main problem of development is not only the complexity of writing code.
It consists in the need to maintain a general understanding of the system with each change.
AI has not fixed this issue yet.
In some cases, he even made it more noticeable.
The faster the code is created, the faster the architecture can collapse.
Previously, changing a large component took a considerable amount of time.
The developer studied the system.
Discussed the solution.
I was writing code.
I was checking the consequences.
The pace of work itself created a natural limitation.
Today, AI is able to change several files at once in a few minutes and propose the implementation of a new mechanism.
But if the model doesn't understand the architectural boundaries of the project, it can just as quickly spread the wrong solution throughout the system.
It turns out a paradox.
AI reduces the cost of writing code.
But at the same time, it increases the cost of an architectural error.
The faster an implementation is created, the more important it is to determine in advance a single canon to which it should correspond.
We saw this during the development of Memora8.
We are developing the Memora8 processor, the Reganta OS operating system, the Sekura JS programming language and related tools.
At first glance, it can be perceived as several separate projects.
In practice, this is a single computing platform.
A change at one level almost always affects others.
A new processor instruction may require a change in the ISA.
The ISA change is reflected in the compiler.
The compiler defines the capabilities of Sekura JS.
The Sekura JS model is related to the work of the Firmware Kernel.
The Firmware Kernel defines how modules are prepared and run in Reganta OS.
One solution runs through the entire platform.
Therefore, writing code for one level is not enough.
It is necessary to verify that the solution remains consistent at all other levels.
One edit means multiple views.
Let's imagine that we are changing the mechanism of operation of a single Memora8 instruction.
For the processor team, this is a hardware implementation.
For the ISA, this is a formal description of the instruction's behavior.
For a compiler, this is a rule for generating machine code.
For Sekura JS, this is an accessible language semantics.
For the Firmware Kernel, this is part of the execution model.
For Reganta OS, this is the system behavior.
For tests, this is a new set of verifiable conditions.
Each participant looks at one solution from their side.
And everyone can formulate it a little differently.
This is how several representations of the same idea appear.
As long as they match, the system remains intact.
When they start to diverge, there is an architectural debt.
Where is the team's time actually being wasted?
It usually seems like it takes time to implement.
But in a complex system, it can take much longer to coordinate.
The architect formulates the solution.
The processor developer clarifies the hardware limitations.
The compiler developer detects an ambiguity.
The language developer offers a different view.
The developer of the Firmware Kernel finds a conflict with the execution model.
The document is being returned for revision.
After the changes, it needs to be re-checked at all levels.
Then the implementation begins.
During the implementation, a new limitation is discovered.
The documentation is changing again.
After that, you need to check which components are already using the previous version of the solution.
One architectural edit can go through several full rounds of approval.
This is where days and weeks disappear.
Not in typing.
Not in writing the function.
It's about constantly restoring a common understanding.
Why doesn't the usual documentation solve the problem?
At first glance, the solution seems obvious.
We need to document the architecture better.
But the mere existence of documents does not create conceptual integrity.
The project can simultaneously exist:
- architectural description;
- ISA specification;
- compiler documentation;
- Language description;
- Firmware Kernel Documentation;
- Technical notes;
- Discussion history;
- outdated versions of solutions;
- comments in the code.
Each document can be correct at the time of creation.
But after a few changes, they start to diverge.
Then the team spends time not searching for information, but determining which document is valid.
The more documentation there is, the more potential points of inconsistency there are.
The problem is not the lack of documents.
The problem lies in the absence of a single object against which all implementations and explanations are checked.
Conceptual integrity requires canon
If the system is to maintain a single architectural design, the team must have a single valid description of this design.
There is no archive of discussions.
Not a set of peer-to-peer documents.
Not a random AI response.
And the canon.
The canon records:
- what decision has been made;
- why is it accepted;
- what restrictions does it set?;
- what levels of the system does it affect;
- which alternatives were rejected;
- what is considered an architectural violation;
- under what conditions should the decision be reviewed?
In this form, architectural knowledge becomes a point of agreement.
All participants can look at the system from different angles.
But they should work relative to the same canon.
This role is performed by Noda for us.
Noda originally appeared as an internal tool for working on Memora8, Reganta OS and Sekura JS.
It wasn't enough for us to keep the documents.
It was necessary to maintain existing engineering solutions.
In Noda, an architectural article becomes canonical after discussion and approval.
If the decision changes, the canon changes.
If the old solution is reversed, it should no longer compete with the new as a valid knowledge.
This allows you to separate the two types of information.
The discussion history shows how the team came to a decision.
The canon shows which solution is in effect now.
Both types of information are needed for development.
But the canon should remain the source of the current architecture.
A new development cycle
In the article about Peter Naur, the main question was as follows:
What is wrong, the theory or its implementation?
Fred Brooks gets a different accent.:
Does the new solution preserve the conceptual integrity of the entire system?
The development cycle looks like this:
Idea → Discussion with LLM → Canon in Noda → Checking the impact on all levels of the platform → Implementation → General analysis → Fix the canon or implementation → Next iteration
Here, Noda is not just used to preserve theory.
It becomes a single object of coordination between different levels of the system.
LLM helps to analyze the consequences.
The engineer makes the decision.
The canon captures a single architectural design.
Each level implements its own part of this plan.
A general analysis checks whether there are any contradictions.
How does this cycle differ from a regular review?
A regular review most often checks a specific change.
Is the code written correctly?
Are there any mistakes?
Does it match the style of the project?
Are the tests working?
But conceptual integrity requires a broader question.:
Is the change consistent with the overall architecture of the system?
The code can be of high quality.
Tests can be run.
The component may be working correctly.
However, this solution may violate the overall model of the platform.
For example, the new mechanism may create a dependency between levels that should remain independent.
It may duplicate an existing responsibility.
It can change the semantics of the language without changing the ISA accordingly.
It can make the Firmware Kernel know the details that should belong to the Sekura JS module.
Such errors are not always detected by regular tests.
They are found only when comparing the implementation with the architectural canon.
The role of LLM in the Brooks cycle
LLM is especially useful when analyzing the impact of changes.
You can ask her questions.:
Which components are affected by this decision?
Does it contradict the existing execution model?
What dependencies can appear?
What needs to be changed in the ISA?
Does the new interface comply with the principles of architecture?
Which canonical articles will need to be reviewed?
But the LLM should not independently declare the architectural solution correct.
It helps to identify contradictions and consider the consequences.
The responsibility for the conceptual integrity remains with the architect.
A separation of roles is obtained:
LLM helps you analyze connections.
The author makes an architectural decision.
Noda fixes the solution as a canon.
The code implements the canon at each level.
The analysis verifies the integrity of the entire platform.
A single developer also faces the problem of matching
It can be assumed that Brooks' problem applies only to large teams.
If one person designs the processor, language, and operating system, they don't need to coordinate decisions with dozens of colleagues.
But in single-player development, the problem does not disappear.
It changes shape.
One engineer consistently performs several roles.
Today, he designs the processor instruction.
Tomorrow he looks at it as a compiler developer.
Then as the author of the language.
Later as a developer of the Firmware Kernel.
Each role has its own limitations and interests.
In fact, coordination does not take place between several people, but between several contexts of the author's thinking.
And here the risk of misalignment may be even higher.
There is no independent architect who will notice the contradiction.
There is no separate documentation team.
There is no mandatory inter-team review process.
The decision may change in the author's mind, but remain the same in one of the components.
Therefore, a single engineer needs a single canon no less than a large team.
Iterative work of a loner
With a single development, the cycle may look like this:
Architectural idea → Discussion with ChatGPT → Formation of the canon in Noda → Impact analysis on Memora8, ISA, Compiler, Sekura JS, Firmware Kernel and Reganta OS → Implementation → Integrity Check → Canon fix or affected components → New iteration
ChatGPT helps you switch between roles in this cycle.
You can ask the model to consider the solution as a processor developer.
Then as the compiler author.
Then as a language developer.
Then as an operating system architect.
But the outcome of the discussion should not remain inside the chat.
It is being translated into the canon.
It is the canon that allows one person to return to the solution after a few months and understand not only what was implemented, but also how different levels of the platform should be consistent with each other.
One instruction is one canon, not seven independent documents.
This does not mean that all the information needs to be put in one huge article.
Different levels can still have their own specifications.
But the architectural solution must have a single canonical center.
It defines common semantics and relationships.
Specialized documents reveal the implementation at a specific level.
This eliminates the situation when seven documents independently describe one solution and gradually begin to contradict each other.
All of them should refer to the same valid architectural canon.
If the canon changes, it becomes clear which views need to be checked and updated.
How Noda and LLM reduce matching
LLM alone does not eliminate the cost of approval.
If you give her contradictory documents, she will only accelerate the creation of new contradictory answers.
Noda by itself does not eliminate matching either.
If the team does not make decisions and does not support the canon, the knowledge base turns into another archive.
The effect appears when they are used together.
First, the participants discuss the solution using LLM.
Then the result is translated into canonical form.
After that, the LLM gets access to the current canon and helps analyze the consequences for different levels of the system.
The team does not coordinate each copy of the document separately.
It coordinates a single architectural solution.
This is what reduces the number of repeated cycles.
You don't have to rebuild the context from scratch every time.
There is no need to redefine which version is current.
There is no need to ask each participant to interpret the discussion history on their own.
What to fix after the analysis
After implementation and analysis, several results are possible.
The implementation violates the canon
The architectural solution remains valid.
One or more components implemented it incorrectly.
The code is being fixed.
The canon is incomplete
During the implementation, a limitation was discovered that was not taken into account.
The canon is being clarified.
After that, all affected levels are checked.
The canon is contradictory
The decision is interpreted differently at different levels.
Necessary eliminate ambiguity in architectural knowledge itself.
Only after that, the implementation continues.
The architectural idea is wrong
Practice has shown that the decision destroys the integrity of the platform or creates unacceptable dependencies.
The canon is being revised.
Then a new iteration is started.
This way, the analysis stops being just a search for errors in the code.
It becomes a test of the overall architecture.
AI is not a silver bullet
One of Brooks' most famous ideas is that there is no single technology that will radically eliminate the essential complexity of software development.
LLMs are really changing development.
But they do not negate the need to understand the subject area.
They do not eliminate architectural compromises.
They do not accept responsibility for long-term consequences.
They do not automatically create a unified system design.
They can speed up the work with already formed knowledge.
They can help identify a contradiction.
They can explain the decision to different participants.
They can generate an implementation.
But conceptual integrity still requires authorship.
Someone has to determine what kind of system it is.
Someone has to make a decision.
Someone has to maintain the canon.
What is really changing
AI did not solve the main problem of development automatically.
But he provided the tools with which it can be solved in a new way.
Previously, architectural coordination required numerous meetings, correspondence, documents, and manual context transfer.
The LLM can now help each participant to get an explanation of the canon in its professional context.
The processor developer gets the hardware side of the solution.
Compiler developer — requirements for code generation.
The author of Sekura JS is the semantics of language.
The developer of the Firmware Kernel — the consequences for the execution of modules.
But all these explanations are based on the same established knowledge.
LLM adapts the form.
The canon retains its meaning.
From documentation to a single approval object
This is the main change in the role of Noda.
It is not just used as a documentation base.
And not only as a project memory.
It becomes a single object for coordinating architectural solutions.
Before the canon appeared, coordination took place between people and documents.
After the appearance of the canon, the participants coordinate their implementations regarding one common solution.
This does not eliminate the need for discussion.
But it reduces the number of repeated discussions.
It does not eliminate architectural errors.
But it makes them more noticeable.
It does not replace the author of the system.
But it helps to preserve the idea he created.
Fred Brooks was right in the age of AI, too.
Today, code is being created faster than ever.
But complex projects are still delayed.
It's not because developers are slow to type.
This is because changes need to be coordinated with architecture, people, and existing solutions.
The more components and participants there are, the higher the cost of synchronization.
The faster AI generates code, the greater the gap between the speed of implementation and the speed of achieving a common understanding.
Therefore, the real challenge of AI-native development is not only to speed up program writing.
It consists in speeding up work with a single architectural design.
Instead of output
Fred Brooks wrote about conceptual integrity long before the advent of modern AI tools.
Today, his idea has become even more important.
AI can quickly create locally correct solutions.
But locally correct solutions do not guarantee the integrity of the entire system.
When developing Memora8, Reganta OS, and Sekura JS, we came to a cycle in which the architectural canon becomes the center of alignment.:
Idea → Discussion with LLM → Canon in Noda → Impact analysis on all levels of the system → Implementation → Conceptual integrity check → Canon or implementation correction → Next iteration
In the article about Peter Naur, the canon preserved the theory of the program.
In the Brooks cycle, he performs a different task.
It allows all levels of the system to remain parts of the same architectural design.
AI did not solve the main problem of development automatically.
He accelerated the creation of code, but did not create conceptual integrity.
However, in combination with the canonical knowledge base, LLM can reduce the cost of approval, help identify contradictions, and make a unified architectural design accessible to each development participant.
Perhaps the next big leap in development won't happen when AI learns how to write even more code.
It will happen when the engineering teams learn to coordinate the knowledge from which this code comes just as quickly.
Современные AI-инструменты научились писать код за секунды.
Они создают функции.
Генерируют тесты.
Объясняют ошибки.
Предлагают архитектурные варианты.
Переписывают целые модули.
Кажется, что разработка программного обеспечения должна была ускориться в несколько раз.
Но на практике команды по-прежнему тратят дни и недели на согласование одного архитектурного изменения.
Код уже можно получить почти мгновенно.
Но прежде чем его писать, нужно договориться, какой именно код является правильным.
И после реализации нужно проверить, сохранилась ли целостность всей системы.
Эту проблему Фред Брукс описывал задолго до появления Git, облачных платформ и больших языковых моделей.
Он называл одно из главных качеств сложной системы концептуальной целостностью.
AI ускоряет реализацию, но не создает единого замысла
Большая языковая модель может предложить несколько технически работающих решений.
Каждое из них может быть разумным само по себе.
Но сложная система не является простой суммой разумных решений.
Все ее части должны подчиняться одному архитектурному замыслу.
Процессор.
Система команд.
Компилятор.
Язык программирования.
Firmware Kernel.
Операционная система.
Инструменты разработки.
Каждый уровень может быть хорошо спроектирован отдельно, но вся платформа при этом останется противоречивой.
Именно поэтому главная проблема разработки заключается не только в сложности написания кода.
Она заключается в необходимости сохранять общее понимание системы при каждом изменении.
AI пока не устранил эту проблему.
В некоторых случаях он даже сделал ее заметнее.
Чем быстрее создается код, тем быстрее может разрушаться архитектура
Раньше изменение большого компонента требовало значительного времени.
Разработчик изучал систему.
Обсуждал решение.
Писал код.
Проверял последствия.
Сам темп работы создавал естественное ограничение.
Сегодня AI способен за несколько минут изменить сразу несколько файлов и предложить реализацию нового механизма.
Но если модель не понимает архитектурных границ проекта, она может так же быстро распространить неверное решение по всей системе.
Получается парадокс.
AI сокращает стоимость написания кода.
Но одновременно повышает стоимость архитектурной ошибки.
Чем быстрее создается реализация, тем важнее заранее определить единый канон, которому она должна соответствовать.
Мы увидели это при разработке Memora8
Мы разрабатываем процессор Memora8, операционную систему Reganta OS, язык программирования Sekura JS и связанные с ними инструменты.
На первый взгляд это можно воспринимать как несколько отдельных проектов.
На практике это одна вычислительная платформа.
Изменение на одном уровне почти всегда влияет на другие.
Новая инструкция процессора может потребовать изменения ISA.
Изменение ISA отражается на компиляторе.
Компилятор определяет возможности Sekura JS.
Модель Sekura JS связана с работой Firmware Kernel.
Firmware Kernel определяет, как модули подготавливаются и запускаются в Reganta OS.
Одно решение проходит через всю платформу.
Поэтому написать код для одного уровня недостаточно.
Необходимо проверить, что решение остается согласованным на всех остальных уровнях.
Одна правка — несколько представлений
Представим, что мы меняем механизм работы одной инструкции Memora8.
Для команды процессора это аппаратная реализация.
Для ISA это формальное описание поведения инструкции.
Для компилятора это правило генерации машинного кода.
Для Sekura JS это доступная семантика языка.
Для Firmware Kernel это часть модели исполнения.
Для Reganta OS это системное поведение.
Для тестов это новый набор проверяемых условий.
Каждый участник смотрит на одно решение со своей стороны.
И каждый может сформулировать его немного иначе.
Так появляются несколько представлений одной идеи.
Пока они совпадают, система сохраняет целостность.
Когда они начинают расходиться, возникает архитектурный долг.
Где на самом деле теряется время команды
Обычно кажется, что время уходит на реализацию.
Но в сложной системе гораздо больше времени может занимать согласование.
Архитектор формулирует решение.
Разработчик процессора уточняет аппаратные ограничения.
Разработчик компилятора обнаруживает неоднозначность.
Разработчик языка предлагает другое представление.
Разработчик Firmware Kernel находит конфликт с моделью исполнения.
Документ возвращается на доработку.
После изменений его нужно повторно проверить на всех уровнях.
Затем начинается реализация.
Во время реализации обнаруживается новое ограничение.
Документация снова меняется.
После этого необходимо проверить, какие компоненты уже используют предыдущую версию решения.
Одна архитектурная правка может пройти несколько полных кругов согласования.
Именно здесь исчезают дни и недели.
Не в наборе текста.
Не в написании функции.
А в постоянном восстановлении общего понимания.
Почему обычная документация не решает проблему
На первый взгляд решение кажется очевидным.
Нужно лучше документировать архитектуру.
Но само наличие документов еще не создает концептуальную целостность.
В проекте могут одновременно существовать:
- архитектурное описание;
- спецификация ISA;
- документация компилятора;
- описание языка;
- документация Firmware Kernel;
- технические заметки;
- история обсуждений;
- устаревшие версии решений;
- комментарии в коде.
Каждый документ может быть правильным в момент создания.
Но после нескольких изменений они начинают расходиться.
Тогда команда тратит время уже не на поиск информации, а на определение того, какой документ является действующим.
Чем больше документации, тем больше потенциальных точек рассогласования.
Проблема заключается не в отсутствии документов.
Проблема заключается в отсутствии одного объекта, относительно которого проверяются все реализации и объяснения.
Концептуальная целостность требует канона
Если система должна сохранять единый архитектурный замысел, у команды должно существовать единое действующее описание этого замысла.
Не архив обсуждений.
Не набор равноправных документов.
Не случайный ответ AI.
А канон.
Канон фиксирует:
- какое решение принято;
- почему оно принято;
- какие ограничения оно устанавливает;
- какие уровни системы оно затрагивает;
- какие альтернативы были отвергнуты;
- что считается нарушением архитектуры;
- при каких условиях решение должно быть пересмотрено.
В таком виде архитектурное знание становится точкой согласования.
Все участники могут смотреть на систему с разных сторон.
Но они должны работать относительно одного канона.
Такую роль для нас выполняет Noda
Noda изначально появилась как внутренний инструмент для работы над Memora8, Reganta OS и Sekura JS.
Нам было недостаточно хранить документы.
Нужно было сохранять действующие инженерные решения.
В Noda архитектурная статья становится канонической после обсуждения и утверждения.
Если решение меняется, изменяется канон.
Если старое решение отменено, оно больше не должно конкурировать с новым в качестве действующего знания.
Это позволяет отделить два типа информации.
История обсуждения показывает, как команда пришла к решению.
Канон показывает, какое решение действует сейчас.
Для разработки необходимы оба типа информации.
Но источником текущей архитектуры должен оставаться именно канон.
Новый цикл разработки
В статье о Питере Науре основной вопрос звучал так:
Что неверно — теория или ее реализация?
У Фреда Брукса появляется другой акцент:
Сохраняет ли новое решение концептуальную целостность всей системы?
Цикл разработки выглядит так:
Идея → Обсуждение с LLM → Канон в Noda → Проверка влияния на все уровни платформы → Реализация → Общий анализ → Исправить канон или реализацию → Следующая итерация
Здесь Noda используется не просто для сохранения теории.
Она становится единым объектом согласования между разными уровнями системы.
LLM помогает анализировать последствия.
Инженер принимает решение.
Канон фиксирует единый архитектурный замысел.
Каждый уровень реализует свою часть этого замысла.
А общий анализ проверяет, не возникло ли противоречий.
Чем этот цикл отличается от обычного ревью
Обычное ревью чаще всего проверяет конкретное изменение.
Правильно ли написан код?
Есть ли ошибки?
Соответствует ли он стилю проекта?
Работают ли тесты?
Но концептуальная целостность требует более широкого вопроса:
Соответствует ли изменение общей архитектуре системы?
Код может быть качественным.
Тесты могут проходить.
Компонент может работать правильно.
Но при этом решение может нарушать общую модель платформы.
Например, новый механизм может создавать зависимость между уровнями, которые должны оставаться независимыми.
Он может дублировать уже существующую ответственность.
Он может изменить семантику языка без соответствующего изменения ISA.
Он может заставить Firmware Kernel знать детали, которые должны принадлежать модулю Sekura JS.
Такие ошибки не всегда обнаруживаются обычными тестами.
Они обнаруживаются только при сравнении реализации с архитектурным каноном.
Роль LLM в цикле Брукса
LLM особенно полезна при анализе влияния изменений.
Ей можно задавать вопросы:
Какие компоненты затрагивает это решение?
Противоречит ли оно существующей модели исполнения?
Какие зависимости могут появиться?
Что необходимо изменить в ISA?
Соответствует ли новый интерфейс принципам архитектуры?
Какие канонические статьи потребуется пересмотреть?
Но LLM не должна самостоятельно объявлять архитектурное решение правильным.
Она помогает выявлять противоречия и рассматривать последствия.
Ответственность за концептуальную целостность остается у автора архитектуры.
Получается разделение ролей:
LLM помогает анализировать связи.
Автор принимает архитектурное решение.
Noda фиксирует решение как канон.
Код реализует канон на каждом уровне.
Анализ проверяет целостность всей платформы.
Одиночный разработчик тоже сталкивается с проблемой согласования
Можно предположить, что проблема Брукса относится только к большим командам.
Если один человек проектирует процессор, язык и операционную систему, ему не нужно согласовывать решения с десятками коллег.
Но в одиночной разработке проблема не исчезает.
Она меняет форму.
Один инженер последовательно выполняет несколько ролей.
Сегодня он проектирует инструкцию процессора.
Завтра смотрит на нее как разработчик компилятора.
Затем как автор языка.
Позже как разработчик Firmware Kernel.
Каждая роль имеет собственные ограничения и интересы.
Фактически согласование происходит не между несколькими людьми, а между несколькими контекстами мышления одного автора.
И здесь риск рассогласования может быть еще выше.
Нет независимого архитектора, который заметит противоречие.
Нет отдельной команды документации.
Нет обязательного процесса межкомандного ревью.
Решение может измениться в голове автора, но остаться прежним в одном из компонентов.
Поэтому одиночному инженеру единый канон нужен не меньше, чем большой команде.
Итеративная работа одиночки
При одиночной разработке цикл может выглядеть так:
Архитектурная идея → Обсуждение с ChatGPT → Формирование канона в Noda → Анализ влияния на Memora8, ISA, компилятор, Sekura JS, Firmware Kernel и Reganta OS → Реализация → Проверка целостности → Исправление канона или затронутых компонентов → Новая итерация
ChatGPT в этом цикле помогает переключаться между ролями.
Можно попросить модель рассмотреть решение как разработчик процессора.
Затем как автор компилятора.
Затем как разработчик языка.
Затем как архитектор операционной системы.
Но итог обсуждения не должен оставаться внутри чата.
Он переводится в канон.
Именно канон позволяет одному человеку через несколько месяцев вернуться к решению и понять не только то, что было реализовано, но и то, как разные уровни платформы должны согласовываться между собой.
Одна инструкция — один канон, а не семь независимых документов
Это не означает, что все сведения нужно поместить в одну огромную статью.
Разные уровни по-прежнему могут иметь собственные спецификации.
Но у архитектурного решения должен существовать единый канонический центр.
Он определяет общую семантику и связи.
Специализированные документы раскрывают реализацию на конкретном уровне.
Так исчезает ситуация, когда семь документов независимо описывают одно решение и постепенно начинают противоречить друг другу.
Все они должны ссылаться на один действующий архитектурный канон.
Если канон меняется, становится понятно, какие представления необходимо проверить и обновить.
Как Noda и LLM сокращают согласование
LLM сама по себе не устраняет стоимость согласования.
Если дать ей противоречивые документы, она только ускорит создание новых противоречивых ответов.
Noda сама по себе тоже не устраняет согласование.
Если команда не принимает решений и не поддерживает канон, база знаний превращается в очередной архив.
Эффект появляется при их совместном использовании.
Сначала участники обсуждают решение с помощью LLM.
Затем итог переводится в каноническую форму.
После этого LLM получает доступ к действующему канону и помогает анализировать последствия для разных уровней системы.
Команда согласовывает не каждую копию документа отдельно.
Она согласовывает единое архитектурное решение.
Именно это сокращает количество повторных циклов.
Не нужно каждый раз восстанавливать контекст с нуля.
Не нужно заново определять, какая версия является актуальной.
Не нужно просить каждого участника самостоятельно интерпретировать историю обсуждения.
Что исправлять после анализа
После реализации и анализа возможны несколько результатов.
Реализация нарушает канон
Архитектурное решение остается действующим.
Один или несколько компонентов реализовали его неправильно.
Исправляется код.
Канон неполон
Во время реализации обнаружилось ограничение, которое не было учтено.
Канон уточняется.
После этого проверяются все затронутые уровни.
Канон противоречив
Решение по-разному трактуется на разных уровнях.
Необходимо устранить неоднозначность в самом архитектурном знании.
Только после этого продолжается реализация.
Архитектурная идея неверна
Практика показала, что принятое решение разрушает целостность платформы или создает неприемлемые зависимости.
Канон пересматривается.
Затем запускается новая итерация.
Так анализ перестает быть только поиском ошибок в коде.
Он становится проверкой общей архитектуры.
AI не является серебряной пулей
Одна из самых известных идей Брукса заключается в том, что не существует единственной технологии, которая радикально устранит сущностную сложность разработки программного обеспечения.
LLM действительно меняют разработку.
Но они не отменяют необходимость понимать предметную область.
Не устраняют архитектурные компромиссы.
Не принимают ответственность за долгосрочные последствия.
Не создают автоматически единый замысел системы.
Они могут ускорить работу с уже сформированным знанием.
Могут помочь выявить противоречие.
Могут объяснить решение разным участникам.
Могут сгенерировать реализацию.
Но концептуальная целостность по-прежнему требует авторства.
Кто-то должен определить, какой является система.
Кто-то должен принять решение.
Кто-то должен поддерживать канон.
Что действительно меняется
AI не решил главную проблему разработки автоматически.
Но он дал инструменты, с помощью которых ее можно решать по-новому.
Раньше архитектурное согласование требовало многочисленных встреч, переписок, документов и ручной передачи контекста.
Теперь LLM может помочь каждому участнику получить объяснение канона в его профессиональном контексте.
Разработчик процессора получает аппаратную сторону решения.
Разработчик компилятора — требования к генерации кода.
Автор Sekura JS — семантику языка.
Разработчик Firmware Kernel — последствия для исполнения модулей.
Но все эти объяснения строятся относительно одного утвержденного знания.
LLM адаптирует форму.
Канон сохраняет смысл.
От документации к единому объекту согласования
В этом заключается главное изменение роли Noda.
Она используется не просто как база документации.
И не только как память проекта.
Она становится единым объектом согласования архитектурных решений.
До появления канона согласование происходило между людьми и документами.
После появления канона участники согласовывают свои реализации относительно одного общего решения.
Это не устраняет необходимость обсуждения.
Но уменьшает количество повторных обсуждений.
Не устраняет архитектурные ошибки.
Но делает их заметнее.
Не заменяет автора системы.
Но помогает сохранить созданный им замысел.
Фред Брукс оказался прав и в эпоху AI
Сегодня код создается быстрее, чем когда-либо.
Но сложные проекты по-прежнему задерживаются.
Не потому, что разработчики медленно печатают.
А потому, что изменения необходимо согласовать с архитектурой, людьми и уже существующими решениями.
Чем больше компонентов и участников, тем выше стоимость синхронизации.
Чем быстрее AI генерирует код, тем сильнее становится разрыв между скоростью реализации и скоростью достижения общего понимания.
Поэтому настоящая задача AI-native разработки состоит не только в ускорении написания программ.
Она состоит в ускорении работы с единым архитектурным замыслом.
Вместо вывода
Фред Брукс писал о концептуальной целостности задолго до появления современных AI-инструментов.
Сегодня его идея стала еще важнее.
AI умеет быстро создавать локально правильные решения.
Но локально правильные решения не гарантируют целостности всей системы.
При разработке Memora8, Reganta OS и Sekura JS мы пришли к циклу, в котором архитектурный канон становится центром согласования:
Идея → Обсуждение с LLM → Канон в Noda → Анализ влияния на все уровни системы → Реализация → Проверка концептуальной целостности → Исправление канона или реализации → Следующая итерация
В статье о Питере Науре канон сохранял теорию программы.
В цикле Брукса он выполняет другую задачу.
Он позволяет всем уровням системы оставаться частями одного архитектурного замысла.
AI не решил главную проблему разработки автоматически.
Он ускорил создание кода, но не создал концептуальную целостность.
Однако в сочетании с канонической базой знаний LLM может сократить стоимость согласования, помочь выявлять противоречия и сделать единый архитектурный замысел доступным каждому участнику разработки.
Возможно, следующий большой скачок в разработке произойдет не тогда, когда AI научится писать еще больше кода.
Он произойдет тогда, когда инженерные команды научатся так же быстро согласовывать знания, из которых этот код появляется.
Share
