--- title: Mitchell Hashimoto's 'I read the code' tweet broke the... description: A tweet from Mitchell Hashimoto sparked widespread debate about whether developers should read AI-generated code. The discourse surfaced three practical... canonical: https://daily.dev/posts/mitchell-hashimoto-s-i-read-the-code-tweet-broke-the-dev-internet-cqdrdqyfi twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Mitchell Hashimoto's 'I read the code' tweet broke the dev internet | daily.dev og:description: A tweet from Mitchell Hashimoto sparked widespread debate about whether developers should read AI-generated code. The discourse surfaced three practical... og:url: https://daily.dev/posts/mitchell-hashimoto-s-i-read-the-code-tweet-broke-the-dev-internet-cqdrdqyfi og:image: https://api.daily.dev/og/posts/CqdrDqyfi.png og:image:alt: Mitchell Hashimoto's 'I read the code' tweet broke the dev internet og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Mitchell Hashimoto's 'I read the code' tweet broke the dev internet **[Trends](https://daily.dev/sources/trends)** · 4 min read · 19 upvotes · 6 comments ## Summary 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. ## Content ## The tweet that started it 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. ## The hardliners 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. ## The "it depends" camp A lot of developers are landing on a three-way split based on what you're actually building: - **Throwaway MVPs and prototypes**: don't bother reading it, the idea is what matters - **Passion projects or anything you care about deeply**: read every line, you want full control - **Production work**: design at the interface level yourself, let AI handle implementation, but review the integration logic 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. ## The darker read 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. ## What actually changes your habits 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. ## Questions this post answers ### Do I need to read every line of code that Claude or Copilot generates before merging it? Opinions split by context rather than a universal rule. For throwaway prototypes, skipping a full read is fine since the idea matters more than the code. For passion projects, reading every line is recommended for full control. For production work, design the interface yourself and let AI handle implementation, but review the integration logic carefully before pushing. _Developers weighing how much AI-generated code to review can follow this debate on daily.dev._ ### What is the 'vibe bobsled' argument about AI coding? Christine Lemmer-Webber's term describes how the slide from careful AI-assisted review toward full vibe coding isn't really a choice but a product of speed incentives that erode oversight at every step, with no realistic checkpoint that holds. She cites Ka-Ping Yee's research showing expert programmers already fail to catch bugs in 100-line programs, while LLMs now generate far more code than that. _Anyone worried about oversight eroding under AI speed pressure can track this discussion on daily.dev._ ### What engineering habits actually make AI-assisted coding with tools like Claude, Copilot, or JetBrains Junie work well? Writing clear specs before asking for code, keeping tasks small, never letting the same AI review its own output, and enforcing strict diff size discipline. One developer who logged hundreds of hours with these tools on production services found these practices exposed weak engineering habits rather than being AI-specific tricks — they're just good engineering practices. _Teams refining their AI-assisted workflow can compare notes on these habits via daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@idoshamun** · 7 upvotes > 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 **@petermrozek** · 6 upvotes > 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? 😉 > > > Nobody audits the internals of a library they npm-install either. > > 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". > > > The concern isn’t that AI code is wrong... > > ...until it is. That's what "being non-deterministic" is all about... ## Similar posts on daily.dev - [Your vibe coded slop PR is not welcome](https://daily.dev/posts/your-vibe-coded-slop-pr-is-not-welcome-c8ehwuqtr) · Hacker News · 36 upvotes · 1 comments --- Tags: [#llm](https://daily.dev/tags/llm), [#ai-coding](https://daily.dev/tags/ai-coding), [#code-review](https://daily.dev/tags/code-review) [View this post on daily.dev](https://daily.dev/posts/mitchell-hashimoto-s-i-read-the-code-tweet-broke-the-dev-internet-cqdrdqyfi) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Mitchell Hashimoto's 'I read the code' tweet broke the dev internet","url":"https://daily.dev/posts/mitchell-hashimoto-s-i-read-the-code-tweet-broke-the-dev-internet-cqdrdqyfi","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/mitchell-hashimoto-s-i-read-the-code-tweet-broke-the-dev-internet-cqdrdqyfi"},"datePublished":"2026-07-15T02:19:40.924Z","dateModified":"2026-09-13T19:14:10.071Z","description":"A tweet from Mitchell Hashimoto sparked widespread debate about whether developers should read AI-generated code. The discourse surfaced three practical...","isAccessibleForFree":true,"articleSection":"Trends","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Trends","logo":"https://media.daily.dev/image/upload/s--ZfSp3asX--/f_auto,q_auto/v1780996004/logos/trends?_a=BAMAMiWQ0","url":"https://daily.dev/sources/trends"},"commentCount":6,"discussionUrl":"https://daily.dev/posts/mitchell-hashimoto-s-i-read-the-code-tweet-broke-the-dev-internet-cqdrdqyfi","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":19},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":6}],"keywords":"llm,ai-coding,code-review","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trends","item":"https://daily.dev/sources/trends"},{"@type":"ListItem","position":3,"name":"Mitchell Hashimoto's 'I read the code' tweet broke the dev internet"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/mitchell-hashimoto-s-i-read-the-code-tweet-broke-the-dev-internet-cqdrdqyfi","comment":[{"@type":"Comment","text":"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","datePublished":"2026-07-15T09:45:50.695Z","url":"https://daily.dev/posts/CqdrDqyfi#c-vJWeUePWq","author":{"@type":"Person","name":"Ido Shamun","url":"https://daily.dev/idoshamun","image":"https://media.daily.dev/image/upload/s---xy_OAwk--/f_auto,q_auto/v1703781380/avatars/avatar_28849d86070e4c099c877ab6837c61f0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":7}},{"@type":"Comment","text":"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? 😉\n\nNobody audits the internals of a library they npm-install either.\n\nYeah, 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”.\n\nThe concern isn’t that AI code is wrong…\n\n…until it is. That’s what “being non-deterministic” is all about - you never know when AI will derail.\n\nwrite clear specs before asking for code, keep tasks small and focused, never let the same AI review its own output\n\nIn 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.\n\nFor now, at minimum: read the diff before you push. That’s not a high bar. Clear it.\n\nThat’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.\nClearly, 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). 😉","datePublished":"2026-07-15T11:38:58.290Z","dateModified":"2026-07-15T15:20:09.106Z","url":"https://daily.dev/posts/CqdrDqyfi#c-BTMVOwtwg","author":{"@type":"Person","name":"Peter Mrożek","url":"https://daily.dev/petermrozek","image":"https://media.daily.dev/image/upload/s--pBfYX68K--/f_auto/v1769247960/avatars/avatar_Qz65P1nVw3Bu6C5YwaZgA?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":6}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/mitchell-hashimoto-s-i-read-the-code-tweet-broke-the-dev-internet-cqdrdqyfi#faq","mainEntity":[{"@type":"Question","name":"Do I need to read every line of code that Claude or Copilot generates before merging it?","acceptedAnswer":{"@type":"Answer","text":"Opinions split by context rather than a universal rule. For throwaway prototypes, skipping a full read is fine since the idea matters more than the code. For passion projects, reading every line is recommended for full control. For production work, design the interface yourself and let AI handle implementation, but review the integration logic carefully before pushing. Developers weighing how much AI-generated code to review can follow this debate on daily.dev."}},{"@type":"Question","name":"What is the 'vibe bobsled' argument about AI coding?","acceptedAnswer":{"@type":"Answer","text":"Christine Lemmer-Webber's term describes how the slide from careful AI-assisted review toward full vibe coding isn't really a choice but a product of speed incentives that erode oversight at every step, with no realistic checkpoint that holds. She cites Ka-Ping Yee's research showing expert programmers already fail to catch bugs in 100-line programs, while LLMs now generate far more code than that. Anyone worried about oversight eroding under AI speed pressure can track this discussion on daily.dev."}},{"@type":"Question","name":"What engineering habits actually make AI-assisted coding with tools like Claude, Copilot, or JetBrains Junie work well?","acceptedAnswer":{"@type":"Answer","text":"Writing clear specs before asking for code, keeping tasks small, never letting the same AI review its own output, and enforcing strict diff size discipline. One developer who logged hundreds of hours with these tools on production services found these practices exposed weak engineering habits rather than being AI-specific tricks — they're just good engineering practices. Teams refining their AI-assisted workflow can compare notes on these habits via daily.dev."}}]} ```