There is a quiet shift in where the value of software actually sits, and it is worth saying out loud. The code itself is worth less than it used to be. Anyone can write it quickly now, and with an AI agent anyone can stand up a working app, or clone an existing one, in an afternoon. The codebase is not the moat it once was.
This is not a complaint about AI. It is a reason to look harder at what does still hold value, because it is not the part most teams treat as the deliverable.
Code was never most of the job
Even before agents, writing code was not where the week went. It went on infrastructure, wiring up platform accounts and access, devops, and communication. The business logic, the part everyone pictures when they think of "coding", was always the fast bit surrounded by slow, unglamorous work.
Value is created somewhere else again: when a business problem is articulated clearly, solved deliberately, and the decisions behind the solution are recorded. That work does happen on every project. The trouble is that it happens inside the code, implicitly, and the moment it is committed most of the "why" evaporates. The code shows what was built. It rarely shows why, what was ruled out, or which constraint forced the awkward part. The most valuable thinking on the project ends up as its least durable record.
The durable asset is the context, not the code
When you capture the specification and the architecture as their own artefact, separate from the code, they stop being tied to any one codebase. They describe the problem, the decisions and the shape of the system, not the syntax that implements it this month. That makes them portable in two directions code is not.
Portable across platforms
The same captured context can drive your website, your Android app, your Electron desktop build and your backend. You feed the spec into whichever stack each platform needs and build to one source of truth, instead of reverse-engineering decisions out of one codebase to reapply them in the next. "A client must approve a report before it is shared" is the same requirement whether it is enforced in TypeScript on the web or in Kotlin on Android. Capture it once, as a decision, and every platform inherits it. Leave it implicit in one codebase and every other platform rediscovers it, usually slightly differently.
Portable across time
Code does not only get rewritten when the product changes. It rots on a schedule you do not control. Framework versions age, language and runtime versions move on, and platforms deprecate their APIs constantly, sometimes quarterly in the case of Shopify. The implementation is forced to change underneath you even when the requirements have not moved at all.
So V2 throws away half of V1, and by V10 barely a line of the original survives. What survives is the specification: a decision about why you chose an approach stays true even after the API that implemented it is gone. Each version compounds on the last instead of relearning it from scratch, which is what happens when the only record of "why" is a codebase that keeps getting replaced.
What this changes
If the code is the disposable layer and the context is the durable one, the practical conclusion is to stop treating specifications as documentation you produce after the real work, and start treating them as a first-class artefact in their own right: the problem, the constraints, the decisions and the architecture, captured so people and machines can build from them again and again.
That is the bet behind how we think about specifications. The code is cheap and getting cheaper. The reasoning behind it is the part worth keeping.