I can't believe he was right - CourtneyR.dev's 2nd Brain

I can't believe he was right. 🔗 **Source:** [I can't believe he was right.](https://www.youtube.com/watch?v=xBM307YwVRw) > [!note]+ Document Notes > tags: [ai-coding, software-development, claude-opus, developer-productivity] > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=xBM307YwVRw > date created: 2025-01-03 14:30 > > # 🏷️ Title: I can't believe he was right. >  ## 🧰 Action Inbox - [H1] Experiment with Claude Code for 30 days — track productivity metrics #ai-tools - [H2] Set up minimum inference spend for team — incentivize AI experimentation #management - [H3] Develop junior dev mentorship strategy for AI era — address capability building #education ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Dario Amodei Panel Discussion](https://www.youtube.com/watch?v=xBM307YwVRw) - [Claude Code Documentation](https://claude.ai) ## 📝 Summary - Dario Amodei's March prediction that AI would write 90% of code within 3-6 months was initially dismissed but has proven largely accurate - Industry data shows 30% of Microsoft code and 25%+ of Google code is now AI-generated, with senior developers reporting 50%+ AI assistance - The shift from writing code to reviewing/orchestrating AI-generated code represents a fundamental change in software development workflow - Junior developers face unprecedented challenges in skill development as traditional learning paths become less viable - Jevons paradox suggests increased demand for software development despite productivity gains ## 📖 Main Content Theo revisits Dario Amodei's controversial prediction about AI writing 90% of code, examining how the timeline played out and what it means for developers. The video explores industry statistics showing significant AI adoption, discusses the psychological shift from writing to reviewing code, and addresses concerns about junior developer career paths in an AI-dominated landscape. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/xBM307YwVRw?t=0) — [H1] Dario's controversial prediction - Key idea: In March, Dario predicted AI would write 90% of code in 3-6 months - Evidence: "We are not far from a world... where AI is writing 90% of the code" #### ⏱️ [01:20](https://youtu.be/xBM307YwVRw?t=80) — [H2] Boris's experience with Claude Code - Key idea: Anthropic developer now writes 100% of contributions using Claude Code - Evidence: "Every single line... across 259 PRs, all of it was done in cloud code and opus" #### ⏱️ [02:45](https://youtu.be/xBM307YwVRw?t=165) — [H1] Personal AI coding projects - Key idea: Theo built multiple complex projects entirely with AI assistance - Evidence: Built Chrome extension, image generation studio, and mobile app using Claude #### ⏱️ [06:15](https://youtu.be/xBM307YwVRw?t=375) — [H2] Industry adoption statistics - Key idea: Major tech companies report significant AI code generation - Evidence: "30% of code at Microsoft is AI... over 25% was written by AI" at Google #### ⏱️ [08:30](https://youtu.be/xBM307YwVRw?t=510) — [H1] Senior developers leading adoption - Key idea: 32% of senior devs report at least half their code comes from AI - Evidence: "More and more senior devs are the ones saying that lots of their code is coming from AI" #### ⏱️ [11:45](https://youtu.be/xBM307YwVRw?t=705) — [H2] Code review sentiment poll - Key idea: Most developers dislike code review but it's becoming primary job function - Evidence: "50% say hate it... 45% saying it's fine but it's tiring" #### ⏱️ [15:20](https://youtu.be/xBM307YwVRw?t=920) — [H1] Productivity transformation - Key idea: Generated 12,000 lines of code in one day versus typical 10-40 lines - Evidence: "According to various surveys, the average developer... writes between 10 and 40 lines" #### ⏱️ [18:10](https://youtu.be/xBM307YwVRw?t=1090) — [H2] Testing automation benefits - Key idea: AI makes rigorous testing more accessible and less burdensome - Evidence: "Tests have always been a chore... Agents are glad to write as many tests as we want" #### ⏱️ [20:45](https://youtu.be/xBM307YwVRw?t=1245) — [H1] System design still human-driven - Key idea: High-level architecture and design decisions remain human responsibilities - Evidence: "The programmer still needs to specify... what's the overall design decision" #### ⏱️ [25:30](https://youtu.be/xBM307YwVRw?t=1530) — [H2] Jevons paradox effect - Key idea: Cheaper code leads to increased demand, not job displacement - Evidence: "If code gets 10 times cheaper, the demand for code will go up by more than 10x" #### ⏱️ [28:15](https://youtu.be/xBM307YwVRw?t=1695) — [H1] AI code quality concerns - Key idea: AI-generated code creates 1.7x more problems than human code - Evidence: "AI code creates 1.7 times more problems... 2x at that 90th percentile" #### ⏱️ [32:40](https://youtu.be/xBM307YwVRw?t=1960) — [H1] Junior developer challenge - Key idea: Traditional skill-building paths may no longer be viable - Evidence: "I don't know how you get that experience now... I don't know what to say or recommend" #### ⏱️ [36:20](https://youtu.be/xBM307YwVRw?t=2180) — [H2] Developer capability perception - Key idea: 61% of viewers consider Claude Opus a better engineer than themselves - Evidence: Poll results showing majority rate AI capabilities above their own ## 📚 References - [Anthropic Claude](https://claude.ai) - [GitHub Actions Performance Studies](https://github.com) - [CodeRabbit Analysis Report](https://coderabbit.ai) - [Depot CI/CD Platform](https://depot.dev) ## 🗣️ Paraphrase - Dario Amodei's prediction about AI writing most code seemed absurd but has largely materialized, with industry data showing 25-30% AI adoption at major tech companies - Senior developers are embracing AI tools more than juniors because they're comfortable with code review and orchestration rather than direct implementation - The fundamental job of programming is shifting from writing code to reviewing and directing AI-generated solutions, similar to the natural progression from individual contributor to tech lead ## 📰 Newsletter **AI Coding Revolution: From Skepticism to Reality** What seemed impossible nine months ago is now everyday reality for many developers. Major tech companies report 25-30% of their code is AI-generated, with senior developers leading adoption at unprecedented rates. **Key Benefits:** - 10-100x productivity gains for certain tasks - Automated testing and documentation - More time for architecture and system design - Reduced friction for experimental projects **Practical Applications:** - Use AI for code generation, human oversight for review - Focus on prompt engineering and system design skills - Embrace the shift from writing to orchestrating code - Invest in learning how to effectively direct AI tools **Community Resources:** The WordPress community can leverage these tools for plugin development, theme creation, and core contributions while maintaining quality standards through rigorous review processes. Resources: [Claude Code](https://claude.ai), [Cursor Editor](https://cursor.sh), [GitHub Copilot](https://github.com/features/copilot) ## ✅ Action Items #### DevRel - Developer advocacy: Create AI-assisted coding workshops and demos with productivity metrics - Education: Develop curriculum for AI-first development workflows and best practices - Developer experience: Integrate AI coding assistants into documentation and SDK examples - Developer marketing: Showcase 10x productivity stories and case studies from real projects - Community management: Facilitate discussions on AI coding ethics and quality standards #### WordPress - Core: Evaluate AI assistance for issue triage, patch generation, and code review processes - Core Performance: Use AI to generate performance test suites and optimization suggestions - Documentation: Leverage AI for generating code examples and keeping docs current with core changes - Training: Create learning paths that combine AI tools with fundamental WordPress development skills - Community: Develop guidelines for AI-assisted contributions and quality standards - Plugins: Establish review processes for AI-generated plugin code and security considerations #### Community - Maintainers: Provide templates and tools for AI-assisted project management and code review - Contributors: Create onboarding programs that teach effective AI collaboration alongside traditional skills - Sponsors: Invest in AI coding infrastructure and training for community members - Ecosystem: Coordinate standards for AI-generated code quality and attribution ## 🧪 Hypotheses - Senior developers will increasingly adopt AI coding tools due to comfort with code review workflows - Junior developers will struggle more with AI adoption due to lack of foundational debugging skills - Code quality issues will increase initially but improve as AI models and review processes mature - Demand for custom software will increase significantly as development costs decrease ### 📊 Methodology - Survey developers across experience levels on AI coding adoption rates and productivity impacts - Conduct longitudinal study tracking code quality metrics in AI-assisted versus human-only projects - Measure time-to-deployment and bug rates across different AI coding tool implementations ### ❓ Questions - How can junior developers effectively build foundational skills in an AI-first development world? - What new mentorship models will emerge to transfer tacit knowledge about system design and architecture? - How will code review processes evolve to handle the increased volume and different error patterns of AI-generated code? ### 🔮 Future Research - Impact of AI coding on software security and vulnerability patterns - Effectiveness of different AI coding education approaches for early-career developers - Long-term effects on developer skill development and career progression paths ### 💡 Implications - Practice: Fundamental shift from writing code to orchestrating and reviewing AI-generated solutions - Education: Need for new curriculum focusing on AI collaboration, prompt engineering, and system design - Security: Increased importance of code review skills and automated security scanning for AI-generated code - Policy: Potential need for guidelines on AI code attribution, liability, and quality standards - Funding: Investment priorities may shift toward AI infrastructure and developer tooling rather than pure headcount ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (Flesch-Kincaid Grade Level) #### 👀 Visual learners - Present: GitHub PR screenshots, poll results, productivity comparisons - Improve: Architecture diagrams showing AI-human collaboration workflows, visual timelines #### 🔊 Aural learners - Present: Video format with spoken explanations and commentary - Improve: Audio-only version, podcast-style discussion segments #### 🗣️ Verbal learners - Present: Clear definitions of AI coding terms, analogies to traditional development - Improve: Glossary of AI coding terminology, comparison frameworks #### 🧩 Kinesthetic learners - Present: Specific tool recommendations and usage examples - Improve: Step-by-step AI coding tutorials, hands-on challenges #### 🧠 Logical learners - Present: Statistics, productivity metrics, structured argument progression - Improve: Decision trees for tool selection, ROI calculations #### 🧑‍🤝‍🧑 Social learners - Present: Community poll results, team collaboration examples - Improve: Discussion prompts for developer teams, peer review templates #### 🧘‍♀️ Solitary learners - Present: Individual productivity examples, self-assessment questions - Improve: Personal development checklists, reflection prompts #### 🌿 Naturalistic learners - Present: Evolution analogies, ecosystem thinking about tool adoption - Improve: Development lifecycle perspectives, tool ecosystem mapping ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings, descriptive video content - Improve: Detailed alt text for visual examples, structured data markup #### Keyboard navigation - Present: Standard video player controls - Improve: Timestamped navigation, keyboard shortcuts for sections #### Contrast and readability - Present: High contrast video player, clear audio - Improve: Closed captions, transcript formatting #### Text resizing and reflow - Present: Responsive video embedding - Improve: Scalable transcript layout, mobile-optimized viewing #### Media and captions - Present: Auto-generated captions available - Improve: Human-reviewed captions, downloadable transcripts #### Forms and interactions - Present: Standard YouTube interaction elements - Improve: Accessible poll interfaces, form labels #### Standards reference - Video content meets WCAG 2.2 AA for media alternatives ### 🌍 DEIB Assessment #### Cultural breadth - Present: US-focused perspective on tech industry - Improve: Global developer community examples, international AI adoption data #### Inclusive language - Present: Gender-neutral technical terms, defined jargon - Improve: Consider accessibility of rapid speech, cultural context for career progression #### Neurodiversity support - Present: Clear section breaks, consistent structure - Improve: Content warnings for rapid topic changes, summary sections #### Representation - Present: Individual developer perspective - Improve: Diverse developer voices, varied company sizes and contexts #### Psychological safety - Present: Honest discussion of uncertainty and challenges - Improve: Balanced perspective on job displacement fears, constructive framing ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Links industry statistics to broader adoption trends effectively - Inductive strength: Uses personal experience and community feedback to generalize about developer workflows - Causal reasoning: Connects AI capabilities to workflow changes with clear mechanisms - Analogical strength: Compares AI adoption to historical technological shifts appropriately #### Fallacies - Survivorship bias: Focus on successful AI adoption cases may miss failed implementations or resistant developers - Hasty generalization: Extrapolating from senior developer experience to all developers without sufficient sample size #### Tone of voice - Overall tone: Conversational and reflective, balancing enthusiasm with legitimate concerns about industry changes ### 🛡️ DARVO Analysis - Deny: No instances of denial patterns detected - Attack: No attacks on critics of AI coding tools - Reverse victim/offender: No victim/offender reversal present - Emotional cues and rhetoric: Genuine uncertainty and concern about industry impacts, particularly for junior developers ## 🎯 Conclusion Dario Amodei's prediction about AI writing 90% of code has largely materialized, fundamentally changing how software development works. While senior developers are embracing this shift due to their existing code review skills, the industry faces significant challenges in developing junior talent and maintaining code quality. The key for developers is to adapt by focusing on orchestration, system design, and effective AI collaboration rather than resisting the change. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] AI coding tools increase productivity 10-100x for experienced developers > [!quote] [I can't believe he was right.](https://youtu.be/xBM307YwVRw) by [[Theo - t3․gg]] via [[YouTube]]. Published 2025-01-03. Accessed 2025-01-03. > "I threw together a 12, --- ## Full Transcript [00:00] Remember back in March when Daario said [00:02] this [00:02] >> if I look at coding programming which is [00:05] one area where AI is making the most [00:07] progress um what we are finding is we [00:09] are not far from a world I think we'll [00:11] be there in 3 to 6 months where AI is [00:13] writing 90% of the code at the time I [00:17] thought this was one of the most absurd [00:18] statements I'd heard any tech CEO make [00:20] in history and it was and to be fair he [00:24] was wrong it actually took nine months [00:27] Boris is the developer in charge of [00:28] claude code. He did an update a few days [00:31] ago talking about how originally cloud [00:34] code was a side project and now it has [00:35] changed how he writes code and now he [00:38] barely ever opens an editor. Every [00:40] single line that he has done in the last [00:42] 30 days across 259 PRs, all of it was [00:46] done in cloud code and opus. Literally [00:49] 100% of his contributions to cloud code [00:51] were written by cloud code. Even here [00:53] like yeah he's an employee at the [00:55] company. Of course he's going to say [00:57] that. But then I started using cloud [00:59] code with Opus more. I built the Chrome [01:01] extension to lock me out of Twitter when [01:02] I don't have Cloud Code running to [01:03] incentivize me to use it more. And then [01:05] I built a whole new image generation [01:07] studio with a separate conversation view [01:09] where you can pick the photo you like [01:11] and do follow-ups with it with a more [01:13] dynamic editing experience. And then I [01:16] made it a mobile app, too. If you want [01:18] the details on all of that, a whole [01:19] separate video about how I use Cloud [01:21] Code is coming very soon. Make sure you [01:22] subscribe so you see that. But that's [01:24] not what I'm here to talk about today. I [01:26] want to talk about what Daario said on [01:27] this panel as well as the part right [01:29] after that I feel like is often skipped [01:31] when this conversation happens and what [01:34] this means for us as developers because [01:37] even if his timeline was slightly off, [01:39] Daria was absolutely correct. And since [01:42] I might not get paid for writing code [01:43] anymore, let's do a quick sponsor break [01:45] instead. There aren't many companies [01:47] that can proudly state that GitHub is [01:49] scared of them, but today's sponsor is [01:50] one of them. Depot is so much better at [01:53] running your GitHub actions that [01:54] Microsoft nuked the whole GitHub brand [01:56] just a few weeks ago trying to tax you [01:58] for using it. They have since delayed [02:00] those changes and even if they made [02:01] them, it would still be worth it because [02:03] Depot is that much better. We're talking [02:05] about realworld performance improvements [02:06] in the range of 37x for a project like [02:09] Post Hog. And remember, Post Hog's open [02:11] source. There's no magic tricks here. [02:13] You can go look at the code yourself and [02:15] see when the action suddenly started [02:16] taking this much less time. We're [02:18] talking a difference of over 2 hours [02:21] from a minute and 50 seconds to 4 [02:23] minutes. Let's be real super quick. How [02:25] much of your time are you wasting [02:26] chasing down failing builds that are [02:28] failing for no reason? How much time are [02:30] you spending waiting for your builds to [02:31] complete so you can actually merge the [02:33] code that you're changing? How much [02:34] hesitation do you feel to push up a new [02:36] change because you know the CI is going [02:38] to take another hour or two to run [02:39] before you can do anything? Imagine life [02:41] without any of those problems. Imagine [02:43] you put up a PR and the build just [02:45] works. There's no random errors or fail [02:47] cases that you hit because GitHub [02:49] actions are unstable. Imagine they're [02:51] happening in seconds instead of hours. [02:54] Imagine life without the hell that is [02:56] waiting on CI. If you haven't tried them [02:58] yet, you're wasting your time. Fix that [02:59] now at soyv.link/depo. [03:01] So, first and foremost, I want to go [03:04] through Daario's whole statement with [03:06] you guys. [03:07] >> I do have a fair amount of concern about [03:09] this. Um, on one hand, I think [03:12] comparative advantage is a very powerful [03:14] tool. If I look at coding programming [03:17] which is one area where AI is making the [03:20] most progress um what we are finding is [03:22] we are not far from a world I think [03:24] we'll be there in 3 to 6 months where AI [03:26] is writing 90% of the code and then in [03:30] 12 months we may be in a world where AI [03:32] is writing essentially all of the code. [03:35] When he first made this statement I did [03:37] a response because the way this is [03:40] measured is going to be really really [03:41] tough. First we have to define what the [03:43] code is. What is 90% of the code? Are we [03:47] talking about the code people are paid [03:49] to ship to production? Are we talking [03:51] about the code being written at [03:52] companies like Google and Microsoft and [03:54] Enthropic? Or are we talking about all [03:57] of code created from all of places? [03:59] Because I would imagine that the amount [04:01] of repos being instantiated and the [04:03] amount of code being written by tools [04:04] like lovable and vzero and bolt and all [04:08] of these types of things just by sheer [04:10] number of lines has changed the amount [04:13] of code being written year-over-year a [04:15] meaningful amount. I would be really [04:17] surprised if we had less than 2x the [04:20] amount of code written this year from [04:22] the year prior as in 2025 to 2024. I [04:24] know it's 2026 now. I'm sorry guys, but [04:26] you get the idea. 2025 probably had 2x [04:29] the amount of code or more written and [04:31] produced than in 2024. Does most of it [04:33] go in a garbage can? Sure. But way more [04:36] code came out. We can't disagree with [04:37] that. Like that's just table sakes. We [04:39] have to agree no matter what side we're [04:41] on that way more code happened last [04:44] year. That said, actual studies have [04:47] been done on the numbers for real [04:49] businesses. And according to Google's [04:51] little AI summary thing, from real [04:54] studies, [04:55] industrywide, the number is a little bit [04:58] lower. Apparently, 30% of code at [05:00] Microsoft is AI. Sundar said over 25% [05:03] was written by AI as of late 2024. I [05:06] don't know if we've gotten an update [05:07] since. Here's where things start to get [05:08] crazy, though. For senior devs, in [05:10] recent surveys, 32% report that at least [05:13] half their code is coming from AI. More [05:16] and more senior devs are the ones saying [05:17] that lots of their code is coming from [05:19] AI. This is one of the biggest shifts [05:20] that happened in 2025. It's no longer [05:24] just devs who are autocompleting some of [05:26] their code. It's no longer just [05:28] beginners who don't have the skills that [05:30] are using AI to make up for a skill gap. [05:33] It's now experienced developers using [05:34] these tools to make up for a time gap. [05:37] And I found myself doing the same. There [05:39] are so many random ideas I have for [05:41] systems, projects, features, and just [05:43] stuff I want to fix in my codebase. And [05:45] as the tools get better, the harnesses [05:47] get better, and of course the models get [05:48] better, the idea that this random thing [05:51] that maybe I would have previously cut a [05:53] Jira ticket for that would have sat in a [05:54] pit of backlog forever, now I can just [05:58] throw it at Opus, get some code, review [06:01] it on GitHub, and merge it. There's also [06:03] a problem here around what our jobs are. [06:06] Running a quick poll to see how much [06:09] people like code review. And as we see [06:12] with the initial results, 50% say hate [06:15] it. Even though there are four options [06:18] that are neutral or better. Now that the [06:20] polls continued going, it's fine but [06:22] tiring is going up. But we still have [06:26] 26% saying hate it, 10% saying neutral, [06:28] and 45% saying it's fine but it's [06:30] tiring. Very small percentage of devs [06:33] like or love code review. I'm in this [06:36] section. I would argue I'm in the like [06:38] it section. I do enjoy code review. I [06:40] wish I could justify doing more of it, [06:42] but my schedule is utter chaos, but I [06:45] like code review. I also think this is [06:47] just one of those things that you have [06:48] to get over over time as you become a [06:51] more experienced developer. Not that you [06:53] have to get over using AI tools, you [06:56] have to get over your own time spent [06:58] writing code. I actually had a long chat [07:00] with Mark not too long ago. If you don't [07:02] know, Mark is my CTO for T3 and all the [07:04] fun things that we built. Mark, now that [07:06] we have more staff, as in Julius is here [07:09] full-time in the US and Yosh still [07:11] contributes throughout his week when he [07:13] can, Mark's time isn't best spent [07:15] writing code anymore. Previously, the [07:17] flow was Mark would write most of the [07:19] code. Julius would go off and figure out [07:21] whatever weird problems, and I would [07:22] come in to do some steering and general [07:24] code review stuff. Now, I'm more removed [07:26] because there's too much [ __ ] going on. [07:27] Running the company is a lot of work, [07:29] and also not doing the best job as CEO. [07:32] trying to get more involved in the [07:32] codebase again, but it's not the best [07:34] use of my time, which means Mark has had [07:36] to bump out a little bit too to do more [07:38] of the orchestration and code review, [07:40] especially with the mobile app in [07:41] flight, too. Managing the team, building [07:43] the mobile app, managing the team, [07:44] building and maintaining the web app and [07:45] the servers and the back end, managing [07:47] upload thing, managing all the other [07:49] services that we maintain. He's not [07:51] writing code as much anymore. And as [07:53] most people will experience when this [07:55] happens in their career, that [ __ ] [07:57] sucks. You suddenly stop feeling [08:00] productive when you're not writing code [08:02] anymore. And previously, you would [08:03] measure your success in a day by how [08:06] much code you had written, how much time [08:07] you spent in your editor, and how many [08:09] problems you had solved. If you're [08:10] spending your time in the GitHub PR tab [08:12] and not in your editor, you feel like [08:14] you're not getting anything done. And [08:15] the amount of times Mark would have a [08:17] crazy day where he did a ton of code [08:19] review, got a ton of stuff shipped, [08:21] handled a ton of support cases, all [08:22] those things, but felt like he didn't [08:24] get anything done simply because he [08:26] wasn't in his editor at all. It's it [08:28] became like an everyday occurrence and [08:30] he was not loving that feeling because [08:33] it sucks and I've seen this happen to a [08:35] lot of developers as they move towards [08:36] management towards tech leads towards [08:39] roles where their job becomes less [08:41] writing code and more orchestrating [08:44] code. This is part of what makes a [08:46] senior engineer. This is the biggest [08:48] reason I think we are seeing that shift [08:50] where more and more senior plus devs are [08:53] reporting that a majority of their code [08:55] is coming from AI. We are more used to [08:57] reviewing code constantly. The average [09:00] dev still probably writes more code than [09:02] they review. The devs that have gotten [09:04] over that already, the ones who are [09:06] maintaining big open source projects, [09:07] the ones who are running teams with a [09:09] lot of engineers, the ones who are [09:10] building systems that require lots of [09:12] people doing lots of disciplined work. [09:14] Those are the people I've seen falling [09:16] the hardest in love with these AI tools [09:18] over the last few months. The people who [09:19] are already over that hump and are used [09:21] to that are the ones who are getting the [09:23] biggest benefits right now. There are [09:25] days where I'll file like 20 pull [09:27] requests and go through them all on [09:29] GitHub. I spend more time generating [09:31] code and then putting it on GitHub than [09:32] actually reading it in my editor at this [09:34] point. It's crazy. But that also sucks [09:36] for a lot of people. I know many [09:38] engineers, myself included, prefer [09:40] writing code to reviewing it. In fact, [09:42] from this poll, it seems like the vast [09:44] majority of developers very much prefer [09:46] writing code to reading it. I [09:48] understand. But that's a thing that will [09:50] suck about our jobs going forward. more [09:52] and more of our job is going to be [09:53] reviewing decisions and work that is [09:55] being done by these tools, not doing the [09:58] work ourselves. Sucks, but it is what it [10:00] is. And those who are willing to make [10:01] that jump are going to see crazy [10:03] success. Sucks when you started writing [10:05] code as a hobby. TBH, it feels horrible [10:07] having your hobby be automated. On one [10:09] hand, totally feel this. It has been [10:12] weird moving away. On the other, I have [10:15] two points. The first is this is the [10:16] natural progression of an engineer as [10:18] they get better. You need to learn to [10:20] delegate and do more talking and [10:22] orchestration and long-term planning and [10:24] managing of your team and the [10:26] development velocity and the changes [10:28] going in and how they're going in and [10:29] all of that. Like that is growth as an [10:30] engineer. Once you are good enough at [10:32] the code writing part, you have to get [10:33] better at those other things to keep [10:35] leveling up. There's a cap at how much [10:36] the code writing actually benefits you. [10:38] The other part of this side is that this [10:41] is what we've been doing as engineers [10:42] forever. We've been writing code to [10:44] automate things that were hobbies for [10:46] other people. We have already destroyed [10:48] so many fields with code. It was only [10:50] time that the fun parts of our field [10:52] started to erode. But I will counter [10:54] this by saying I'm having a lot more fun [10:55] coding overall lately. It's much more [10:58] fun seeing how far you can push these [11:00] agents and the crazy things they can do [11:02] and not feeling bad when you throw away [11:04] the code cuz it sucks. The worst feeling [11:06] ever is when one of your employees or [11:08] teammates or somebody you care about [11:10] goes off on a crazy tangent, deep dives [11:13] on something, builds a crazy solution, [11:15] and then for any of many reasons, it [11:17] just doesn't work. It doesn't fit the [11:19] project, you can't merge it, and you [11:20] have to close the PR. It hurts. It [11:23] sucks. It feels so bad to throw away [11:26] hard work that one of your co-workers or [11:28] peers or friends did. But if it was an [11:30] agent, I don't give a [ __ ] I just [11:31] closed the PR. So, I'm having a lot more [11:32] fun with experiments. I'm having a lot [11:34] more fun trying things out, playing with [11:37] new languages, overhauling code bases, [11:39] experimenting with new stuff. It's I'm [11:41] writing comically more code than I've [11:43] ever written. I threw together a 12,000 [11:45] line of code project in a day. What? [11:48] 12,000 lines of code in a day. According [11:51] to various surveys, the average [11:53] developer on the average day writes [11:55] between 10 and 40 lines of thoroughly [11:57] tested and debugged code. Opus and I [12:00] wrote 12,000. This might seem like cap, [12:02] but when you average it out, this is [12:04] very real. I know everybody in chat's [12:06] like, "No, that's stupid. That's [12:07] insane." Now, if you do a PR with 250 [12:11] lines of code, you start working on it [12:13] on Monday, you put up the PR Tuesday, it [12:15] takes two days to get thorough reviews. [12:17] On Thursday, you finally have a good [12:19] enough review and have to go make [12:20] changes. So, you make changes, and then [12:22] on Friday, it ships. That was 5 days for [12:24] 240 lines of code. That is That is about [12:27] right. And that's hilarious. That is [12:30] absurd. This is the 10 to 100x people [12:33] keep talking about is when it is [12:35] significantly easier to not just write [12:38] the code, but write the tests to [12:39] automate the testing process to set up [12:41] endto-end testing. GMO just posted about [12:43] this and the more I've thought about it, [12:44] the more I think he might be right. AI [12:46] coding will result in the most [12:47] rigorously tested, type checked, and [12:49] provably correct code in the world. [12:51] First, the testing and verification [12:52] feedback loop helps agents and prevent [12:53] slop. Yep. God, cloud code got so much [12:56] more usable when the LSP was added. It's [12:57] kind of broken, but it helps so much. [12:59] But the second part, tests have always [13:01] been a chore, but who doesn't love the [13:03] pile of check marks that a high test [13:04] count gives you? Agents are glad to [13:06] write as many tests as we want. Yep, the [13:09] pain of writing and maintaining test has [13:10] gone down a ton, and I'm starting to [13:11] rethink my own relationship with testing [13:13] for my projects. This is one of the [13:16] coolest parts. It would take me way more [13:17] time to write testing code than the [13:19] actual code because getting the test [13:20] right is hard and tedious and slow and [13:22] annoying and not actually the thing that [13:24] we like doing. Now the agent can do that [13:26] part and then do the implementation and [13:28] then put up the code and then do the [13:30] first pass on the code review and catch [13:31] any mistakes and then you go and look [13:33] over the like final pieces and give it a [13:35] thumbs up or down. It's a whole [13:36] different way of building and it is [13:37] changing how I think about software. [13:39] Back to the rest of the quote because [13:41] this is what I think a lot of people [13:43] have missed. [13:44] >> But the programmer still needs to [13:46] specify you know what what what are what [13:49] what are what are the conditions of what [13:51] you're doing? what you know what what [13:53] what what what is the overall app you're [13:55] trying to make? What's the overall [13:56] design decision? How do we collaborate [13:59] with other code that's been written? Um [14:02] you know, how do we have some common [14:04] sense on whether this is a secure design [14:06] or an insecure design? So, as long as [14:08] there are these small pieces that a [14:11] programmer, a human programmer needs to [14:13] do that the AI isn't good at, I think [14:17] human productivity will actually be [14:19] enhanced. I really want to emphasize [14:20] that part because it's a huge part of [14:22] what I love about coding. It's not just [14:25] the process of writing the beautiful [14:27] lines in my editor that I could stare at [14:29] and smile and screenshot and tweet. It's [14:32] the way I think about the system, the [14:33] way the parts come together, when the [14:35] right abstraction works in the right [14:37] place the right way and it all comes [14:39] together well. When you pull together [14:41] the set of tools you want to use and [14:43] they come together the right way or one [14:44] of them doesn't quite work how you need, [14:46] so you swap it out for something else [14:47] and it does work. And that feeling of [14:50] cohesion when you get the right parts to [14:52] work together. That's my favorite thing [14:54] when I'm writing code. When all of the [14:56] pieces come together and the result is [14:58] something awesome. Both a thing that [15:00] you're confident in your ability to [15:02] maintain and also a thing that is [15:03] actually pleasant to use for the product [15:05] that you're actually putting together. [15:07] This is awesome. I find this so fun. It [15:11] is different. It is strange. It's a [15:13] fundamental change in how we write code [15:15] every day. What does this mean about our [15:17] day-to-day work, about our careers, [15:19] about the people that we hire? About the [15:21] people we might have to fire? How is our [15:23] workforce going to change? A lot of [15:25] people said this prediction obviously [15:26] wasn't true because Anthropic not only [15:29] didn't fire 90% of their engineers, [15:31] they're actually still trying to hire [15:33] more, but they also have been doing a [15:36] lot more coding. In fact, Daario [15:38] actually mentioned this in a follow-up [15:40] when people were questioning his take [15:42] here. Thank you to FaZe for fixing the [15:44] audio in this clip so we can actually [15:45] listen to it. [15:46] >> I would say maybe 70 80 90% of the code [15:49] written in Enthropic is written by [15:51] Claude. You know, I said something like [15:52] this 3 or 6 months ago. People think of [15:54] it as falsified because they think of it [15:56] as like we're going to fire 70 80 or 90% [15:58] of the software engineers. But what [16:00] really happens is that the 10 the 10% [16:03] we're still writing, you know, humans [16:05] become managers of AI systems. There's a [16:07] shift because of the principle of [16:08] comparative advantage. So it looks more [16:10] normal than you think. I think [16:12] eventually it all, you know, kind of [16:14] eventually that logic may not hold, but [16:17] but there's a sort of sci-fi sheen to [16:19] these predictions to looking at the [16:21] future that it's going to be weird that [16:23] you'll be looking through different [16:25] colored glasses that there will be, you [16:27] know, that it'll look like Star Wars or [16:29] something. Um the often when these [16:31] predictions come true, it's wild, but [16:33] it's also in a way ordinary. Yeah, [16:35] they're just building more and that [16:37] makes a lot of sense. And you get used [16:39] to it and it no longer feels as crazy. [16:41] And I'm even feeling that a bit too. [16:43] Like when I'm just [ __ ] around in [16:45] cloud code, I don't necessarily feel [16:47] like, oh, this all happened at once. [16:49] It's when I left my computer and was [16:51] talking about it with friends that it [16:52] hit me just how absurd it is that I [16:54] built two projects without ever opening [16:56] an IDE. Like, that's just crazy. That's [16:59] absurd. So absurd that now Boris is [17:02] again doing all of his day-to-day work [17:04] in Claude Code 2. And Darren made a post [17:07] a few days ago about how you should [17:09] totally now be able to have one highly [17:11] skilled person doing the equivalent of [17:13] 10 engineers of work. Does this mean [17:15] that the industry will be slashed to [17:17] only the top 10% of engineers if that's [17:19] all that's needed? Shouldn't we be [17:20] concerned? I really like Simon's [17:22] response here. If code gets 10 times [17:24] cheaper, the demand for code will go up [17:26] by more than 10x. A whole bunch of [17:28] companies that previously couldn't [17:30] afford custom software will suddenly be [17:32] in the market for it. And existing [17:34] companies with multi-year road mapaps [17:35] will hire more to help get them through [17:37] it. This is known as Jevans paradox. The [17:40] Jeans paradox is a thing that occurs [17:42] when technological advancements make a [17:43] resource more efficient to use, thereby [17:45] reducing the amount needed for a single [17:47] application. But if the cost goes down [17:49] and the demand is price elastic, this [17:52] can result in demand increasing instead [17:55] causing the total resource consumption [17:56] to rise. And I think we're already [17:57] seeing this. There is definitely more [17:59] code happening. There are definitely [18:01] more companies more interested in [18:03] building their own internal tools than [18:05] I've ever seen. For example, at RAMP, [18:07] the finance management company for [18:09] startups, they have been building their [18:11] own internal tool that uses open code to [18:15] take some plain text description of work [18:18] and go do it. Here is one where they [18:20] asked, "What are the 20 most common [18:22] sensory issues in core? Spin up child [18:24] sessions fixing all of them." And [18:26] apparently it just worked. They looked [18:27] at the sentry issues and then spun up 20 [18:29] agents to go fix all of them and then [18:32] filed 20 poll requests. That's kind of [18:34] crazy. This does mean you're spending a [18:36] lot more time reviewing code, but also [18:37] the process of linking these things all [18:39] up like this. And I'm certain that 90 [18:42] plus% of the code in this inspect tool [18:44] that they made is probably vibe coded, [18:46] too. This is the thing that is changing [18:48] that is crazy. And the more you dive in [18:51] and play with it yourself, you'll find [18:53] the way you think about these things [18:54] changes. When you realize you can go [18:56] just spin up the tool and it's not that [18:58] much work, you'll try things you [19:00] wouldn't have tried. I'm considering [19:01] going as far as setting a minimum [19:03] inference spend for my team. I might [19:05] make it so everybody at T3 Chat is [19:08] expected to spend at least $200 a month [19:11] on inference so that they're going to go [19:13] out and try new strange [ __ ] I want to [19:15] see what they do when I put some [19:17] pressure on them to spend more money [19:19] rather than less because then they might [19:21] experiment a bit more and do some [19:22] crazier stuff. I'm probably going to do [19:24] that at this point. I've been thinking [19:25] about it too much. I want to I'm [19:27] probably going to. This fun report just [19:29] got linked while I was filming and I [19:30] wanted to include it because it's [19:31] another one of the reasons we have to [19:33] review the code that the AI is writing. [19:35] AI code creates 1.7 times more problems. [19:39] My initial question was when was this [19:41] published? because that will change how [19:43] I think about this report a lot. And I [19:46] couldn't figure it out, but everybody in [19:47] chat was saying they could see it. Check [19:49] this out. When I squash it down to [19:51] mobile size, it shows the date, December [19:53] 17th. And when I zoom out, we get this [19:56] sidebar that shows December 17th, 7 [19:58] minute read. But if you're zoomed in too [20:00] much for the sidebars to fit, but not [20:02] enough for it to trigger the mobile [20:05] mode, you don't get to see the values [20:07] there. Just one example of a bug that [20:11] occurs when you vibe code your UIs. Just [20:14] funny to see one of these bugs in the [20:16] article about how you find up to 70% [20:19] more of these in AI code than human [20:22] written code. This report was across 470 [20:25] PRs, including 320 that AI co-authored [20:28] and 150 that were human only using code [20:30] rabbit's structured issue system across [20:33] a bunch of open source projects. And [20:35] yeah, AI does accelerate the output, but [20:36] it also amplifies certain categories of [20:38] mistakes. Surprise, surprise, you get [20:40] the idea. One interesting piece is that [20:42] they only measured as per PR. They [20:45] didn't do per line of code. Also, high [20:48] issue outliers were more common in [20:50] AIPRs. So, you would randomly have a PR [20:53] that had way more issues. 1.7x at the [20:57] like average, but it's 2x at that 90th [21:01] percentile. So, when it does bad, it [21:02] does way worse. Cool information and [21:05] again more reason you need to be doing [21:07] the code review part. But this leaves us [21:10] with my biggest concern, the junior dev. [21:13] And I'll be honest, I don't know what we [21:15] can do about that. I built up these [21:17] skills by writing code for almost 20 [21:20] years. And those skills are still [21:22] essential in my day-to-day use of these [21:24] tools. Just knowing weirdness about how [21:26] CSS works and scroll containers being [21:28] strange in the browser. the amount of [21:30] times I've had to remind Claude Code [21:32] that it doesn't have the ability to have [21:34] a tool tip come out of a box when it has [21:37] any overflow rule set on it. I don't [21:39] know if you know this, but if you set an [21:40] overflow X rule on a box, you can't go [21:43] out of it Y direction. So, if you have [21:46] some behavior where it has a border [21:48] color when you hover over it, that will [21:49] get cut off. Or you have a little X [21:51] button in the corner of the square, [21:53] that'll get cut off. And I've had to [21:55] remind Opus about this so many times [21:58] that it suggested adding it for me to my [22:00] global quad MD file. Like you need to [22:03] know these things to be successful with [22:05] these tools. But these tools existing [22:07] drastically lowers the incentive to [22:09] learn these things because the cost of [22:11] doing it wrong used to be really high. [22:14] And the cost of figuring it out also was [22:16] really high. You would spend the time to [22:18] do it. Now, if you don't know the reason [22:20] these things happen, you can screenshot [22:22] the problem, show it to the model, and [22:24] say, "Hey, fix this." And there's a one [22:25] in three chance it does it right, and [22:27] then you keep doing that over and over [22:29] again forever. The amount of these types [22:31] of issues will go down constantly. But [22:33] also, the amount of work we have these [22:35] tools doing is going up constantly. If [22:38] it used to make one of these mistakes [22:39] every 100 lines of code, then it was [22:42] kind of useful. Now, it's every thousand [22:44] lines of code. Maybe they'll get to [22:46] every 10,000 lines, but it doesn't make [22:48] that bug any easier to solve with the [22:50] AI. And I don't know how you get that [22:52] experience now. I really don't. I've [22:54] been thinking a lot about this. I kind [22:55] of want to do a follow-up on my like [22:56] junior dev videos, like how do I think [22:59] about this for early career engineers [23:01] now. And I don't know what to say or [23:04] recommend. I still think it's really [23:06] important that you try to use these [23:08] tools not as a way to do work you don't [23:11] know how, rather to break apart and [23:15] delegate work that you don't have the [23:16] time to do. That's when they're [23:17] strongest. When you're using these tools [23:19] to multiply your own capabilities, not [23:22] to work around your lack of [23:23] capabilities. But I don't know how you [23:25] get those capabilities anymore. At the [23:28] absolute least, you need to read the [23:29] code that you're generating, especially [23:31] when you're early and you're spinning up [23:32] things that are actual projects you want [23:35] to maintain over time. Writing code [23:36] manually is still a very good way to [23:39] learn, but honestly, [23:42] I still think until you have gotten [23:44] relatively deep and are like multiple [23:47] projects in building things that real [23:50] people use, you should probably [23:52] prioritize using a chat app to ask [23:54] questions. Or maybe you can shortcut [23:57] this and use something like cursor and [23:59] use the ask mode where it doesn't change [24:01] code, it just answers questions to learn [24:03] more. Combine that with tab complete and [24:06] you can keep leveling up your [24:09] understanding. But man, this this [24:12] stuff's changing fast. And the thing I [24:14] never would have expected is that my [24:17] skills as a senior dev, which are mostly [24:19] orchestration and planning and [24:21] management of people doing things in [24:24] parallel. That part matters now more [24:26] than ever, which is cool on one hand [24:28] because now a lot of devs are going to [24:29] skill up on their talking skills. Like [24:30] prompting is more a comm skill than an [24:32] end skill in so many ways, but also like [24:36] you might not learn the ins and outs the [24:37] same way. This is tough. I don't really [24:40] know what I want to what my point here [24:42] is other than to express how confused I [24:44] am still. Oh [ __ ] Lero's here. Yeah, [24:47] apparently they're adding a teacher mode [24:49] to cursor, which is actually really [24:51] really really exciting, especially if [24:52] they let people do this on like a [24:54] student tier. Like if they're in school, [24:55] they get it for free. Oh. Oh, that'll be [24:57] so good. Also, tools like code crafters [24:59] are more useful than ever in my opinion. [25:02] Code crafters, bootupdev, stuff like [25:04] that that actually encourages real [25:06] project building. This is how you have [25:08] to learn now. And the AI will make it so [25:10] you're less likely to get blocked and [25:12] less likely to need somebody to help [25:14] carry you through the hard parts. Yeah, [25:16] know this is going too deep. I probably [25:19] need to think this through, like sit [25:20] down and really think about what works [25:22] and talk to some recent people who just [25:24] got into the industry and then maybe [25:25] I'll make a dedicated video on this. But [25:27] right now, I don't even know how to like [25:28] organize my thoughts on it. One more [25:31] question for you as a viewer of this [25:33] video. If I was to ask you, where do you [25:36] think you fit in terms of intelligence [25:38] and capability writing code against [25:40] Opus? Would you consider yourself a [25:41] better engineer, same tier roughly, or a [25:44] worse engineer? Where do you think you [25:47] fit? And what answers do you think my [25:49] chat would give? How do you think the [25:51] split would be of those? Think about it [25:53] for a sec. Get your idea of where you [25:55] would put yourself and where you think [25:57] the splits are for my own audience. [26:00] Ready for the results? [26:02] 61% of my viewers think that Opus 4.5 is [26:05] a better death than them. 16% did the [26:08] bailout answer. 13% said roughly as good [26:11] as me. And 10% said worse. That's where [26:13] we're at. These things are moving [26:15] absurdly fast. The way we code now is so [26:19] different from the way at the very least [26:20] I coded 3 to 4 months ago, which is way [26:23] different from how it was at the [26:24] beginning of the year, which is way [26:26] different from how it was the year [26:27] before. But the speed at which these [26:29] changes in my workflow are happening is [26:31] condensing. It's like every three months [26:33] now massive change happens. Previously [26:35] it was every six months. Then it was [26:37] every year. Then it was every few years. [26:40] It's crazy. Don't fall behind. I'm going [26:43] to do a whole dedicated video on how to [26:44] keep up on all of this in the near [26:46] future. I also have a video about my own [26:47] usage of cloud code that's coming very [26:48] soon. Keep an eye out for that. I'm very [26:50] excited about that one. So yeah, keep [26:52] playing with this stuff. Keep trying new [26:54] things and keep doing your best to build [26:56] the best possible things and take [26:57] advantage of the tools that exist around [26:59] you. Don't write this stuff off because [27:01] you're scared of grifters or people like [27:03] me who happen to have invested in a few [27:04] of these tools, almost none of which I [27:06] talked about today. Just focus on [27:08] building. That's what's going to get you [27:10] the furthest always. And there is more [27:12] to be built than ever. And there are [27:13] more ways to build than ever, too. I've [27:15] never loved code as much as I do today, [27:17] even if my relationship with it is very [27:18] different than it was a year ago. And I [27:20] recommend that you reflect yourself and [27:22] give these things a try. Let me know [27:23] what y'all think and how you're using [27:24] these tools today.  ## 📺 Video ![](https://www.youtube.com/watch?v=xBM307YwVRw) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: I can't believe he was right. ## 🧰 Action Inbox - [H1] Experiment with Claude Code for 30 days — track productivity metrics #ai-tools - [H2] Set up minimum inference spend for team — incentivize AI experimentation #management - [H3] Develop junior dev mentorship strategy for AI era — address capability building #education ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Dario Amodei Panel Discussion](https://www.youtube.com/watch?v=xBM307YwVRw) - [Claude Code Documentation](https://claude.ai) ## 📝 Summary - Dario Amodei's March prediction that AI would write 90% of code within 3-6 months was initially dismissed but has proven largely accurate - Industry data shows 30% of Microsoft code and 25%+ of Google code is now AI-generated, with senior developers reporting 50%+ AI assistance - The shift from writing code to reviewing/orchestrating AI-generated code represents a fundamental change in software development workflow - Junior developers face unprecedented challenges in skill development as traditional learning paths become less viable - Jevons paradox suggests increased demand for software development despite productivity gains ## 📖 Main Content Theo revisits Dario Amodei's controversial prediction about AI writing 90% of code, examining how the timeline played out and what it means for developers. The video explores industry statistics showing significant AI adoption, discusses the psychological shift from writing to reviewing code, and addresses concerns about junior developer career paths in an AI-dominated landscape. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/xBM307YwVRw?t=0) — [H1] Dario's controversial prediction - Key idea: In March, Dario predicted AI would write 90% of code in 3-6 months - Evidence: "We are not far from a world... where AI is writing 90% of the code" #### ⏱️ [01:20](https://youtu.be/xBM307YwVRw?t=80) — [H2] Boris's experience with Claude Code - Key idea: Anthropic developer now writes 100% of contributions using Claude Code - Evidence: "Every single line... across 259 PRs, all of it was done in cloud code and opus" #### ⏱️ [02:45](https://youtu.be/xBM307YwVRw?t=165) — [H1] Personal AI coding projects - Key idea: Theo built multiple complex projects entirely with AI assistance - Evidence: Built Chrome extension, image generation studio, and mobile app using Claude #### ⏱️ [06:15](https://youtu.be/xBM307YwVRw?t=375) — [H2] Industry adoption statistics - Key idea: Major tech companies report significant AI code generation - Evidence: "30% of code at Microsoft is AI... over 25% was written by AI" at Google #### ⏱️ [08:30](https://youtu.be/xBM307YwVRw?t=510) — [H1] Senior developers leading adoption - Key idea: 32% of senior devs report at least half their code comes from AI - Evidence: "More and more senior devs are the ones saying that lots of their code is coming from AI" #### ⏱️ [11:45](https://youtu.be/xBM307YwVRw?t=705) — [H2] Code review sentiment poll - Key idea: Most developers dislike code review but it's becoming primary job function - Evidence: "50% say hate it... 45% saying it's fine but it's tiring" #### ⏱️ [15:20](https://youtu.be/xBM307YwVRw?t=920) — [H1] Productivity transformation - Key idea: Generated 12,000 lines of code in one day versus typical 10-40 lines - Evidence: "According to various surveys, the average developer... writes between 10 and 40 lines" #### ⏱️ [18:10](https://youtu.be/xBM307YwVRw?t=1090) — [H2] Testing automation benefits - Key idea: AI makes rigorous testing more accessible and less burdensome - Evidence: "Tests have always been a chore... Agents are glad to write as many tests as we want" #### ⏱️ [20:45](https://youtu.be/xBM307YwVRw?t=1245) — [H1] System design still human-driven - Key idea: High-level architecture and design decisions remain human responsibilities - Evidence: "The programmer still needs to specify... what's the overall design decision" #### ⏱️ [25:30](https://youtu.be/xBM307YwVRw?t=1530) — [H2] Jevons paradox effect - Key idea: Cheaper code leads to increased demand, not job displacement - Evidence: "If code gets 10 times cheaper, the demand for code will go up by more than 10x" #### ⏱️ [28:15](https://youtu.be/xBM307YwVRw?t=1695) — [H1] AI code quality concerns - Key idea: AI-generated code creates 1.7x more problems than human code - Evidence: "AI code creates 1.7 times more problems... 2x at that 90th percentile" #### ⏱️ [32:40](https://youtu.be/xBM307YwVRw?t=1960) — [H1] Junior developer challenge - Key idea: Traditional skill-building paths may no longer be viable - Evidence: "I don't know how you get that experience now... I don't know what to say or recommend" #### ⏱️ [36:20](https://youtu.be/xBM307YwVRw?t=2180) — [H2] Developer capability perception - Key idea: 61% of viewers consider Claude Opus a better engineer than themselves - Evidence: Poll results showing majority rate AI capabilities above their own ## 📚 References - [Anthropic Claude](https://claude.ai) - [GitHub Actions Performance Studies](https://github.com) - [CodeRabbit Analysis Report](https://coderabbit.ai) - [Depot CI/CD Platform](https://depot.dev) ## 🗣️ Paraphrase - Dario Amodei's prediction about AI writing most code seemed absurd but has largely materialized, with industry data showing 25-30% AI adoption at major tech companies - Senior developers are embracing AI tools more than juniors because they're comfortable with code review and orchestration rather than direct implementation - The fundamental job of programming is shifting from writing code to reviewing and directing AI-generated solutions, similar to the natural progression from individual contributor to tech lead ## 📰 Newsletter **AI Coding Revolution: From Skepticism to Reality** What seemed impossible nine months ago is now everyday reality for many developers. Major tech companies report 25-30% of their code is AI-generated, with senior developers leading adoption at unprecedented rates. **Key Benefits:** - 10-100x productivity gains for certain tasks - Automated testing and documentation - More time for architecture and system design - Reduced friction for experimental projects **Practical Applications:** - Use AI for code generation, human oversight for review - Focus on prompt engineering and system design skills - Embrace the shift from writing to orchestrating code - Invest in learning how to effectively direct AI tools **Community Resources:** The WordPress community can leverage these tools for plugin development, theme creation, and core contributions while maintaining quality standards through rigorous review processes. Resources: [Claude Code](https://claude.ai), [Cursor Editor](https://cursor.sh), [GitHub Copilot](https://github.com/features/copilot) ## ✅ Action Items #### DevRel - Developer advocacy: Create AI-assisted coding workshops and demos with productivity metrics - Education: Develop curriculum for AI-first development workflows and best practices - Developer experience: Integrate AI coding assistants into documentation and SDK examples - Developer marketing: Showcase 10x productivity stories and case studies from real projects - Community management: Facilitate discussions on AI coding ethics and quality standards #### WordPress - Core: Evaluate AI assistance for issue triage, patch generation, and code review processes - Core Performance: Use AI to generate performance test suites and optimization suggestions - Documentation: Leverage AI for generating code examples and keeping docs current with core changes - Training: Create learning paths that combine AI tools with fundamental WordPress development skills - Community: Develop guidelines for AI-assisted contributions and quality standards - Plugins: Establish review processes for AI-generated plugin code and security considerations #### Community - Maintainers: Provide templates and tools for AI-assisted project management and code review - Contributors: Create onboarding programs that teach effective AI collaboration alongside traditional skills - Sponsors: Invest in AI coding infrastructure and training for community members - Ecosystem: Coordinate standards for AI-generated code quality and attribution ## 🧪 Hypotheses - Senior developers will increasingly adopt AI coding tools due to comfort with code review workflows - Junior developers will struggle more with AI adoption due to lack of foundational debugging skills - Code quality issues will increase initially but improve as AI models and review processes mature - Demand for custom software will increase significantly as development costs decrease ### 📊 Methodology - Survey developers across experience levels on AI coding adoption rates and productivity impacts - Conduct longitudinal study tracking code quality metrics in AI-assisted versus human-only projects - Measure time-to-deployment and bug rates across different AI coding tool implementations ### ❓ Questions - How can junior developers effectively build foundational skills in an AI-first development world? - What new mentorship models will emerge to transfer tacit knowledge about system design and architecture? - How will code review processes evolve to handle the increased volume and different error patterns of AI-generated code? ### 🔮 Future Research - Impact of AI coding on software security and vulnerability patterns - Effectiveness of different AI coding education approaches for early-career developers - Long-term effects on developer skill development and career progression paths ### 💡 Implications - Practice: Fundamental shift from writing code to orchestrating and reviewing AI-generated solutions - Education: Need for new curriculum focusing on AI collaboration, prompt engineering, and system design - Security: Increased importance of code review skills and automated security scanning for AI-generated code - Policy: Potential need for guidelines on AI code attribution, liability, and quality standards - Funding: Investment priorities may shift toward AI infrastructure and developer tooling rather than pure headcount ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (Flesch-Kincaid Grade Level) #### 👀 Visual learners - Present: GitHub PR screenshots, poll results, productivity comparisons - Improve: Architecture diagrams showing AI-human collaboration workflows, visual timelines #### 🔊 Aural learners - Present: Video format with spoken explanations and commentary - Improve: Audio-only version, podcast-style discussion segments #### 🗣️ Verbal learners - Present: Clear definitions of AI coding terms, analogies to traditional development - Improve: Glossary of AI coding terminology, comparison frameworks #### 🧩 Kinesthetic learners - Present: Specific tool recommendations and usage examples - Improve: Step-by-step AI coding tutorials, hands-on challenges #### 🧠 Logical learners - Present: Statistics, productivity metrics, structured argument progression - Improve: Decision trees for tool selection, ROI calculations #### 🧑‍🤝‍🧑 Social learners - Present: Community poll results, team collaboration examples - Improve: Discussion prompts for developer teams, peer review templates #### 🧘‍♀️ Solitary learners - Present: Individual productivity examples, self-assessment questions - Improve: Personal development checklists, reflection prompts #### 🌿 Naturalistic learners - Present: Evolution analogies, ecosystem thinking about tool adoption - Improve: Development lifecycle perspectives, tool ecosystem mapping ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings, descriptive video content - Improve: Detailed alt text for visual examples, structured data markup #### Keyboard navigation - Present: Standard video player controls - Improve: Timestamped navigation, keyboard shortcuts for sections #### Contrast and readability - Present: High contrast video player, clear audio - Improve: Closed captions, transcript formatting #### Text resizing and reflow - Present: Responsive video embedding - Improve: Scalable transcript layout, mobile-optimized viewing #### Media and captions - Present: Auto-generated captions available - Improve: Human-reviewed captions, downloadable transcripts #### Forms and interactions - Present: Standard YouTube interaction elements - Improve: Accessible poll interfaces, form labels #### Standards reference - Video content meets WCAG 2.2 AA for media alternatives ### 🌍 DEIB Assessment #### Cultural breadth - Present: US-focused perspective on tech industry - Improve: Global developer community examples, international AI adoption data #### Inclusive language - Present: Gender-neutral technical terms, defined jargon - Improve: Consider accessibility of rapid speech, cultural context for career progression #### Neurodiversity support - Present: Clear section breaks, consistent structure - Improve: Content warnings for rapid topic changes, summary sections #### Representation - Present: Individual developer perspective - Improve: Diverse developer voices, varied company sizes and contexts #### Psychological safety - Present: Honest discussion of uncertainty and challenges - Improve: Balanced perspective on job displacement fears, constructive framing ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Links industry statistics to broader adoption trends effectively - Inductive strength: Uses personal experience and community feedback to generalize about developer workflows - Causal reasoning: Connects AI capabilities to workflow changes with clear mechanisms - Analogical strength: Compares AI adoption to historical technological shifts appropriately #### Fallacies - Survivorship bias: Focus on successful AI adoption cases may miss failed implementations or resistant developers - Hasty generalization: Extrapolating from senior developer experience to all developers without sufficient sample size #### Tone of voice - Overall tone: Conversational and reflective, balancing enthusiasm with legitimate concerns about industry changes ### 🛡️ DARVO Analysis - Deny: No instances of denial patterns detected - Attack: No attacks on critics of AI coding tools - Reverse victim/offender: No victim/offender reversal present - Emotional cues and rhetoric: Genuine uncertainty and concern about industry impacts, particularly for junior developers ## 🎯 Conclusion Dario Amodei's prediction about AI writing 90% of code has largely materialized, fundamentally changing how software development works. While senior developers are embracing this shift due to their existing code review skills, the industry faces significant challenges in developing junior talent and maintaining code quality. The key for developers is to adapt by focusing on orchestration, system design, and effective AI collaboration rather than resisting the change. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] AI coding tools increase productivity 10-100x for experienced developers > [!quote] [I can't believe he was right.](https://youtu.be/xBM307YwVRw) by [[Theo - t3․gg]] via [[YouTube]]. Published 2025-01-03. Accessed 2025-01-03. > "I threw together a 12, --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=xBM307YwVRw)* **[00:00]** Remember back in March when Daario said this >> if I look at coding programming which is one area where AI is making the most progress um what we are finding is we are not far from a world I think we'll be there in 3 to 6 months where AI is writing 90% of the code at the time I thought this was one of the most absurd statements I'd heard any tech CEO make in history and it was and to be fair he was wrong it actually took nine months Boris is the developer in charge of claude code. He did an update a few days **[00:31]** ago talking about how originally cloud code was a side project and now it has changed how he writes code and now he barely ever opens an editor. Every single line that he has done in the last 30 days across 259 PRs, all of it was done in cloud code and opus. Literally 100% of his contributions to cloud code were written by cloud code. Even here like yeah he's an employee at the company. Of course he's going to say that. But then I started using cloud code with Opus more. I built the Chrome extension to lock me out of Twitter when **[01:02]** I don't have Cloud Code running to incentivize me to use it more. And then I built a whole new image generation studio with a separate conversation view where you can pick the photo you like and do follow-ups with it with a more dynamic editing experience. And then I made it a mobile app, too. If you want the details on all of that, a whole separate video about how I use Cloud Code is coming very soon. Make sure you subscribe so you see that. But that's not what I'm here to talk about today. I want to talk about what Daario said on this panel as well as the part right after that I feel like is often skipped when this conversation happens and what **[01:34]** this means for us as developers because even if his timeline was slightly off, Daria was absolutely correct. And since I might not get paid for writing code anymore, let's do a quick sponsor break instead. There aren't many companies that can proudly state that GitHub is scared of them, but today's sponsor is one of them. Depot is so much better at running your GitHub actions that Microsoft nuked the whole GitHub brand just a few weeks ago trying to tax you for using it. They have since delayed those changes and even if they made them, it would still be worth it because Depot is that much better. We're talking **[02:05]** about realworld performance improvements in the range of 37x for a project like Post Hog. And remember, Post Hog's open source. There's no magic tricks here. You can go look at the code yourself and see when the action suddenly started taking this much less time. We're talking a difference of over 2 hours from a minute and 50 seconds to 4 minutes. Let's be real super quick. How much of your time are you wasting chasing down failing builds that are failing for no reason? How much time are you spending waiting for your builds to complete so you can actually merge the code that you're changing? How much hesitation do you feel to push up a new **[02:36]** change because you know the CI is going to take another hour or two to run before you can do anything? Imagine life without any of those problems. Imagine you put up a PR and the build just works. There's no random errors or fail cases that you hit because GitHub actions are unstable. Imagine they're happening in seconds instead of hours. Imagine life without the hell that is waiting on CI. If you haven't tried them yet, you're wasting your time. Fix that now at soyv.link/depo. So, first and foremost, I want to go through Daario's whole statement with **[03:06]** you guys. >> I do have a fair amount of concern about this. Um, on one hand, I think comparative advantage is a very powerful tool. If I look at coding programming which is one area where AI is making the most progress um what we are finding is we are not far from a world I think we'll be there in 3 to 6 months where AI is writing 90% of the code and then in 12 months we may be in a world where AI is writing essentially all of the code. When he first made this statement I did **[03:37]** a response because the way this is measured is going to be really really tough. First we have to define what the code is. What is 90% of the code? Are we talking about the code people are paid to ship to production? Are we talking about the code being written at companies like Google and Microsoft and Enthropic? Or are we talking about all of code created from all of places? Because I would imagine that the amount of repos being instantiated and the amount of code being written by tools like lovable and vzero and bolt and all **[04:08]** of these types of things just by sheer number of lines has changed the amount of code being written year-over-year a meaningful amount. I would be really surprised if we had less than 2x the amount of code written this year from the year prior as in 2025 to 2024. I know it's 2026 now. I'm sorry guys, but you get the idea. 2025 probably had 2x the amount of code or more written and produced than in 2024. Does most of it go in a garbage can? Sure. But way more code came out. We can't disagree with that. Like that's just table sakes. We **[04:39]** have to agree no matter what side we're on that way more code happened last year. That said, actual studies have been done on the numbers for real businesses. And according to Google's little AI summary thing, from real studies, industrywide, the number is a little bit lower. Apparently, 30% of code at Microsoft is AI. Sundar said over 25% was written by AI as of late 2024. I don't know if we've gotten an update since. Here's where things start to get crazy, though. For senior devs, in **[05:10]** recent surveys, 32% report that at least half their code is coming from AI. More and more senior devs are the ones saying that lots of their code is coming from AI. This is one of the biggest shifts that happened in 2025. It's no longer just devs who are autocompleting some of their code. It's no longer just beginners who don't have the skills that are using AI to make up for a skill gap. It's now experienced developers using these tools to make up for a time gap. And I found myself doing the same. There are so many random ideas I have for **[05:41]** systems, projects, features, and just stuff I want to fix in my codebase. And as the tools get better, the harnesses get better, and of course the models get better, the idea that this random thing that maybe I would have previously cut a Jira ticket for that would have sat in a pit of backlog forever, now I can just throw it at Opus, get some code, review it on GitHub, and merge it. There's also a problem here around what our jobs are. Running a quick poll to see how much people like code review. And as we see **[06:12]** with the initial results, 50% say hate it. Even though there are four options that are neutral or better. Now that the polls continued going, it's fine but tiring is going up. But we still have 26% saying hate it, 10% saying neutral, and 45% saying it's fine but it's tiring. Very small percentage of devs like or love code review. I'm in this section. I would argue I'm in the like it section. I do enjoy code review. I wish I could justify doing more of it, **[06:42]** but my schedule is utter chaos, but I like code review. I also think this is just one of those things that you have to get over over time as you become a more experienced developer. Not that you have to get over using AI tools, you have to get over your own time spent writing code. I actually had a long chat with Mark not too long ago. If you don't know, Mark is my CTO for T3 and all the fun things that we built. Mark, now that we have more staff, as in Julius is here full-time in the US and Yosh still contributes throughout his week when he **[07:13]** can, Mark's time isn't best spent writing code anymore. Previously, the flow was Mark would write most of the code. Julius would go off and figure out whatever weird problems, and I would come in to do some steering and general code review stuff. Now, I'm more removed because there's too much [ __ ] going on. Running the company is a lot of work, and also not doing the best job as CEO. trying to get more involved in the codebase again, but it's not the best use of my time, which means Mark has had to bump out a little bit too to do more of the orchestration and code review, especially with the mobile app in flight, too. Managing the team, building **[07:43]** the mobile app, managing the team, building and maintaining the web app and the servers and the back end, managing upload thing, managing all the other services that we maintain. He's not writing code as much anymore. And as most people will experience when this happens in their career, that [ __ ] sucks. You suddenly stop feeling productive when you're not writing code anymore. And previously, you would measure your success in a day by how much code you had written, how much time you spent in your editor, and how many problems you had solved. If you're spending your time in the GitHub PR tab and not in your editor, you feel like **[08:14]** you're not getting anything done. And the amount of times Mark would have a crazy day where he did a ton of code review, got a ton of stuff shipped, handled a ton of support cases, all those things, but felt like he didn't get anything done simply because he wasn't in his editor at all. It's it became like an everyday occurrence and he was not loving that feeling because it sucks and I've seen this happen to a lot of developers as they move towards management towards tech leads towards roles where their job becomes less writing code and more orchestrating code. This is part of what makes a **[08:46]** senior engineer. This is the biggest reason I think we are seeing that shift where more and more senior plus devs are reporting that a majority of their code is coming from AI. We are more used to reviewing code constantly. The average dev still probably writes more code than they review. The devs that have gotten over that already, the ones who are maintaining big open source projects, the ones who are running teams with a lot of engineers, the ones who are building systems that require lots of people doing lots of disciplined work. Those are the people I've seen falling **[09:16]** the hardest in love with these AI tools over the last few months. The people who are already over that hump and are used to that are the ones who are getting the biggest benefits right now. There are days where I'll file like 20 pull requests and go through them all on GitHub. I spend more time generating code and then putting it on GitHub than actually reading it in my editor at this point. It's crazy. But that also sucks for a lot of people. I know many engineers, myself included, prefer writing code to reviewing it. In fact, from this poll, it seems like the vast majority of developers very much prefer **[09:46]** writing code to reading it. I understand. But that's a thing that will suck about our jobs going forward. more and more of our job is going to be reviewing decisions and work that is being done by these tools, not doing the work ourselves. Sucks, but it is what it is. And those who are willing to make that jump are going to see crazy success. Sucks when you started writing code as a hobby. TBH, it feels horrible having your hobby be automated. On one hand, totally feel this. It has been weird moving away. On the other, I have two points. The first is this is the **[10:16]** natural progression of an engineer as they get better. You need to learn to delegate and do more talking and orchestration and long-term planning and managing of your team and the development velocity and the changes going in and how they're going in and all of that. Like that is growth as an engineer. Once you are good enough at the code writing part, you have to get better at those other things to keep leveling up. There's a cap at how much the code writing actually benefits you. The other part of this side is that this is what we've been doing as engineers forever. We've been writing code to automate things that were hobbies for other people. We have already destroyed **[10:48]** so many fields with code. It was only time that the fun parts of our field started to erode. But I will counter this by saying I'm having a lot more fun coding overall lately. It's much more fun seeing how far you can push these agents and the crazy things they can do and not feeling bad when you throw away the code cuz it sucks. The worst feeling ever is when one of your employees or teammates or somebody you care about goes off on a crazy tangent, deep dives on something, builds a crazy solution, and then for any of many reasons, it just doesn't work. It doesn't fit the **[11:19]** project, you can't merge it, and you have to close the PR. It hurts. It sucks. It feels so bad to throw away hard work that one of your co-workers or peers or friends did. But if it was an agent, I don't give a [ __ ] I just closed the PR. So, I'm having a lot more fun with experiments. I'm having a lot more fun trying things out, playing with new languages, overhauling code bases, experimenting with new stuff. It's I'm writing comically more code than I've ever written. I threw together a 12,000 line of code project in a day. What? 12,000 lines of code in a day. According **[11:51]** to various surveys, the average developer on the average day writes between 10 and 40 lines of thoroughly tested and debugged code. Opus and I wrote 12,000. This might seem like cap, but when you average it out, this is very real. I know everybody in chat's like, "No, that's stupid. That's insane." Now, if you do a PR with 250 lines of code, you start working on it on Monday, you put up the PR Tuesday, it takes two days to get thorough reviews. On Thursday, you finally have a good enough review and have to go make changes. So, you make changes, and then **[12:22]** on Friday, it ships. That was 5 days for 240 lines of code. That is That is about right. And that's hilarious. That is absurd. This is the 10 to 100x people keep talking about is when it is significantly easier to not just write the code, but write the tests to automate the testing process to set up endto-end testing. GMO just posted about this and the more I've thought about it, the more I think he might be right. AI coding will result in the most rigorously tested, type checked, and provably correct code in the world. First, the testing and verification **[12:52]** feedback loop helps agents and prevent slop. Yep. God, cloud code got so much more usable when the LSP was added. It's kind of broken, but it helps so much. But the second part, tests have always been a chore, but who doesn't love the pile of check marks that a high test count gives you? Agents are glad to write as many tests as we want. Yep, the pain of writing and maintaining test has gone down a ton, and I'm starting to rethink my own relationship with testing for my projects. This is one of the coolest parts. It would take me way more time to write testing code than the actual code because getting the test right is hard and tedious and slow and **[13:22]** annoying and not actually the thing that we like doing. Now the agent can do that part and then do the implementation and then put up the code and then do the first pass on the code review and catch any mistakes and then you go and look over the like final pieces and give it a thumbs up or down. It's a whole different way of building and it is changing how I think about software. Back to the rest of the quote because this is what I think a lot of people have missed. >> But the programmer still needs to specify you know what what what are what what are what are the conditions of what you're doing? what you know what what **[13:53]** what what what is the overall app you're trying to make? What's the overall design decision? How do we collaborate with other code that's been written? Um you know, how do we have some common sense on whether this is a secure design or an insecure design? So, as long as there are these small pieces that a programmer, a human programmer needs to do that the AI isn't good at, I think human productivity will actually be enhanced. I really want to emphasize that part because it's a huge part of what I love about coding. It's not just **[14:25]** the process of writing the beautiful lines in my editor that I could stare at and smile and screenshot and tweet. It's the way I think about the system, the way the parts come together, when the right abstraction works in the right place the right way and it all comes together well. When you pull together the set of tools you want to use and they come together the right way or one of them doesn't quite work how you need, so you swap it out for something else and it does work. And that feeling of cohesion when you get the right parts to work together. That's my favorite thing when I'm writing code. When all of the **[14:56]** pieces come together and the result is something awesome. Both a thing that you're confident in your ability to maintain and also a thing that is actually pleasant to use for the product that you're actually putting together. This is awesome. I find this so fun. It is different. It is strange. It's a fundamental change in how we write code every day. What does this mean about our day-to-day work, about our careers, about the people that we hire? About the people we might have to fire? How is our workforce going to change? A lot of people said this prediction obviously **[15:26]** wasn't true because Anthropic not only didn't fire 90% of their engineers, they're actually still trying to hire more, but they also have been doing a lot more coding. In fact, Daario actually mentioned this in a follow-up when people were questioning his take here. Thank you to FaZe for fixing the audio in this clip so we can actually listen to it. >> I would say maybe 70 80 90% of the code written in Enthropic is written by Claude. You know, I said something like this 3 or 6 months ago. People think of it as falsified because they think of it as like we're going to fire 70 80 or 90% **[15:58]** of the software engineers. But what really happens is that the 10 the 10% we're still writing, you know, humans become managers of AI systems. There's a shift because of the principle of comparative advantage. So it looks more normal than you think. I think eventually it all, you know, kind of eventually that logic may not hold, but but there's a sort of sci-fi sheen to these predictions to looking at the future that it's going to be weird that you'll be looking through different colored glasses that there will be, you know, that it'll look like Star Wars or **[16:29]** something. Um the often when these predictions come true, it's wild, but it's also in a way ordinary. Yeah, they're just building more and that makes a lot of sense. And you get used to it and it no longer feels as crazy. And I'm even feeling that a bit too. Like when I'm just [ __ ] around in cloud code, I don't necessarily feel like, oh, this all happened at once. It's when I left my computer and was talking about it with friends that it hit me just how absurd it is that I built two projects without ever opening an IDE. Like, that's just crazy. That's **[16:59]** absurd. So absurd that now Boris is again doing all of his day-to-day work in Claude Code 2. And Darren made a post a few days ago about how you should totally now be able to have one highly skilled person doing the equivalent of 10 engineers of work. Does this mean that the industry will be slashed to only the top 10% of engineers if that's all that's needed? Shouldn't we be concerned? I really like Simon's response here. If code gets 10 times cheaper, the demand for code will go up by more than 10x. A whole bunch of companies that previously couldn't **[17:30]** afford custom software will suddenly be in the market for it. And existing companies with multi-year road mapaps will hire more to help get them through it. This is known as Jevans paradox. The Jeans paradox is a thing that occurs when technological advancements make a resource more efficient to use, thereby reducing the amount needed for a single application. But if the cost goes down and the demand is price elastic, this can result in demand increasing instead causing the total resource consumption to rise. And I think we're already seeing this. There is definitely more code happening. There are definitely **[18:01]** more companies more interested in building their own internal tools than I've ever seen. For example, at RAMP, the finance management company for startups, they have been building their own internal tool that uses open code to take some plain text description of work and go do it. Here is one where they asked, "What are the 20 most common sensory issues in core? Spin up child sessions fixing all of them." And apparently it just worked. They looked at the sentry issues and then spun up 20 agents to go fix all of them and then **[18:32]** filed 20 poll requests. That's kind of crazy. This does mean you're spending a lot more time reviewing code, but also the process of linking these things all up like this. And I'm certain that 90 plus% of the code in this inspect tool that they made is probably vibe coded, too. This is the thing that is changing that is crazy. And the more you dive in and play with it yourself, you'll find the way you think about these things changes. When you realize you can go just spin up the tool and it's not that much work, you'll try things you wouldn't have tried. I'm considering going as far as setting a minimum **[19:03]** inference spend for my team. I might make it so everybody at T3 Chat is expected to spend at least $200 a month on inference so that they're going to go out and try new strange [ __ ] I want to see what they do when I put some pressure on them to spend more money rather than less because then they might experiment a bit more and do some crazier stuff. I'm probably going to do that at this point. I've been thinking about it too much. I want to I'm probably going to. This fun report just got linked while I was filming and I wanted to include it because it's another one of the reasons we have to review the code that the AI is writing. **[19:35]** AI code creates 1.7 times more problems. My initial question was when was this published? because that will change how I think about this report a lot. And I couldn't figure it out, but everybody in chat was saying they could see it. Check this out. When I squash it down to mobile size, it shows the date, December 17th. And when I zoom out, we get this sidebar that shows December 17th, 7 minute read. But if you're zoomed in too much for the sidebars to fit, but not enough for it to trigger the mobile mode, you don't get to see the values **[20:07]** there. Just one example of a bug that occurs when you vibe code your UIs. Just funny to see one of these bugs in the article about how you find up to 70% more of these in AI code than human written code. This report was across 470 PRs, including 320 that AI co-authored and 150 that were human only using code rabbit's structured issue system across a bunch of open source projects. And yeah, AI does accelerate the output, but it also amplifies certain categories of **[20:38]** mistakes. Surprise, surprise, you get the idea. One interesting piece is that they only measured as per PR. They didn't do per line of code. Also, high issue outliers were more common in AIPRs. So, you would randomly have a PR that had way more issues. 1.7x at the like average, but it's 2x at that 90th percentile. So, when it does bad, it does way worse. Cool information and again more reason you need to be doing the code review part. But this leaves us **[21:10]** with my biggest concern, the junior dev. And I'll be honest, I don't know what we can do about that. I built up these skills by writing code for almost 20 years. And those skills are still essential in my day-to-day use of these tools. Just knowing weirdness about how CSS works and scroll containers being strange in the browser. the amount of times I've had to remind Claude Code that it doesn't have the ability to have a tool tip come out of a box when it has any overflow rule set on it. I don't know if you know this, but if you set an **[21:40]** overflow X rule on a box, you can't go out of it Y direction. So, if you have some behavior where it has a border color when you hover over it, that will get cut off. Or you have a little X button in the corner of the square, that'll get cut off. And I've had to remind Opus about this so many times that it suggested adding it for me to my global quad MD file. Like you need to know these things to be successful with these tools. But these tools existing drastically lowers the incentive to learn these things because the cost of **[22:11]** doing it wrong used to be really high. And the cost of figuring it out also was really high. You would spend the time to do it. Now, if you don't know the reason these things happen, you can screenshot the problem, show it to the model, and say, "Hey, fix this." And there's a one in three chance it does it right, and then you keep doing that over and over again forever. The amount of these types of issues will go down constantly. But also, the amount of work we have these tools doing is going up constantly. If it used to make one of these mistakes every 100 lines of code, then it was **[22:42]** kind of useful. Now, it's every thousand lines of code. Maybe they'll get to every 10,000 lines, but it doesn't make that bug any easier to solve with the AI. And I don't know how you get that experience now. I really don't. I've been thinking a lot about this. I kind of want to do a follow-up on my like junior dev videos, like how do I think about this for early career engineers now. And I don't know what to say or recommend. I still think it's really important that you try to use these tools not as a way to do work you don't know how, rather to break apart and **[23:15]** delegate work that you don't have the time to do. That's when they're strongest. When you're using these tools to multiply your own capabilities, not to work around your lack of capabilities. But I don't know how you get those capabilities anymore. At the absolute least, you need to read the code that you're generating, especially when you're early and you're spinning up things that are actual projects you want to maintain over time. Writing code manually is still a very good way to learn, but honestly, I still think until you have gotten relatively deep and are like multiple **[23:47]** projects in building things that real people use, you should probably prioritize using a chat app to ask questions. Or maybe you can shortcut this and use something like cursor and use the ask mode where it doesn't change code, it just answers questions to learn more. Combine that with tab complete and you can keep leveling up your understanding. But man, this this stuff's changing fast. And the thing I never would have expected is that my skills as a senior dev, which are mostly **[24:19]** orchestration and planning and management of people doing things in parallel. That part matters now more than ever, which is cool on one hand because now a lot of devs are going to skill up on their talking skills. Like prompting is more a comm skill than an end skill in so many ways, but also like you might not learn the ins and outs the same way. This is tough. I don't really know what I want to what my point here is other than to express how confused I am still. Oh [ __ ] Lero's here. Yeah, apparently they're adding a teacher mode to cursor, which is actually really **[24:51]** really really exciting, especially if they let people do this on like a student tier. Like if they're in school, they get it for free. Oh. Oh, that'll be so good. Also, tools like code crafters are more useful than ever in my opinion. Code crafters, bootupdev, stuff like that that actually encourages real project building. This is how you have to learn now. And the AI will make it so you're less likely to get blocked and less likely to need somebody to help carry you through the hard parts. Yeah, know this is going too deep. I probably need to think this through, like sit down and really think about what works **[25:22]** and talk to some recent people who just got into the industry and then maybe I'll make a dedicated video on this. But right now, I don't even know how to like organize my thoughts on it. One more question for you as a viewer of this video. If I was to ask you, where do you think you fit in terms of intelligence and capability writing code against Opus? Would you consider yourself a better engineer, same tier roughly, or a worse engineer? Where do you think you fit? And what answers do you think my chat would give? How do you think the split would be of those? Think about it **[25:53]** for a sec. Get your idea of where you would put yourself and where you think the splits are for my own audience. Ready for the results? 61% of my viewers think that Opus 4.5 is a better death than them. 16% did the bailout answer. 13% said roughly as good as me. And 10% said worse. That's where we're at. These things are moving absurdly fast. The way we code now is so different from the way at the very least I coded 3 to 4 months ago, which is way different from how it was at the **[26:24]** beginning of the year, which is way different from how it was the year before. But the speed at which these changes in my workflow are happening is condensing. It's like every three months now massive change happens. Previously it was every six months. Then it was every year. Then it was every few years. It's crazy. Don't fall behind. I'm going to do a whole dedicated video on how to keep up on all of this in the near future. I also have a video about my own usage of cloud code that's coming very soon. Keep an eye out for that. I'm very excited about that one. So yeah, keep playing with this stuff. Keep trying new things and keep doing your best to build **[26:56]** the best possible things and take advantage of the tools that exist around you. Don't write this stuff off because you're scared of grifters or people like me who happen to have invested in a few of these tools, almost none of which I talked about today. Just focus on building. That's what's going to get you the furthest always. And there is more to be built than ever. And there are more ways to build than ever, too. I've never loved code as much as I do today, even if my relationship with it is very different than it was a year ago. And I recommend that you reflect yourself and give these things a try. Let me know what y'all think and how you're using these tools today.