Tag: ai

# "AI Code Needs Human Review" — And That's a Diagnosis of Your Manager

There is a popular assertion that code and scripts generated by a model must be reviewed manually — a human eyeballing every line the model produced. It sounds like common sense, like responsibility, like mature engineering culture.

Stop for a second. The assertion is insane. It makes working with AI slower and more pointless. Why use a model at all if you still need to attach an engineer to it — like a worker bolted to a machine? AI was invented to replace the engineer, not to slow the engineer down further.

<!--more-->

And the problem is not speed. The problem is whose bet you are making when you say this.

## Who benefits from making adoption look idiotic

The first people to champion this position are the Luddites. Those who do not want AI adopted at all — and therefore implement it in the most idiotic way possible, so the client waves it off and drops it on their own. Attaching a live engineer to read every generated line is the perfect way to bury the idea while formally "adopting" it.

But saboteurs are a sideshow. At least they are conscious of what they are doing. The real problem is deeper, and it is not about the executor — it is about the person above them.

## The manager who put production on a human being

A manager who insists on this way of working is relying on human control. Their production cycle now depends directly on human error.

They are throwing the entire history of industrial evolution out the window.

For centuries, industry has worked to remove the human from the equation — or at least push them off the critical path. Any modern production line is automation with a thin layer of replaceable people on top. If you have worked in any conveyor business, the first thing you saw was a system of regulations and rules that keeps the process running regardless of which specific person is standing at the machine today.

That is the goal of progress. Any system that depends on a specific human is unreliable.

## Professionals build systems, not shift schedules

Professionals build automated systems for control, verification, validation, and testing. The price of not doing so shows on the numbers — with no AI in the picture.

One product business, before a process overhaul, was catching 5–10 defects per day and shipping releases every few months. Once quality control, build, and deployment were put on automated rails — QA, CI, CD — the defect flow dropped to five per week, releases went weekly, and revenue grew 50%. Reliability did not come from a brilliant tester who "holds it all in their head." It came from a system that does not care who is having a bad day today.

With AI the logic is the same, just with more layers of control:

- **Guardrails** — rules enforced by machine, not by declaration. Not an instruction that "the engineer must remember and check by eye," but a technical checkpoint that cannot be bypassed. An independent Guardian with veto power.
- **Eval harness as a release gate** — layers of automated checks that let a change proceed only if it passes them, replacing a demo-grade "looks like it works" approval.

This matters for a specific reason. An AI failure does not look like a red error in the console. It looks like confident, smooth, dangerous text. A human reading the generation by eye is trying to catch the exact thing that is hardest to notice — on fatigue, on page ten, on a Friday evening. A system catches it identically on any day of the week.

Examples of these systems are laid out in open articles — take them and build:

- guardrails — https://www.dobryakov.com/blog/2282/
- AI code review — https://www.dobryakov.com/blog/2262/
- eval-harness — https://www.dobryakov.com/blog/2246/
- kafka two-phase commit — https://www.dobryakov.com/howto/kafka-two-phase-commit.html

## Your best person will call in sick

This is where the full picture opens.

When a manager says they rely on a specific person in their critical chain — one who might call in sick tomorrow, or whose judgment depends on whether they slept last night, or who might be having a bad day — what I see is a manager who cannot build reliable organizational structures and systems.

Manual review of AI-generated code is not "engineering maturity." It is a bet on a human in the critical path, dressed up as a virtue. And it is a losing bet by definition, because moving away from that exact bet is what production has been doing for the last two hundred years.

A manager who bets on the human will lose to the ones who know how to build systems. Inevitably.

## Run

So however flattered you are that your company trusts you with something this important — eyeballing AI-generated code by hand — run.

Run, or in a year a competitor who automated this will wipe you out.