For a while, estimation was part of my job. One politically sensitive project asked for an estimate accurate to 1%. My answer: build the project, then report how it went. An estimate is a model of the end state, and the only model precise enough to be right about everything is the thing itself.
A spec, the code, the tests, the types, the API docs, the migration, the commit history, the README (and now the "PRD" and even the prompt history). We treat these as different artifacts. They're not. They're all views of the same thing -- one intent, projected onto different surfaces.
The spec is the intent in prose. The code is the intent made executable. The tests are the intent as claims you can check. The types are the intent narrowed to shapes. Docs are the intent explained to someone who wasn't there.
Multiple views can pay off when you need to triangulate. A test is a different cognitive angle than a paragraph, so you catch in one what you'd never see in the other. The value of a test suite was never the file. It was that someone restated the intent a second way and the two versions had to agree. Plus it can assert that over time. Disagreement is where bugs surface before a user finds them[1].
The downside is drift. Change one view and the others quietly go stale. Anyone who has been at this a while knows the feeling of a large, elaborate, brittle unit test suite that nobody trusts. The tell is when you see FAIL and immediately assume it's the test that is broken. The spec describes the system as pitched, the docs as launched, the code as it is. Most software process exists to fight this: review checklists, doc linting, coverage gates, requirement matrices. We've built an industry around keeping copies of the same idea in sync.
The tradeoff is triangulation against drift, and the ultimate value of this really depends on how much a reader can hold at one time across these perspectives. Which raises the question: does an AI agent need multiple views at all?
An agent can reason directly on the code. It doesn't necessarily need the README to know what a module does. It can just read the module. For the most part, the views we maintain are compensation for a reader with limited working memory, and that reader is no longer the only one in the room. If the agent really does hold the whole thing (a big and evolving if), any view that merely restates another becomes pure drift risk.
Reading the code tells the agent what the system does, not what was wanted[2]. Code is the view most cluttered with decisions nobody cared about, and nothing in it marks intent apart from accident. How often have you reached for git blame to see who the hell did this... only to discover it's you. An agent working from code alone will faithfully preserve every bug (or bug-like-quirk), because from the inside a bug and a feature look the same. The views worth keeping hold what the code can't: the intent, the reasons, the failure someone once hit in production.
Increasingly, the code is the canonical form. My own agent workflow is pushing me in that direction. That doesn't mean it holds everything worth knowing. But in a world where agents can reason over greater and greater spans, additional views need to be sharp and adding very precise value. Another view can still earn its keep as an independent check. A single source has nothing to disagree with. And "independent" matters. If the same model derives the code and the check from the same reading of the problem, the check inherits the misreading[3]. The disagreement has to come from a second mind, not a second file. Sometimes that's the user, which is the expensive way to find out. For now it's usually you, which is the whole point of skilled humans in the loop.
A spec could take that place, but a spec precise enough to generate the system from isn't obviously smaller than the system[4]. That's my 1% estimate again. For now, maintaining the code increasingly makes more sense to me.
The reality today is agents can't hold the whole thing. In fact, the current generation seems to suffer from hyper-focus and a narrow view of intention. The clearest examples of this are elaborate multi-line comments that are hard to justify. Or unit tests that verge on testing "1+1". The agent understood the ask; it just applied it too narrowly.
I still write code, tests and docs and (attempt to) keep them in sync. But increasingly, I start with the code. The other views need to tell me something I can't get from it: why a decision was made, what a customer needed, what went wrong last time. Otherwise they're another thing to keep up to date.