this is not an anti-AI stance. this is an anti-idiot stance.

Mitchell Hashimoto said that last month when he banned AI-generated code from Ghostty without explicit contributor approval. I've been thinking about it ever since because it's the most honest thing anyone has said about vibe coding in six months of discourse that has mostly been people yelling past each other.

The discourse is this: vibe coding is either the future of software development or the fastest way to produce a codebase that nobody can maintain and nobody can secure and nobody fully understands. Both sides are correct. That's the thing. They are both empirically, provably correct, and the reason nobody can resolve the argument is that they are arguing about different populations of engineers doing different things.

Let me say what I actually think.

The research numbers are not ambiguous.

AI-generated code has 2.74x more security vulnerabilities than human-written code, according to CodeRabbit's analysis of 470 open-source pull requests. Pull requests per developer went up 20% with AI tools. Incidents per pull request went up 23.5%. More output. More incidents. Faster. 63% of developers say they spend more time debugging AI-generated code than they would have spent writing it. The METR study found that experienced open-source developers working on complex tasks were 19% slower when using AI tools than without them -- and reported feeling faster the whole time.

That last number is the one that should scare you. Not the vulnerability rate -- you can scan for those. The feeling of velocity that exists independently of actual velocity. The sensation of productivity without the productivity. You are shipping more PRs and introducing more incidents and it feels like you are going faster.

Daniel Stenberg shut down cURL's bug bounty after AI-generated submissions hit 20% of total reports. Not because AI submissions were slightly worse. Because triaging them was consuming maintainer time without producing anything useful -- and that time is not free. The open source ecosystem runs on maintainer attention. Flooding it with confident, coherent, wrong bug reports is not a contribution. It is a tax.

Here is the true thing that nobody wants to say.

Vibe coding is a multiplier. It multiplies what you already are.

Senior engineers with 3+ years of experience reported 40-50% productivity gains with AI coding tools. Junior engineers reported 15-25% gains -- and the gains are mostly illusory because junior engineers cannot reliably distinguish correct AI output from plausible-looking incorrect AI output. They are shipping code they cannot fully evaluate. The 40-50% gain is real because the senior engineer knows what correct looks like. They can skim the AI output and catch the wrong parts the same way they'd skim a junior's PR. The 15-25% gain is partly real and partly the Dunning-Kruger graph rendered as a token stream.

"But you can just review every line of the output--" If you are reviewing every line of AI-generated code, that is not vibe coding. That is augmented coding, which is a different thing with a different risk profile and generally positive outcomes. Vibe coding is specifically the pattern where you accept the output without fully understanding it. That is the whole definition. That is what "giving in to the vibes" means. The moment you are carefully reading and understanding the generated code before shipping it, you have exited the category the discourse is about.

The uncomfortable implication: vibe coding selects for the engineers who are already good enough to evaluate AI output quickly and confidently. It does not produce that ability. It rewards people who had it. For everyone else it is a competency laundromat -- the output comes out looking clean and still has the same stains.

The open source crisis is real and specific and different from the general vibe coding debate.

"Good first issue" labels on GitHub used to function as a filter. Opening a PR required reading code, understanding context, writing something coherent. That friction screened out unserious contributors. AI eliminated that friction entirely. Craig McLuckie from Stacklok put it directly: you file something as "good first issue" and in under 24 hours you are inundated with low-quality vibe-coded submissions that consume maintainer review time without producing anything mergeable. The filter broke. The tax on maintainer attention went up.

Hashimoto's Ghostty ban is the correct response. Not because AI-assisted code is bad -- Ghostty uses AI tools extensively and many of its maintainers use AI daily. Because accepting AI-generated contributions without requiring the contributor to understand and own the code destroys the accountability structure that makes open source work. You cannot merge code that nobody in the PR thread actually understands. That code will break and nobody will know why and nobody will be able to fix it without understanding what it was trying to do, which nobody does.

This is not anti-AI. This is anti-"I generated this with Claude and submitted it without reading it." Those are very different things and it matters that we say so clearly.

The part I find genuinely interesting: Linus Torvalds vibe coded the Python visualizer in his AudioNoise project in January. Put it in the README explicitly. "The Python visualizer tool has been basically written by vibe-coding."

Linus Torvalds. Who invented Git. Who has strong opinions about code quality that he expresses publicly. Who does not ship things he doesn't understand.

He vibe coded a throwaway tool component and said so openly. Because it's a throwaway tool component. Because the risk profile of a Python visualizer in a personal audio project is not the risk profile of production infrastructure handling customer data.

The argument was never "vibe coding is always bad." The argument is about where the risk profile of the code intersects with the consequences of getting it wrong. Throwaway weekend project: acceptable. Prototype to understand a problem: acceptable. Production authentication path in a system that handles payments: not acceptable -- unless you are reviewing every line with the same scrutiny you'd apply to a junior developer's first major PR, in which case you are not vibe coding, you are augmented coding, which is fine.

The discourse collapses this distinction and then argues about the wrong question for months.

What I actually do.

I use AI coding tools every day. I read the output. I do not merge code I do not understand. I treat AI-generated code the way I treat code from a very fast engineer with inconsistent judgment -- they produce a lot quickly and some of it is exactly right and some of it is confidently wrong in subtle ways and the difference is not always visible from the surface.

That is the correct mental model. Not "AI code is bad." Not "AI code is good." "AI code requires the same scrutiny as any other code -- and the scrutiny itself requires that you know what you're looking for."

If you know what you're looking for: vibe coding is a productivity tool.

If you don't know what you're looking for: vibe coding is a way to ship fast and break things in ways that are very hard to trace back later.

Both of those things are true. The population using these tools contains both types of people. The discourse is two groups of people describing their own experience accurately and assuming the other group is wrong.

They are both right. About different people.

"this is not an anti-ai stance. this is an anti-idiot stance."

hashimoto nailed it.

the idiot isn't the person using ai tools.

the idiot is the person who thinks using ai tools means they don't have to understand the code.

those are different people. the discourse keeps treating them as the same person. that's why the argument never resolves.