Stop Reading Every Line of Code  🔗 **Source:** [Stop Reading Every Line of Code](https://www.youtube.com/watch?v=434cG4g5KLE) > [!note]+ Document Notes > --- > tags: ["ai-assisted-development", "code-review", "software-testing", "experimental-code", "developer-productivity", "risk-management"] > author: "Theo" > source: "YouTube" > reference: "https://www.youtube.com/watch?v=434cG4g5KLE" > date_created: "2026-07-22" > --- > # 🏷️ Stop Reading Every Line of Code > ## 🧭 Table of Contents > - References > - Summary > - Main Content and Notes > - References > - Paraphrase > - Newsletter > - Action Items > - Hypotheses > - Methodology > - Questions > - Future Research > - Implications > - Learning Styles Assessment > - Accessibility Assessment > - DEIB Assessment > - Logical Validity > - DARVO Analysis > - Conclusion > - Refactor Appendix > - Template Library > ## 🔗 References > - [Original video](https://www.youtube.com/watch?v=434cG4g5KLE) > - [NIST Secure Software Development Framework](https://csrc.nist.gov/Projects/ssdf) > - [Google Engineering Practices: Code Review](https://google.github.io/eng-practices/review/) > ## 📝 Summary > **What happened:** Theo argues that developers should keep reviewing code that ships while generating far more disposable code for experiments, test harnesses, load tests, debuggers, API probes, and competing solutions. > **Why it matters:** AI changes the cost of writing code. The key distinction is no longer read versus do not read; it is production code versus temporary evidence-generating code. > **Stakeholders:** Developers, reviewers, engineering managers, security teams, regulated organizations, maintainers, and users affected by software failures. > **Risks:** The provocative title can be read as permission to skip review; generated test code can share the implementation’s blind spots; more experiments can create access, cost, cleanup, and supply-chain risks. > **Bottom line:** Do not reduce scrutiny on code that matters. Generate cheap, isolated code that attacks assumptions and improves the evidence used to review the small part that will ship. > ## 📖 Main Content > ### 1. Separate generated from shipped code > Most generated code in the proposed workflow never enters production. It exists to explore, test, measure, or explain. > ### 2. Scale verification around risk > Critical APIs and production changes still receive direct review. Disposable agents and harnesses can try more theories than a human would write by hand. > ### 3. Treat code as an investigative medium > One-off debuggers, load generators, data transformations, and sample clients become affordable when generation cost falls. > ### 4. Keep boundaries explicit > Temporary code belongs in isolated folders, repositories, or disposable infrastructure with no implied path to merge. > ### 5. Measure outcomes, not line counts > The speaker’s invented ratios explain the idea but do not prove productivity, safety, or quality. > ## 🗒️ Notes > - The accurate thesis is ‘write more cheap code,’ not ‘verify less production code.’ > - Generated tests are evidence only if their oracle and assumptions are independent of the implementation. > - Disposable code still needs secrets, cost, network, and cleanup controls. > - High-risk systems need formal assurance beyond code reading. > - The insults aimed at critics weaken an otherwise useful distinction. > ## 📚 References > - The transcript is the primary source for the speaker’s argument. > - NIST SSDF and established review guidance supply a baseline for code that reaches production. > - The productivity ratios in the video are illustrative and not observed data. > ## 🗣️ Paraphrase > 1. Developers often hear ‘stop reading code’ as a claim about merging unreviewed output. > 2. The speaker instead separates code that ships from code that generates evidence. > 3. When generation is cheap, teams can build more test clients, stress tools, debuggers, and alternate implementations. > 4. Production interfaces and critical changes still deserve direct scrutiny. > 5. The quality gain comes from using temporary code to challenge assumptions, not from counting generated lines. > 6. Teams need isolation and deletion rules so experiments do not become accidental dependencies. > ## 📰 Newsletter > ### Write more throwaway code, not less-reviewed code > The useful idea behind the inflammatory title is simple: keep the review bar for production, then surround that code with disposable probes, stress tests, sample clients, and competing implementations. Cheap generation can buy more evidence. It does not buy a waiver from judgment. > **WordPress angle:** Plugin and Core contributors can use disposable WordPress Playground sites, generated fixtures, and alternate patches to test a change while keeping the actual diff small and reviewed. > ## ✅ Action Items > ### DevRel > - Demonstrate an AI-generated test harness that never enters the plugin release artifact. > ### OSPO > - Define repository policy for generated experiments, licensing, provenance, and deletion. > ### Community > - Run a review workshop that labels production, test, fixture, and exploratory code before discussing scrutiny. > ### WordPress teams > - **Core:** Keep production patches small and reviewed; use generated fixtures to test edge cases. > - **Core Performance:** Measure user-visible cost before proposing a performance change. > - **Core AI:** Define safe disposable-agent patterns and independent test oracles. > - **Core Program Team:** Route cross-team work to named owners and a release milestone. > - **Mobile:** Check the equivalent task on small screens and with mobile assistive technology. > - **Playground:** Offer one-command sandboxes for throwaway experiments and failure injection. > - **Community:** Turn the strongest lesson into a contributor discussion with affected users represented. > - **Training:** Create a short exercise that keeps the authentic task and supplies safe practice. > - **Marketing:** State the user benefit without turning an example into proof. > - **Support:** Add a diagnostic question when the source exposes a recurring support failure. > - **Design:** Check focus, hierarchy, error recovery, comprehension, and alternate interaction paths. > - **Documentation:** Add a verified example and name its version, scope, and limits. > - **Photos:** Use inclusive media with accurate alternative text when visuals support the lesson. > - **TV:** Publish captions, a transcript, and chapter markers for any related recording. > - **Polyglots:** Flag terms that need translator context and test text expansion and right-to-left layouts. > - **Accessibility:** Test the relevant flow against WCAG 2.2 AA with manual assistive-technology checks. > - **Meta:** Check whether WordPress.org discovery, metadata, or contributor tools need a change. > - **CLI:** Support dry runs and machine-readable diffs for generated maintenance actions. > - **Hosting:** Translate operational claims into access controls, logs, backups, and tested recovery. > - **Tide:** Add an automated check only when it is deterministic and low-noise. > - **Openverse:** Use openly licensed supporting media and preserve attribution and descriptions. > - **Themes:** Test the result in both classic and block themes when presentation is involved. > - **Plugins:** Exclude experimental harnesses and secrets from release packages. > ### The WPCC > - Publish enterprise guidance for risk-tiered review and disposable agent sandboxes. > ### FAIR > - Keep generated verification artifacts portable and disclose model, prompt, dependencies, and license where retained. > ## 🧪 Hypotheses > - Teams that generate isolated verification code will find more defects without increasing production diff size. > - Risk-tier labels will reduce accidental merging of exploratory output. > - Independent test generation will find more failures than tests produced in the same prompt as the implementation. > - Disposable load tests will shorten performance feedback cycles. > - Teams without cleanup budgets will accumulate generated-code debt. > ## 📊 Methodology > - Randomize comparable changes to standard review or review plus generated probes and compare escaped defects. > - Track generated, reviewed, merged, deleted, and retained lines as separate categories. > - Use seeded defects and independent test oracles. > - Measure reviewer time, cloud cost, false confidence, and cleanup work. > - Stratify results by risk class and team experience. > ## ❓ Ques Every once in a while when I decide I want to film a video, I realize that there's almost no benefit to me because the video is going to frustrate both sides of the argument. This is definitely one of those cases because I want to talk about how much of your code you should be reading. I'm so scared to say this next part that I'm just going to put it on the screen instead. I think this is the case for the vast vast majority of engineers. Whether you're building slopside projects or you're building really important infrastructure that powers the world or medical devices that keep people alive, I think that the percentage of code you're reading is probably too high. It could also be too low, but for the most part, I think a lot of people, especially those who think their code is so so important, are reading way too much. But there's another side here that I think is even more important. You're not generating enough code yet. In many ways, that's actually the more important piece. And I think you'll understand after we talk about this for a bit. This video concept came from a tweet I made a few days ago. How much better do the models have to get before you'll stop reading the code? And the answer to this should not be as direct as many people seem to think. This is going to be quite a video and if I do it right, you should be able to come out of it with a better idea of how to get as much value as possible out of AI generated code. But first, a quick break for today's sponsor. Setting up O for your users is pretty easy. As long as your users aren't agents or enterprises, then it gets hairy fast. Thankfully, we have Work OS to smooth out those rough edges. They really understand what enterprises need for Oth, but that doesn't mean they're compromising on the developer experience. They still have all of the things you would expect from a modern O service through OHKit, their package system for getting the UI and connections necessary to set up O across every different framework you would possibly want to use. Your agents will be able to figure it out just fine. Their enterprise offerings are where they've historically shined because they have everything a business needs to sign up for your service. And businesses have a lot of very specific needs, including the admin portal, which makes it trivial for you to send a link to the IT team at the company you're trying to get to sign up for your service so they can onboard themselves. And if you want a company's agents to be able to register for your service, the new standard OMD, which has been pioneered by work OS, is probably your best bet. It's the first standard I've seen that actually makes sense for agents and will make it possible for your users to sign up without actually having to do it themselves. This is why companies like Cloudflare, Firecol, Reesend, Monday, and more have already adopted this new standard. Get your app ready for users, agents, and businesses at swivev.link/workos. Now that my first statement has absolutely destroyed the comment section, let's start talking about what's actually up here. Gonna start with my favorite, a spectrum. This is meant to be the importance of code spectrum. And on one side here, we have like slop website with one viewer. And on the other side, we have I don't know, I'll say firmware for pacemaker. How about that? No one could argue that the firmware on your pacemaker, the thing that keeps your heart beating, isn't really important and that a mistake on that would be really bad because it would literally kill people. All software kind of fits somewhere on this spectrum. And I don't want to pretend otherwise. I feel like the narrative around AI code and whether or not you should read it and verify and all of this is kind of plagued by this spectrum and people thinking it matters more than it does because everybody is somewhere on here. And if I'm being real, the code I write is not particularly far down it. Like I likely am in this range depending on how you want to define it if it's exponential or not. Whatever I don't care. I will gladly say Theo's code is nowhere near as important as the firmware on a pacemaker. What I've noticed is that a lot of people seem to think they're further along the line than they are. But more importantly, they think really really negatively about everything below them on this line. So whenever somebody makes a statement about AI generated code, the developer who hears it will think about where they are on the spectrum and if they like the statement, they'll assume that the person who's talking is where they are or better. And if they don't like the statement, they'll assume the person is where they are or below, probably below. This makes the conversation here nearly impossible because everybody is thinking too highly of themselves and more importantly thinks that the code they write matters way more than it does. I could sit here and argue all day with the people who are arguing against me because they think their code is so important. And what would I know? I generate rappers for LLMs. Doesn't matter that I built video infrastructure for years before that. But that aside, I don't want to have these arguments. I'm going to do a thing that I don't need to do. I'm going to presume the important code people are correct. I don't have to do this. I think these people are [ \_\_ ] full of themselves and most of them are stupid. But I don't want to argue that because that's not the point I want to make. We are presuming the people who are saying every line of code is important are being real. So let's dig into that statement. Every line of code is important in my work. We'll assume this is true. Every line of code that is being written, being put into a PR, being committed, being compiled, being shipped is so important that people could literally die if you get it wrong. I'll even go that far. If one line is wrong, people could die. In this case, I agree. If this is the case for the projects you're working on, you absolutely should be reading every line of code that gets shipped. But here's the other harsh reality I want you to consider. Code is useful for things other than shipping. If your code is so important that you need to be sure every single line is correct, maybe you could use more code that is less important to verify the important code. There is no person alive where 100% of the code they write is missionritical because if it is, they're not good at their job because you need to work on other things to hone your skills, to keep learning, to keep growing. But also, you can write code that is a little less important to verify the code that is so important. Let's talk about how things used to be. I'm just going to make up numbers for this, but the percentages are going to line up with what my experience was like in the past. Let's say in a given day back when I worked at Twitch, I would read, I don't know, let's say a thousand lines of code a day. This is a thousand lines of code I would read. Let's say I would write, I don't know, let's say I would write 200 or so. So I would write 200 lines of code and then through reading that referencing other code doing code reviews and everything else I would read a thousand lines and I would write 200. This made a lot of sense in a world where writing code was expensive and all the code we merged was important. So we had to take the time to read a ton of code others were writing because every time somebody wrote a line of code in hopes of getting it into prod, at least two people should read it before we give it a thumbs up and merge it or everything's going to slowly fall apart. This has changed. Whether or not we want to admit it, this has changed. And if it hasn't changed for you yet, you are not very good at your job right now. Period. Hear me out. Let's add one more metric here. We'll say that I read a,000 lines. I wrote 200. And let's say out of that 200, only 100 of them were good enough to merge. This ratio of 2:1 for my written code is not too bad. two underlines written for every hundred worth merging. Acceptableish. Let's presume you are similar to me and you're working on projects that are somewhat important but like if they break you can just revert and it's fine. This has changed a lot in that case. Nowadays I find myself reading maybe roughly the same amount of code but I have to move this to the side now because it's more complex. I might read a thousand lines of code a day, but I'm generating 2,000 plus. So, I might be reading a good bit, but I'm generating way more. And what I merge has increased. Let's increase a meaningful amount. We'll say it's 500 lines of code being merged a day. We're kind of in danger because there's a lot of code here that is being generated that is not being read. And that's scary. Except for the fact that most of this code that is being generated is not being put up for code review. It's not being merged. It's not being used for much of anything other than testing ideas. This did not used to make sense because back in my day when I learned how to code by hand, every line of code took time. So writing a shitload of code to do one quick thing never made sense. If you wanted to get an answer to a question about your users, you might have to write a hundred lines of code that you would stuff into the product to do new analytics and then you'd have to write another 20 or 30 lines of SQL in order to get the answer later on. That was obnoxious, but if the question was important enough, you could do it. The reality is that code is way cheaper now. You should be generating more code than you were before because code is so goddamn cheap. And now we get into the stupid push back that a lot of people have. If you're able to slop this amount of code, your product isn't that important and that's okay. I'm sorry, Lar, you are incredibly wrong here. Nev asked, "I write code for a financial ERP system. Mistakes in this code could be converted to huge losses for my companies who use this ERP system. Is my code important?" Probably. But you should be writing way more code. Hear me out. If your code is so goddamn important that every single line needs to be verified because it could bankrupt businesses, it could get people killed, it could stop people's hearts, it could drive cars into walls. If your code is that important, you should be writing an unbelievable amount of slop. Not to put in your product, but to verify your product. Every line of code that goes in should have a 100 lines of slop verifying it. Every line that goes in should have 10,000 lines of code of slop that you can use to verify the system. You should be building custom debuggers. You should be building custom runtimes that you can run your stuff in to verify them. You should be building the tools to guarantee the thing you care so much about keeps working. You cannot convince me that your code is so important that AI can't touch it. But it's not important enough to build verification systems. Oh, but our verification systems are so important. Those need to have every line of code checked, too. Okay, abstract one layer higher. Then, if the core of your code is too important for AI to touch and the layer around it is too important for AI to touch, then build one more on top of that. Build tools that introspect all of the runs that all of your testing tools are using. If you don't have a custom debugger for your software yet, you're not slopping hard enough. If you don't have custom logging systems tracking all the things that matter on top of the vetted ones you already wrote by hand, you're not slopping hard enough. If your code is so goddamn important that you talk [ \_\_ ] on people for only reading 10 to 20% of the code they generate in a given day, you're not doing your job well. Period. And I know this because I know a lot of the people working on these types of systems. Imagine how many lives will be ruined by doing this. Please elaborate. Kek, I'm listening. How does building sloppy debugging tools to use on top of the existing processes you already have hurt anyone? Please explain. Shiao says 80% of the code he generates goes into test harnesses and guardrails. And the LM has access to the results of the harnesses, which results in way less mistakes. That's a great way to do it. And if you write your code by hand or you review that code by hand, even if you review the test by hand, awesome. I'm cool with all of that. My argument isn't that you shouldn't read all the code you write. Let's let's flip this a bit to be a little clearer about what I mean here. Let's say you're one of the people who writes this really important code. And we'll say that you write, review, and verify 100 LLC a day. This code is super, super important. And this is all you wrote. You wrote the 100 lines. You verified the 100 lines. These 100 lines could get people killed. They're really, really important. So, you didn't write any additional code. You didn't read or review any additional code. This was your whole day. I am not saying that you should reduce the number of lines of code you read. If you write a 100 lines of code and you also read, let's say you read a bit more. Well, say previously you would write 100 lines and you would read 200 lines. 100 lines of code written and verified and 200 lines of code were read. If this is the case for you, this should not change. What I would say is today you should still write and hand verify 100 lines of code. Like don't change that. This is code is really important. Keep doing that. Maybe it even goes down a little bit. Maybe you only have time in the day to do 80 lines of code written and verified now. Unfortunate, but I know that's the case for a lot of people. Let's say you're sadly you can only write 80% of the code you wrote before. But now you review 400 lines of code instead. But you generate, and this is the difference. This is the thing I really need you guys to understand. You now generate 800 lines of code. And this 800 lines of code is absolute [ \_\_ ] slop. And you don't touch this in your actual product. This 800 lines of code sits in another repo or at the very least some other [ \_\_ ] up directory in your important repos. And all it does is explores. It verifies assumptions. It tests those 80 lines before in all the crazy ways that were never worth it before because writing a thousand lines of code to make sure one line of code works how it's expected to never made sense before. I am not telling people that they need to change how they verify the code that goes into prod. I'm not saying you need to merge slop into your projects. I am saying that if you are of the belief that your code is so godamn important that every line needs to be read or people will die, then you're not writing enough code yet. You're just not generating enough. That's all I am saying. If you put a little time into realizing that code is useful for things other than merging, it's useful for things other than updating your product. Code can do so much [ \_\_ ] I have like 10,000 lines of JavaScript I wrote on my Windows computer just for organizing files. That never made sense before. Writing 10,000 lines of code for a couple bespoke asset movements. Like I think I maybe moved like a 100 assets with it. 10,000 lines of code to organize a 100 files is mental illness until the code is free to generate. Then all of a sudden it's totally reasonable. And this is the thing people haven't internalized yet. They are correct that AI code is cheap. They are correct that AI code is bad. They are correct that AI code could get people killed if it's not verified properly. They are incorrect that code is expensive still. And if you can't find ways to use this cheap infinite code generating system to verify your existing systems, you are not a very creative engineer. The fact that code can be generated on a whim for any theory, for any question, for any problem you want to verify, for any step you want to debug, for anything, it's a magical thing. And it absolutely sucks that we don't get to experience this as end users because most people are letting AI code just generate slop and they're too lazy to check it. And I agree, that's a problem. And I am with you, that should be stopped. Important systems need more care and craft with the code going into them. But now we have a tool we can use to verify it harder to check it more. I never used to write custom lint rules. I wrote maybe one or two in my life. Now I generate custom lint rules all the time. I didn't used to make custom debug tools. I would rely on the ones that existed in the browser. Now, I will build my own one-off debuggers and systems and compiler hooks that add a bunch of stuff into my React code to try and see how it performs better. When I was testing how much load my systems could handle, I would have to hit up friends and like put together these complex tests. Now, I just tell Codeex, "Hey, you have access to AWS. Go spin up a bunch of [ \_\_ ] and stress test the system so I can get a better idea of how much traffic it can handle." The power of unlimited code is hard [snorts] to fathom. And if you're still thinking of code in that small box that is so important, I get why you're struggling to make this jump. But you need to realize important code is only part of your day-to-day. And if 90% of the code that you're touching in a given day is that important, you're just not touching enough code yet. And when your life had to be that way because every line of code was so important people could die, that got so ingrained in your head as it should because if it doesn't, people die. That era is over now. I'm not saying move faster. I'm not saying merge slop. All I am saying is that everybody can benefit some amount from the infinite code generator that we now all have access to on Bedrock, on codeex, on cloud code, on whatever. I'm not telling you to make your code cheaper. I'm telling you to make more cheap code. And that's a huge difference. And there are a ton of creative ways you can do this. If you're still reading all of the code, you're not generating enough of it. I'm not saying you should verify less code than you used to. I'm saying you should write more code than you used to. And you should be writing so much code that a lot of it isn't worth human attention. Reading code takes energy and effort and time. And it should. We shouldn't try to find ways to read code faster. We shouldn't try to find ways to merge unsafe things quicker. We should be finding ways to make the code we care the most about better, faster. Let's think about code in a funnel top to bottom where the majority of code is at the top and a very small percentage is at the bottom. This is meant to be a funnel of importance. There always be more code that is garbage than code that is super important. And this gap is going to widen rapidly over time. The top here I will clearly label as such. I would rather die than have anyone read this code. It's code that doesn't matter. It's code like the 10,000 lines I wrote to organize assets on my computer. I accidentally read 10 lines of it once. It's such slop that I'm offended that I did. No one should have to read the slop. Nobody should have to read the [ \_\_ ] people are generating unlovable for their like pet stores. And I agree there. And if you don't perceive a difference between that and the code inside of a pacemaker, you are making my job harder here because I'm trying to be realistic here. But there's stops between and these stops are valuable. It's I'll frame these as I'd like for this to work in the middle tier and I might and I'll get fired if it doesn't work for the tier below. I think this roughly represents the tears I think of code in. At the very top there's slop. At the very bottom there's death. And in between is where most of us actually live. Vast majority of people watching their code falls between this range where the code is important enough that like you'd be upset if it didn't work or the code is important enough that bad business things will happen, people will get fired, etc. We need to think about these types of code differently. And I would also argue, and this is probably the most important part, nobody spends all of their time in just one of these sections. Okay, slop coders that just use stuff like lovable spend most of their time here and probably don't go very far down. But people who write a lot of code at the very least hop between 1 through three. Some touch on this fourth layer, the really scary stuff. But all of us should be writing code in all of these ranges. The thing that changed, if we were to label these as tiers A, B, C, and D, the thing that changed is that tier D code was so expensive that spending any time in the other tiers just didn't seem valuable because it's just as much work to write bad code as it is to write good code if you're writing it by hand and you know how to write good code because it's hard to turn off your brain and all the demons that are like you have to make sure every line is safe. But realistically, we should all be doing more in these other ranges. Let's say you're one of these engineers working on pacemakers. And in the average day, the vast majority of the code you wrote was that Dtier. It was the death tier. People could die otherwise. I am not saying write less. I am simply saying you should draw a line between that code and everything else. And you should be writing a whole lot more of the everything else. But let's take a look at stuff that I do. Let's take a look at how I think of T3 code changes or how I think of lake bed changes. Some of that code is more important than other parts. DAX touches on this a little bit in his post here. Lately, after a big diff change, instead of reading the diff, I asked the agent for a summary of what it did in every file. Anything weird will stick out immediately and one to two prompts later, it's completely how he wants it. Files and function signatures he needs to know, but he cares less about the function body. Very much agree here. The way I would think of this is the engineers who wrote mostly tier C and B code should find the right ways to get the pieces that matter out of the parts that are in this tier so they can ignore more of the parts here. And figuring out where to cut these layers is important. I read all of the function signatures and all of the API definitions in Lakebed. Every single one. It is very important to me that the API and SDK are super solid because if they're not, it makes maintaining the project over time way harder. It makes future updates way harder. It massively increases the risk of future releases. So, I want to make sure those layers are as solid as possible. And part of how I do that is writing a shitload of slop to test it. One of my favorite things to do when I define a new API or SDK is to put it in a package that works on my machine and then go spin up 10 agents with much dumber models to build things on top of it. I absolutely love using Grock models, not for actually writing code that matters, but for writing absolute slop and to see if they despite being dumb are still capable of using these APIs. If they are awesome, I ship it. If they aren't interesting, I fix it. So to go back to the pacemaker people, let's say you are mostly writing code here in tier D, but you also have a bunch of tests and harnesses and wrappers and things verifying your work in tier C. I would agree those things are really important. If you have a test suite that you've slaved over to make sure your super important code continues to work as expected, awesome. I salute you. You should still be reading a lot of that and you should also be building systems to verify it, too. But maybe, just maybe, you could write more code up here. If you've built all these systems and you have all these tests and then somebody puts up a PR that you're really not sure about, maybe have an agent do some slop to try out three different theories and test all of them. Maybe have the agent write a new set of tests that don't exist yet for your one-off theory. Maybe you're curious if the code will be faster in Rust than it is in Go. So, you have an agent slop the whole thing over and then run the test suite against it. You know, it's not all going to pass. You know, it's not all going to merge, but it's going to answer important questions you might have. If you're not finding these opportunities, then you're not curious enough. You're not creative enough. You're not taking advantage of this once in a-lifetime opportunity we have here, the ability to generate infinite code. It's crazy how cool it can be. And I understand why you might feel differently. It's cuz the people in this top a tier are the most obnoxious people on Earth. the people who are shipping endless [ \_\_ ] code for services nobody [ \_\_ ] uses. They are the ones who are the loudest on social media and they are the ones that represent this new slop AI vibe coding movement. I hate them too. I need you to understand that we are on the same side. Even if I rage bait on Twitter a little bit, that doesn't mean there isn't value here. There's also the fact that you should probably have AI reading your code too. That's a whole separate rant I don't want to bog this down with. But generally speaking, I don't bother my team with code until multiple agents have verified it deeply. Use AI to review your code. It's actually really cool for that. I think this is the diagram that best summarizes my thoughts here on this type of important code. I will be clear, there are lots of other types of code where this level of hand review is not that important and you're probably merging a lot more too. But if your code is so important that you need this pipeline, please be realistic. Most importantly, I want you to be more creative. Find more ways to use code to verify the things that matter. If your code's important, you should write code that isn't to verify the code that is. You'd be amazed what you can come up with when you start treating code as more disposable, as throwaway for one idea, one theory, one question, one thing. Be creative, and you'll make awesome things happen. I've said all I have to on this one, and it seems like I pissed everyone off, which means mission accomplished. Go be more creative. Write more slop., Stop Reading Every Line of Code, youtube.com, 01ky54t62smz5751asny74she1.