The AI Wrote It. Nobody Read It. That's the Whole Problem.

Two identical capsules, two very different foundations

The image at the top of this article makes an argument in one frame. Two builds, same gleaming module on top, same three tools feeding both. Underneath one: taped ducting, improvised bracing, warning lights. Underneath the other: braced steel, labelled runs, serviceable panels.

The point is not that one team had better AI. They had the same AI.

That is worth sitting with, because most of the vibe coding debate is conducted as though the tools are the variable. They are not. The variable is what happens in the ninety seconds after the model returns its answer, and whether anyone is accountable for what that answer actually does.

The word means something much narrower than you think

Andrej Karpathy coined vibe coding on February 6, 2025. The full quote matters, because it is far more specific than the way the term is now used:

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension.

And then the line almost nobody quotes: "It's not too bad for throwaway weekend projects."

Karpathy scoped it to disposable software. He is one of the most accomplished engineers alive and does not need AI assistance at all. He was describing a mode of play.

Django co-creator Simon Willison sharpened the definition a few weeks later, worried the term was already escaping its intent. His formulation is the cleanest available: vibe coding means "building software with an LLM without reviewing the code it writes." And critically:

If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that's not vibe coding, it's software development. The usage of an LLM to support that activity is immaterial.

The usage of an LLM is immaterial. That is the caption on the image, stated by a working engineer. Willison also offers the most usable standard anyone has proposed: he will not commit code to his repository if he could not explain exactly what it does to somebody else.

Notice what that rule does not say. It does not say write it yourself. It does not say avoid AI. It says be able to explain it. That is a bar a fast, AI-assisted team can clear all day, and one a prompt-patch-ship workflow cannot clear at all.

Willison is not a sceptic, which is what makes him worth quoting. He has written at length about his own AI-assisted workflow and published dozens of vibe-coded experiments. His argument is not that the tools are dangerous. It is that two very different activities have collapsed into one word, and that collapsing them makes it impossible to talk sensibly about either.

AI amplifies what is already there

Google's 2025 DORA research, the long-running State of DevOps program, reached a conclusion that reads like a caption for the picture: AI does not fix a team, it amplifies what the team already has. Strong teams get stronger. Struggling teams find their existing problems intensified.

The mechanism is specific. DORA found AI adoption continues to have a negative relationship with software delivery stability. AI raises the volume of change. Volume of change is safe only if you have the control systems to absorb it: strong automated testing, mature version control, fast feedback loops. Without those, more change simply means more instability, faster.

DORA also names a cost that rarely appears in the ROI slide. The report describes a verification tax, where time saved during code generation gets reallocated to auditing and reviewing what was generated. The work does not vanish. It moves. And a team that has not budgeted for the move tends to skip it.

Roughly 30 percent of respondents reported little or no trust in AI-generated code, which is a rational position given the rest of the evidence.

The engineering press arrived at the same conclusion from the practitioner side. LeadDev's summary of the pattern is that AI does not create great developers, it amplifies them. A senior engineer using AI is a senior engineer moving faster, because they still recognise a bad answer when they see one. Someone without that judgement gets the same volume of output and no filter, and volume without a filter is the taped ducting in the picture.

This is also why the debate keeps stalling. Two people can report completely opposite experiences of the same tool and both be telling the truth, because they are running it on top of different foundations. It is the same pattern we saw at company scale when Meta tried to run itself on AI agents: more output, and a 40 percent rise in incidents.

What the security numbers actually say

Here is the finding that should end the "it is getting better every month" argument.

Veracode's 2026 GenAI Code Security Report tracked more than 100 models across four testing snapshots and found an average security pass rate of 56 percent, essentially unchanged from the previous year. The models got dramatically more capable. They did not get safer. Around 44 percent of code generation tasks introduced a risky vulnerability.

The breakdown is more useful than the headline.

Models performed reasonably on SQL injection and weak cryptography, which makes sense because those are the vulnerability classes most heavily represented in training data and most discussed in tutorials. Then they fell off a cliff on cross-site scripting and log injection.

That is not random error. It is a shape. Models are good at the security problems the internet has written a lot about and bad at the ones it has not. Which means the vulnerabilities most likely to survive into your production code are precisely the ones a non-specialist reviewer is least likely to recognise.

Separate research reported by CSO Online found output from dedicated vibe coding tools prone to critical security flaws, and security teams are now dealing with the sprawl: scanning across vibe coding platforms turned up roughly 380,000 publicly accessible assets built outside any security review, of which about 5,000 contained sensitive corporate information.

Confidently backwards

Statistics understate this failure mode, so here is what it looks like in production.

