Tacit Bankruptcy: How AI Is Liquidating Your Team’s Architectural Memory

A senior engineer once spent an entire afternoon refusing to merge a pull request that, on paper, was flawless. The change worked. Tests passed. CI was green. He just “didn’t believe the code.” Eventually, he asked the author to walk through the reasoning line by line, out loud. Roughly forty minutes in, the author said something offhand: “Well, this assumes the queue is FIFO, but I think that’s safe.”

It wasn’t safe. The queue was FIFO in development and best-effort-FIFO in production, a distinction buried in a runbook nobody had opened in two years. The senior had smelled the disaster from the diff alone. He couldn’t articulate the threat upfront, it lived in a constellation of subtle features, a decade of buried bugs, and the cognitive cost of understanding code without a deep mental model, which is the essence of tacit knowledge. An AI code review bot would have approved it instantly.

This is the tacit knowledge crisis in software architecture. The expertise that prevents incidents is often the hardest to document, and right now, it is exactly the expertise that AI-assisted development is engineered to ignore.

In 1966, chemist-turned-philosopher Michael Polanyi published The Tacit Dimension. Its central claim is brutally short: We can know more than we can tell. Polanyi wanted to know how an experienced scientist looks at an apparatus and knows it is going to fail before the symptoms appear. His answer was that most expert knowledge is structurally resistant to language. It lives in the body, in the practice, in cumulative pattern-recognition. You cannot extract it. You can only absorb it slowly, over years, by working alongside someone who already holds it.

If you have been writing software for more than a few years, you know this in your bones. You have skimmed a PR and felt that something was off before you could name it. Ten minutes later, maybe you produced a defensible critique: the dependency direction was wrong, the error-handling pattern violated an implicit contract, the function “wanted to be split in two” even though nothing was strictly wrong. The recognition arrived in milliseconds. The explanation took minutes and remained incomplete.

There is a common sentiment among experienced developers that the hallmark of a great engineer used to be the ability to explain their decisions clearly. That is still valuable. But the deeper truth is that some of the most protective knowledge in a codebase operates beneath the threshold of articulation. It is the half-memory of why the auth system was designed for a specific failure mode that the docs do not mention. It is the unwritten convention that “we never throw exceptions across this module boundary, even though the type signatures allow it.” And it is precisely the kind of knowing that how AI tools lack architectural context, reinforcing the need for human-driven tacit knowledge.

We are living in what must be called the Articulation Era: a period where the only knowledge that counts is the kind you can write down. Architecture Decision Records, runbooks, type annotations, READMEs. The explicit dimension. Anything not on the page does not exist.

The AI industry did not invent this bias, but it has operationalized it ruthlessly. An LLM is a maximum-articulation machine. Its training corpus is, by definition, something somebody wrote down. So when you ask it to generate code, what comes back is the weighted average of every explicit solution to that kind of problem that has ever been recorded.

What is structurally absent from that corpus?

• The shared team understanding that the User type is for the public-facing API, while Account is for internal flows.
• The senior’s half-conscious memory that a particular service falls over under a specific concurrency pattern, which is why the current design avoids a seemingly cleaner approach.
• The smell that a function “wants to be split in two”, even though no current line violates a linting rule.

None of this can be in the training data, because it was never written down. Not “won’t be”, cannot be, by Polanyi’s definition. If it could be encoded into text for a model to ingest, it would no longer be tacit. This is not a problem that more parameters or better data curation will solve. It is a boundary built into the concept itself.

This creates what we might call the Fluency Mask. Ask an LLM why your codebase uses a certain pattern and you will receive a confident, articulate, plausible explanation. That explanation is generated from a thousand similar-looking repositories on GitHub. It has no relationship to your codebase’s actual reasons. The fluency is real. The “knowing” is not. This is why “explain this code to me” is one of the most misleading uses of AI assistance: the explanations are always plausible and almost never grounded.

Once you see the frame, the failure modes start showing up everywhere.

Articulation Bias is the systematic preference, baked into AI tooling, for knowledge that can be written down. An assistant is happy to consult your README and your type definitions. It cannot consult the seventeen tribal conventions your team accumulated over four years. It generates code that adheres to the articulated rules and quietly violates the unarticulated ones. The PR passes the bot. It fails the human who has been there since the beginning.

