Engineering Wisdom

A senior engineer opens a pull request an agent produced overnight. Every measurable box is checked: tests pass, the diff follows the team’s conventions file line for line, the commit message cites the ticket, and the change matches the acceptance criteria word for word. The engineer approves it, but leaves one comment that says only that the change feels fragile near the payment path, and asks for a second look before it ships. Pressed to explain further in the thirty seconds a review comment actually gets, the engineer cannot say much more than that.

Three weeks later, fragile turns out to have been exactly right. The code handles every case anyone had written a test for and fails on a load pattern nobody had seen often enough to think it needed a rule. Nothing in the review process would have caught it: the linter was silent, the conventions file said nothing about this case, and the agent’s own reasoning, read back afterward, was internally consistent from the first line to the last. The one signal in the room that turned out to be correct was a feeling a senior engineer could not fully explain at the time — and it arrived a full review cycle before any test did.

A category the checklist doesn’t check

This is not a new problem, and it did not arrive with AI-assisted development. Software engineering’s own knowledge-management research has spent two decades applying, to this field specifically, a distinction the wider knowledge-management literature had already settled on: what a team knows sorts into an explicit layer that can be written into a document, a rule, or a process, and a layer that resists exactly that kind of transfer no matter how well-intentioned the effort to capture it. Work on pair programming sharpened the point further. Knowledge transfer is one of pairing’s most widely claimed benefits, and a 2015 in-depth study of professional developers found the mechanism had barely been examined — identifying six distinct strategies, from direct instruction to a much subtler kind of hinting, that experienced developers use, mostly without being trained to use them, to move knowledge a novice could not simply be told.

The vocabulary already exists, informally

Engineers already have words for this, and none of them belong to a specification. Smells fragile. Something’s off, give me a minute. I wouldn’t ship this, but I can’t tell you exactly why yet. These phrases are not vague because the engineers using them are inarticulate — they are vague because the thing being described genuinely resists the kind of articulation a document requires. The chapters before this one in the volume have shown how much of what a team knows actually can be captured: institutional memory, a decision graph that keeps what a team decided and why queryable as Decision Memory, documentation written for humans and increasingly read by agents, playbooks that turn a known failure mode into an executable procedure, and even knowledge an agent writes and maintains about itself. What is left over, after all of that, is not a rounding error. It is a specific, well-studied category with its own name.

What Polanyi actually argued

The name comes from the chemist-turned-philosopher Michael Polanyi, and it predates AI-assisted engineering by almost sixty years. In The Tacit Dimension, a short 1966 book, Polanyi opened with a claim that has outlived most of the philosophy published alongside it: we know more than we can tell. His example was recognition, not code — a person can pick a familiar face out of a thousand strangers without being able to list the features that made the identification possible. The knowing is real and reliable. The telling is not available, not because the person is withholding it, but because the knowledge was never stored in a form language can fully retrieve. Polanyi called this tacit knowing, and drew the line precisely: explicit knowledge is what can be written down and handed to someone else intact; tacit knowledge is what a person, or a team, knows and relies on without being able to make it fully explicit, even to themselves.

The distinction is not a soft metaphor borrowed loosely for this chapter’s convenience. It is one of the most cited ideas in twentieth-century philosophy of knowledge, and software engineering’s own knowledge-management research adopted it directly, mapping a team’s know-how onto exactly this axis rather than inventing a separate framework for the field. The judgment a senior engineer applies in a code review, the sense that one part of a system is the genuinely hard problem while the rest is busywork, the taste that tells a reviewer a passing, well-documented change is still not good code — none of that is a gap in the team’s documentation. It is tacit knowledge, operating exactly as Polanyi described it.

Why the leftover category is getting more valuable, not less

It would be reasonable to expect the opposite: as more of engineering’s explicit layer gets captured — playbooks, conventions, decision archives, agents that execute codified procedure reliably — tacit judgment should matter less, a shrinking sliver of what remains after automation eats the rest. The evidence points the other way. Once the codifiable layer is well handled, the remaining gap between a merely competent team and a genuinely excellent one concentrates almost entirely in judgment calls no playbook anticipated, which is exactly what is left once everything that could be written down has been.

