I finally understood why anti-AI luddites so fiercely deny generated code. The reason is exactly the one that made them deny automated tests a generation ago.
I understood this not from an article about AI, but from my own memory of people who, twenty years ago, used the exact same intonation to explain why you cannot trust automation but can trust your eyes.
How a healthy engineer behaves
You have an application. It does not matter who wrote it: you, your colleagues, a model, or somebody who downloaded it from the internet. A healthy engineer takes it and covers it with tests.
Emphasis: you cover the application, not the code. With functional and non-functional end-to-end tests. You simulate the conditions in which the application will run in production: under the corresponding load, with realistic data volumes, and you pull its levers with real operational tasks.
Non-functional tests are a separate class: load, resilience, security, data volumes, and other non-functional requirements from the customer and desired operating conditions. Not "does the form open," but "what happens to the system under real pressure."
If the application withstands all of this, it is fit for operation. The logic is simple: if you simulated operation on a staging environment faithfully enough, the application will perform the same functions no worse in real operation. This is not faith. This is what the entire discipline of testing has stood on for decades.
What the luddit answers
"Pfft, nonsense, neuroslop, this guarantees nothing. You have to read the code with your eyes."
Let us break this position down on its merits, because it deserves the breakdown — as any claim that looks sound but falls apart at first touch deserves.
You took a vibe-coded application and put it in an environment that is a copy of production. You loaded it with data that is a copy of production. You applied load that is a copy of production. You exercised every function exactly the way real users exercise it: with synthetic traffic or replayed recordings from real production logs.
And you saw: everything works. Memory does not leak. Keys do not leak to third parties. The database does not deadlock. Disk space does not run out. The network does not collapse. Vulnerability scanners show zero.
After all that, they tell you none of this guarantees anything, and you absolutely must read every line with your eyes.
One question: what exactly will reading lines with your eyes add to a staging environment that has already reproduced production in full? A human reading a diff will not see a memory leak under load — the profiler on the staging environment sees it. Will not see a deadlock on realistic data volumes — the load test catches it. Will not find a vulnerability faster than a scanner. The engineer's eye checks the author's intent for a line. The staging environment checks the system's behavior. In production, behavior works, not intent.
Where I have seen these people before
I started recalling where I had seen this way of arguing before. And I remembered. Wherever automated tests were being introduced.
The argument "for" was then word-for-word the same as the argument "for AI" now: you can write without staring at every line, and verify the result end-to-end instead of reading code by eye. Trust verified behavior, not manual inspection.
The argument "against" is mirror-identical, with the sign flipped: "the machine does not understand meaning," "this guarantees nothing," "a real engineer must walk the code by hand." Swap the word "automated test" for "AI" and you cannot tell a 2008 speech from a 2026 one.
Modern anti-AI luddites are exactly the same people who once resisted automated tests in favor of massive time sinks in manual review. Same role, same logic, same arguments that lost twenty years ago. History has already issued a verdict in this dispute — there is just different stage dressing now.
The loop, not the eyes
From this follows a practical conclusion that will outlive the entire debate.
If you provide AI coding with a normal QA process — the staging environment described above — a vibe-coded application works identically to one written by hand. Not "almost," not "with caveats." Identically in observable behavior, because what is being checked is exactly behavior under production conditions.
There is a live illustration of this thesis. A founder single-handedly rewrote a decade-old codebase on AI infrastructure: about six months without production incidents, 10–15 deploys a day. This is someone else's case, not my personal experience — but it shows exactly what is at stake: AI code plus a process equals reliability. Reliability comes from the process, not from the origin of the lines.
Manual line-by-line review of AI code is isomorphic to the old resistance to automated tests: a control ritual that feels like safety but does not produce it. Safety is produced by a behavior-checking loop. An eye over a diff does not produce it.
Who knows how to build this
The entire catch is that "just provide normal QA" is itself the work. A staging copy of production, synthetic load based on real logs, non-functional tests, quality gates, unified acceptance rules — this is not something that boots itself just because you are against luddites.
I built this loop with my own hands. At Korus — scaling automated tests on PHPUnit and Cypress, growing release reliability, formalizing quality control processes and quality gates at the department level. At UMI, the tracker had several thousand bugs hanging open at the start, with 5–10 new ones arriving daily; after introducing QA practices, systematic bug tracking, unified acceptance rules, and CI/CD, release quality and stability improved concretely.
That is the skill that turns vibe-coded into production-grade: not reading lines, but building an acceptance loop you can trust.
So the dispute over "reading code with your eyes" has been closed for a long time — it was closed back on automated tests. All that remains is to build the loop, and if you need someone who can assemble this loop in practice — you know where to find me.