Code as artifact

The most direct implication of the thesis: the code you ship is an output of the concept. Claude can rebuild your code from a well-curated spec at will. The spec is evergreen; the code is an artifact of the current spec applied to the current toolchain.

This is not a rigid one-way compiler from spec to code. During the creative process, specification and implementation feed each other: a prototype often comes first, teaches you something, and gets folded back into the spec. What stays fixed through all of it is the invariant core. The surface (implementation details, layouts, even architecture at the edges) is free to churn as long as the invariants hold.

Code as output, spec as source

Treating code as output changes what you pay attention to.

When code is the source of truth, you optimize for:

• Writing clever code that’s hard to regenerate
• Memorizing how you solved past problems
• Resisting rewrites because “the code is the accumulated knowledge”

When the spec is the source of truth, you optimize for:

• Writing a clear spec that anyone (or any model) can build from
• Regenerating code when the toolchain improves
• Rewriting freely when a better implementation exists, because the knowledge is upstream in the spec

The second posture ages better as models and frameworks improve. Over the life of a project the spec’s value accrues (each session refines it, each implementation validates it) while any specific implementation gets more replaceable as the ecosystem moves.

Rebuild-from-spec as a real-world test

A good spec can regenerate the product. The test: wipe your codebase, hand Claude the spec, and say “build this.” The resulting code won’t be byte-identical, but the invariants and core capabilities must hold, and the structure should be recognizably the same.

If the test fails, the spec is missing something. Fill in the missing pieces before the next real rebuild (version upgrade, tech migration, vendor change). You’ll face one eventually.

What this means for code review

Review the spec change first, then verify the code reflects it. A PR without a corresponding spec change is either trivial (typo, refactor) or suspicious (undocumented behavior added). Either the spec already described what you’re building, or the spec needs to be updated to describe it. A PR that touches an invariant deserves the most scrutiny of all, because that’s a product decision wearing a code diff.

The compounding return

Every session invested in the spec pays off in every future session that reads it. The spec is read on every turn; the code is read when someone debugs it. The read-rate asymmetry is huge. Invest accordingly.

Where this breaks down

Some code is legitimately upstream of any reasonable spec:

• Low-level performance work. Inner loops, data-structure choices, memory layouts. The implementation is the specification at this level.
• Hardware-adjacent code. Drivers, firmware, anything where the constraints are physical.
• Research code. Throw-away experiments where writing the spec would take longer than writing the result.

For these, code really is the source. The spec-over-code rule applies to product code, not to every line of software ever written.