Bram Cohen: the bad code isn’t from the AI — it’s from the rule that says you can’t look at the code

Bram Cohen — yes, that Bram Cohen, BitTorrent — published an essay arguing that the cult of vibe coding has taken dogfooding to a religiously absurd extreme. The Claude codebase, in his analysis, suffers from architectural duplication and code-quality problems that would be obvious to any engineer who looked at it for an hour. The reason nobody fixed them, he argues, is that looking under the hood is cheating. You’re only supposed to have vague conversations with the machine.

The core sentence in the essay is the kind that should be tattooed on a project wall: Bad software is a choice you make.

What Cohen is actually critiquing

This is not the standard AI writes bad code critique. Cohen is making a more specific argument: AI-assisted development is fine when paired with critical engagement. It becomes pathological when the methodology forbids critical engagement as a matter of principle.

His own practice, as described in the post, is the pragmatic alternative: have exploratory conversations with the AI to identify what’s wrong conceptually, then direct the AI to execute structured cleanup tasks. The AI does the keystrokes; the human does the architecture review. This works. It’s not vibe coding in the religious sense, because the human is allowed to look at the code, but it produces fast and clean output.

The category mistake Cohen is naming

Vibe coding as a movement collapsed two distinct things: (1) using AI as a coding accelerator, and (2) refusing to engage with the resulting code on principle. The first is a productivity move. The second is an ideological one. They got bundled together in the early hype, and the second became the implicit test of whether you were truly vibe coding or just using AI like a tool.

Cohen’s argument is that the bundle is a category mistake. You can absolutely have (1) without (2). And when teams that produce code with public consequences adopt (2) — refusing to look at the architecture, refusing to acknowledge that there’s a codebase to be looked at — they’re not being braver about AI. They’re outsourcing the parts of engineering that pay off long-term, and the consequences show up six months later as inexplicable bugs and structural debt.

What an indie builder should take from Cohen

The productive use of these tools is (1) without (2). Have the AI conversation. Generate the code. Then read the code, restructure it, and ask the AI to fix the structural problems you identify. This loop is slower than pure vibe coding by 20-30% and faster than hand-coding by 5-10x. It also doesn’t leave you with a 50,000-line codebase you’ve never opened, which is the position you don’t want to be in when a customer reports a bug at 3am.

Cohen’s essay is also a useful diagnostic for whether you’re working with a healthy team. If anyone on your team uses we don’t look at the code as a point of pride, the team has adopted ideology over practice. Course-correct now; the cleanup at year two is much harder than the conversation today.