A recent piece on org design argues that the bottleneck in how companies build things was never speed. It was translation cost. A product manager encodes intent as a document. A designer decodes the document and re-encodes it as a visual. An engineer decodes the visual and re-encodes it as code. Every handoff loses fidelity and requires another alignment meeting. The wait isn’t laziness: it is the genuine difficulty of making one person’s understanding legible to another.
That framing travels well beyond feature development. It changes what codification is for.
Two costs, not one
When knowledge isn’t written down, it costs you twice.
The first cost is discovery: the effort of finding the knowledge at all. Who knows this? Where is it? Is the person who knows it in meetings until three? Most codification work aims squarely at this cost. You build the single source of truth, make it searchable, stop the same question being asked five times a week. That kind of friction quietly takes a lot out of a team, and removing it feels like the whole job. This is what codification aims to solve.
The second cost is translation: once you have found the knowledge, the effort of turning it into something you can act on. A dense page you have to read three times. A decision buried in a thread that you have to reconstruct into a rule. A standard written for people who already hold the context, which you don’t.
Discovery cost and translation cost are different problems. Most codification only solves the first.
Where the second cost hides
A well-run documentation project drives discovery cost close to zero. Everything is in one place, indexed, linked. But there it stops.
The material still assumes a human reader who will interpret it: fill the gaps, infer the intent, notice that an example is out of date and mentally correct for it. That is fine, because humans are good at exactly that. The translation cost is real, but it is paid quietly, by whoever is doing the work, and it rarely shows up in any measure of how the codification is performing.
So the standard looks finished. It is findable, it is current, people cite it. The work of turning it into action has just been distributed across everyone who uses it, one reading at a time.
Most teams judge codification on coverage and freshness: is the process written down, and is it up to date. Neither question asks how much interpretation the document still demands before anyone can act on it. That cost that stays hidden, because for a human reader it has always been small enough to ignore.
When the reader can’t ask
An agent hitting your codified process pays the translation cost too, and it cannot do the things a human does to absorb it. It cannot infer the unstated context, spot the exception everyone knows about, or ask Sarah. It re-derives its understanding from the raw material every time it runs, and if that material was written for a human, the translation is lossy and it is paid again on every execution.
A codified job whose instructions still need interpreting is not automated. It is a job with a waiting room. Something can start it, and then it stalls until a person turns the document into intent.
Compile it once
A team points an agent at its Confluence space or its Notion workspace, expects it to run a process end to end, and gets output that is confidently wrong at the edges. The knowledge was all there. The agent still had to reconstruct intent from prose written for colleagues, and it got some of it wrong.
The alternative is to write the codification for the actor that will consume it, not for the archive.
Andrej Karpathy’s LLM wiki, a short spec he published in April, is the clearest example I have seen. Instead of pointing an agent at a pile of raw documents and having it work out the answer on every query, you compile the raw material once into a structured, interlinked set of markdown files that the agent maintains and reads directly. Karpathy’s own version reportedly runs to more than a hundred articles and four hundred thousand words. Each new query starts from the synthesis, not from the sources. The wiki, as he puts it, is a persistent, compounding artifact.
The translation happens once, when knowledge goes in, rather than every time knowledge comes out. The shift: pay the translation cost at write time, not read time.
Codifying for the actor, not the archive
Codifying before you automate is about sequence: do the foundational work before you deploy. This is about form. The codification advantage is not just having your judgment written down. It is having it written down in a form the next actor can act on without a translator.
In practice that means a few things:
- Criteria, not description: what triggers each step and what good output looks like, not a narrative account of the process.
- Structure an agent can navigate, not prose it has to parse.
- Explicit exceptions, because the agent will not know the one everyone else does.
- Codification that lives where the work happens, referenced in the prompt and the definition of done, not in a side document people open when they remember it exists.
This costs more than writing a page that reads well, so it is not worth doing everywhere. The jobs that earn it are the ones an agent will run often: the weekly report, the triage step, the first-pass review. Compile those once. Leave the rest as prose for the humans who can still fill the gaps.
None of this is new advice to anyone who has tried to make a standard stay alive. What is new is why it now matters. When the reader was always human, a document that needed interpreting was merely inefficient. When the reader is an agent running the job a thousand times, the interpreting is the job. You have not codified anything until something can do it without asking you what you meant.
Leave a Reply