Tacit knowledge: what a product owner knows that agents do not
Stefan-Iulian Tesoi · · 6 min read
It stops reaching the work. A developer absorbs a product owner's tacit knowledge in conversation and code review: who a feature is really for, which edge case burned the team last year. A coding agent builds only from what is written down, so every rule that lived in someone's head comes back as a plausible change that is wrong.
The knowledge was always unwritten. What changed is that the person who used to fill the gaps without being asked is no longer the one doing the building.
Why does tacit knowledge stop reaching the work?
Because it travelled through channels an agent is not on. Most knowledge transfer in software teams happens in passing: a question across a desk, a comment on a pull request, a correction in stand-up. A developer who misread an item was usually put right before the merge, often because they asked.
Michael Polanyi named the problem in The Tacit Dimension in 1966: "we can know more than we can tell." The distinction between tacit vs explicit knowledge is the distinction between what a team does and what it has written down. Explicit knowledge is in the backlog item, the rules file and the tests. Tacit knowledge is in the heads of the people who have been there longest, and it surfaces only when someone is about to get it wrong.
A coding agent does not ask. Faced with a gap, it picks the most plausible reading and builds it well, so the result passes a quick review. The gap was always there. A person used to close it silently, and nobody counted how often.
Four kinds of unwritten rule an agent cannot pick up
Most undocumented requirements fall into four kinds, and each fails in its own way when nobody writes it down.
| Kind | Example | What the agent does without it |
|---|---|---|
| Who it is really for | The export exists for the finance team's month-end close | Builds the general case, with the columns an analyst would want |
| Scar tissue | Never send a customer two emails inside an hour | Rebuilds the behaviour that caused the complaint |
| Conventions | Money is stored as integer cents; times are stored in UTC | Copies the nearest example, which may be the exception |
| Decisions and rejected options | Polling was chosen over websockets because of a customer's proxy | Proposes the rejected option again, persuasively |
The first kind belongs to the product owner almost entirely. Engineers rarely hold it, because it comes from sales calls, support tickets and the conversation where a customer explained what they would actually do with the feature.
The fourth kind is the most expensive to lose. A rejected option leaves no trace in the code, so an agent that rediscovers it presents it as an improvement, and a reviewer who was not in the original discussion may agree.
How do you find what was never written down?
From the work that comes back wrong. Every rejection whose reason is not in the item, the rules file or a test has found an unwritten rule, and the rejection is the moment to write it.
Four places turn up most of them:
- Rejected work, read for its reason. Tag each rejection as bad code or bad item. In our own reviews, roughly half of what gets sent back turns out to be a specification defect, and each one points at a rule.
- The new-hire question. In refinement, ask what someone in their first week would get wrong about this item. The answer is usually a rule nobody wrote.
- Recent review comments. Search the last thirty for "we always", "we never" and "remember that". Each phrase marks a rule taught by hand.
- Incident write-ups. Each one taught a rule. Check that the rule now lives somewhere an agent reads.
The cost of missing one is easy to underestimate. On this site, one page sat in the sitemap while telling search engines not to index it, for eight months. Everyone would have agreed with the rule that forbids that. Nobody had written it, so nothing checked it, and it is now a build check that fails.
Where should each kind of rule live?
Where it will be read at the moment it applies. A rule in the wrong place is as good as unwritten, because the agent reads what it is handed for this task and nothing else.
| Kind | Where it lives | Why there |
|---|---|---|
| Who it is for | The backlog item, as its outcome and criteria | It applies to one piece of work |
| Scar tissue | A test, plus a do-not-break note for that area | A failing test cannot be skimmed past |
| Conventions | CLAUDE.md or AGENTS.md | Every task in the repository needs them |
| Decisions | A decision log, against the item it was made on | The rejected option is the part that disappears |
The item carries most of the weight, which is why a backlog item an agent can execute states its outcome and its scope rather than a feature name. A rules file holds only what every task needs; what belongs in an AGENTS.md file covers where that line falls.
Laimonade hands a coding agent three of these over MCP before it edits anything: the item with its criteria, the team's own rule files such as CLAUDE.md, and the do-not-break notes for the paths it is about to change. A fourth tool writes a decision against the item it was made on, including what was rejected. How Laimonade works describes the order an agent reads them in.
What does it cost to write everything down?
More than it saves, if everything is meant literally. Polanyi's point was that some knowledge cannot be fully told, and trying produces documents nobody reads.
A rules file that grows past a few pages stops being followed reliably, by people and by agents. A decision log that records every choice buries the five that mattered. The useful rule is narrower:
Write a rule down the second time somebody has to say it out loud.
The part that cannot be written is judgement: which trade-off a customer will tolerate, when a convention should bend, whether a technically correct change is the right one. That part is why the product owner still reviews returned work rather than only writing items, and why who owns the backlog matters more once agents build. The wider job is set out in what an AI product owner actually does: the writing can be shared, and the judgement stays with a person.
Frequently asked questions
Can an agent learn the rules from the codebase?
Some of them. Conventions show in the code, and an agent reading nearby files will copy them, including the exceptions, because it cannot tell a convention from a mistake repeated twelve times. Who a feature is for, which incident shaped it and which option was rejected are not in the code at all. The code records what was built, not why.
Who should write the missing context down?
The person who noticed it was missing, at the moment they noticed. Usually that is the reviewer rejecting a change, and a rejection is the cheapest moment to write a rule, because the example is in front of them. The product owner owns rules about customers and scope; the tech lead owns conventions and architecture decisions.
Does this make onboarding new engineers easier as well?
Yes. An engineer in their first month needs the same four kinds of rule an agent does, and a written rule reaches them on day one instead of after their first rejected pull request. It does not replace pairing. The judgement Polanyi meant, knowing which rule applies in an unfamiliar case, still travels by working next to someone.