No, I'm Not Vibe Coding

The critics of AI-generated code are mostly right. That’s exactly why it doesn’t describe how I work.

Tell someone you build with AI coding agents and you can watch the verdict land on their face before you’ve finished the sentence. Across every repository you own? The words they’re reaching for are “vibe coder,” and they mean it roughly the way you’d mean “he lets the toddler drive.” I get it a lot, and it deserves a real answer, because they’re pointing at something that is genuinely worth worrying about. They’re just pointing at the wrong person.

Let me draw the line where it actually goes.

What vibe coding actually is

The term comes from Andrej Karpathy, who coined it in early 2025 to describe a specific way of working: you say what you want in plain English, an AI writes the code, and you accept it with barely a glance. You don’t really read the diff. You don’t fully understand what shipped. When something breaks, you don’t so much debug it as describe the breakage back to the model and hope the next version holds. The defining move isn’t that the AI writes the code. It’s that nobody looks at it. The vibes are the not-looking.

And in its lane, that’s fine. For a throwaway prototype, a weekend toy, a script you’ll run once, or a non-coder building something that would otherwise never exist at all, vibe coding is a small miracle. I’m not here to sneer at it. I’m here to say it’s a different activity than the one I do, even though from across the room the two look identical.

The critics are right

Here’s the part where I hand the microphone to the skeptics, because the honest truth is that the data is on their side.

A study late in 2025 worked through hundreds of open-source pull requests and found that code co-authored by AI carried something like 1.7 times as many major issues as human-written code: more logic errors, meaningfully more misconfigurations, and a security-vulnerability rate close to three times higher. That lines up with a quieter, stranger finding that keeps surfacing: developers report feeling more productive with these tools while measurably producing worse code. The subjective experience and the objective measurement point in opposite directions, which is precisely the condition under which people ship things they shouldn’t.

And then the number that says it all: roughly nine in ten developers now reach for AI coding tools every day, and fewer than a third trust what comes out. Adoption has sprinted miles ahead of governance.

If your workflow is “accept what the model wrote and move on,” those numbers are not a warning about somebody else. They’re a forecast of your next incident. The people calling that reckless aren’t gatekeeping a craft. They’re describing a real failure mode, accurately, with receipts.

So when someone tells me vibe coding is dangerous, I don’t argue. I agree.

Which is exactly why it isn’t what I do

Look again at each of those failures, though, and they all trace back to one root cause: nobody read the code. That’s the variable I removed, and removing it is the whole job.

There is a better name for the alternative, and it isn’t mine, which is part of why I trust it. By the middle of this year Karpathy himself had called vibe coding passé for professional work and offered a replacement: agentic engineering. The developer supervises the agents, writes the specs, reviews the diffs, and runs the evaluation loops. The AI does the typing; the human owns the architecture, the quality, and the correctness. The field drew that line on its own. I just happen to live on the near side of it. And supervising well means understanding the thing you’re supervising, which is the reason I pulled the whole stack apart down to the tokens: you cannot own the correctness of a system you treat as a magic box.

The difference between the two isn’t the tools. We use the same models. The difference is who owns the judgment, and whether anyone is actually looking.

The receipts

I’d rather show you than tell you, so here’s my real setup, laid directly against the failure modes from a minute ago.

Nothing reaches the main branch directly. Every change an agent makes arrives as a pull request, against a rule the agent can’t override. That alone catches the drift and the misconfigurations, because nothing lands unseen.

Every one of those pull requests gets reviewed before I ever look, by another program I built. It reads the diff for the specific ways agents go sideways: a leaked credential, edits wandering into files that were never in scope, missing tests, a dependency that quietly appeared. Leaked secrets and genuinely risky changes don’t earn a polite warning; they fail the check and block the merge outright. That is the answer to the three-times-higher vulnerability rate: the risky patterns don’t get a vote.

Then a human signs off. Me. Nothing merges because a machine felt good about it. It merges because I read it and decided it was right. If the industry’s problem is that only a third of developers trust the output, my answer is that I don’t trust it either. I verify it, every time, and I built the tooling so that verifying is cheap enough to actually do.

And the fences go up before any of it starts. Before an agent writes a line, there’s a written brief that spells out the goal, the constraints, and what “done” means. The agent doesn’t get handed an empty repo and a shrug. It gets a fenced yard, a task, and a supervisor.

I didn’t skip the review that vibe coding skips. I automated it, and then I put myself on top of the automation. I’ve written before about that gate on a single agent’s pull requests, and about running a whole estate of repositories this way. None of it works for a second if the human stops reading.

We actually want the same thing

I could tell you the loudest critics are simply afraid: of the tools, for their jobs, for a craft they spent years earning. Some of that is real, and pretending otherwise would be dishonest. But leaning on it would be a cheap way to dodge the actual argument, and it would make me sound like every hype merchant who ever waved off a legitimate concern as fear of progress.

Here’s the more useful truth. The critics and I want the identical thing: software that a human being understands and will stand behind. We disagree on exactly one point, which is whether an AI can be part of producing it. I think it can, but only if you build the discipline back in on purpose, because the tools will not supply it for you. That isn’t a rebuttal of the critics. It’s an agreement with them about the goal, plus a demonstration that the goal survives contact with the machine when you’re deliberate about it.

The real problem was never the AI

Step back and the whole debate collapses into that one gap: nine in ten adopting, fewer than a third trusting. The crisis isn’t that AI can write code. It’s that we started letting it write production code faster than we built the systems to govern what it writes. Agentic engineering, all the specs and gates and reviews and guardrails, is that governance layer. It isn’t a personal quirk of how I happen to like working. It’s where the whole industry has to go, because the alternative is shipping a rising tide of code that nobody read and nobody can vouch for, and then finding out the hard way what’s in it.

That’s why I open-source the guardrails instead of hoarding them. The failure mode belongs to everyone now. The fix should too.

The line, one more time

So picture that person again, the one whose face already filed me under “vibe coder.” We’re using the same models. We might even be typing similar prompts. The thing that separates us was never the technology. It’s that at the end of my loop, someone reads the code, owns the outcome, and can tell you exactly what shipped and why.

I’m not vibe coding. I’m supervising. The vibes are optional. The review never was.