AI Does Not Transfer Tacit Knowledge

Instead of copying what is inside people's heads, we need to redesign the work structure that made tacit knowledge necessary.

In spring 2026, reports said that Meta had internally announced plans to collect employees' mouse movements, clicks, keystrokes, and some screen snapshots as training data for AI agents. Around the same time, reports also described AI-centered restructuring and large-scale layoffs at the company.

At first glance, this can look like the fastest way to turn tacit knowledge into data. If you capture how people actually work - where they pause on screen, which buttons they click, which shortcuts they use - won't that know-how move into the model?

But there is a trap here.

Screens show behavior, but they do not show judgment. A click remains, but the reason behind the choice does not. A pause remains, but the risk that was being considered does not. What gets captured is the surface of work. What is actually needed is the structure of judgment.

That difference is where the whole phrase "transferring tacit knowledge" starts to get confusing.

What We Call "Tacit Knowledge"

These days, we often hear that organizations need to transfer their tacit knowledge into AI. It is an attractive phrase. It sounds as if we can keep the existing people and the existing way of working, simply attach AI next to them, and gain productivity. That is why it sells.

But much of what organizations call tacit knowledge is not truly ineffable intuition.

It is undocumented criteria, context that was shared only in meetings, exception handling that only one person remembers, and judgment history that never made it into the system.

In many cases, tacit knowledge is closer to "work that has not yet been structured" than to "knowledge that cannot be explained."

For example:

• This customer appears to want fast delivery, but actually values verification material more.

• This expression is not legally wrong, but may read as exaggerated to the customer.

• This task can be automated, but a person must review it before final submission.

• This number may look correct, but it should not be used without a clear source.

To an experienced person, these judgments are so obvious that they often do not write them down. To AI, they are not obvious at all.

So the question changes. It is no longer "How do we copy a person's head into AI?" It becomes "Why was this work only inside one person's head in the first place?"

The Weak Link Becomes More Important

Stanford economist Chad Jones's "weak link" perspective touches this exact point.

A single job contains dozens, sometimes hundreds, of smaller tasks. Even if AI automates some of them very quickly, the weak link that cannot be automated still determines the productivity of the whole system.

That weak link is usually made of questions like these: What needs to be verified? Which exception should be treated as risky? How far can we go when speaking to a customer? Which judgment requires human approval? What needs to be recorded after a failure so the next person can continue?

This may be the real shape of what organizations have been calling tacit knowledge. It looked like an expert's intuition, but in practice it was a bundle of judgment criteria, verification procedures, authority structures, and memory practices tied to one person.

So the more AI takes over fast work, the more valuable the remaining weak links become.

So It Is Not Transfer, But Decomposition

AI-native transformation is not about putting a person's head into a model. It is about taking the work structure that one person was holding alone and moving it outside.

The most concrete way to explain this is a GitHub repository.

GitHub is not only for software development. Proposals, research, customer meetings, product planning, and operating design can also be split into work units and placed in repositories or folder structures. The point is not simply to store files. The point is to leave work in a structure that can be reopened.

For example, one customer project can become one repository. Inside it are meeting notes, customer requirements, decision logs, risk lists, reference material, execution specs, and current progress. Who made which decision, why it was made, what evidence was reviewed, and what remains unverified all stay in files and history.

Then Codex or Claude Code reads that repository. It is not asking a human to remember. It is reading the work context that has already been externalized. On top of that, AI can draft, find missing evidence, flag risks, and suggest the next execution unit.

When the work is done, it is committed again. The commit message records what changed, and teammates can enter the same context through the change history. When needed, approval and review can be left through Pull Requests or review comments.

At that point, work changes from "something the person in charge remembers" into "an object that the team and AI can read together." I often regain the context of a project I had not touched for more than a week within minutes just by reopening its repository. I do not need to hear the whole explanation again because the repository and its change history speak for the current state.

Some of what is externalized becomes documents. Some becomes checklists. Some becomes data structures. Some becomes verification rules. Some remains as approval authority. And some must remain human judgment to the end.

In practice, it is enough to break work into five parts. Context becomes repositories and memory. Judgment becomes decision logs. Verification becomes checklists. Authority becomes review and approval structures. Experience becomes commits and execution logs. Once these five are in place, AI works much better. Without them, AI may sound plausible, but the organization still depends on one person's memory.

Where Do Humans Remain?

There is one important misunderstanding to cut off here. Decomposing the structure does not mean removing people.

A good AI system does not say, "We can automate everything." It distinguishes what should be automated, what should be assisted, what should be held, and what should be excluded. Trust does not come from saying what AI can do. It comes from clearly saying what AI must not do.

This becomes even clearer in regulated industries. Can an AI answer be traced back to the original clause and version? Does the final approver remain human? If those are missing, it is not a system. It is an incident waiting to happen.

Tacit Knowledge Does Not Disappear. Its Location Changes.

Tacit knowledge does not disappear because of AI. Its location changes.

In the past, it lived inside the body and memory of experienced people. Now it needs to be distributed across layers of the work system. The same five parts apply: context becomes repositories and memory, judgment becomes decision logs, verification becomes checklists, authority becomes review and approval structures, and experience becomes commits and execution logs.

Recently, I have felt that this view is no longer just one person's argument. It is starting to be tested in the field. I meet more builders who have arrived at the same conclusion through different paths, and in my own small research around a similar problem, I again confirmed that "a structure where evidence and judgment can be traced" matters more than "AI giving an answer."

Even Meta's attempt to look into employees' screens is a rough version of the same hunger: the desire to somehow put how people judge into a system. But that cannot be captured by screen recording alone.

AI does not transfer tacit knowledge. AI exposes the work structure where tacit knowledge was hiding.

And what companies need to do is redesign that structure.