Generated 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. Routine assurance comes from the language, the compiler, the tests, and the program’s behavior.

Generated source code can be treated as a similar kind of build artifact. It is necessary output from a production process. Confidence in the system cannot depend on a person reading every generated line.

The analogy ends at the input.

Generators Receive Ambiguous Intent

A compiler receives a program with defined semantics. Its optimizer may transform that program, but its job is to improve performance without changing how the program behaves.¹ There are compiler bugs and languages contain undefined behavior. The contract is still clear enough that programmers do not routinely audit emitted machine instructions after an ordinary change.

A code generator receives intent expressed through requirements, context, examples, existing code, and tests. Those inputs can be incomplete or contradictory. The generated result can call the wrong API, miss an edge case, misunderstand a permission boundary, or satisfy the wording while violating the actual requirement. No compiler contract closes that gap.

Treating generated code as a build artifact still leaves the model untrusted. Assurance moves to the level where correctness can be stated and observed.

Source inspection remains useful when the source itself is the best evidence available. A new authentication path deserves scrutiny. So does a data migration, payment calculation, permission check, destructive operation, or parser exposed to hostile input. The first generated change in an unfamiliar system may reveal assumptions that no test suite records yet.

The problem is making that level of inspection universal.

Line-by-Line Review Becomes the Constraint

Generated implementation can arrive faster than a person can read it carefully. When every line requires the same human review, reading speed sets the team’s delivery rate. Faster generation only creates a longer queue for the reviewer.

That queue also encourages a weak kind of assurance. A plausible diff feels understood after someone has followed its control flow and approved its style. The review may still miss the wrong requirement, a broken interaction between components, or a failure that appears only under production data. Readable code is valuable. Readability alone does not show that the system does the right thing.

The mismatch grows with routine code. Adapters, serializers, generated clients, repetitive UI, and mechanical migrations can contain many lines while carrying little independent design judgment. Charging each line the same review cost spends the scarcest attention without regard to risk.

Assurance Belongs at the Behavioral Boundary

Generated code still needs a demanding standard. The standard has to describe what the system must do.

Tests should state behavior rather than copy the implementation’s structure. A contract should define which inputs are valid, which outputs are promised, what may change, and what must remain true. Constrained interfaces should make invalid or excessive actions difficult to express. Evaluation against real workflows should test whether the customer can finish the job, not merely whether isolated functions return expected fixtures.

Monitoring covers the part that predeployment assurance cannot. It shows error rates, latency, rejected operations, data drift, and failures at the boundaries the team decided matter. Good telemetry makes a behavioral claim observable after release and gives the team a place to begin when the claim fails.

These methods can run repeatedly. They can evaluate ten generated changes without asking a reviewer to maintain equal attention across ten times as many lines. More important, they test the property the company cares about: the workflow completes, the data stays correct, permissions are respected, and failures become visible soon enough to limit damage.

Inspection Follows Risk and Evidence

Source review becomes targeted work. Changes with expensive failure modes receive inspection before release. Observed failures send an engineer to the responsible path with logs, inputs, and a violated contract. Strange performance points to the query or loop that produced it. A weak test exposes a missing specification before more code is generated against the same ambiguity.

Focused review gives the reviewer a question. Does this permission check fail closed? Can this migration be resumed safely? Why did these inputs escape validation? The source provides evidence toward an answer. A universal diff queue asks only whether every line looks reasonable.

Teams do not need one assurance method. Risk determines the mix. A generated CSS adjustment may need a screenshot and a viewport check. A billing rule may need examples, invariants, property tests, and human inspection. An authorization boundary may deserve all of those plus an adversarial review. Generated code changes the volume. It does not flatten the consequences.

Assurance Is the Engineering Question

Treating generated code as a build artifact changes how a team verifies software. Source Code Has No Value makes the separate business case: implementation complexity provides little durable protection from a functional substitute.

The engineering task is to move confidence out of universal line reading and into behavior that can be specified, tested, constrained, and observed. Source inspection stays where risk or evidence gives it a reason to be there.

Footnotes

1. The Clang compiler manual defines optimization as improving performance without changing program semantics, assuming the program has no undefined behavior. ↩