The post has been translated automatically. Original language: Russian
When an experienced engineer makes a decision, he rarely starts with a complete formal proof.
Sometimes he immediately sees that a certain option is not suitable.
Notices a dangerous addiction.
He feels that the architecture will become unstable.
Understands that the proposed simplification will create more problems later than it will solve now.
When asked about the reason, he can answer:
"That's understandable enough."
"You can't do that."
"Practice shows that it won't work."
"The very model of the system is being violated here."
The engineer is often right.
But his understanding remains inside his head.
Another developer can't use it.
A new employee repeats an old mistake.
The documentation records the final decision, but does not explain why the alternatives were rejected.
The AI sees only the text and begins to complete the missing logic on its own.
This problem was investigated by the philosopher and scientist Michael Polanyi.
His key message is usually conveyed like this:
a person knows more than he is able to express directly in words.
Today, this idea is becoming especially important for corporate knowledge and development systems with LLM.
What is implicit knowledge?
Not all human knowledge exists in the form of rules and instructions.
The person recognizes the face, although he cannot list the exact signs by which he did it.
An experienced doctor notices an unusual pattern of symptoms before making a diagnosis.
The engineer hears the operation of the mechanism and realizes that something is wrong with it.
The program architect sees the solution and notices in advance where the unwanted connectivity will appear.
This does not mean that such knowledge is mystical or beyond analysis.
It is shaped by experience, observations, many special cases, and internal models.
But a person cannot always immediately decompose it into explicit statements.
Polanyi called this understanding implicit knowledge.
We use it all the time.
However, it is much more difficult to transfer it to another person than to apply it yourself.
Why does the documentation keep only the visible part?
Technical documentation usually records the result.
How the interface works.
Which parameters the function accepts.
Which instruction exists in the processor.
What features does the system provide?
How the module is launched.
But behind every such decision there are many questions.
Why does the interface have this exact shape?
What alternatives were considered?
What limitations were critical?
What kind of behavior is considered unacceptable?
What happens if you change one of the elements?
In which cases can the rule be revised?
What assumptions does the author consider so obvious that he didn't even write them down?
Without these answers, the document retains the form of a solution, but it does not always retain understanding.
The code also does not extract knowledge from the author's head.
The source code shows which solution has been implemented.
Sometimes you can use it to restore part of the idea.
But the code doesn't explain all the reasons.
Let's say there is no specific mechanism in the system.
It can be:
- a conscious architectural prohibition;
- time limit;
- the result of a lack of resources;
- an opportunity that has not yet been realized;
- an experimental solution;
- a consequence of another system principle.
It is impossible to reliably determine the reason for the absence in the code alone.
The LLM can analyze the implementation and offer a plausible explanation.
But plausibility does not guarantee that she has restored the author's real theory.
We are constantly faced with this during the development of Sekura.
Sekura is developing as a connected architectural platform.
It includes the Memora8 processor, Reganta OS, Sekura JS language, Firmware Kernel, system modules, and a streaming execution model.
Many solutions of this system differ from common approaches.
For example, a habitual developer may automatically expect classic processes, a preemptive scheduler, a traditional driver model, or standard component interaction mechanisms.
But Sekura is based on a different theory of execution.
The author of the system understands why certain familiar mechanisms are not suitable.
He sees connections between hardware architecture, memory model, modules, threads, and system contracts.
However, this understanding cannot be conveyed in one phrase.:
"Our processes are not used."
For reliable knowledge, it is necessary to disclose:
- why were they abandoned;
- what problem does the alternative model solve?;
- what advantages are expected;
- What new obligations do the modules have?;
- what are the limitations?;
- in what cases can the decision be reviewed?;
- why can't you just transfer the familiar model to another OS?
This is where the work with implicit knowledge begins.
The discussion history contains knowledge, but does not make it accessible.
During the conversation with the LLM, the engineer gradually formulates his model.
First he expresses an idea.
Then he responds to objections.
Clarifies the terms.
Corrects incorrect interpretations.
Compares the options.
Detects hidden assumptions.
At the end of the discussion, his understanding becomes much clearer.
But if the entire result remains in the chat history, the problem is not solved.
The dialog contains:
- the initial hypothesis;
- mistakes;
- rejected options;
- temporary formulations;
- contradictions;
- clarifications;
- the final decision.
The next AI tool does not have to go through the whole path again and independently determine which fragment is valid knowledge.
Implicit understanding doesn't just need to be discussed.
It needs to be turned into a canon.
LLM as a knowledge extraction tool
Classical expert systems faced the so-called bottleneck of knowledge extraction.
It was difficult for the expert to formalize everything he knows.
The knowledge engineer asked questions, observed the specialist's work, clarified the rules, and tried to turn the experience into a formal structure.
LLM radically simplifies this process.
She can have a long conversation.
Ask clarifying questions.
Offer counterexamples.
Show alternative interpretations.
To look for contradictions.
Ask to define the boundaries of the rule.
To help turn intuitive understanding into a consistent explanation.
The model does not create expert knowledge instead of human knowledge.
It helps a person to make his knowledge explicit.
What questions reveal hidden insights
Let's say the architect says:
"This module should work like firmware and should not be superseded."
The statement itself captures the solution.
But for a full-fledged canon, the LLM can continue its research.
Why can't the module be displaced?
Is it directly connected to the device?
What guarantees of execution time are needed?
Can it load other modules?
Does it support the full Reganta OS contract?
How does it exchange streams with the rest of the system?
What happens in case of an error?
Can a separate CPU group belong only to this task?
Where is the boundary between firmware, kernel, and system modules?
Which cases are the exceptions?
After such questions, the initial intuition turns into an architectural model.
Noda saves not the dialogue, but the extracted knowledge.
The Noda Task The goal is not to accumulate all the conversations with LLM.
The value is not in the number of discussions.
The value lies in the knowledge that has been extracted from them.
After the dialog, a canonical article is created.
She fixes:
- the decision taken;
- the meaning of the decision;
- reasons;
- scope of applicability;
- limitations;
- exceptions;
- links to other solutions;
- rejected assumptions, if they are important to understand;
- conditions for possible revision.
In this way, Noda becomes a layer between the expert's personal understanding and the subsequent use of knowledge by humans and AI.
Why is one final rule not enough?
Suppose the canon contains the phrase:
"Sekura JS modules are required to complete execution on their own after processing a unit of work."
This is a useful rule.
But AI can apply it incorrectly if it doesn't understand the context.
What is considered a unit of work?
How does the module report completion?
What happens if there is no new data yet?
Should the module terminate or go to sleep?
Is this usually due to the lack of a classical process?
Who is responsible for the relaunch?
How does it work in a cyclical flow?
Which system modules may have a different lifecycle?
Implicit knowledge is often hidden in these clarifications.
The expert perceives them as a single model.
But in the canon, the connections must be expressed explicitly.
Implicit constraints are more important than explicit features
Documentation often lists what the system can do.
But limitations are especially important for architecture.
What can not be done?
What assumptions are unacceptable?
What actions violate the model?
Where can you not use the usual approach?
When is the LLM obligated to stop and request a solution?
It is the constraints that often remain implicit.
The engineer simply does not consider the prohibited option, because he internally understands its incompatibility with the system.
AI has no such understanding.
If the prohibition is not expressed, the model may offer a technically plausible but architecturally unacceptable solution.
Example: A common solution is not a Sekura solution
Suppose the AI analyzes an execution planning task.
There are many typical approaches in common sources.
The model can suggest a process, an operating system thread that displaces a quantum, or a standard task pool.
Every suggestion will look reasonable.
But Sekura can use a different unit of execution and a different CPU release contract.
In order for AI not to transfer someone else's architecture automatically, the canon should contain not only a description of the operating mechanism.
He should explain it clearly.:
- which traditional assumptions don't apply here;
- why aren't they working;
- what replaced them;
- what obligations does the module assume?;
- how does the solution relate to the Reganta OS streaming model;
- which properties of Memora8 support this architecture.
This is how the implicit understanding of the author becomes available to the system.
A single developer is especially dependent on explicit knowledge
In a large team, some of the understanding can be restored through colleagues.
You can ask the author.
Hold a meeting.
Find the person who participated in the discussion.
A single developer does not have this option.
Today he remembers all the details.
After a year, some of the reasons will disappear from memory.
After three years, your own decision may look like someone else's.
At the same time, LLM allows one person to create systems that previously required a team.
The volume of decisions being made is growing.
Dependence on the author's memory becomes more dangerous.
Therefore, a single development needs a mechanism for systematically extracting knowledge from one's own head.
Polanyi Cycle for Sekura and Noda
This process can be represented as a separate cycle.
Intuitive understanding → Dialogue with LLM → Clarifying questions and counterexamples → Explicit formulation of the solution → Canon in Noda → Human or AI usage → Discovery of a new implicit assumption → Updating the canon
The main issue of the cycle:
What does the expert understand, but not yet expressed?
Sometimes the answer is discovered only after an AI error.
The model received the article, but interpreted it differently.
This does not always mean that the LLM does not reason well.
Perhaps the author assumed a condition that he never wrote down.
It was obvious to him.
Not for the external reader.
Then the wrong answer helps to reveal the hidden part of knowledge.
AI error as an interview with an expert
Usually, a model error is perceived as a defect.
But when working with the canonical database, it can perform a diagnostic function.
If the LLM systematically understands the article differently from the author, you need to ask:
What part of the meaning exists only in the author's head?
What connection was not expressed?
Which limitation was considered obvious?
Which term allows for a different interpretation?
What counterexample destroys the current formulation?
So the AI's response turns into a kind of interview with the owner of knowledge.
Each discrepancy shows where implicit understanding has not yet become canon.
Not all implicit knowledge can be fully formalized
It's important not to go to the other extreme.
It is impossible to guarantee that all the expert's experience will be completely transformed into text.
Some skills are formed only by practice.
Some decisions depend on the context.
Some signs are difficult to list in advance.
But this does not mean that the extraction attempt is useless.
Even partial fixation:
- reasons;
- restrictions;
- examples;
- Counterexamples;
- selection criteria;
- signs of risk;
- The limits of confidence
significantly improves the quality of knowledge transfer.
Noda is not obligated to replace a live expert.
It should preserve as much of his current understanding as possible and clearly define the boundaries where a human solution is required.
The possession of knowledge remains with the person
LLM can ask good questions.
Suggest formulations.
Detect logical gaps.
Compare articles.
Show contradictions.
But it should not independently approve the architectural canon.
The model is not responsible for the consequences of the decision.
It does not have the full implicit context of the author.
He does not know all the goals of the project.
It does not determine which compromise is acceptable.
Therefore, the roles must remain separate.
The expert has a substantive understanding.
LLM helps to explore and express it.
Noda saves the approved result.
Sekura develops based on this canon.
From personal knowledge to a scalable system
As long as the knowledge is only in the expert's head, it can be used by one person.
After it is fixed in the canon, it becomes available.:
- to other developers;
- to the future author;
- To the AI assistant;
- a code analysis tool;
- the module generator;
- architecture verification system;
- technical support;
- to users of the platform.
LLM scales access to knowledge.
But first, this knowledge must be extracted, purified, and validated.
It is Noda that makes the transition from personal understanding to a managed database.
The canon should store not only the answer, but also the method of discrimination.
Strong expert knowledge is not just a ready—made rule.
This is the ability to distinguish between suitable the case is from an unsuitable one.
Therefore, a good article should help to answer:
When does the rule apply?
When does it not apply?
What signs are important?
What are the secondary signs?
What similar cases require a different solution?
What information is needed to make a choice?
When is there not enough data?
This is especially important for AI.
Without discrimination criteria, the LLM may know the rule, but apply it too broadly.
An example of a knowledge structure for Sekura
Let's say a separate firmware module is described for a special task.
A full-fledged canon should contain more than just the statement that such modules are acceptable.
He has to explain:
- what special task do they solve?;
- why is a CPU or a CPU group allocated to this task?;
- what part of the Reganta OS contract does such a module support?;
- which system modules does it not load;
- how is the flow exchange carried out?;
- why can't the mechanism be considered an ordinary user module?;
- which hardware resources belong to the task;
- when is such an architecture justified?;
- when should a regular system module be used?
Such differences usually exist in the architect's understanding, but are absent from the brief technical description.
Noda as a continuation of the expert's work
Classic documentation is often created as a separate responsibility after making a decision.
In the Noda model, knowledge extraction becomes part of the engineering process itself.
The discussion with the LLM does not end with the choice of an option.
After selecting it, you need to check:
Was it possible to explain the reason?
Are the boundaries clear?
Are the hidden limitations expressed?
Are there any counterexamples?
Will another AI be able to apply this knowledge without the author's personal presence?
If not, the solution has not yet fully become canon.
Instead of output
Michael Polanyi has shown that human knowledge is much broader than what a person can immediately formulate.
For engineering systems, this means a simple but unpleasant conclusion.
Even if an expert has written documentation, most of his understanding may remain implicit.
The code preserves the implementation.
The article retains the wording.
But the reasons, differences, limitations, and criteria often continue to live only in the author's head.
LLM provides a new way to work with this problem.
She can become a patient conversationalist who asks questions, checks examples, suggests alternative interpretations, and helps discover hidden assumptions.
Noda turns the result of such a conversation into canonical knowledge.
Sekura uses this canon as the basis for the architecture, implementation, and operation of AI tools.
It turns out a new engineering cycle:
The expert knows more than he can immediately say → LLM helps to discover this → the author formulates a solution → Noda preserves the canon → Sekura develops based on it → new questions reveal the next layer of implicit knowledge.
This is how personal understanding stops disappearing along with the author's memory.
It becomes part of an evolving engineering system.
Сегодня многие говорят, что искусственный интеллект меняет программирование.
Наблюдая за этим, я часто вспоминаю другой технологический переход, который мне довелось пережить более тридцати лет назад.
В начале 90-х я программировал на советском компьютере «Корвет».
Это был большой серый компьютер с клавиатурой, встроенной в основной корпус. Внутри работал процессор КР580ВМ80А — советский аналог Intel 8080 с тактовой частотой около 2,5 МГц.
Оперативной памяти было всего 64 килобайта.
Именно килобайта.
По современным меркам этого недостаточно даже для хранения одной фотографии с телефона.
Но тогда в этих 64 КБ помещалась вся программа.
«Корвет» поддерживал графическое разрешение 512×256 точек и цветную графику. Для советского учебного компьютера конца 80-х это выглядело очень достойно.
Однако самое интересное было не в характеристиках.
Главное заключалось в том, как приходилось мыслить программисту.
Если нужно было вывести изображение на экран — ты работал практически напрямую с видеопамятью.
Если требовалось нарисовать кнопку — рисовал ее сам.
Если нужен был интерфейс — создавал его самостоятельно.
Каждый байт памяти был ценностью.
Каждая операция процессора имела значение.
Компьютер не скрывал своего устройства.
Он постоянно напоминал, что внутри находятся процессор, память и видеоконтроллер.
А программист должен понимать, как все это устроено.
Мир IBM PC
К 1994 году IBM PC и совместимые компьютеры ушли далеко вперед.
В офисах уже работали машины на Intel 80386 и Intel 80486.
Появлялись первые Pentium.
Память измерялась мегабайтами.
Жесткие диски — десятками и сотнями мегабайт.
Видеокарты VGA поддерживали 256 цветов, а Super VGA — еще более высокие разрешения.
По техническим характеристикам разрыв с «Корветом» был огромным.
Но программная среда оставалась переходной.
Большинство компьютеров загружалось в DOS.
После включения пользователь видел привычную строку:
C:>
Если требовался графический интерфейс, запускалась Windows 3.1.
Она работала поверх DOS.
Закрыл Windows — снова оказался в командной строке.
Поэтому разработчики постоянно жили сразу в двух мирах.
Одна программа писалась для DOS.
Другая — для Windows.
Многие пользователи вообще продолжали работать исключительно в текстовом режиме.
Графический интерфейс уже существовал, но еще не стал естественной частью компьютера.
А потом появился Macintosh
В 1994 году мне впервые довелось программировать на Macintosh.
Именно тогда я испытал настоящее удивление.
Не из-за скорости.
Не из-за процессора.
Не из-за количества памяти.
Компьютер оказался построен совершенно иначе.
После включения не нужно было запускать графическую оболочку.
Рабочий стол появлялся сразу.
Окна.
Меню.
Иконки.
Мышь.
Все это уже являлось частью операционной системы.
В то время Apple выпускала компьютеры на процессорах Motorola 68030 и Motorola 68040.
Именно в 1994 году появились первые Power Macintosh на новой архитектуре PowerPC.
Но главным отличием были вовсе не процессоры.
Главным отличием была философия.
Mac OS представляла собой законченную среду разработки приложений.
За графику отвечал QuickDraw.
За интерфейс — Macintosh Toolbox.
Операционная система уже умела создавать окна.
Отрисовывать кнопки.
Показывать стандартные диалоги.
Работать с меню.
Обрабатывать события мыши и клавиатуры.
Программисту больше не нужно было каждый раз создавать все это самостоятельно.
Нужно было думать уже не о том, как нарисовать окно.
Нужно было думать о том, что должно происходить внутри этого окна.
Именно это стало для меня самым большим открытием.
Компьютер поднял программирование на новый уровень абстракции.
Изменилось не железо. Изменился способ мышления.
После «Корвета» я думал:
«Как записать данные в видеопамять?»
После IBM PC вопрос звучал иначе:
«Будет программа работать под DOS или под Windows?»
После Macintosh вопрос изменился еще сильнее:
«Что должен сделать пользователь и как приложение должно на это отреагировать?»
Вместо управления устройствами я начал думать о поведении программы.
Именно тогда я впервые почувствовал, что развитие программирования заключается не только в увеличении частоты процессоров.
Настоящий прогресс происходит тогда, когда меняется уровень абстракции.
Когда разработчик перестает решать вчерашние задачи и получает возможность сосредоточиться на более сложных.
Сегодня мы переживаем похожий переход
Прошло более тридцати лет.
И сегодня я снова наблюдаю похожую картину.
Раньше программист писал практически каждую строку самостоятельно.
Сегодня значительную часть этой работы способен выполнить искусственный интеллект.
Но очень быстро становится понятно, что проблема больше не в написании кода.
Современные языковые модели умеют писать функции, объяснять алгоритмы и предлагать архитектурные решения.
Главный вопрос теперь другой.
Откуда AI берет знания о конкретном проекте?
Почему именно так устроена архитектура?
Какие правила приняты в команде?
Почему несколько лет назад было принято именно такое решение?
Эти знания почти никогда не находятся в исходном коде.
Они живут в головах разработчиков, в обсуждениях, документации и накопленном опыте.
Именно поэтому я начал развивать Noda.
Если операционные системы когда-то подняли разработчика над уровнем работы с видеопамятью и регистрами процессора, то Noda помогает подняться еще на один уровень.
Она превращает знания команды в структурированную базу, понятную не только людям, но и искусственному интеллекту.
Архитектурные решения.
Принципы.
Ограничения.
Причины принятых решений.
Все это становится частью знаний проекта, которыми затем могут пользоваться современные языковые модели.
Получается интересная эволюция.
Сначала программист работал напрямую с аппаратурой.
Потом появились операционные системы.
Затем — библиотеки и фреймворки.
Теперь появляется следующий уровень — системы управления знаниями, которые позволяют человеку и искусственному интеллекту работать вместе.
Оглядываясь назад, я понимаю, что самым удивительным в Macintosh были вовсе не процессор Motorola, не цветной экран и не красивые окна.
Самым удивительным оказалось то, что компьютер изменил мой способ мышления.
Мне кажется, именно это сегодня происходит и с искусственным интеллектом.
Меняется не инструмент.
Меняется уровень, на котором работает инженер.
И именно такие переходы потом становятся новой нормой для всей отрасли.
Share
