Two different bars
Working code produces the right output for the input you tried. Production code keeps producing sensible behaviour when the input is wrong, the network is down, two people do it at once, the data is ten times bigger, and the person reading it in a year is not you.
Generated code reliably clears the first bar. It clears the second only when you asked for the second — and by default, nobody does.
| Concern | Working code | Production code |
|---|---|---|
| Errors | Assumes success | Handles failure, and says what failed |
| Input | Trusts it | Validates at the boundary |
| Secrets | Hardcoded or in a comment | Environment variables, never logged |
| Logging | console.log left in | Structured, with enough to debug and no personal data |
| Concurrency | Not considered | Considered, or explicitly ruled out |
| Tests | None | Cover the edges, not the happy path |
| Deletion | Nobody knows if it's used | Traceable, so it can be removed later |
The gaps that recur
Errors swallowed rather than handled
A try/catch that logs and continues looks responsible and is often worse than crashing — the operation silently didn't happen, and you find out days later from a customer.
No validation at the boundary
Generated code tends to trust its inputs, because in the examples it learned from, the inputs were trustworthy. Anything arriving from a browser, a webhook, or a file upload needs checking before use.
The N+1 query
A loop that fetches one record at a time. Correct, readable, and fine with ten rows. At ten thousand it's ten thousand round trips, and it's the most common performance problem in generated data code.
// Generated: correct, and one query per order.for (const order of orders) { order.customer = await db.customer.find(order.customerId);} // Production: one query for all of them.const ids = [...new Set(orders.map((o) => o.customerId))];const customers = await db.customer.findMany({ where: { id: { in: ids } } });const byId = new Map(customers.map((c) => [c.id, c]));for (const order of orders) { order.customer = byId.get(order.customerId);}Dependencies added casually
A package pulled in to solve something small. Every dependency is a permanent obligation: updates, vulnerabilities, and a maintainer who may stop.
A second way of doing something
The model doesn't know your conventions unless you show them. Left alone, it introduces its own date formatting, its own error shape, its own fetch wrapper — each perfectly reasonable and each a fork in your codebase.
The audit, in order
- Does every external call have a failure path that a human would understand?
- Is every input from outside validated before it's used?
- Are there secrets in the code, in a comment, or in a log line?
- Does anything loop over a query, a network call, or a file read?
- Were dependencies added, and is each one worth permanent ownership?
- Does it match how this codebase already does this?
- Can you explain every line? If not, that line hasn't been reviewed.
When working code is enough
Not everything needs the second bar. A one-off script to migrate data you'll run once and delete needs to be correct that once. A prototype meant to answer a question and be thrown away is fine at the first bar.
The failure mode is the prototype that quietly becomes production — running for eighteen months, with nobody having decided it should. If a piece of code survives its intended lifetime, it has silently changed category, and the audit above is now overdue.
Common mistakes
- Shipping the first version because it ran on the first input
- Leaving a catch block that logs and continues on an operation that must not silently fail
- Missing the loop-with-a-query, which passes review and fails at scale
- Letting a prototype become production without a review it never had
- Accumulating three ways of doing the same thing across a codebase
Key takeaways
- Working code and production code are different bars, and only one is the default output
- The recurring gaps are error handling, validation, N+1 queries, dependencies, and convention drift
- A second, explicit request closes most of the gap
- Prototypes that outlive their purpose are the most common way this bites
Try it yourself
Take a piece of generated code already in your project and run the seven-item audit against it. Most people find at least two items — the useful outcome is knowing which two recur for you.