The spec is the source. The prompt is build scrap.

Here's a question that sounds simple and isn't, once an AI agent is writing most of your code: what is the source code now? Point at the thing that is the real, authoritative, you-edit-this artifact of the project. Most people point at the code the agent generated. Some point at the prompt. Both are wrong, and the gap between the right answer and those two is the whole shift worth understanding.

I wrote before that the spec, not the prompt, is the artifact you should reason about. A year of this becoming an industry has only sharpened the claim. It's not just that the spec is an artifact. It's that the spec is now the source — and the two things you instinctively reach for, the code and the prompt, have both been demoted under it.

The old hierarchy: code was the truth

For the whole history of software, the source code was the source of truth. It was the durable thing you authored by hand, owned, put under version control, reviewed line by line, and argued about. Documentation and comments were secondary — descriptions of the code, allowed to drift, never the authority. When the docs and the code disagreed, the code won, because the code was real and the docs were a story about it.

That hierarchy is inverting, and it has a name.

The flip: the spec is the source, code is the build output

Spec-driven development — the methodology every major AI coding tool shipped a version of in 2025–26 — makes a written, version-controlled specification the single source of truth, and treats code as a generated output. You write the spec — what the system does and why — derive a plan, break it into tasks, and the agent generates the code from it. The spec is the artifact humans edit; the code is what the build emits.

The analogy the field keeps reaching for is exactly the right one: the spec is the source the way a .c file is the source, and the code is the binary it compiles to. You don't hand-edit a compiled binary; you edit the source and rebuild. In spec-driven development the generated code is the binary — you don't patch it by hand either, because the moment you do, it's desynced from the source that's supposed to define it. You change the spec and regenerate.

This isn't a fringe idea anymore. GitHub's Spec Kit crossed 90,000 stars and supports 29+ agents; AWS Kiro is an IDE built entirely around it; Cursor, OpenSpec, Tessl, and the rest all shipped their own flavor. One person even called it the fifth generation of programming. The whole tooling world converged on the same inversion at once.

Why it's right, not just trendy

The reason this works is the same reason compiling from source works: you reason and make changes at the level of intent, and let the build produce the artifact. Spec-driven development emerged specifically as the antidote to "vibe coding" — prompting an agent into a pile of plausible code that drifts from what you meant, hallucinates an API, and rots as it grows. Anchor the build to a written intent and the drift has something to be measured against.

And it pays. GitHub reports teams using Spec Kit ship features with roughly an order of magnitude fewer "regenerate from scratch" cycles than ad-hoc prompting; AWS documents 40-hour features shipped in under 8 hours of human time when authored spec-first. That's not a small efficiency — it's what happens when you stop hand-editing the binary and start owning the source.

So what's the prompt, then?

This is the part that reframes everything. If the spec is the source and the code is the build output, the prompt isn't even in the hierarchy of things you keep. The prompt is build scrap — the transient command you issue to kick off a generation, like the shell line you type to run make. You don't put your make invocation under version control and review it in a pull request; you version the Makefile and the source, and the command is just how you started the build that time.

Which is why obsessing over prompt wording was always aiming at the wrong target — the same point I made when I argued prompt engineering is dead. Teams polish the phrasing of a throwaway while under-investing in the spec, which is the thing they should be laboring over, versioning, and reviewing. They're proofreading the match and ignoring the blueprint.

What it looks like in practice

This is just how I build. The spec is the artifact I actually work on — the thing I draft, argue with myself about, put in version control, and review like it matters, because it's the part that does. The agent generates the code from it. If the code is wrong, I almost never patch the code; I fix the spec and regenerate, because patching the output by hand is editing the binary and desyncing from the source. And the prompt that drove a given generation? Gone by the next day. I never look at it again, because it was scrap — the thing you strike to start the build, not the thing you keep.

So the question I opened with has a clean answer now. The source code of an AI-built system is the spec. The code is what the build emits from it. The prompt is the match you strike and then drop. Write the spec like it's the source — because that's exactly what it became.