“Let AI write it and have a human review it” sounds unanswerable and does not survive contact with practice.
AI produces hundreds of lines at a time. Reading every line before accepting it puts you back at the speed of writing it yourself, or slower, since reading someone else’s code is slower than writing your own.
Reading none of it does not work either. The question is not whether to read, it is where to look.
Here is what we do, and which mistakes produced it.
Attention is finite and should be spent deliberately
Start by admitting something: human attention on code decays quickly. By line one hundred you are scanning rather than reading; by line three hundred, reading and not reading are much the same.
So “read all of it” is in practice “read the beginning and pretend about the rest”, and errors tend to be in the rest — the beginning is usually the main logic and the end is edge handling.
Rather than pretending, choose a few categories to read properly and cover the remainder by other means.
Four categories that get read properly
1. Anything done in bulk.
Loops, batch replacements, regular expressions. This is where AI most reliably produces code that is mostly right — correct for ninety percent of inputs and quietly wrong for the rest.
We were caught by this: a string operation intended to strip a stray trailing quote was written as replacing a trailing letter u together with the quote. Every name ending in u lost a character.
Syntactically perfect, no error at runtime, and the output looked fine — unless you happened to inspect the few entries ending in u.
How to check: not by reading, but by running three or four real values through and looking at the result. Reading rarely finds this; running finds it immediately.
2. Anything that fails silently.
The most dangerous category, because there is no feedback. A wrong SEO tag raises nothing. A missing cache rule raises nothing. A missing page, a stale price in structured data — nothing.
AI corrects itself from feedback. Where there is none, it falls back on conventions from training, and conventions frequently do not hold in a particular project.
These have to be verified deliberately, because they will never come to you.
3. Anything shared.
Break a file belonging to one site and one site is affected. Break configuration shared by dozens and all of them are.
The care taken should differ by an order of magnitude. Our rule: back up shared things before editing, apply the change to one target first, verify, then widen.
4. Anything irreversible.
Deletions, migrations, domain changes, database operations. AI performs these as readily as it changes a colour and the consequences are not comparable.
Here we stop and work out how to undo the step before taking it. Five minutes, against not spending a day.
The rest is covered by mechanism, not by eyes
Code outside those four categories does not get read line by line. Three mechanisms cover it:
Validate before it lands. Files sync to a temporary directory, every one is syntax-checked there, and only a clean run overwrites production. One failure and nothing moves.
This came from an actual incident: a file with an unbalanced bracket uploaded directly, and the entire site went white for two minutes. We wrote up that episode.
Verify after installing. Deployment requests a set of key pages automatically and checks each response code. Anything other than 200 fails the deploy and prints the rollback command.
Another check followed later: after generating static pages, confirm the files for key pages exist. A missing page raises no error and merely becomes quietly slow.
Everything can be undone. All changes are in version control, rollback is one command, and it returns to precisely before a given change.
What these share is that none of them depend on someone remembering. Any step that does will eventually be forgotten — particularly when time is short, which is also when mistakes are likeliest.
An unintuitive conclusion
Working with AI, the investment worth making is not checking code more carefully but surfacing errors faster.
The error rate will not reach zero. Neither does a person’s. What decides the cost is how long an error survives between being made and being noticed.
Noticed in two minutes, it costs two minutes. Noticed in three months, it costs every affected visitor across three months.
So the same hour returns more spent on automatic verification after deployment than on reading twice before it. The first is deterministic; the second depends on how you happen to be feeling.
So what is the client buying
If AI writes the code and people merely arrange some checks, where is the value?
In those checks, and in knowing where they belong.
Using AI is not a barrier to anything — you could start this afternoon. What is difficult is knowing which places it fails silently, and putting something there in advance. That knowledge does not come from documentation. It accumulates one guard at a time, each added after something went wrong.
Our client projects run the same process, including the three mechanisms above. There is nothing proprietary in the configuration — this article is essentially all of it. The difference is whether someone actually built it, and whether they add the next one after the next incident.