Google’s DORA research program made this concrete in early 2026, warning of what it called an expertise paradox: AI can bridge a knowledge gap fast enough that it risks bypassing the productive struggle necessary for deep technical expertise, producing what the report bluntly names false expertise rather than the real thing. Anthropic’s own randomized trial of junior engineers learning a new library reached a compatible, if narrower, conclusion — participants who used AI to complete tasks scored roughly 17% lower on a follow-up assessment of debugging and conceptual understanding than those who worked unassisted, a gap the researchers attributed partly to the fact that struggle itself, including the frustrating kind, appears to do real cognitive work in building mastery. Both findings deserve care rather than treatment as settled science — the Anthropic study is a single trial of 52 engineers learning one specific library, and the wider debate over how AI tools affect skill formation is active and genuinely unresolved — but they point in a consistent direction: the layer of engineering expertise that is hardest to write down is also the layer AI-assisted work is currently worst positioned to build in a less experienced engineer, precisely because building it seems to require the friction AI is designed to remove.

Cognitive effort — and even getting painfully stuck — is likely important for fostering mastery.

Anthropic, on a randomized trial of AI-assisted learning

How judgment has always moved, and still does

None of this means tacit knowledge is untransferable — only that it does not transfer the way a document transfers. It moves through apprenticeship, and it always has. A classic 1991 account of cognitive apprenticeship makes the underlying mechanism explicit: conventional schooling tends to make expert thinking invisible, while apprenticeship exposes it by default, because the novice can simply watch the process happen. The teaching strategy the researchers named modeling — an expert working while narrating the reasoning behind each choice — turns invisible judgment into something a novice can observe, even though it was never written down for that purpose and could not have been.

This is also, separately, the mechanism naturalistic-decision-making research found underneath the kind of split-second judgment that looks like pure intuition. Studying firefighters, critical-care nurses, and pilots who had to decide fast under real pressure, Gary Klein’s research described experienced professionals recognizing a situation as an instance of a pattern before they could explain the recognition, and found that the professionals who did this reliably had, almost without exception, spent years watching others do the same work under the same pressure. The senior engineer’s fragile comment at the top of this chapter is the same mechanism, applied to code instead of a burning building.

The mechanism this Library already has for it

Software engineering does not need a new transfer mechanism for tacit knowledge; it needs to notice it already has access to the oldest one. Volume V’s chapter on workflow replay makes a related argument for a different reason — that a recorded, scrubbable AI session is a genuine worked example, not just an audit trail — and grounds it in John Sweller’s cognitive-load research showing that novices learn a new domain faster by studying a worked example than by solving the same problem unguided. The connection to this chapter is direct rather than decorative: a worked example is exactly what apprenticeship has always used, and a replay of an AI-assisted session that a person can scrub, slow down, and rewatch is that same worked example, produced automatically, for a kind of work that used to leave no observable record at all. Watching someone work, live or replayed, is a structurally different channel of transfer than reading a document about how they worked. The second is explicit knowledge about a process; the first is the closest a team can get to handing over the tacit knowledge underneath it.

What actually transfers, and how

The volume’s earlier chapters and this one describe two genuinely different problems, and it is worth laying them out side by side rather than letting the difference stay implicit.

What to check, not what to assume

What this chapter is not arguing

None of this is an argument that AI-assisted engineering degrades judgment as some kind of law, or that the right response is avoiding AI tools while building expertise. The DORA research cited above frames the same evidence as a design problem, not a verdict: organizations that pair junior engineers with senior review on AI-generated decisions, or that deliberately preserve some manual work on the pieces meant to build foundational understanding, appear to get the productivity gains without paying the whole cost in eroded judgment. The point is narrower, and more useful: tacit judgment is not a knowledge-management problem the rest of this volume’s tools will eventually solve. It resists exactly the kind of capture the first nine chapters describe, on purpose, because Polanyi’s distinction was never a temporary gap waiting for better documentation software.

The honest position, and the one this Library carries into its final chapter, is that the best response to a category of knowledge that cannot be made explicit is not to keep trying to force it into an explicit format anyway. It is to get better at the transfer mechanism that has moved tacit knowledge for as long as engineering has existed — watching someone work — and to notice that AI-assisted sessions, unlike almost every other kind of engineering work before them, now leave behind something that can actually be watched.