In this section: The Book
Frequently Asked Questions
Straight answers to the questions that come up most, about the book and about the toolkit it ships alongside.
What is The Day After actually about?
It's about why AI coding agents keep making unsafe changes to real codebases, and it argues the cause isn't the agents. It's that most software never wrote down why it works the way it does. The book calls that missing layer tribal knowledge, and walks through a methodology, contracts, capabilities, and a capability graph, for making it explicit instead of leaving it in people's heads.
Who is the book for?
Engineers, architects, and engineering leaders working in codebases that are starting to have AI agents open pull requests against them. It's also written with product managers and designers in mind, since a few chapters address what this shift means for their side of the work, not just the code itself.
Is it a technical book or a business book?
Both, on purpose. The core argument is technical, contracts, graphs, extraction priority, but it's written so a non-engineering reader in the same organization can follow the reasoning and understand what's being asked of their team. Nobody needs a computer science degree to get through it, and nobody working in code will find it thin.
Where can I buy the book?
Links to the current retailers are on the homepage and repeated at the bottom of every page on this site, right below the main content.
Do I need to be an AI or machine learning expert to read it?
No. The book isn't about how models work internally. It's about how to make a codebase safe for an agent, or a new hire, to operate in without tribal knowledge. If you've worked on a production codebase, you already have the background it assumes.
Is the cdad CLI free?
Yes. It's an open source command-line tool you install and run against your own repository. There's no paid tier gating the commands described on this site.
Is the toolkit actually open source?
Yes, the CLI, the contract schemas, and the validation logic are all public in the companion GitHub repository. You can read exactly how a report gets scored or a contract gets validated instead of taking a description of it on faith.
What languages or stacks does the toolkit work with?
Conceptually, any codebase organized around business capabilities rather than a specific framework. The methodology, and the contract format it produces, isn't tied to one language. The questionnaire in cdad check asks about behavior and exception paths, not syntax, so it applies whether the capability underneath is written in one language or several.
Do I need to read the book to use the toolkit?
No. You can install cdad, run cdad checkagainst a repository, and follow the reports it produces without having read a page of the book first. The book is what explains the reasoning behind why the tool asks the questions it asks, and most people find that context makes the later steps, especially prioritizing extraction, easier to trust.
How is a contract different from documentation?
Documentation describes a system and drifts out of date the moment the code changes underneath it. A contract is validated, versioned, and machine-readable, so cdad validatecan catch it when the contract and the code it describes fall out of sync. Documentation is a description. A contract is closer to a checked promise.
What does legibility mean in this context?
It's the degree to which a capable engineer, or an agent, can understand why a capability behaves the way it does without relying on tribal knowledge nobody wrote down. It's measured with a short questionnaire covering four questions, and the resulting score is what the toolkit uses to find where the risk actually sits.
Does adopting this mean rewriting our codebase?
No, and that's a deliberate part of the argument. The methodology is built around extraction, contracting one capability at a time inside the codebase you already have, rather than a rewrite that consumes months of senior engineering time and still doesn't declare what the new code knows.