The Cult of Vibe Coding Is Insane

Bram Cohen (creator of BitTorrent) argues that "vibe coding" — deliberately refusing to look at AI-generated code — is dogfooding taken to a cult-like extreme. The trigger: Anthropic's Claude Code source code leaked and turned out to be full of duplication and redundancy. Cohen's explanation is that the team treated reading their own codebase as cheating.

Pure vibe coding is a myth

Cohen points out that even the most committed vibe coders are still making human contributions. They're using human language to direct the AI. They're building infrastructure: plan files, skills, rules, framework scaffolding. The machine works poorly without this structure. The claim of "no human contribution under the hood" doesn't survive contact with what's actually happening.

The leaked Claude codebase had things implemented as both agents and tools — obvious duplication that anyone could spot by reading the code. But reading the code was against the rules. You're only supposed to have "vague conversations with the machine about what it's doing."

How to actually use AI well

Cohen describes his daily workflow, and it's the opposite of hands-off. The pattern has three phases:

Phase 1: Audit and notice. Look at the code. Actually read it. Start conversations with specific observations: "Let's audit this codebase for unreachable code." "This function makes my eyes bleed." The AI is bad at spontaneously noticing mess. It will not tell you "hey, this is spaghetti, I should clean it up." But if you point at the mess, it can clean it up well.

Phase 2: Discuss until alignment. Use Ask mode (or equivalent) to walk through examples, share your reasoning, and — critically — correct the AI when it sycophantically agrees with something wrong. This is where the real work happens. You're not writing code, but you're doing the hard thinking: figuring out edge cases, establishing guidelines, making judgment calls about what belongs where.

Cohen gives a concrete example from the Claude leak: "There's a lot of things that are both agents and tools. Let's go through and make a list of all of them, look at some examples, and I'll tell you which should be agents and which should be tools. We'll have a discussion and figure out the general guidelines. Then we'll audit the entire set, figure out which category each one belongs in, port the ones that are in the wrong type, and for the ones that are both, read through both versions and consolidate them into one document with the best of both."

Phase 3: Execute. After enough back and forth — when you've stopped having new thoughts and the AI has stopped saying wrong things — tell it to make a plan and build. At this point it "zooms ahead" because you've already clarified the weird edge cases. It looks like one-shotting. It's not. The preparation was the bulk of the work.

This workflow still fits within the spirit of vibe coding, Cohen argues. You're reading the code, but you're only giving "high-level, conceptual, abstract ideas about how problems should be solved." The machine does all the actual writing.

Bad software is a decision you make

Cohen's core thesis is that AI doesn't cause bad software. Refusing to apply rigor causes bad software. The same was true before AI — "I have been screaming at my computer this past week dealing with a library that was written by overpaid meatbags with no AI help."

The difference AI makes is that cleanup is now cheaper. Historically, most projects carried so much tech debt that paying it down would consume a year of pure cleanup work. With AI, you can get that done in weeks, or pay it down gradually while still shipping features. "Helping you clean up mess is something AI is actually very good at."

The implication: the bar for acceptable quality should go up, not down. If cleanup is cheaper, there's less excuse for leaving duplication, dead code, and architectural confusion in place. People who produce bad software with AI are making an active choice — the same choice they'd make without AI, just faster.

How this connects

The audit-discuss-execute pattern is essentially human-in-the-loop applied to code quality rather than safety. The human isn't approving individual actions; they're setting the direction and criteria, then letting the AI execute at scale.

Cohen's observation that AI "is very bad at spontaneously noticing spaghetti code" is related to byzantine-fault thinking — the AI won't flag its own output as wrong. You need an external validator (the human reading the code) to detect divergence from quality standards.

The argument that software quality is a human decision regardless of tooling connects to individual-engineer-agency — the gap between what an individual can influence and the system-level outcome.

Bryan Cantrill's "The Peril of Laziness Lost" frames the same insight philosophically: Cohen's audit-discuss-execute loop is exactly the "virtuous laziness" that drives crisp abstractions — the hard upfront thinking LLMs skip.

James Bennett's theoretical case reaches the same conclusion from a different direction: the bottleneck in software development isn't code generation speed but essential difficulty (specification, design, testing the conceptual construct), and tools that only accelerate code production run into Brooks' math. Cohen's leaked-Claude-Code example is also central to Bennett's argument.

agentic-coding-fatigue takes the operational view: even with the discipline to read every line of generated code, the supervisor has a daily ceiling of about half a normal workday. Cohen's audit-discuss-execute is the right loop; 0xsid's point is that you can only run it for so many hours before the filtering judgment degrades.

The sharpest disagreement is with vibe-engineering (claude-is-not-a-compiler), which accepts Cohen's premise that the human must own quality decisions but rejects the audit phase as the way to do it — the human decides across every layer while reading almost none of the code, and divergence between independently built implementations (differential-spec-analysis) substitutes for reading. Cohen's "AI is very bad at spontaneously noticing spaghetti code" is exactly the claim that method is betting against, by asking several agents rather than one.

agentic-coding-is-a-trap adds the structural view: the supervisor role itself depends on skills that supervised work erodes — the skill-atrophy-supervision-paradox. Cohen's loop is one of the few mitigations that preserves the relevant skills, since the audit phase keeps the human reading code rather than just approving it.