Watch Andrej Karpathy code with an AI agent and it looks effortless. Context flows. The agent knows what he’s building, why he’s building it, and which decisions were already made three tabs ago. The demo is mesmerizing and slightly demoralizing, because you sit down at your own enterprise codebase the next morning and nothing works that way.
Here’s why his setup works: he is the context.
His IDE, his prompts, his tweets explaining the system, his YouTube walkthroughs are all temporary outputs of the same source. A single brain holding the whole system. One reader, one writer, same person. Drift is impossible. Ambiguity is impossible. The agent doesn’t need to reconstruct anything, because the human next to it already has.
Enterprises don’t have a shared head. So what do we do?
Today the answer is: give agents connectors. Point them at Jira, Drive, Confluence, Slack, the wiki nobody updates, the slide deck from Q2, the ADR that disagrees with the code. Let the agent stitch it together at runtime.
It works once, before it breaks down.
Why stitching fails
That kind of stitching falls apart quickly in the following predictable ways.
The Scavenger Hunt: Context smeared across five systems and none of them authoritative. The PRD says one thing. The schema says another. The Slack thread where the decision actually got made is in a channel the agent can’t see. The agent picks a source and commits. You find out which one in production.
Runtime Reconstruction: Every call, the agent re-derives the world from scratch, and thus derives it slightly differently each time. Instead of giving a deterministic context to the agent, you're making a coin flip each time.
Drift Degredation: Docs and code diverge - they always do. In the old world, a human reads the doc, notices it's stale, and makes an override. In the new world, the agent reads the stale doc and acts on it. Hence creating an stochastic drift.
Every proposed fix in the wild today is more connectors / integrations / MCP servers. At the end of the day that just scales the same mistake:
“If we just pipe in Confluence, it’ll have the context.”
No. It won’t. You’re asking the agent to do at runtime what Karpathy does in his head: synthesize, prioritize, discard, trust. Except the agent doesn’t have years of your codebase in its working memory.
Invert the stack
Here’s the move: we need to stop writing specs for humans. Instead, write them for the system and then generate the extraction you need for humans.
Make the machine-readable corpus the source of truth. Types. Schemas. State machines. Contracts. Executable examples. The stuff that’s already unambiguous because the system won’t run if it isn’t. That becomes the canonical, persistent base layer.
Then, generate the human artifacts on demand. The slide for Monday’s product review. The architecture diagram for the exec readout. The onboarding doc for the new hire. They all become disposable, downstream renders off the same source.
| Old stack | New stack |
|---|---|
| Humans write specs | Corpus is the spec |
| Agents scrape docs at runtime | Agents read the corpus directly |
| Human artifacts are source of truth | Human artifacts are generated |
| Drift caught by humans, eventually | Drift caught at the source, immediately |
| Context reconstructed every run | Context is persistent |
This is the inversion. No one does this today. But in the new world, the primary reader of your specs is no longer the human. It’s the agent. Humans get served by generation on top.
What the corpus needs
Once you accept the inversion, the question becomes: what makes a corpus trustworthy enough to be the base layer? There are four properties that come to mind for me (4Cs):
Consolidated: Distilled from source systems once, and therefore not refetched every run. You do the synthesis upfront; the agent reads the result. Hard thinking happens in one place, not on every invocation.
Close-to-Code: Expressed in machine-native formats, like types, schemas, YAML, executable definitions. The spec mirrors the code’s structure, not a human’s narrative about the code. Typed artifacts don’t have room for ambiguity.
Contextual: Lives in the repo, next to the code it describes. The agent doesn’t reach for it through a connector. It’s already there when the agent opens the file. If your agent needs a search tool to find the spec, you’ve already lost.
Current: Regenerated or validated on code change. Drift is caught in CI, not six months later by a human reading a stale doc. If the spec and the code disagree, the build fails. That’s the only enforcement mechanism that works.
This is Code Over Config, again
If this sounds familiar, it should. Same argument I made in Code Over Config, applied to documentation.
Stop hand-authoring the artifact. Author the source, compile the artifact.
Specs are config for documentation. For a long time we hand-wrote them because the tooling wasn’t there to do anything else. The tooling is there now. Types generate docs. Schemas generate UIs. State machines generate diagrams. Executable contracts generate onboarding flows. Every time you’re writing a spec as prose, you’re writing config that should be code.
The shift isn’t about replacing human-readable docs. It’s about demoting them from being the source, to simply a "view".
The Enterprise Karpathy
Every enterprise building with agents right now is trying to replicate Karpathy’s setup by piling on connectors and more retrieval. But it’s all stitching, and none of it is a real base layer.
So the work is to build the persistent, machine-readable corpus, vs. integrate more connectors. That’s what makes the inversion possible.
But the corpus is just the input. What happens inside it - like how raw context becomes structured, adaptive memory - is the next move.
Next: the architecture inside the corpus, and the four layers that turn it into a living memory system.