Tacit Bankruptcy is the long-term consequence, and it should terrify engineering leaders. A codebase that once ran on tacit knowledge, held by its team, transmitted through working together, slowly spends down that reserve when AI starts doing the writing. The original carriers retire or switch teams. No new carriers form, because juniors are being apprenticed to an autocomplete engine instead of a senior. After a few years, the organization has the code, the docs, the tests, and none of the knowledge that made the system make sense. The codebase keeps running. Nobody knows why.

Walk into any team that fully embraced AI assistance two years ago and ask the remaining senior what changed about junior questions. The questions have flattened. The “why does this work this way” line of inquiry has dried up, because juniors are not reading the code anymore. They are prompting against it. Research from Stanford’s Digital Economy Lab indicates that companies adopting AI at higher rates are already hiring juniors thirteen percent less, and how AI coding assistants accelerate the erosion of tacit knowledge is becoming impossible to ignore.

Then there is the infrastructure-level response. Context graphs have been declared AI’s next trillion-dollar opportunity. ServiceNow launched a Context Engine. The premise is seductive: if we can just map the entities, decisions, and dependencies, we can preserve institutional memory.

Forrester’s Charles Betz has correctly noted that this is a convergence, not an invention. Enterprise Architecture has maintained entity graphs since Zachman in 1987. Configuration Management Databases and process mining have been building pieces of a unified context graph in isolation for decades. The problem is not invention, it is how documentation collapse in event-driven systems mirrors the broader crisis of unarticulated architectural knowledge.

As analyst George Anadiotis and knowledge architect Jessica Talisman argue, eliciting tacit knowledge and encoding reasoning in formal, machine-queryable form is not a database problem. It requires systematic knowledge engineering: observing work practices, interviewing experts, extracting undocumented reasoning, and representing it in formal structures like RDF/OWL. Without that investment, decision traces stay trapped in Slack threads, incident postmortems, Jira tickets, and people’s heads.

But here is the uncomfortable edge. Ontologies can govern typed entities and versioned provenance. Semantic layers can map business terms to query logic. What they cannot do is capture the half-conscious smell that a function wants to be split, or the instinct that a queue assumption is unsafe. The gap is part of the definition. Knowledge architecture turns fragmented decision traces into governed memory, which is genuinely useful governance. It does not, and cannot, translate what Polanyi proved was structurally untranslatable.

If you accept that some knowledge cannot be made explicit, a few practical things follow immediately.

Re-elevate apprenticeship. Working at the shoulder of someone who holds the tacit knowledge is the only known transmission mechanism. Pair programming, voice-based code review where the senior explains (or admits they cannot explain), walking through bugs together, these are not quaint agile rituals. They are the wire. Burn them and you burn the transfer.

Distinguish articulated from tacit work. Write the ADRs. Capture the runbooks. Record what you can. But do not pretend the articulation captures everything. The remainder is not an oversight, it is the irreducible part. The shift from code to specifications as the primary artifact, which threatens the tacit understanding of system behavior, makes this distinction even more urgent.

Pay seniors to teach, not just to ship. A senior who spends two hours pairing with a junior is doing the most important work on the team that week. If your incentive structure does not reflect that, your incentive structure is bankrupting your tacit capital one sprint at a time.

Resist the fluency mask. When AI produces a confident explanation of your code, treat it the way you would treat a confident explanation from a stranger who has never worked on your team. The fluency in and of itself is no evidence of grounding.

Redesign junior roles as architecture apprentices. Stop pretending that code generation is the entry point. Let juniors own review, quality assurance, failure-mode analysis, and the interrogation of AI-generated output. Force the “why does this work this way” conversation back into the daily rhythm.

Polanyi left us with a line that could double as a description of every difficult debug session you have ever had:

We start by an act of personal commitment, recognising in some pattern the promise of a hidden meaning. We pursue it without being able to say what we are looking for, and we know we have arrived without being able to say what we have found.

If that does not describe reading a tricky PR, nothing does. And it is exactly the thing AI cannot do, can never do by its current construction, and is steadily making us forget we used to do ourselves.

The Articulation Era will pass. When it does, the engineers who quietly kept the tacit dimension alive, by mentoring, reviewing, and refusing to outsource the judgment that mattered, will be the ones the next generation of teams desperately needs. In a world hellbent on automating the articulable, the value of the people who carry the inarticulable has actually gone up. Quietly, but a lot.

We can know more than we can tell. Make sure your team still has people who know.