Beyang

Cindy Sridharan

Gergely Orosz

<h2>The tweet that started it</h2>
Mitchell Hashimoto posted something simple: he reads the code Claude writes. That was enough to set off a week’s worth of discourse about whether reading AI-generated code is a professional obligation, a waste of time, or somewhere in between.
The timing matters. This landed alongside new model releases (Anthropic’s Fable and GPT-5.6), right as the “just vibe code it” crowd was feeling vindicated by increasingly capable agents. Hashimoto’s tweet read as a rebuke to that whole vibe.
<h2>The hardliners</h2>
Cindy Sridharan (@copyconstruct) put the sharpest stake in the ground: “Every time I hear people say ‘Claude wrote it all: I don’t understand how it works’, I decide that they can’t debug it, full stop. If you can’t debug it, you can’t own it. And if you can’t own it, anyone who cares about reliability or stability cannot trust you as a vendor.”
That’s not a nuanced take. It’s a line in the sand. And it’s resonating with the reliability-focused crowd who’ve watched AI-generated code sail through review and then explode in production.
On the other end, Sourcegraph’s Beyang Liu offered the pragmatist middle: “You don’t need to read every line of AI-generated code. But you should probably give that diff a quick once over before you push.” He posted this twice, which either means he really means it or he’s trying to calm two different audiences.
<h2>The “it depends” camp</h2>
A lot of developers are landing on a three-way split based on what you’re actually building:
<ul>
<li>Throwaway MVPs and prototypes: don’t bother reading it, the idea is what matters</li>
<li>Passion projects or anything you care about deeply: read every line, you want full control</li>
<li>Production work: design at the interface level yourself, let AI handle implementation, but review the integration logic</li>
</ul>
This framing is useful because it dissolves the binary. The people saying “I never read it” are often talking about prototypes. The people saying “you must read it” are usually thinking about production systems. They’re both right about different things.
<h2>The darker read</h2>
Christine Lemmer-Webber’s piece on what she calls the “vibe bobsled” is worth sitting with. Her argument: the slide from careful AI-assisted review toward full vibe coding isn’t a choice, it’s gravity. Speed incentives erode oversight at every step, and there’s no realistic checkpoint that holds. She cites Ka-Ping Yee’s research showing expert programmers failing to catch bugs in 100-line programs — and LLMs are generating far more than 100 lines.
She also coins “vibe sickness” for the broader feeling of AI-generated slop permeating open source, professional work, and everyday life. The uncomfortable part of her argument is that opting out is nearly impossible once the incentives are set.
Gergely Orosz amplified a related point: engineers need real-time feedback on whether their “AI slop factor” is creeping up. The implication being that most don’t know it’s happening until it’s already a problem.
<h2>What actually changes your habits</h2>
One developer who logged hundreds of hours with Claude, Copilot, and JetBrains Junie on real production services found something unexpected: AI didn’t just speed things up, it exposed weak engineering habits. The practices that made AI collaboration work — writing clear specs before asking for code, keeping tasks small, never having the same AI review its own output, strict diff size discipline — turned out to be good engineering practices that had nothing to do with AI.
That’s probably the most honest framing of where this lands. The “should you read the code” debate is really a proxy for a deeper question about ownership and accountability. The answer isn’t a rule about line counts. It’s about whether you understand what you’re shipping well enough to fix it when it breaks.
Right now, for most production work, that still requires reading the code. We’re not at the point where we can safely delegate that away — even if the models keep getting better at making it feel like we can.

Trends

A tweet from Mitchell Hashimoto sparked widespread debate about whether developers should read AI-generated code. The discourse surfaced three practical stances: skip it for throwaway prototypes, read every line for long-term projects, and for production work design at the interface level yourself while letting AI handle implementation details. Heavy AI users report that the tools reward existing engineering discipline — clear specs, small tasks, tight diffs. The emerging consensus is a low bar: at minimum, skim the diff before pushing, because LLMs make design decisions that compound over time, not just implementation decisions.

Mitchell Hashimoto's 'I read the code' tweet broke the dev internet

I don’t like strict rules. The good old “it depends” is the right answer. Sometimes you need or even must read the code, and sometimes it’s fine to do some testing and ship. Most of us don’t build space rockets or health systems. Don’t be too serious

Sure, don’t read anything. If you’ve got money to burn on millions of tokens then clearly you’ve got enough to pay any fines that will result from data leaks, right? 😉
<blockquote>
Nobody audits the internals of a library they npm-install either.
</blockquote>
Yeah, but that was based on the assumption that the people writing the library did that already. That it was verified to be complete, safe and ready for use before release. Now, you don’t have that assumption anymore, because you “just ship it”.
<blockquote>
The concern isn’t that AI code is wrong…
</blockquote>
…until it is. That’s what “being non-deterministic” is all about - you never know when AI will derail.
<blockquote>
write clear specs before asking for code, keep tasks small and focused, never let the same AI review its own output
</blockquote>
In short: write specs and hope for the best. How else are you going to verify that the code is written according to specs? The “other AI” can hallucinate as well.
<blockquote>
For now, at minimum: read the diff before you push. That’s not a high bar. Clear it.
</blockquote>
That’s the bare minimum I would require, but it’s not enough. Studies already show reading diffs doesn’t create the same type of awareness (and neural pathways) as creating a solution by yourself - you don’t learn how the system works as a whole. That’s where comprehension debt is created.
Clearly, I’m delighted by the idea that we’re making a non-deterministic system take over a discipline that should be handled as precisely as possible (software engineering). 😉