The Day After AI
Making Software Companies
Legible to AI Agents.
Tribal Knowledge
Is the Bottleneck.
Every software organization has the same hidden liability: the reasoning behind its own decisions lives in people's heads, in Slack threads that decay within months, in commit messages that record what changed but never why. AI agents can read an entire codebase in seconds, but they can't ask a senior engineer what a payment constraint actually means, or why a service calls another out of the “obvious” order.
That gap isn't a documentation problem you can wiki your way out of. It's structural. The knowledge that keeps a system safe was never designed to be found by anything that can't tap someone on the shoulder, and every constraint that exists only in someone's memory is a constraint an agent will walk straight past.
The Day After opens on a single incident: a clean, fast, technically correct AI-generated change that breaks production hours later, not because the agent did anything wrong, but because the system never told it what it needed to know. It's the pattern already playing out on every team pointing agents at a real codebase, and it's where the book begins.
Use Cases
The Onboarding Tax
New hires spend weeks reconstructing context that already existed, just nowhere they could find it.
The Departure Risk
When a senior engineer leaves, years of undeclared context leave with them.
The Agent Blind Spot
Coding agents read your files, not your Slack history, so tribal knowledge is invisible to exactly the tool you're betting on.
Contracts Are
the Answer.
Contracts aren't more documentation, and they aren't a better wiki. A contract is a structured, machine-readable declaration of what a piece of business logic does, why it does it, and what would break if it changed, written once, in a form both humans and agents can act on.
Every fix teams normally reach for, documentation sprints, tighter prompts, more supervision, treats the symptom. Each one makes an illegible system slightly less illegible for a while. None of them change the underlying condition: the system still doesn't declare what it knows.
Chapter 3 makes the case for contracts as the structural fix, not a documentation exercise: what a contract has to capture, and why “good enough” documentation was never going to be enough for agents that can't ask a follow-up question.
Not Documentation
A wiki page describes a system. A contract declares it, in a form an agent can act on without a human translating first.
Machine-Readable
Contracts are structured enough for an agent to parse, and specific enough for a human to trust.
Built to Survive Turnover
Contracts outlive the engineer who wrote them, the way a Slack thread never does.
The Capabilities
Graph.
Contracts describe individual pieces of logic. The capabilities graph is what happens when you connect them: a map of every capability in a system, its dependencies, its owner, and the contract that governs it, legible to a new hire and an AI agent in exactly the same way.
Chapter 4 introduces the capability as a new atomic unit of software design: headless, portable, and contract-defined, a different way of decomposing a system than the service boundaries most teams already have.
The result isn't a diagram for a slide deck. It's a structure a coding agent can actually navigate, the difference between an agent guessing at your architecture and an agent reading it.
The Graph
Headless
A capability doesn't know or care how it's presented, no UI assumptions baked into the logic.
Portable
The same capability runs wherever it's called from, without dragging its old service along.
Contract-Defined
Every capability's boundaries, dependencies, and rules are declared, not inferred from reading the code.
Extraction Over
Refactoring.
The instinctive response to an illegible codebase is a refactor. Chapter 5 argues that's the expensive trap: a months-long cleanup that consumes an organization's most senior engineers and, at the end, produces cleaner code that still can't explain itself to an agent.
Refactoring makes code easier to read. It doesn't make a system declare what it knows, and legibility is a property of declared contracts, not clean code. An agent pointed at a beautifully refactored system fails for the exact same reasons it failed before.
Extraction is the alternative this chapter lays out: pull capabilities out of the legacy system one at a time, contract them properly, and leave the rest of the codebase untouched until it's its turn, progress that compounds instead of a rewrite that has to finish before it pays off.
Code Is Cheap
Rewriting a service is the easy part. Capturing why it works the way it does is what refactors skip.
Ship the Slice
Extract one capability, contract it, move on, value lands after the first slice, not after the whole system is done.
Senior Time, Spent Once
The knowledge in your senior engineers' heads gets captured in the contract, not burned re-implementing what already worked.
"A system that cannot make its intent legible to an AI agent is a system that will be navigated by competitors who can."