The Library · Perspective
Generated code is a draft, and drafts are useful
AI writes good code and does not write production systems. The gap is not competence at the line level; it is everything the line level does not contain.
Two things are true at once and the argument about AI coding usually insists on only one. Generated code is genuinely good — often better than what a hurried human would write for the same task. And a system assembled from generated code is not production quality, for reasons that have little to do with the quality of any individual line.
What generation is actually good at
It is very good at the local problem. Given a clear, bounded task with a stated interface, it produces idiomatic, reasonable code quickly. It is better than most people at recalling API surface, at boilerplate, at translating between languages, and at the first draft of a test suite.
Dismissing this is a mistake. The productivity gain on well-specified local work is large and it is not going away.
Every tile is internally clean and no two agree at the join. Nothing here is locally wrong, and the whole is incoherent — which is the characteristic defect rather than a broken function.
What a production system contains that a line of code does not
The gap shows up at a level generation does not operate on.
Invariants that span files. A system holds properties that no single function is responsible for: this identifier is always validated before it reaches that query; this cache is invalidated whenever that table is written. Generated code satisfies the local contract and is indifferent to the global one, because the global one was never in the context.
The reason a thing is the way it is. Much production code is strange for a reason — a race condition found in an incident, a vendor quirk, a regulation. Generation produces the obvious version, which is frequently the version that was tried and abandoned.
Failure behaviour under load. Correct on the happy path and correct at 3am under partial failure are different properties. The second is rarely in the prompt and is rarely in the output.
Consistency across time. Ten generated solutions to ten similar problems will be ten reasonable and mutually inconsistent designs. Coherence is what makes a codebase maintainable, and it is a property of the whole.
The failure mode this produces
The characteristic defect in a heavily generated codebase is not a broken function. Functions tend to work. It is that the codebase is plausible everywhere and coherent nowhere — every part reviewable in isolation, and the whole slowly becoming impossible to reason about.
This is worse than obviously bad code, which announces itself and gets fixed. Plausible code passes review, especially the fast review that generation makes tempting.
Using it well
The teams getting the most out of this treat generated code the way a good editor treats a first draft. It is genuinely valuable, it saves real time, and it is not the finished thing.
That means: keep the human accountable for the design rather than the typing. Specify interfaces and invariants before generating against them. Review for coherence and for the global properties, not for syntax — syntax is the part that is now reliably fine. And keep the test suite meaningful, because it is the only artefact that checks the properties a reviewer cannot hold in their head.