The easiest way to dismiss someone using AI is to say they no longer care about the work.
A programmer says they no longer read every line an LLM writes. The response is immediate: they have abandoned code quality. Years of talking about software craft apparently disappeared the moment they trusted generated code.
That conclusion assumes reading the implementation created the quality.
Reading code is one control
Reading code can catch a great deal. A reviewer can spot a missing authorization check, a dangerous query, or an assumption that does not fit the rest of the system. For unfamiliar or high-risk code, inspection remains useful quality control.
It also has familiar limits. Reviewers miss things. Large diffs exhaust attention. Familiar patterns pass because they are familiar. Code can encode the wrong requirement and look clean while doing it. Humans have been approving plausible mistakes for as long as code review has existed.
Treating line-by-line inspection as the proof of professional care confuses an activity with its intended result. The result is confidence that the system will behave correctly, limit damage when it does not, and leave enough evidence to find out what happened.
Put the guarantee somewhere else
The strongest guardrails are enforced outside the model.
A database constraint does not care whether a query came from an experienced engineer or an LLM. Row-level security still applies when the generated code forgets a tenant filter. A server-side authorization check remains in force when a client asks for something it should never receive.
Capability-scoped tokens and network egress allowlists work the same way. They reduce the authority available to the code before anyone has to predict exactly how it might fail. A model with credentials for one tenant cannot quietly become a cross-tenant incident. A process that can reach three approved services cannot invent a fourth destination during a confused tool call.
These controls can be inspected and tested independently. They let a reviewer establish a worst case without simulating every possible mistake the model might make.
Bound the mistake before predicting it
Production systems fail in ways nobody predicted. Spend caps, rate limits, quotas, scoped credentials, and per-tenant isolation do not need a complete catalogue of those failures. They put a ceiling on what one mistake can cost.
A service allowed to spend ten dollars has a different risk profile from one holding an unrestricted billing credential. The code may be identical. The system is not.
Trust becomes proportional to the blast radius you are prepared to accept.
Recovery is evidence
Soft deletes, dry-run modes, staged rollouts, and restore-tested backups change the meaning of a mistake.
A backup that probably works is reassurance. A restore completed in staging last Tuesday is evidence. A dry run that shows the exact 1,847 rows about to be deleted gives a human something concrete to approve. A generic "Are you sure?" prompt becomes muscle memory within a week.
Reversibility makes trust testable. The team can run an operation against a bounded environment, inspect the actual effect, and prove that recovery works.
Some actions remain irreversible. Those deserve confirmation that names the real consequence. Delete these rows. Transfer this amount. Revoke access for these accounts. The decision should be attached to the diff, not hidden behind a polite dialog.
Reject ambiguity at the boundary
Schema and type validation matter most when they refuse malformed output.
Coercion is tempting. The model returned something close to the expected tool call, so the runtime repairs it and continues. That convenience weakens the boundary. Now the executable action is the product of two uncertain interpretations: what the model meant and what the coercion layer guessed.
A hard reject keeps the contract visible. The output satisfies the schema or it does not run. The model can try again with a precise error, but ambiguity never crosses into an action.
The boundary is explicit. Malformed calls do not run.
Trust needs a record
Append-only audit logs are another easy box to tick and ignore. A log nobody reads proves only that storage was available.
Detection is what makes the record useful. Someone has to review unusual tool calls, authorization failures, rate-limit events, destructive operations, and recovery attempts. Those observations turn repeated safe operation into evidence. They also expose near misses before they become the story people tell about why AI could never be trusted.
Without detection, "we have had no incidents" may mean the system is safe... or that nobody was looking.
Responsibility survives delegation
Generated code operating with broad credentials, weak tests, no recovery path, and no independent constraints deserves very little trust. Skipping review in that environment would be negligent.
A bounded change with independent constraints, tested failure paths, staged deployment, and a reliable rollback has a different risk profile. Reading every line may add confidence, but it is no longer the only evidence available.
The engineer still owns the outcome. That responsibility is expressed through the controls and the evidence supporting the change. Authorship does not alter it. Inspection does not complete it.
Disparaging someone merely for trusting an LLM avoids the useful questions. What was the model allowed to do? Which constraints remain effective when it is wrong? How large can the failure become? Can the change be reversed? Who will know when a boundary is hit?
The answers determine whether the trust is justified. The number of lines somebody read does not.
The one-line version
Trusting generated code is responsible when the surrounding system can reject, contain, expose, and recover from its mistakes.