Source Code Is a Build Artifact

Reading a compiled binary instruction by instruction to confirm that the compiler did what you asked would be an egregious waste of a programmer’s time. The binary is necessary, but routine assurance does not come from comparing each instruction to the source. It sits elsewhere: in the language, the compiler, the tests, and the behavior of the program.

That is a useful way to think about generated source code. In Software Has No Value, I argued that implementation is losing the scarcity premium it once carried. The argument reaches all the way down to repository files: source code is increasingly a process output.

The Analogy Has a Limit

A compiler has a semantic contract. Given a defined program, its job is to produce a result with the same behavior, even when an optimizer rewrites the program substantially.¹ Compilers have bugs, and programs can have undefined behavior, but the contract is clear enough that programmers do not normally audit emitted machine code for ordinary changes.

LLM code generation is different. It is sampled output. The same request can produce different code, and a model can invent an API, misunderstand a requirement, miss a boundary case, or make a change that looks plausible without being correct. Even an API seed only makes repeatability a best effort; it does not guarantee it.²

That difference explains the current instinct to read generated code closely. A diff is concrete. It tells a reviewer where the model touched the system. In a security-sensitive path, a payment integration, a migration, or the first pass over an unfamiliar codebase, being picky about the lines is often justified.

It cannot remain the default for all code as generated-code volume rises.

Reading Becomes the Constraint

Writing software used to take longer than reading it. That made line-by-line review a tolerable part of the production process. If a team can generate ten times as much implementation in the same period, a requirement that a person read every line turns human reading speed into the company’s throughput limit.

Generated code still needs assurance. The company needs assurance that the system behaves correctly. Tests, contracts, constrained interfaces, monitoring, and evaluation against real workflows give a different kind of confidence than a reviewer following an implementation detail through a diff. They can also run repeatedly.

Source inspection still has a place. It belongs at boundaries where a small mistake has a large cost, and at the site of a failure that needs explanation. It is good investigative work. It becomes less useful when required for every generated helper, adapter, and routine change.

The practical shift is from treating source files as the thing being made to treating them as evidence that a process produced something. What matters is whether the customer can complete the workflow, the data remains correct, the system respects its permissions, and failures are visible soon enough to matter.

The Company Cannot Rely on the Files

This matters beyond engineering practice. A source tree has little durable value when a close version can be reproduced cheaply from a description, a running product, and a competent model. The code may still be large, difficult, and necessary. Those qualities do not automatically make it a lasting advantage.

A company needs another principal source of value. It may understand a customer problem deeply enough to know which details matter. It may sit inside operations that are hard to replace, hold data a customer cannot recreate, have earned trust with sensitive work, own a route to the market, or benefit from a network that gets stronger as more people use it. The software expresses those advantages and delivers them.

As implementation gets cheaper, customer understanding, operational integration, data, distribution, and trust account for more of why customers choose a company. The code still does the work. It just accounts for less of the reason the company gets to keep doing it.

Footnotes

1. The Clang compiler manual describes optimization as changing performance without changing program semantics. ↩

2. OpenAI’s API reference says seeded output is best-effort and determinism is not guaranteed. ↩