On the AI app platform Lovable, a generated backend implemented access control logic that was inverted. It blocked authenticated users and permitted unauthenticated ones. Not on one function. Repeated across multiple critical functions. The Register reported that a researcher demonstrated access to another user's data from a free account, extracting database credentials out of exposed source code.

Sit with the shape of that bug. The code ran. It passed a smoke test, because a smoke test asks "does the page load." It shipped. It was wrong in the exact direction nobody manually checks, because no human writing that function by hand would invert the condition and then not notice.

This is the characteristic risk of AI-generated code, and it is different from the risk of junior-developer code. Junior code fails visibly. It throws, it breaks, it looks wrong. AI code fails plausibly. It is syntactically clean, idiomatically correct, well-commented and confidently incorrect.

The supply chain version is worse because it is adversarial. Models invent package names that do not exist. Researchers from the University of Texas at San Antonio, Virginia Tech and the University of Oklahoma analysed 16 code-generation models and found roughly a fifth of recommended packages were fabricated. Attackers noticed. Security researcher Seth Larson named the resulting attack slopsquatting: register the hallucinated name on npm or PyPI, upload a payload, wait for the next developer to paste the same suggestion and run install.

It is not theoretical. A researcher at Aikido Security registered one hallucinated package name, react-codeshift, and traced it into 237 GitHub repositories. Had that been a real attacker, 237 codebases would have executed hostile code because nobody checked whether a dependency existed before installing it.

The speed that was not there, and the bill that was

The productivity case deserves the same scrutiny.

METR, a research nonprofit, ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks in their own repositories, some averaging over a million lines of code. Each task was randomly assigned to allow or forbid AI.

Be fair to the study's limits, because they matter. Sixteen developers is a small sample, these were experts working in mature codebases they knew intimately, the tooling was early-2025 vintage, and METR itself revised the experiment design in February 2026. This is one strong data point, not a law of nature, and AI is plainly faster for greenfield work and unfamiliar languages.

But the perception gap survives all those caveats, and the perception gap is the finding. Developers were wrong about their own speed by roughly 39 percentage points, in the flattering direction. If you cannot feel the difference between faster and slower, you certainly cannot feel the difference between secure and insecure.

Practitioners report the same thing from the other end. Stack Overflow's 2025 Developer Survey found trust in AI accuracy fell to 29 percent, down from 40 percent. The single largest frustration, cited by 66 percent, is AI solutions that are "almost right, but not quite," feeding directly into the second largest, that debugging AI-generated code takes more time, at 45 percent. And the number that speaks loudest to the human-in-the-loop question: 75 percent said they would still ask another person when they do not trust an AI answer.

Then the maintenance bill. Analysis from GitClear, reported by LeadDev, found code duplication rising sharply in the AI era, with an eight-fold increase during 2024 in blocks of five or more duplicated lines, while refactoring fell from about 25 percent of all code changes to under 10 percent. Copy-pasted lines overtook moved lines. As InfoWorld put it, AI coding debt is different from ordinary technical debt, because it accumulates faster than anyone reads it.

Duplication up, refactoring down, churn up. That is the left side of the picture, described in metrics: more stuff, less structure, nobody tending it.

What human in the loop actually means

The phrase has been worn smooth by overuse, so let us be concrete. In practice it means five things.

1. Somebody can explain every merged line. Willison's rule, and the only one that scales, because it does not require you to write the code, only to understand it.
2. Tests exist before the AI writes the implementation. Google has specifically highlighted test-driven development as a practice that amplifies AI success, and the logic is clean: a test written by a human encodes the intent, so an AI that satisfies it has been constrained by a human judgement rather than a vibe.
3. Security review is a separate pass, not a side effect of code review. Given a 15 percent pass rate on cross-site scripting, assuming your general reviewer will catch it is optimistic.
4. Dependencies are verified before install. Every package name gets checked for existence and provenance. This one is nearly free and defeats slopsquatting outright.
5. Someone owns it at 2am. Not the model. A person who understands the architecture well enough to debug it under pressure. That is what the right-hand side of the image is actually depicting: not prettier code, but serviceable code, with labelled runs and access panels, built by people who expected to come back.

What to actually do with this

If you are commissioning a website or an application and nobody can answer those questions, you are buying the left-hand side of the picture regardless of what the proposal says. That is precisely the review built into our web design and development work, and the same standard we hold ourselves to on AI-assisted content: a human accountable for every claim and every line.

The tools are extraordinary and getting better. The models on both sides of that image are the same models. What is under the hood is still a human decision, and it is still the only part that determines whether the thing survives contact with real users.

A note on sourcing: where a finding originates from a commercial security or analytics vendor, we credit the vendor by name in the text and link to the independent trade publication that reported it, rather than to the vendor's own page.