We All Fell for It… - CourtneyR.dev's 2nd Brain

We All Fell for It… ![rw-book-cover](https://img.youtube.com/vi/lNVa33qUzZ8/maxresdefault.jpg) 🔗 **Source:** [We All Fell for It…](https://www.youtube.com/watch?v=lNVa33qUzZ8) > [!note]+ Document Notes > tags: #ai-coding #developer-skills #cognitive-debt #technical-expertise > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=lNVa33qUzZ8 > date created: 2024-12-19 09:30 > > # 🏷️ Title: We all fell for it… (AI Coding Trap Analysis) >  ## 🧰 Action Inbox - [H1] Evaluate team's AI coding practices against cognitive debt patterns — discuss with engineering leadership #developer-experience - [H2] Create learning paths that maintain fundamental skills while leveraging AI — design educational frameworks #technical-education - [H3] Establish debugging standards that combine AI assistance with systems understanding — 0:45:30 #debugging ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Agentic coding is a trap - Lars Fay](URL) - [BrowserBase Fetch API](https://api.base.com/fetch) ## 📝 Summary - Analysis of "cognitive debt" from AI coding tools versus traditional technical debt - Why AI coding may not be a true abstraction layer like previous programming evolution - Junior developers and some seniors losing fundamental debugging/coding skills through over-reliance - Distinction between skilled developers who leverage AI effectively vs. slot-machine-style coding - Warning about industry-wide skill atrophy and vendor lock-in for teams ## 📖 Main Content Theo examines Lars Fay's article "Agentic coding is a trap" which introduces the concept of "cognitive debt" - the deterioration of critical thinking and coding skills through AI over-reliance. Unlike traditional technical debt, cognitive debt affects developers' ability to understand and debug systems they didn't directly create. The core argument challenges whether natural language to code represents a true abstraction (like assembly to C++) or something fundamentally different. Previous abstractions still required understanding underlying concepts, while AI coding can enable developers to work beyond their competence level without building foundational knowledge. Key evidence includes Reddit posts from experienced developers reporting brain fog, skill deterioration, and inability to debug without AI assistance. However, Theo argues this affects different developer archetypes differently - those with strong systems understanding can leverage AI effectively, while those lacking fundamentals become dependent on "slot machine" coding approaches. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/lNVa33qUzZ8?t=0) — [H2] AI productivity claims and hidden costs - Key idea: Industry celebrates massive code output but ignores skill atrophy and increasing costs - Evidence: "37,000 lines of code every single day" productivity claims mask deeper problems #### ⏱️ [02:15](https://youtu.be/lNVa33qUzZ8?t=135) — [H1] Personal AI workflow evolution - Key idea: Theo's work has shifted from code to prompt files and CSV data analysis - Evidence: "I'm not even looking at code in it. I'm looking at a prompt file and then a bunch of CSVs" #### ⏱️ [08:30](https://youtu.be/lNVa33qUzZ8?t=510) — [H2] Cognitive debt versus technical debt - Key idea: Technical debt affects code quality; cognitive debt affects developer capabilities - Evidence: "AI is phenomenal at those things" - referring to tech debt cleanup tasks #### ⏱️ [12:45](https://youtu.be/lNVa33qUzZ8?t=765) — [H1] Cost efficiency improvements in AI models - Key idea: Intelligence per dollar is decreasing even as token usage increases - Evidence: "Same tier of intelligence from before... is now less than half the price" #### ⏱️ [16:20](https://youtu.be/lNVa33qUzZ8?t=980) — [H2] Developer skill requirements for AI supervision - Key idea: Only skilled developers can effectively supervise AI-generated code - Evidence: "Only a skilled developer who's thinking critically... can spot the issues" #### ⏱️ [19:45](https://youtu.be/lNVa33qUzZ8?t=1185) — [H3] Personal experience with rapid development patterns - Key idea: Theo's pre-AI development style prepared him for current AI workflows - Evidence: "I used to ship like five plus projects a year before AI" #### ⏱️ [25:30](https://youtu.be/lNVa33qUzZ8?t=1530) — [H2] Pain avoidance and learning incentives - Key idea: AI enables avoiding the productive discomfort necessary for skill development - Evidence: "Your choices are go learn the pieces... or keep pulling the slot machine" #### ⏱️ [28:15](https://youtu.be/lNVa33qUzZ8?t=1695) — [H1] Abstraction layer comparison analysis - Key idea: Natural language to code may not be a true abstraction like previous programming evolution - Evidence: "A high level of ambiguity is not a higher level of abstraction" #### ⏱️ [33:00](https://youtu.be/lNVa33qUzZ8?t=1980) — [H2] Evidence of developer skill deterioration - Key idea: Multiple Reddit posts show experienced developers losing fundamental abilities - Evidence: "9 years of experience... I feel like I'm losing my skills" #### ⏱️ [38:45](https://youtu.be/lNVa33qUzZ8?t=2325) — [H1] Effective AI debugging workflow example - Key idea: Combining systems knowledge with AI assistance for efficient problem-solving - Evidence: Detailed walkthrough of Ping.gg outage resolution using AI and manual debugging #### ⏱️ [45:30](https://youtu.be/lNVa33qUzZ8?t=2730) — [H2] Gap between great and poor developers expanding - Key idea: AI amplifies existing developer quality differences rather than equalizing them - Evidence: "The gap between the great and not great engineers has grown massively" #### ⏱️ [52:15](https://youtu.be/lNVa33qUzZ8?t=3135) — [H3] Senior pipeline disruption concern - Key idea: Industry won't develop next generation of senior engineers without fundamental skill building - Evidence: "You won't get the next wave of seniors if we're all abdicating the friction" #### ⏱️ [58:00](https://youtu.be/lNVa33qUzZ8?t=3480) — [H2] Priority inversion in development goals - Key idea: AI tools prioritize speed over understanding, reversing traditional good development practices - Evidence: "LMS are inverting this list" - referring to code understanding, standards, conciseness, then speed ## 📚 References - [Agentic coding is a trap - Lars Fay](URL) - [OpenAI GPT-5.5 Release Analysis](URL) - [Artificial Analysis Model Benchmarks](URL) - [BrowserBase API Documentation](https://api.base.com/fetch) ## 🗣️ Paraphrase - AI coding tools create "cognitive debt" where developers lose fundamental skills while becoming dependent on automated code generation - Unlike previous programming abstractions that still required understanding underlying concepts, AI enables working beyond one's competence level - Experienced developers with strong systems knowledge can leverage AI effectively, but those lacking fundamentals become addicted to "slot machine" coding - The industry risks not developing the next generation of senior engineers if fundamental skill-building friction is eliminated ## 📰 Newsletter **The AI Coding Paradox: When Productivity Tools Reduce Capability** This week we're examining a growing concern in our developer community: the concept of "cognitive debt" from AI coding tools. While these tools promise incredible productivity gains, evidence suggests they may be creating a generation of developers who can generate code but struggle to debug or understand the systems they create. The key insight? **Effective AI supervision requires the exact skills that AI over-reliance tends to erode.** Successful developers are those who use AI to amplify their existing expertise rather than replace fundamental knowledge. **For WordPress developers specifically**: Consider how AI might help with tedious tasks (like updating deprecated hooks across a large codebase) while ensuring you still understand core concepts like the action/filter system, database queries, and security patterns. **Practical next steps**: Identify areas where AI helps you move faster on tasks you already understand well, while deliberately practicing fundamentals in areas where you feel knowledge gaps. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create content distinguishing healthy AI usage from skill-replacing patterns - Education: Design workshops that teach AI-assisted debugging while maintaining systems understanding - Developer experience: Audit internal tools to ensure they enhance rather than replace core competencies - Community management: Facilitate discussions about sustainable AI adoption practices #### WordPress - Core: Establish guidelines for AI-assisted contributions that maintain code review standards - Community: Create mentorship programs pairing AI-experienced developers with those learning fundamentals - Training: Develop lesson plans that integrate AI tools while preserving foundational knowledge - Documentation: Update guidance for using AI in WordPress development responsibly ## 🧪 Hypotheses - Developers with strong pre-AI fundamentals will outperform peers who learned primarily with AI assistance over 2-3 year periods - Teams with mandatory AI usage policies will show higher technical debt accumulation than those with selective adoption - Open source contributors will develop better AI integration patterns than developers working solely on private codebases - Organizations prioritizing AI productivity metrics will experience increased debugging time and system reliability issues ### 📊 Methodology - Longitudinal study tracking developer skill assessments before and after AI adoption periods - Code quality analysis comparing AI-generated vs. human-written code in production systems - Survey analysis of developer confidence levels in debugging scenarios with and without AI assistance ### ❓ Questions - What specific practices distinguish developers who benefit from AI from those who become dependent? - How can organizations measure and prevent cognitive debt accumulation in their engineering teams? - What role should AI play in computer science education and developer onboarding programs? ### 🔮 Future Research - Long-term career trajectory analysis for developers with different AI adoption patterns - Development of assessment frameworks for measuring systems thinking capabilities - Investigation of optimal AI integration patterns for maintaining skill development ### 💡 Implications - Practice: Teams need explicit policies distinguishing appropriate vs. problematic AI usage patterns - Policy: Engineering organizations should track cognitive debt alongside technical debt metrics - Education: Developer training programs must balance AI productivity with fundamental skill preservation - Security: Over-reliance on AI-generated code may introduce vulnerabilities through reduced human oversight ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical content with domain-specific terminology) #### 👀 Visual learners - Present: Code examples and workflow diagrams throughout video - Improve: Add visual comparison charts showing skill development trajectories #### 🔊 Aural learners - Present: Full video discussion with detailed verbal explanations - Improve: Create audio-only summary highlighting key distinctions #### 🗣️ Verbal learners - Present: Clear definitions of cognitive debt vs. technical debt, extensive analogies - Improve: Glossary of terms and more real-world examples #### 🧩 Kinesthetic learners - Present: Detailed debugging walkthrough example - Improve: Hands-on exercises demonstrating healthy vs. problematic AI usage ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Video has spoken content with clear topic transitions - Improve: Add detailed transcript with proper heading structure #### Keyboard navigation - Present: Standard YouTube player controls - Improve: Ensure any supplementary materials support keyboard navigation #### Media and captions - Present: Auto-generated captions available - Improve: Add professional captions with technical term accuracy ### 🌍 DEIB Assessment #### Cultural breadth - Present: Examples from various tech companies and developer backgrounds - Improve: Include perspectives from developers in different global markets #### Inclusive language - Present: Generally inclusive technical discussion - Improve: Acknowledge different paths into software development beyond traditional CS education #### Neurodiversity support - Present: Clear structure with topic transitions - Improve: Add chapter markers for easier navigation of lengthy content ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from AI tool capabilities to skill atrophy outcomes - Inductive strength: Multiple anecdotal examples supporting broader patterns - Causal reasoning: Well-established links between practice reduction and skill degradation #### Fallacies - Survivorship bias: Theo's success with AI may not generalize to all experienced developers - Appeal to authority: Heavy reliance on industry expert opinions without broader data #### Tone of voice - Overall tone: Analytical and concerned but balanced, acknowledging both benefits and risks of AI tools ### 🛡️ DARVO Analysis - Deny: No denial patterns detected - Attack: No attacks on specific groups, focuses on systemic issues - Reverse victim/offender: Not applicable to this technical analysis - Emotional cues and rhetoric: Appropriate concern about industry trends rather than manipulative rhetoric ## 🎯 Conclusion The video presents a nuanced analysis of AI coding tools' impact on developer capabilities. The key insight is that AI tools amplify existing skills rather than replace the need for fundamental knowledge. Developers who understand systems deeply can leverage AI effectively, while those who rely on AI to compensate for knowledge gaps risk entering a cycle of dependence that reduces their long-term effectiveness. For the WordPress ecosystem, this suggests prioritizing educational approaches that use AI to enhance understanding of core concepts rather than bypassing them entirely. The community should focus on sustainable AI adoption patterns that preserve the pipeline of skilled developers needed for long-term ecosystem health. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Cognitive debt differs fundamentally from technical debt > [!quote] We all fell for it… by [[Theo - t3․gg]] via [[YouTube]]. Published 2024. Accessed 2024-12-19. > "Cognitive debt is a much much more interesting idea than technical debt." Cognitive debt affects developer capabilities and judgment, while technical debt affects code maintainability. AI tools can help resolve technical debt but may contribute to cognitive debt. [view highlight](https://youtu.be/lNVa33qUzZ8?t=510#H1) #xref #articleseed ID:rw_001 ### [H2] AI abstraction differs from traditional programming abstractions > [!quote] We all fell for it… by [[Theo - t3․gg]] via [[YouTube]] > "A high level of ambiguity is not a higher level of abstraction." Previous programming abstractions maintained deterministic relationships between layers, while AI introduces non-determinism that breaks traditional abstraction patterns. [view highlight](https://youtu.be/lNVa33qUzZ8?t=1695#H2) #xref ID:rw_002 --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] Effective AI supervision requires skills AI erodes - Applies to developers using AI coding tools without maintaining fundamental knowledge - Referenced throughout discussion of cognitive debt patterns - Links: [[AI-Tools]] [[Developer-Skills]] #### [Z2] Pain avoidance prevents necessary skill development - Universal learning principle applicable beyond programming contexts - Demonstrated through skateboarding analogy at 25:30 - Links: [[Learning-Theory]] [[Skill-Development]] --- ### ✏️ Fleeting Queue - [F1] Research educational frameworks that combine AI assistance with fundamental skill preservation #fleeting #inbox - [F2] Analyze cost trends in AI model pricing vs. intelligence capabilities #fleeting #inbox - [F3] Investigate correlation between open source contribution and AI tool effectiveness #fleeting #inbox --- ## Full Transcript [00:00] AI code is here and it's here to stay. [00:01] Who hasn't seen the productivity gains? [00:03] We're talking CEOs of companies doing [00:05] 37,000 lines of code every single day. I [00:08] mean, what else is there to our lives as [00:10] developers? If we can put out that much [00:12] code, why would we do anything else? [00:14] This totally isn't going to come back to [00:15] bite our asses, right? It's not like [00:17] we're going to lose all our skills as we [00:19] rely on the slot machine more and more, [00:20] and as a result, the slot machine [00:22] becomes a slot machine and nothing ever [00:24] works how it's supposed to. This [00:26] definitely isn't currently happening and [00:28] people definitely aren't starting to [00:30] notice, right? Oh, Aenta coding is a [00:33] trap. This sounds like it's going to be [00:35] a very, very fun article. I have a lot [00:38] of thoughts here, as you guys can guess. [00:41] On one hand, I love coding. I love [00:43] building things. I care about the [00:45] nitty-gritty of syntax. I've built [00:46] entire stacks around my specific tech [00:48] preferences that have went so viral that [00:50] they helped build my entire career on [00:52] platforms like this. On the other hand, [00:55] I very much enjoy these AI coding tools. [00:57] So much so that they've fundamentally [00:58] changed how I think about tech and the [01:00] things that I build. And I've never [01:02] spent less time actually writing code. [01:04] In fact, if I open up my code editor [01:06] right now, I'm not even looking at code [01:08] in it. I'm looking at a prompt file and [01:10] then a bunch of CSVs for the data for [01:12] all of the runs that I'm currently doing [01:14] with agents. I'm barely looking at code [01:16] anymore. There are things I'm doing more [01:18] of, which is cool. Like I've never [01:19] gotten so good at git in my life. I've [01:21] never used SSH and remote boxes as much [01:24] as I do now. I'm trying out all sorts of [01:26] new things. I am learning all sorts of [01:27] new technologies, but I also feel some [01:29] of my skills atrophying and I find [01:32] myself when something doesn't work just [01:34] rolling the slots again and again hoping [01:36] that this time might be the one where I [01:38] get the output I'm looking for. Pulling [01:40] that lever costs a lot of money. You [01:42] never know what you're going to get, but [01:44] at the very least, you know what you're [01:45] going to get in our sponsor break is a [01:46] really cool company like this one. Are [01:48] you the type that pays attention to what [01:49] tool calls your agents make? Cuz I am. [01:52] And I've noticed that there's one thing [01:53] they tend to do a lot. Curl. The [01:55] frequency at which I see my agents [01:57] making curl calls to get information [01:58] about web pages, documentation, and more [02:00] is honestly kind of funny, especially [02:02] because of the frequency at which it [02:04] fails. Because it turns out a lot of the [02:06] web doesn't respond with the real [02:07] contents when you hit it via curl. [02:09] Whether it's an empty HTML page that [02:10] requires JavaScript to populate the [02:12] content or something that's hidden [02:13] behind a capture or a firewall or some [02:15] off layer of some form, there's a good [02:17] chance your agents are going to struggle [02:18] if they're relying on doing curl [02:20] exclusively. It'd be really nice if you [02:22] could just wrap your curl request in [02:23] some way where it won't fail on those uh [02:25] oh, it's on the screen already, isn't [02:28] it? Yeah. Today's sponsor is browser [02:30] base and they just added a new fetch [02:31] feature that makes it easier than ever [02:33] to get the real content from any [02:34] website. If you want it as HTML, JSON, [02:37] or even markdown, they'll handle it all [02:39] for you. Instead of curling the site you [02:40] want directly, you make a post request [02:42] to the API.base.com/fetch [02:45] endpoint. You pass it the body with the [02:47] URL you want, and then all it needs is [02:49] an API key, and it will now be able to [02:51] scan that site reliably for you and get [02:54] you what you want. On the pages that [02:55] require JavaScript to run, they have you [02:57] handled, too, because Browserbase can [02:59] spin up real browsers in the cloud. [03:01] That's why they exist. That's how they [03:02] got their whole name. They provide real [03:04] browsers for your agents to do real [03:05] things on the web. Whether it's clicking [03:07] buttons, signing in, getting [03:08] information, running JavaScript, and [03:10] more, they have you covered. Going to be [03:11] real with you guys though, there were [03:12] some use cases a cloud browser wasn't [03:14] great for, like search. Oh, is it on the [03:16] screen again? I need to stop doing that. [03:18] The search stuff is really cool, too. [03:20] Adding a real way for your agents to do [03:22] search and get the context they need to [03:23] unblock themselves is incredible, and [03:25] that's why so many companies rely on [03:27] them for it. So if your agents need [03:28] better searching, better fetching, [03:30] better curling, or just better access to [03:32] the web through a real browser, look no [03:33] further than soy. Browserbase. Back to [03:36] where we were. Agentic coding is a trap [03:39] written by Lars Fay. I'm actually really [03:41] excited about this one. Multiple people [03:42] who I trust sent this to me to take a [03:44] look at. I haven't read it yet, so we [03:46] get to go through this together and [03:47] hopefully we'll have interesting things [03:49] to add. Remaining vigilant about [03:51] cognitive debt and atrophy. Interesting [03:54] that the angle here is cognitive debt [03:56] and not technical debt. I already have a [03:58] feeling I'm going to like this a lot [04:00] because I've personally found tech debt [04:02] is actually one of the coolest things to [04:03] deal with with AI. It's actually kind of [04:06] amazing how willing models are to go [04:09] after tedious tasks like making a new [04:12] lint rule work across your whole [04:13] codebase or updating a package that [04:15] broke the definitions for a thing that [04:17] occurs in 5,000 places. I have done [04:19] crazy work for tech debt in my life that [04:23] just required so much brute force and [04:25] manpower it wasn't worth it. Like I I [04:27] still vividly remember a time at Twitch [04:29] where we were doing a migration for our [04:30] GraphQL layer that broke I think it was [04:33] 8,000 or so TypeScript files. So we took [04:36] all the ones that were now broken, put [04:38] them in a Google sheet and would assign [04:40] chunks to different engineers to go [04:42] through and manually update on the [04:44] shared branch to try and get everything [04:46] up to date. Like those are the types of [04:49] things we used to do by hand that often [04:51] would get left and the tech that would [04:52] just sit there because the process of [04:54] fixing it was too much manpower to be [04:57] worth it. AI is phenomenal at those [04:59] things. So whenever I see the like AI [05:01] causes tech debt argument, I get [05:03] frustrated because it also solves a lot [05:05] of the same tech debt that it can [05:06] potentially cause. But cognitive debt is [05:08] a much much more interesting idea. So [05:11] let's see what Lars has to say. Starts [05:13] with a quote. AI does the coding and the [05:15] human in the loop is the orchestrator. [05:17] This is the sentiment being hyped up [05:19] around the industry currently. [05:20] Traditional coding is all but dead. [05:22] Inspect driven development is the [05:24] future. Okay, I really think we're going [05:26] to agree if he's talking [ __ ] on STD [05:28] already and we barely started. Oh boy. [05:31] You generate a plan and disconnect from [05:33] writing any code. The agents know better [05:35] and handle all the implementation. You [05:37] are there as the expert to provide good [05:39] taste, review the outputs, and [05:41] constantly steer the agents to execute [05:43] the plan that you meticulously put [05:45] together. How meticulous are you guys [05:47] writing these plans out to be? Cuz I I [05:50] don't believe you. I don't believe any [05:52] of you are actually putting that much [05:53] effort into the plans if you're not [05:55] watching the agent when it runs after. [05:57] Yeah, there's there's another angle I [06:00] could talk about with the expert thing [06:01] here. I'm not going to go into it yet [06:02] cuz I want to read a bit more first, but [06:04] I already have so many thoughts. The [06:05] workflow takes many shapes at this [06:07] point, but in general, it's a process [06:09] where someone defines the project's [06:10] requirements simultaneously at a micro [06:12] and a macro level. Very, very good call [06:14] out here. They generate a plan, and then [06:16] they pull the slot machine lever over [06:18] and over, iterating and reiterating with [06:20] often multiple agent instances until [06:23] it's done. All the while putting a [06:25] growing distance between the [06:26] orchestrator and the code that is [06:28] actually being generated and committed. [06:30] Coding agents are helpful and powerful, [06:32] but there's already some quantifiable [06:34] trade-offs that need to be discussed. [06:36] First, we have an increase in the [06:38] complexity of the surrounding system to [06:40] mitigate the increased ambiguity of AI's [06:42] non-determinism. Very real problem. [06:44] Second, we have the atrophying of skills [06:46] for a wide swath of the population. I'm [06:48] definitely starting to see this. Third, [06:50] we have vendor lockin for individuals [06:52] and entire teams. Cloud code outages [06:54] have already had entire teams at [06:55] standstills. Yep. and fluctuating and [06:58] increasing costs to access the tools. An [07:01] employees cost is fixed. Tokens are a [07:03] constantly moving target. Yeah, I do [07:05] think that the demand going up is [07:08] causing our brains to fall out a bit [07:10] with the costs increase. I don't think [07:12] long-term the cost for agentic work is [07:14] going to keep going up. The same way I [07:16] think people are going to do more with [07:19] AI and use more tokens, but the cost of [07:21] intelligence at a given level is [07:23] consistently going down. Flashbang [07:25] warning. I talk about this a lot with [07:27] the new GPT models because they are more [07:30] expensive per token. So if you're [07:31] measuring a given input and output that [07:33] are the same work between the old and [07:35] new models, 5.5 is 2x more expensive. [07:38] It's double the cost for input and [07:40] output tokens. But if you compare per [07:42] level of intelligence and the number of [07:43] tokens generated, things get much more [07:45] interesting. GBT55 is the highest [07:48] scoring model on artificial analysis. It [07:50] is at 60 points whereas the previous [07:52] generation with Opus 47, Gemini 31 Pro [07:54] and GBD54 were only at 57 points. [07:58] Meaningful improvement, but I'm going to [07:59] add something to this. GBT 5.5 low as [08:04] well as GPT 5.5 medium. And here's [08:08] what's super interesting. 55 medium [08:11] scores the same as 54x high. And 55 low [08:14] still scores very well, too. comparable [08:17] to Claude's sonnet 46. But when we go [08:20] back down to the cost efficiency, this [08:22] is the cost that artificial analysis [08:24] paid or would have paid if they weren't [08:26] comped to run their entire benchmark [08:28] suite. Opus 47 is the most expensive by [08:30] far at 5 grand, even though it's less [08:33] smart than 55. But remember, 55 medium [08:35] and 54x high are the same level of [08:37] intelligence. 54x high cost $2,800 to [08:40] run this bench. 55 medium cost under [08:43] 1,200. So if that level of intelligence [08:46] was enough for you, your cost just got [08:49] cut in more than half. You're now at [08:52] less than 50% of the cost to do those [08:54] same tasks as you were at before. That [08:57] is a very, very meaningful change. Sure, [09:00] the best model in the world got slightly [09:02] more expensive, going from 2,800 to [09:04] 3,300, but that same tier of [09:06] intelligence from before, the one that [09:08] came out 2 months ago that we were [09:10] totally happy with, is now less than [09:12] half the price. And if you're okay with [09:14] going a little bit dumber, not even much [09:16] dumber, just like sonnet levels, the [09:18] price drops all the way to $500. Another [09:21] having of the price. And this model 55 [09:24] low is as smart as 46 sonnet max, which [09:27] is the second most expensive model at [09:29] $4,200. And this model came out very [09:32] recently as well. So again, if we look [09:34] at this based on the intelligence level [09:37] per dollar, the cost per IQ point here [09:40] has dropped by 8x in just a few months. [09:44] Sonnet 46 came out earlier this year, [09:47] $4,200 to run this benchmark, 51 points [09:49] on the bench. 55 Low, which I would [09:52] argue is a much smarter and nicer to [09:54] work with model. Same level of [09:55] intelligence and eighth the price. So, I [09:57] just wanted to jump on that because I [09:59] don't necessarily agree that the costs [10:01] are increasing in the sense that every [10:04] month if you do the same thing the [10:05] number goes up. It's that we are doing [10:08] more with tokens. So, the amount of [10:10] tokens we're using is going up, but [10:11] we're also finding ways to get more [10:13] intelligence per dollar. So, the cost [10:15] per task and the cost per level of [10:17] intelligence is going down. So, we need [10:19] to be realistic about those differences. [10:22] It doesn't mean that companies aren't [10:23] getting a little screwed here because [10:25] they hired a bunch of developers. They [10:26] pay their devs I don't know let's say [10:28] company pays their devs 5 mil a year [10:30] last year they paid 100k in cursor this [10:32] year they've already paid a half a mill [10:34] in cursor and they're only a few months [10:36] in that that is a legitimate cost that [10:38] they are eating that sucks so on the [10:40] bill it does look like prices are going [10:42] up but by the metrics on how things are [10:44] actually changing and improving much [10:46] less so we're just using the AI more [10:49] just want to jump on that cuz I agree [10:50] with almost all of the rest of this [10:52] being successful with this approach to [10:53] coding agents hinges on a rather crucial [10:56] element ment. Only a skilled developer [10:58] who's thinking critically and [10:59] comfortably operating at the [11:01] architectural level can spot the issues [11:03] in these thousands of lines of generated [11:05] code before they become a problem. Yet, [11:07] in an ironic twist of fate, it's the [11:09] individual's critical thinking skills [11:10] and cognitive clarity that AI tooling [11:12] has now been proven to impact [11:14] negatively. This is all around the term [11:16] cognitive debt, which is a really good [11:18] phrasing. Many relevant people like [11:20] Simon Willis and Martin Fowler are [11:22] describing the experience of cognitive [11:23] debt directly. They talk about getting [11:25] lost in their own projects and finding [11:27] it harder to confidently add new [11:28] features. They can move faster, but they [11:30] lose the deeper sense making that [11:31] connects decisions to intent and the [11:33] intent to the code. So, my hot take on [11:36] this is that if you weren't already [11:38] experiencing a bit of it, you weren't [11:40] shipping fast enough. I can't tell you [11:42] how many projects I had that I went [11:45] really hard on for a month, got to a [11:47] pretty good state, then had to go do [11:49] something else, came back to it, and had [11:51] no idea what the [ __ ] was going on [11:52] anymore. This is this is inherently the [11:56] way humans work when they're doing [11:58] enough different things. You can't keep [12:00] the details of all of the context of [12:02] stuff in your head. The problem is I [12:04] perceive it here is that more people [12:06] became theos because of AI. I used to [12:09] ship like five plus projects a year [12:11] before AI cuz I just loved building [12:13] things and putting them out there for [12:14] people. That took a lot of not like [12:17] expertise in the traditional sense, but [12:20] it was a just like the way I built, the [12:22] way I thought about things and how I [12:24] would cut project scope down to get a [12:26] deliverable, usable version as [12:27] efficiently as possible. Hell, this is [12:29] why I made the T3 stack. I wanted to be [12:31] easier to build things with confidence [12:34] rapidly that would work reliably without [12:37] having to fully understand all of the [12:39] pieces. I was kind of an early vibe [12:42] coder. Not because I was using AI to [12:44] write all my code, but because as soon [12:46] as it worked, I would move on to the [12:47] next thing and forget what the hell I [12:49] had just done. It was just like [12:51] willy-nilly deleting giant chunks of [12:53] code, writing code mods to update [12:55] thousands of things, hoping that it [12:57] worked and just checking if the build [12:58] came out correct in the end. I have been [13:00] slinging far too many lines of code for [13:03] my levels of expertise for my entire [13:05] career. And it's fun seeing everybody [13:07] else have the problems that I have had [13:09] for the better part of a decade now. [13:11] Specifically around remembering where [13:13] everything is in the codebase and having [13:14] confidence when you review code that [13:16] things are actually changing the right [13:18] way. I would also argue and many would [13:20] push back on it but I understand both [13:22] sides that my ability to do this was [13:24] novel and potentially exceptional. It no [13:28] longer is. The thing that made me [13:29] special on a team is that I could [13:31] unblock and make things move and hit [13:33] deadlines that didn't seem possible [13:35] before. I was a bargaining chip at my [13:37] job where my team would negotiate with [13:38] other teams to lend me to them to [13:40] unblock something that they were [13:42] complaining about so they would unblock [13:43] us on something we had to do. Very [13:44] common that I would be traded around to [13:47] make things move faster. Now you can [13:49] just prompt your way through it. The [13:51] issue is I had to work to get there. You [13:54] can argue whether or not I was an expert [13:57] and that's why I could do this. But you [13:59] can't argue that it was a novel thing [14:01] that I could do this. It was novel [14:03] enough that I was paid exceptionally [14:04] well and had a really good career [14:07] because I was able to jump between a lot [14:09] of things and I could deal with the [14:11] cognitive load and the cognitive [14:14] shifting going between all of these [14:17] different things. Now everyone is doing [14:19] it and most people aren't built for this [14:21] and it sucks. There's a separate problem [14:23] that combines with this though. The [14:25] reason I could do this is I deeply [14:27] understood the building blocks I used to [14:30] build in this way. I might not remember [14:32] exactly how I assembled the things, but [14:34] I knew the pieces I used to assemble [14:36] well enough that I could infer why a [14:38] problem happened based on my knowledge [14:40] of the pieces. AI disincentivizes you [14:43] from learning about the pieces. And I [14:45] think that's the biggest problem. Humans [14:48] are very pain. Feeling dumb hurts. When [14:52] you're trying a thing and it doesn't [14:53] make sense, you feel pain. When you try [14:56] a thing and it just goes as expected, [14:58] you feel good. AI has made it easier to [15:02] avoid that pain and feel that reward. [15:05] And what used to be a upfront cost you [15:08] would pay to learn the pieces and then [15:10] you could get the reward of solving the [15:12] puzzle is now a slot machine. And your [15:15] choices are go learn the pieces so that [15:17] you can actually solve the puzzle [15:19] correctly or keep pulling the slot [15:21] machine until hopefully the correct [15:23] answer comes out because each pull hurts [15:26] a lot less than reading the docs for a [15:28] language you don't understand or [15:30] learning a library that doesn't map with [15:32] your mental model properly or debugging [15:34] something that feels hopeless. I learned [15:36] about this from skateboarding. The [15:38] reason most skaters give up before [15:39] learning to ollie, much less kickflip, [15:42] is because it feels so bad. You hate the [15:46] feeling seeing others so effortlessly [15:48] jump on their skateboard, ollie [15:50] downstairs, and do all these fancy [15:51] tricks, and you can't even get the board [15:53] to come up off the ground with you. And [15:55] then maybe you try a little too hard, [15:56] and you hit your shin really hard, and [15:59] now walking's uncomfortable for a few [16:00] days. Most people give up before they [16:02] learn those tricks because the pain is [16:06] so great and the feeling of stupid and [16:08] incompetence is so strong that they [16:10] don't want to push through it. At least [16:12] in code you didn't have the physical [16:14] pain. You just had to feel dumb. And [16:16] I'll be real, I kind of miss feeling [16:18] dumb. I haven't gotten to as much lately [16:21] and I try to find ways to like [16:22] intentionally picking languages I don't [16:24] know like Rust when I build a new [16:25] project so that I have to not get it and [16:28] start learning things about it. But [16:29] every time I start feeling dumb, I feel [16:32] the itch. I feel the temptation to pull [16:35] the slot, to just do one more run in [16:38] hope that maybe this time it'll generate [16:40] a solution and now I don't have to learn [16:42] the thing. And I think other people just [16:45] don't have the same willpower. And I [16:48] don't think that is that exceptional a [16:49] thing. I don't think it was even [16:50] necessary before. But your your ability [16:53] to say no as a developer has never [16:55] mattered more than now. And your [16:57] willingness to feel stupid, to go [16:59] through the details and not let the AI [17:01] bail you out is a superpower. [17:04] Personally, I have been learning a lot [17:06] more than I've ever learned because of [17:07] this. Both because I'm learning all [17:08] about AI and the business side [17:10] especially, but also because I'm finding [17:12] more fun in things that I felt too dumb [17:14] in before. Like I'm getting way deeper [17:16] in cryptography. I'm making cryptography [17:18] challenges. I never thought I'd be able [17:19] to do that. I was always fascinated by [17:21] it. Now I'm doing it and I'm asking [17:23] questions about it and I'm having back [17:24] and forth with the agents and now I [17:26] don't feel as bad bothering my friends [17:28] about it because I'll exhaust the AI's [17:30] capability to answer my questions first [17:32] and now when I bug a friend that is [17:34] deeper in the space I'm asking better [17:36] questions. Then there's also the aspect [17:38] of fear here and I have a feeling we'll [17:40] talk about that later so I'm not going [17:41] to dive into that just yet. Let's get [17:42] back to the article cuz it's already [17:44] making me talk too much. The next [17:46] section is called not just another [17:47] abstraction. Common refrain we hear in [17:50] the community is that programmers are [17:51] just quote moving up the stack and into [17:53] a different type of abstraction. Whether [17:55] or not these tools really are an [17:57] abstraction layer in the first place is [17:58] not a settled matter. A high level of [18:00] ambiguity is not a higher level of [18:02] abstraction. Woof bars. What he's [18:05] referring to here is the idea that we've [18:08] already done abstractions. Like we used [18:10] to do punch cards and then assembly made [18:12] it so we didn't have to poke the holes [18:14] in the cards. Then C happened and it was [18:16] much easier to write and then generate [18:18] code that was assembly for different [18:20] systems. Then we got C++ which would [18:22] include a lot of the things that you [18:24] would have to build yourself previously [18:25] in C. Then we got languages like Python [18:28] and JavaScript that didn't even have to [18:29] be compiled. They just ran in a virtual [18:32] layer, a runtime that was built in these [18:35] other languages. We kept abstracting [18:36] higher and higher up. And let's be real, [18:39] how many JavaScript developers can read [18:41] assembly? I mean, let's be real. How [18:43] many JavaScript devs can even read [18:44] JavaScript at this point? But you get [18:46] the idea. These abstractions would keep [18:50] you from knowing as much about the [18:51] layers below. But the best engineers had [18:53] strong incentives to learn at least one [18:55] layer above and below where they were. [18:57] All the best C++ devs I know are very [18:59] familiar with V8, the JS runtime. All [19:01] the best JavaScript devs I know are very [19:03] familiar with V8 and its quirks. The mid [19:05] ones don't understand the things above [19:07] and below them. But the great ones tend [19:08] to be at least one layer, maybe two or [19:10] three, above and below where they tend [19:12] to live. But is natural language another [19:14] one of these abstractions? Is markdown [19:17] to JavaScript what JavaScript is to C++? [19:20] I used to think it might be, but I'm [19:21] learning now the answer is probably no. [19:23] Let's see what Lars has to say about [19:24] this. If we put the abstraction [19:26] conversation to the side, it is true [19:28] that programmers tend to be weary of new [19:30] languages and new ways of programming. [19:31] When Fortrren was released, programmers [19:33] were skeptical of it as well. They had [19:35] similar claims. It was likely to [19:36] introduce more bugs and instability. [19:38] Writing assembly more directly was more [19:40] efficient. Later, there would be [19:41] discourse around the integration of [19:42] compilers, introducing too much magic [19:44] into the process. These were normative [19:46] arguments around the fear of what might [19:48] be lost if these new technologies were [19:50] embraced. The difference with what is [19:51] happening today is that those previous [19:53] fears were speculative and theoretical. [19:55] In just the short few years that AI [19:56] tooling has existed, we've already seen [19:58] significant impacts. These aren't just [20:00] junior devs, but even those with a [20:02] decade or more of experience. Here are [20:04] some posts that he grabbed from Reddit. [20:06] Losing my ability to code due to AI. [20:08] Hello everyone. I don't see it come up a [20:10] lot, but even after a few years of [20:11] coding, using AI on a regular basis for [20:13] over a year has made me feel a lot more [20:15] insecure about my coding abilities. I [20:17] feel like my skills are really [20:18] deteriorating while simultaneously [20:19] feeling like there might be no need to [20:21] know how to code at all. Handling [20:23] feeling dumber or like losing skills due [20:25] to the need of using AI. Recently, my [20:26] company started enforcing using only AI [20:28] for all software dev. That's a terrible [20:30] idea. Erase the code. I love that this [20:32] dev is so deep that code autocorrects to [20:34] codeex. It writes the code, then agents [20:37] review the code, etc. We're supposed to [20:38] be architects who only look at outcomes [20:40] and not the code. For context, I have 9 [20:42] years of experience. I'm 31, a father of [20:44] a 1-year-old, so let's agree that a side [20:45] project after hours is not an option. [20:48] Every time I use AI to do everything, I [20:50] feel like I'm losing my skills, that I'm [20:51] becoming a worse professional, etc. [20:53] Especially that if you want to get a new [20:55] job, you're mainly and mostly graded [20:57] based on your technical skills. Letting [20:59] AI do 100% coding fried my brain. Help. [21:02] AI reliance and cognitive decline. I [21:04] find myself using more and more AI to [21:06] speed my efficiency. Whether it's [21:07] organizing a schedule or a quick [21:08] screening of code to actually writing [21:10] small snippets. There are definitely [21:12] people experiencing this. I was afraid I [21:15] would experience this and somehow [21:18] haven't. I I know I keep making the same [21:21] comparison over and over again. I think [21:23] the fact that my job wasn't just coding [21:27] and hasn't been for a while prepped me [21:29] better for this. I've had a team of [21:31] engineers for the better part of a [21:34] decade at this point. And realizing my [21:37] best use of my time isn't being in the [21:39] weeds writing the code. It's helping the [21:41] team execute more effectively while [21:43] understanding the system well enough to [21:45] help them debug when things go wrong. I [21:47] write less than 5% of the code across [21:49] our products, but I solve over half the [21:51] outages. And I'm really proud of that. [21:53] My understanding of the system has gone [21:56] up, not down over time. And the AI tools [21:58] are helping me maintain that [22:00] understanding and guide my team better [22:03] as we architect our systems. I would bet [22:06] my ass that every single one of these [22:09] four people has never had to manage a [22:11] team before. I also see Chris Titus [22:13] Techch in chat with a similar experience [22:15] here. He's coming from a CIS admin and [22:17] infra background. Most of his coding [22:18] abilities used to revolve around [22:20] scripting and now with AI, it's really [22:22] opened so many doors. He could jump into [22:23] low-level languages he would have never [22:24] had time to before. And that's what I [22:27] experienced too. There's a lot of things [22:28] that weren't worth me learning because [22:31] the friction of going through the long [22:33] window of dumb and the burden I would be [22:35] to other people asking questions was too [22:36] high. AI has lowered that to the floor. [22:39] So the right mindset here can make you [22:42] way more productive and way more capable [22:45] of learning in a way that's really cool. [22:47] I'll say that less experienced engineers [22:50] like junior engineers, career [22:52] transitioners or people that just didn't [22:54] get it before, they're getting a little [22:57] more screwed here. My chat sent me this [22:59] tweet from Austin Kennedy who's 22 years [23:01] old. He thinks Claude Co is [23:02] deteriorating his brain. Every single [23:04] day for the last six months, he's had [23:05] six to eight quad code terminals open, [23:07] waiting for a response to so he can hit [23:08] enter 75% of the time. It's done [23:10] something to him. Apparently, his [23:11] friends bring it up pretty frequently. [23:13] None of them feel as sharp as they used [23:14] to. Don't know if it's just us or others [23:16] in their 20s who are feeling the same [23:17] thing, but something he's been thinking [23:19] about. Yeah, if you didn't get through [23:21] the years of friction to really [23:23] understand these things, you're going to [23:26] get addicted to the slot machine. I've [23:28] seen a lot of people falling for this in [23:30] particular. Also, the the worst ones are [23:32] the ones who have always been really [23:33] insecure. The people who I'll I'll be [23:36] real crude here. The people who don't [23:38] have imposttor syndrome. They are just [23:39] imposters. And I've seen some horrifying [23:42] examples of this. People who have been [23:44] like working at Google for four years [23:45] that don't know how to use SSH. Like [23:47] I've seen this a lot. And those people [23:49] are now addicted to the slot machine. [23:51] And they went from being kind of bad, [23:54] but like at least they could write some [23:55] Python here and there to just a net [23:58] negative on the team. Funny enough, I've [24:00] seen that same person instinctively go [24:02] to chat GPT and ask where they left [24:04] their keys because they're so used to [24:06] asking it everything. This archetype of [24:09] person, I would argue, was never [24:11] particularly useful. And the AI is just [24:16] continuing to erode their already eroded [24:18] brain. The gap between the great and not [24:20] great engineers has grown massively and [24:24] AI has accelerated that. And again, [24:27] examples from people in the industry [24:29] saying that the juniors on their team [24:30] are shipping really fast, but they don't [24:31] know how to debug anything they didn't [24:33] actually write the code for. This dev [24:35] hired a junior who learned to code with [24:36] AI. He can't debug without it. Don't [24:38] know how to help him. AI debugging [24:41] underrated. It's a specific skill [24:44] separate from building with AI. I don't [24:46] think you should be debugging without AI [24:48] at this point because if you have a bug [24:50] and it's affecting users, everything you [24:53] can do to increase the likelihood that [24:54] you solve the problem is something you [24:56] should be doing. So, when I had an [24:58] outage a few days ago on Ping, our video [25:00] product, I haven't touched that codebase [25:02] in 4 years minus like testing agents [25:05] upgrading it every once in a while, but [25:07] it was built on the OGT3 stack, a stack [25:09] that I invented. I know the layers very [25:12] well. I know where the failures can be. [25:14] So, I grabbed the first error I hit. I [25:17] pasted it into a codeex instance and [25:19] immediately went back to the browser to [25:21] try and get more info and debug it. I [25:23] ended up figuring out roughly what it [25:25] was. It was Prisma getting a null for an [25:27] ID when it was trying to do a [25:28] referential integrity check to get data [25:31] for a join that it was doing and it just [25:34] got a null and failed as a result. By [25:36] the time I had figured this out, the [25:38] agent that was running had its own [25:40] entirely different theory, but I didn't [25:42] care. I opened up another tab in T3 code [25:45] and asked a different question. Which of [25:47] these table referential integrity checks [25:49] is the most likely to have a problem and [25:51] I switched over to fast mode. While it [25:54] was running, I was going through the [25:55] code and going through our error logs. I [25:58] saw the notification that the request [25:59] was done. I went and checked and it said [26:01] that it was very likely to be the link [26:03] between user table and the join for [26:05] which users are in rooms. I knew what I [26:07] had to do at this point. I had to remove [26:08] all of the links between the rooms and [26:11] the user that were for this dead user. I [26:14] didn't want to write the SQL query [26:15] wrong. So I told it what our schema was [26:19] and asked it to write the query to [26:21] remove all the rows that match this [26:22] particular pattern. And then it worked [26:25] and then I was done. So I did around [26:28] three AI agent requests while I was [26:30] doing this debugging. I don't even know [26:32] what the first one output. I just had it [26:33] run in the background while I was [26:35] debugging. found a much more likely root [26:37] cause, asked a second agent about that. [26:40] It correctly identified what table the [26:42] problem would be from. I asked it to [26:44] write a query to figure out what row was [26:46] affected. It did. I pasted it. I got the [26:48] right result. I pasted the results back [26:50] into my agent. It told me what query to [26:52] run to clean it up and then it was [26:53] fixed. This was me and the AI going back [26:57] and forth sharing our understanding of [26:59] the capabilities of my system and what [27:01] we were experiencing in order to debug [27:04] more effectively. Note that this would [27:06] not have worked at all if I didn't know [27:07] the system already. I also would have [27:09] taken much longer to solve this if I [27:11] didn't have AI and I would have been [27:13] more scared about my solutions because I [27:14] didn't want to go write the [ __ ] SQL [27:16] for this when I was at an event in [27:18] Miami. Yeah. So, I am very okay with [27:22] using AI in the debugging process. [27:23] Anybody who says otherwise is either [27:25] stupid or bad faith. The problem is [27:28] people leaning on AI because they don't [27:30] understand the system and their refusal [27:32] to learn the system because it makes [27:33] them feel dumb results in them only [27:36] getting anything done with AI. Different [27:38] problems and I want to be very clear [27:39] with the distinction here because again [27:42] these tools are really useful when you [27:44] know what you're [ __ ] doing. Back to [27:46] the article, Lars says it is actually [27:48] different this time and I agree. This is [27:50] different from a C++ dev moving to [27:53] Python or Java because as he says, they [27:56] didn't complain about brain fog when [27:57] they made the move. They complained [27:58] about the awful object-oriented [28:00] programming patterns that they had to [28:01] adopt in Java. When a CIS admin moves to [28:03] AWS, they don't feel like they're losing [28:05] their ability to understand networking. [28:07] On that note, there's a lot of people [28:09] who would argue Verscell cost them their [28:10] networking understanding, but different [28:13] conversation for a different time. A [28:15] senior engineer losing their coding edge [28:16] and becoming rusty over time as they [28:18] move into managerial roles and practice [28:20] coding less often is not a new [28:21] phenomenon. This was the natural [28:23] progression of expertise. An engineer [28:25] would put in decades to coding [28:27] experience lots of friction and their [28:29] experience would be logged and that [28:30] would result in them having the time and [28:32] experience necessary to solidify their [28:34] skills and wisdom and they could apply [28:36] that wisdom when their job became less [28:37] about syntax and more about higher level [28:39] architectural decision. Those [28:40] individuals are not only exceedingly [28:42] rare, but you won't get the next wave of [28:44] seniors if we're all abdicating the [28:46] friction of writing, problem solving, [28:47] and debugging. Ding, ding, [ __ ] ding. [28:51] This is the concern I have. I am [28:53] predisposed to being good with this [ __ ] [28:56] because I already coded in a way that [28:58] relates to this. And then when I moved [29:01] to leadership positions and I was [29:02] advising at many different teams while [29:05] also coding and being in the weeds, too, [29:07] I got to build these skills really [29:09] early. And I'm super thankful for the [29:11] people I worked with for letting a [29:12] stupid [ __ ] 22year-old step way [29:15] outside of their role to start steering [29:17] architectural decisions and helping in [29:19] outages that they shouldn't be near. [29:21] Being involved in like P1 instances that [29:24] they should have nothing to do with and [29:26] learning not just how things work, but [29:29] more importantly how they fail. I'm [29:32] really [ __ ] proud of my debugging [29:34] skills. My team's almost annoyed that [29:36] like I can come into a codebase I've [29:38] barely touched in years because there's [29:41] some outage and say, "Oh, it's probably [29:42] that." And I'm right like 70% of the [29:44] time. And if I'm not, I get it right [29:46] within the next three tries. Usually my [29:49] systems understanding and my ability to [29:51] like link one, two, and three to form [29:53] the picture. That's what I'm good at. [29:56] And I wasn't initially. I had to build [29:58] that skill up because I was doing too [30:00] many things at any given time. and I was [30:02] lucky enough to be surrounded with [30:04] people that were cool with me stepping [30:05] way outside of what I should have been [30:07] doing. I will say that with the right [30:09] mindset and focus, I do think the skills [30:12] I built can be built independently now [30:15] if you build a big enough system and put [30:17] the effort into understanding where it [30:19] fails. On the other hand, the incentives [30:21] for that are going down and the interest [30:24] in building your fundamentals is going [30:27] down with it. I used to be the person [30:28] that would push back on learning like [30:30] fundamental CS. Like I didn't think you [30:32] needed to go memorize all of the [30:34] different sorting algorithms and all of [30:36] the different like big O notations for [30:39] different solutions to various problems. [30:41] Like I don't think most devs should need [30:43] to know how to inverse a binary tree. [30:45] But the moment you have to, you should [30:47] be able to figure it [ __ ] out. And [30:49] this is always my take. The fundamentals [30:52] don't matter until they do. And you [30:53] should be in the right mindset to learn [30:55] them when it makes sense to. when you [30:57] have a problem that benefits from it. If [30:59] something is slower than it should be [31:00] and you notice that your sort algorithm [31:02] takes too long, it's time to learn [31:04] better sort algorithms. I don't know if [31:06] that take of mine will carry over to [31:08] this era. I would hope that when you're [31:11] running into problems because you're [31:12] fetching all of your data through use [31:14] effects that you'll look into how other [31:16] people do it and you'll find React [31:17] Query, but I think it's more likely the [31:19] agent just does it for you and you never [31:21] learn the difference. I suspect that [31:23] because I've already seen a lot of [31:24] engineers do that even before AI. The [31:27] number of engineers I saw making their [31:29] code comically worse by fetching all of [31:31] their data in these weird patterns that [31:33] were super inconsistent and unreliable [31:35] across their codebase that wouldn't use [31:37] React Query because they don't want to [31:39] learn another new thing. [ __ ] [31:41] you're basically unlearning. It is less [31:43] code and less effort. It is a simple [31:45] wrapper for async functions. It couldn't [31:47] be easier. But the idea of another thing [31:49] to learn was enough of a turnoff for the [31:52] average low IQ dev that they wouldn't [31:54] [ __ ] bother. And now that person's [31:55] been given a lever they can pull to make [31:57] it matter even less. That sucks. AI is [32:00] going to take bad devs and make them [32:02] atrocious. But I do still hold a little [32:04] bit of hope that the devs who love this, [32:07] who really care about how things work, [32:09] not just the feeling of them working, [32:10] will take advantage of these tools to [32:13] accelerate how quickly they learn and [32:14] grow. And I have already seen this. It's [32:16] a small number of people, but I have [32:18] them in my community. People who are [32:20] doing way more than they should be at [32:22] their young age without any real career [32:24] experience yet because they're building [32:26] things bigger than they have any right [32:28] to and they're curious about why they're [32:30] breaking and how to solve the problems [32:31] at fundamental levels that I love. I [32:34] like this framing here, too. What's [32:36] happening now is a trend where devs who [32:38] have never had the longevity or the 30 [32:40] plus years of friction that lead to the [32:42] deep understanding are being moved to [32:43] higher level workflows requiring those [32:45] same skills to manage the AI agents that [32:47] the senior engineers took decades to [32:49] obtain. Yep. I'll go a step further. You [32:51] had to be a good engineer to have a big [32:53] code base. Either you were hired to help [32:55] in that big codebase or you built it [32:57] yourself. There was a intelligence and [33:00] competence requirement like a a friction [33:02] that was necessary like a you have to be [33:04] this tall to come in type thing. You had [33:06] to be this competent and this experience [33:08] to build real work before. Now Claude [33:11] can get you into a position where you're [33:13] maintaining a code base that is bigger [33:15] than any engineer with 5 years of [33:17] experience would be comfortable with and [33:18] you learned how to code a month ago if [33:20] you even actually learned. That is the [33:22] biggest issue is there's devs who are [33:24] way out of bound for where their [33:26] capabilities are and they're not using [33:28] the tools to learn to better their [33:30] capabilities. They're using the tools to [33:32] reach past their capabilities and then [33:34] just throw up their hands when things [33:35] break. Another great point from Chris [33:37] Titus Tech. He's on fire. He'd expand [33:39] this and say that if you do open source [33:40] and have contributors, it will help [33:41] point out the mistakes. I'll go even [33:43] further than you are here, Chris. Open [33:45] source maintainers are massively [33:46] outperforming average devs in the AI [33:48] world because they're used to slinging [33:51] slop and dealing with random [ __ ] [33:53] from various capabilities and levels of [33:55] engineers, many of which know better [33:57] than them, many of which know less than [33:59] them, all of which are opportunities to [34:01] learn. And this is actually why I think [34:03] you're an exceptional dev despite not [34:05] being a dev because you're doing [34:06] something way harder. You're trying to [34:08] fix Windows, but aside from that, you're [34:10] also trying to like maintain these real [34:13] legitimate open- source projects people [34:15] rely on every day. I say as a person who [34:17] relies on win till every time I do a new [34:18] Windows install, which is far too often. [34:20] That puts you in a position where you [34:22] learn so much more and those details [34:25] matter so much more. You've effectively [34:27] let yourself do 5 years of real world [34:30] experience every year with the stuff [34:31] that you do, even though you're not an [34:33] engineer in the traditional sense, which [34:35] is silly and dumb. and one of the many [34:37] reasons I want to help you get make more [34:38] [ __ ] money. So yeah, if you're doing [34:40] real open source stuff that people rely [34:41] on and use, whether you're a contributor [34:43] or even better a maintainer that is [34:46] helping go through stuff, your level of [34:48] experience for where you're at in your [34:50] career will be significantly higher than [34:53] you would otherwise expect. Like I know [34:55] people who have one year of experience [34:57] that is mostly open source work that [34:59] runs circles around somebody with five [35:01] years of experience at Microsoft. The [35:03] author does remind us that senior [35:04] engineers aren't immune. Simon Willis, [35:07] the creator of Django, good friend of [35:08] the channel, one of the best people in [35:10] the AI developer space for talking about [35:12] how this actually affects us as devs. He [35:14] has 30 years of experience. He's been [35:15] coding since I was born. He reported [35:17] that he doesn't have a firm mental model [35:19] of what the applications he builds can [35:21] do and how they work, which means each [35:23] additional feature becomes harder to [35:24] reason about. And I can absolutely [35:26] understand that. The skilled [35:27] orchestrator problem buried in a recent [35:29] study by Anthropic was a surprisingly [35:31] honest moment when speaking about the [35:33] risks of engaging with coding agents on [35:35] a regular basis. One reason that the [35:37] atrophy of coding skills is concerning [35:38] is the paradox of supervision. [35:40] Effectively using Claude requires [35:42] supervision and supervising Claude [35:44] requires the very coding skills that may [35:46] atrophy from overusing AI. A director of [35:48] software engineering at LinkedIn who has [35:49] 50 engineers reporting to them has [35:51] noticed it proliferating throughout the [35:53] organization and requested his team to [35:54] not use them for quote tasks that [35:57] require critical thinking or problem [35:58] solving. To grow skills, people need to [36:00] go through hardship. They need to [36:01] develop the muscle to think through [36:02] problems. How would someone question if [36:04] AI is accurate if they don't have [36:06] critical thinking? Yep. I don't know [36:08] what it looks like to build these skills [36:09] now. It's very different from how it [36:11] used to be. I'm sure there are new ways [36:13] to and I'm sure they're even more [36:14] effective using these tools, but I don't [36:16] know what that looks like because I [36:17] already have the skills. I can't [36:18] properly reset to my brain before I knew [36:21] all of these things. There's also the [36:23] question of what constitutes this [36:24] overuse. We already have evidence, both [36:26] datadriven and anecdotal, that these [36:28] skills can atrophy and dissipate rather [36:30] quickly, sometimes even within months. [36:32] This is the contradiction that has many [36:33] AI boosters talking out of both sides of [36:35] their mouths. The use of coding agents [36:37] is actively diminishing the very skills [36:38] needed to effectively manage the same [36:40] coding agents. LMS accelerate the wrong [36:43] parts. Oh boy, this is going to be a fun [36:45] section. Contrary to the current [36:47] narrative that is being espoused, we [36:49] didn't necessarily need to write code [36:51] faster, especially code that we didn't [36:53] fully understand, and particularly in [36:54] huge swaths that we couldn't review in [36:57] reasonable time frames. Before AI, a [36:59] good dev's priority list might look like [37:00] the following. First, understanding of [37:02] the code and its relation to the [37:04] codebase. Second, if the code is aligned [37:05] with the documented and efficient [37:07] standards. Three, as few lines of code [37:09] as needed to accomplish the goal while [37:11] maintaining readability, and four, [37:13] turnaround time. I don't agree. Depends [37:18] on what type of good dev you're [37:20] referring to here, because there's a lot [37:22] of things that make a dev good, and [37:23] everyone will disagree on what those [37:25] are. Some people think a good dev is [37:27] somebody who writes meticulously [37:28] detailed specs and writes five unit [37:30] tests per line of code. Others might [37:32] think a good dev is the person who [37:34] understands the user and the codebase [37:35] well enough to make the two meet. Others [37:38] might think the best dev is the one who [37:39] comes up with a novel solution that is [37:41] far outside of the way anyone else [37:42] thinks that no one understands until 5 [37:45] years later and then we're all using it. [37:46] I think good devs are people who solve [37:48] real problems. I like working with devs [37:50] that understand the code base, that are [37:53] writing code that is well aligned and [37:54] standard, that are writing as few lines [37:56] of code as possible, which is actually [37:58] very rare. or there's a lot of great [37:59] devs that don't even do this and have [38:01] good turnaround time. But I have found [38:03] that any one of these skills at the [38:05] upper end is novel enough that it makes [38:07] you unique. Like if you write really [38:09] efficient code, that is a thing you're [38:10] known for. Like I know Mark, my CTO, is [38:13] the code golfer. One of his favorite [38:14] things is to see if he can do a whole [38:16] advent of code problem in one line of [38:18] JavaScript. And then turnaround time, as [38:20] I mentioned before, was one of my [38:21] skills. And it was enough that it [38:22] boosted my career meaningfully that I [38:24] could come in, find the things that made [38:26] the road map unnecessarily complex, [38:28] helped trim and get like really locked [38:30] into the thing we actually wanted to [38:32] build. So we weren't distracted by all [38:35] the things that took most of the time [38:36] and brought none of the value. So I [38:39] would say a great dev has all of these [38:41] skills, but a good dev is somebody who [38:44] has the right compromise between them. [38:46] The problem is that agentic coding and [38:47] LMS in general are inverting this list. [38:50] Yeah, most devs should not be allowed to [38:52] code fast. That I agree with. As [38:55] somebody who coded fast a lot, watching [38:58] others try to keep up resulted in a lot [39:00] of pain. And the solution was often for [39:02] me to slow down, not because my code was [39:04] getting buggy, but to get everybody [39:06] around me to stop trying to keep pace [39:07] because when they did, everything fell [39:09] apart. And AI now has everyone trying to [39:11] keep pace, and now everything is falling [39:12] apart. Their capabilities and usage tend [39:14] to focus on speed by increasing the [39:16] amount of code that can be generated in [39:18] a specified time frame. Speed's a [39:19] natural byproduct of high aptitude. When [39:22] it's forced, it always leads to lower [39:24] accuracy. Okay, I do love this framing. [39:26] Actually, this is perfect. I earned my [39:28] right to the speed. Y'all haven't yet. [39:31] Okay, many of you have. I'm actually [39:32] really impressed with how competent so [39:34] much of my audience is when I meet you [39:35] guys at events and things. I'm blown [39:36] away with the [ __ ] so many of you are [39:37] doing. Your annoying ass co-workers have [39:40] not earned the right to ship fast yet. [39:42] And the result is slump. Julius on my [39:44] team has absolutely earned the right to [39:46] ship fast. He's shipping faster than I [39:48] ever have and is pushing the limits of [39:50] what agents can do, but also is very [39:52] meticulous about how things are [39:54] structured more than almost anybody. And [39:57] as the author says, the integration of [39:58] AI tools does not tend to focus much on [40:01] deeper understanding or conciseness. And [40:03] I want to be really clear because every [40:04] time I mention something like this, the [40:06] response is, "Oh, we need better tools [40:08] that do that. Those should make a lot of [40:09] money." And then I get five people [40:11] coming up to me at the OpenAI GBT 5.5 [40:14] event trying to get me to invest in [40:16] their company making AI education [40:18] products to help people learn better [40:20] with AI instead of just use the AI. Who [40:23] do you think makes more money, casinos [40:26] or people selling books about casinos? [40:29] There's pretty obviously one that does [40:31] much better. I have been burned on so [40:33] many education investments, even the [40:35] ones that were doing revenue, that I [40:37] just don't believe that people want this [40:39] at all. Given the option of a slot that [40:41] makes you feel good and a lesson that [40:43] makes you feel bad, 99% of people are [40:46] going to pick the prior, there is no [40:48] business building this, which sucks that [40:50] human nature in capitalism prevent tools [40:54] that educate you from being successful. [40:56] But that's your guys's fault as users, [40:59] not business's fault. Doesn't matter how [41:01] good the business does. If users don't [41:03] want it, it won't work. Believe me, I'm [41:05] speaking from a lot of experience here. [41:07] It is absolutely possible to use these [41:09] tools if you're determined enough in a [41:11] way that will actually make you learn [41:13] more and understand systems better. But [41:16] that's not how they're being used. Lots [41:17] of companies have force mandates that [41:19] you have to be doing more with AI and [41:20] they have crazy leaderboards and stuff [41:22] that are incentivizing bad usage. And [41:24] all the hype around that is [41:25] demonstrating just how bad things are [41:27] getting. Coding equals planning. This is [41:30] going to be a fun section. There's a [41:31] divide between devs that isn't [41:33] highlighted as much. Some of us plan and [41:35] think better with code. Thinking and [41:37] working in code isn't just meaningless [41:39] drudgery. It forces you to think about [41:41] things on a technical level that [41:42] involves everything from security to [41:44] performance to user experience to [41:46] maintainability. I very much agree here. [41:49] I like planning in code. A thing I talk [41:51] about a lot is what got coined at [41:52] Twitch's theo method. Instead of writing [41:55] a spec, assuming we know how everything [41:57] works, that is super long and tedious, [41:59] and then building the product and [42:00] realizing the spec doesn't make any [42:02] sense, I would start with a really [42:04] simple, minimal implementation that was [42:06] the minimum viable shape of the idea. [42:10] And in building that in just a few days, [42:12] often I would learn a ton. Sometimes it [42:15] would even be good enough we could ship [42:16] that as is. Other times I would find all [42:18] of the things that make it annoying to [42:21] implement and then I can write a good [42:23] spec based on what I learn. Death Fudge [42:25] put it perfectly in chat. Write once, [42:27] throw it away and then build it. Right. [42:29] Absolutely. And if AI helps you do that, [42:32] awesome. I did this so much it got [42:34] coined under my name at my last company [42:36] that I worked at traditionally. It is [42:39] really powerful to get in the weeds [42:41] first. You can't really do that in [42:43] coding without coding. I write much [42:45] worse plans when I'm not in the [42:47] codebase. That's just reality. And when [42:49] I'm working with my team, I'll often do [42:51] a first pass before proposing the thing [42:53] to the team so I have like my roots to [42:56] base my proposals on. And guess what? [42:58] Plan mode is not that. Plan mode is not [43:01] that at all. In a recent interview [43:02] discussing specri development, Dax, the [43:04] creator of Open Code, which is an open [43:06] source coding agent, no less, is quoted [43:08] as such. It's also worth noting Dax [43:09] isn't the creator of Open Code. He's a [43:10] devril at Open Code. Here's what he had [43:12] to say. When working on something new or [43:14] something challenging, me typing out [43:16] code is the process by which I figure [43:18] out what we should even be doing. I have [43:20] a really tough time just sitting there [43:21] writing out a giant spec on exactly how [43:23] the feature should work. I like writing [43:25] out types. I like writing out how some [43:27] of the functions might play together. I [43:28] like playing with the folder structure [43:30] to see what the different concepts [43:31] should be. And this is all stuff I think [43:33] most people, most programmers have [43:35] always done. I don't agree there. You [43:37] would be amazed how many programmers [43:40] don't do any of this. They just wait [43:42] till the ticket is cut properly and then [43:45] they spend way too long writing a [43:46] document and then hope they can get [43:48] promoted before they even finish the [43:50] feature. Most devs don't do this because [43:52] most devs are roughly average or worse. [43:55] Good devs do this, but most devs don't. [43:58] I do agree with him that we shouldn't [43:59] necessarily stop doing this. There's no [44:01] good reason to, and it's how we figure [44:03] out what to do and how to do it right. [44:04] The one big part I'll disagree with [44:06] here, though, is that when you get it [44:07] wrong, it's never been cheaper to fix [44:09] it. I always had a sense of dread when I [44:12] would commit to a new folder structure [44:14] or a new way to do type systems or a new [44:16] way to do data fetching because if I'm [44:18] wrong, getting it out as hell. Now I can [44:21] get it out in a for loop and that's [44:23] awesome. It has made my willingness to [44:24] experiment with these things go up a ton [44:27] and I'm trying patterns I never would [44:29] have tried before cuz they had way too [44:30] high a risk of being [ __ ] But they [44:32] turned out to work really well and I'm [44:33] surprised, but it never was worth the [44:35] effort before. So again, there's two [44:37] sides here. Back to the article. what [44:39] you say is often not what you mean and [44:41] LLMs fill in ambiguity with assumptions [44:43] or even worse hallucinations which leads [44:46] to more review, more agent revisions, [44:48] more tokens burned and more [44:49] disconnection from what is being [44:51] created. Inversely, you can marvel at [44:53] the most beautiful unambiguous perfectly [44:55] structured prompt you ever written and [44:56] the LM can still output a hallucinated [44:58] method because it's fundamentally a next [45:00] token prediction engine, not a compiler. [45:03] You cannot replace a deterministic [45:04] system with a probabilistic one and [45:06] expect zero ambiguity. As a JavaScript [45:08] dev, I am offended. Oh boy, this will be [45:10] a fun section. Vendor lockin. When I was [45:12] browsing LinkedIn during the cloud [45:14] outage that occurred a bit ago, I [45:15] noticed numerous posts highlighting that [45:17] certain devs and engineering teams were [45:19] at a standstill. Their workflows, their [45:20] own coding abilities, had already [45:22] reached a point where they were largely [45:23] dependent on these vendors. What used to [45:25] be a skill that they could execute with [45:26] just a keyboard and text editor suddenly [45:28] required a subscription to an AI model [45:30] provider. I haven't selfplugged in a [45:31] bit, so please permit me to do it this [45:34] one time. If you're experiencing vendor [45:36] lock in right now, that is your fault. [45:38] There are lots of great tools, and I [45:40] will obviously plug my own with T3 code, [45:42] that don't just give you the ability to [45:45] switch between models. They give you the [45:47] ability to switch between subscriptions [45:49] and providers. There is no world in [45:52] which claude, codecs, cursor, and open [45:55] code are all down at the same time. And [45:58] it's actually quite valuable to hop [46:00] between these things. I can't tell you [46:01] how many times I've had GBT 5.5 debug [46:05] Opus slop and how many times I've had [46:07] Opus come in and make a slightly better [46:08] UI for some GPT 5.5 code. A lot of devs [46:11] are doing this wrong. They are relying [46:14] on one thing way too hard. The same way [46:16] that a lot of devs rely on US East1 too [46:18] hard. The difference is that somehow [46:20] Anthropic is less reliable than US [46:22] East1, but it's the same problem. And [46:24] there's lots of good open-source [46:26] solutions to this problem. Again, T3 [46:28] Code is a fully open-source desktop app [46:31] and web app now, too, that you can use [46:33] to run all of your agents on your [46:35] existing subscriptions and hop between [46:38] them at a moment's notice. I have had [46:39] times where Claude was down and I wanted [46:41] to use it, but I hopped over to GPT 5.5 [46:44] and was fine or even hopped over to [46:46] Cursor where they were using Opus models [46:48] through other providers and also were [46:50] fine. You can also deploy Claude on [46:52] things like Amazon Bedrock, which has [46:54] way more reliability and better uptime [46:56] than you would get out of using Claude [46:58] directly. So, I don't love this vendor [47:01] lockin point. I think like all things, [47:04] reliability is your concern as a dev. [47:06] The problem here isn't that we're all [47:08] stuck relying on one thing. It's that [47:10] stupid devs have nothing else to do when [47:12] their thing goes down, so they complain [47:14] about it online. An interesting point [47:15] here is that you can't predict your [47:17] token cost. Model providers are heavily [47:19] subsidized and the models themselves are [47:20] built on shifting sands. Every new model [47:23] released follows the same pattern of [47:24] high benchmarks followed by hype [47:25] followed by the reality of usage and [47:27] everyone complaining about them being [47:28] nerfed and burning through 2x or 3x as [47:30] many tokens to get the same job done. [47:32] This is a cloud complaint. This is [47:34] absolutely a cloud complaint. Like this [47:35] is not how it works at open land. You [47:37] guys are just so deep on cla code that [47:39] your brains are falling out. everyone, [47:41] whatever side you're on, if you're a [47:43] Claude Code Dieard or a Claude Code [47:44] hater, Claude Code specifically has [47:47] ruined the discourse about so many of [47:49] these things. Oh, don't quote that. That [47:51] Primagen video, not that video. Not the [47:53] one I had to tear to pieces cuz it was [47:54] so wrong. Oh, no. Don't quote that. This [47:57] article was so good up until this point. [47:59] You know how much your employees cost, [48:01] but you have no idea how much your token [48:02] costs will be dayto-day, monthtomonth, [48:04] year to year. If all of your costs are [48:06] fixed, you don't have a real [ __ ] [48:07] business. I've never worked with a [48:09] company that is doing well that had [48:11] entirely fixed costs. Everything is [48:15] flexible. Everything fluctuates. [48:17] Computer costs skyrocketed because of [48:20] tariffs and RAM being more expensive. [48:22] Egg costs skyrocketed for restaurants. A [48:25] fixed cost business is a failing [48:27] business. Generally speaking, I'm just [48:30] going to skip this paragraph because I [48:32] don't agree. To be frank, I generally [48:34] think vendor lockin arguments are [48:36] competence failures. Good vendors make [48:38] it easier to do less work and the move [48:41] out of a given vendor is just the [48:43] adoption of the work you avoided doing. [48:45] So the example I often give is Verscell. [48:47] Moving off of Versell is easy. You just [48:49] have to write the code you hadn't [48:50] written yet. I don't write code that [48:52] only works on Verscell. I write code [48:54] that works on Versel that is missing [48:56] pieces that I didn't have to write [48:58] because I was using Verscell and [48:59] Verscell handles it. When I leave [49:00] Verscell, I have to go add those pieces [49:02] back in. Using cloud code means I don't [49:05] have to write the code by hand. Leaving [49:07] cloud code doesn't mean I can't write [49:08] code anymore. It means I have to go [49:09] write it myself again or use any of the [49:11] 15 other providers. Like there's so many [49:14] options. I just I don't like this [49:15] argument. Vendor lockin is not the right [49:17] framing for all of this. So let's go to [49:18] the last section here. Demoting AI's [49:20] role and certainly not advocating for [49:22] typing all code out manually. [49:23] Programmers have always been looking for [49:25] ways to create code without having to [49:26] write it. That's why we have things like [49:27] emit the autocomplete system that is in [49:30] VS Code for shorthand. I always hated [49:32] EMTT personally but each their own. They [49:33] also have traditional autocomplete [49:35] snippets as well. I used to be like the [49:37] biggest anti-nippid and template guy. AI [49:39] means I don't have to care anymore, [49:40] which is great. Even Cobalt was designed [49:42] to encapsulate more instructions with [49:43] less writing by using English-like words [49:46] such as move and write. BigQuery's motto [49:48] was write less, do more. LMS are another [49:50] addition to this array of codegen tools. [49:52] What I'm advocating for, though, is [49:54] leveraging LM's and coding agents as a [49:56] secondary process, a way that doesn't [49:58] sacrifice the individual skill at the [50:00] alter productivity. You can flip the [50:02] script and lean on them to brainstorm [50:03] the planning parts of the process while [50:06] staying actively engaged throughout [50:07] implementation. Delegating to them on an [50:09] asneeded basis. You can leverage the [50:11] productivity gains and mitigate the [50:13] comprehension debt. I'm going to go [50:14] through his workflow and then I'm going [50:16] to discuss mine and my framing that [50:17] might be a little different. He uses LLM [50:19] to help generate specs and plans while [50:21] he facilitates the implementation. [50:23] It's an inversion of the orchestration [50:25] flow. He's still manually coding [50:26] anywhere from 20% to 100% depending on [50:28] the task. I use LMS to investigate but [50:31] not to write the plan. That's [50:33] interesting. I very often am writing [50:36] pseudo code when I do engage with the [50:37] models. Closing the distance between the [50:39] request and generate code. Yep, [50:40] absolutely. I love writing pseudo code. [50:41] I like doing it back and forth on pseudo [50:43] code too where I'll have the model [50:44] generate the pseudo code. I'll make [50:46] recommendations. We'll go back and [50:47] forth. I'll be like, "Okay, that's good. [50:49] What does it look like in my codebase?" [50:51] He also uses the models as delegation [50:52] utilities for ad hoc code generation and [50:54] interactive documentation as well as [50:56] research tools so that he can constantly [50:58] ask questions, iterate, refactor, and [50:59] gain clarity. Okay, now we're cooking. [51:02] We'll go back there in a sec. He never [51:04] generates more than he can review in a [51:06] given sitting. If it's too much to [51:07] review, he slows down and splits the [51:09] task up, manually refactoring when [51:11] needed to ensure a comprehensive [51:13] understanding of the end result. And [51:14] he'll never ask an LLM or agent to [51:16] implement something that he's never done [51:18] before or couldn't do on his own, except [51:20] perhaps purely for educational or [51:22] tutorial purposes and often discarded [51:24] afterwards. Okay, he's dancing around a [51:27] concept here that I don't even know if [51:29] he has embraced yet. The harsh reality [51:32] is that most code wasn't worth writing [51:35] before if it wouldn't be run thousands [51:37] of times. Any task that code can solve, [51:40] a human can too, just not necessarily as [51:43] efficiently. But if I only have to do [51:44] the thing once and it would take a [51:46] thousand lines of code, it wasn't worth [51:49] writing that code. I would just do the [51:50] thing by hand. The important thing to do [51:53] is to think about how important is each [51:56] function that you're writing. Is the [51:58] code that you're writing code that's [52:00] going to be run thousands of times a day [52:02] by your users? Or is it code that's [52:04] going to be one once in a migration? Or [52:06] maybe you're doing some data analysis [52:07] and you want to like dig something out [52:09] of 500,000 rows in a CSV and you're only [52:12] going to run the code once. you just [52:13] want to get this info. Understanding how [52:17] frequently a piece of code is going to [52:19] run is essential in understanding how [52:21] important that code is and how important [52:23] it is to understand that code. And once [52:25] you've internalized this, you can go [52:28] further with it. When you realize [52:30] there's a lot of code where the quality [52:32] doesn't matter because you're just [52:33] running the thing one time and not [52:35] thinking about it again, you're going to [52:36] start writing code for things you [52:38] wouldn't have before. I have written so [52:40] much code for [ __ ] stuff like oneoff [52:43] calculators for checking numbers from [52:45] one specific task I did or writing a [52:48] 2000 line of code JS file to manage [52:51] assets on my NAS when I'm in the middle [52:53] of transferring a bunch of files between [52:55] [ __ ] Those things were never worth [52:56] writing code for before cuz it would be [52:58] faster to just sit there and do the task [52:59] yourself. Now all of a sudden it is way [53:03] more valuable to write code for those [53:05] things. And that has been the biggest [53:07] shift for me is using the AI to write [53:10] code that otherwise wouldn't have been [53:11] worth writing and at the same time using [53:13] AI to better understand the code that is [53:16] worth writing. The harsh reality is that [53:18] most people who are working with agents [53:20] can't tell you which code is running at [53:22] all, much less which code is running a [53:23] lot and which code is run once. And if [53:25] you don't have that level of [53:26] understanding, you need to fix that. But [53:29] once you have this understanding and you [53:31] can think through the work you're doing [53:32] in this range, you're going to find more [53:35] value on both ends of that spectrum. On [53:37] the end where you're writing code to run [53:38] personally just a couple times, you'll [53:40] be doing way more in solving way more [53:42] interesting problems in more interesting [53:44] ways. And on the other side, the most [53:46] complex code can be explained to you [53:48] with an agent and you can find the hot [53:50] paths and learn more about how it's [53:52] architected. And if there's something [53:53] wrong with it, you can use the agent to [53:55] adjust things at massive scales like you [53:57] couldn't before. And I have found that I [53:59] use AI entirely differently for the code [54:01] that is run a lot and is shipping to [54:03] users versus the code that I'm using for [54:06] one-off tasks. And realizing this and [54:08] realizing you can do better in both [54:10] areas with AI is the powerful unlock [54:13] I've been trying to help more of you [54:14] have. The author titles the next [54:16] section, I'm not going faster, but I'm [54:18] doing better quality work. Why not both [54:21] is my challenge. Faster for the one-off [54:24] things, faster to solve problems, faster [54:26] to do stuff that wasn't even worth doing [54:29] before, but improving the quality in [54:31] things that required too much manpower, [54:33] improving the quality in things that you [54:35] didn't understand fully and now can. [54:37] Getting more versions of a thing out [54:38] before solidifying the one you want to [54:40] commit to. The code that matters should [54:42] be better quality because of AI. And the [54:44] code that doesn't should be 10 times [54:46] more prolific because of AI. We should [54:48] get both. And when those two get [54:50] confused with each other, everything [54:51] falls apart. Let's wrap this up because [54:53] this was an awesome article. I'll be [54:55] real. I want to let him have the last [54:56] word. The productivity gains from these [54:58] models are real. And so is the friction [55:00] and understanding that came from [55:01] engaging with the work on a tangible and [55:03] frequent basis. Despite countless failed [55:05] attempts at trying to democratize coding [55:07] while not understanding coding, we're [55:09] faced with the reality that you cannot [55:10] understand code without engaging with [55:12] it. It's also become clear that if you [55:14] don't keep engaging in writing it, you [55:16] can lose touch with that understanding, [55:17] which will in turn make you a less [55:19] capable orchestrator in the first place, [55:21] rendering this phase of AI coding a [55:23] strange and needlessly stressful [55:24] interlude. Perhaps I am worrying too [55:26] much, but history contains lessons. This [55:28] all feels similar, though, like another [55:30] large experiment we're running on [55:32] ourselves. We've been through a similar [55:33] period with the introduction of social [55:35] media without understanding the [55:36] long-term implications, and we're now [55:37] faced with attention deficit amongst [55:39] many other issues on a wide scale. This [55:41] time we're gambling with something much [55:42] riskier. He ends with a quote from [55:44] Jeremy Howard. People who go all in on [55:46] AI agents now are guaranteeing their own [55:49] obsolescence. If you outsource all your [55:51] thinking to computers, you stop [55:53] upskilling, learning, and becoming more [55:55] competent. I absolutely agree. This is a [55:58] phenomenal article from Lars. Definitely [56:00] recommend checking out his blog. It'll [56:01] be linked in the description if you want [56:03] to see his other posts. This is far from [56:05] his only great blog post. Definitely [56:06] check out his indispensable value in AI [56:08] era post as well as everyone can [56:10] delegate now just from this year alone. [56:12] Very thankful to Lars for writing this. [56:13] This is an awesome read and I hope you [56:15] learn something from it. Don't let the [56:17] AI take away your thinking. Let it [56:19] advance your thinking and you can build [56:21] better, smarter things as you learn more [56:23] and solve more problems. If AI isn't [56:25] making you smarter, you are using it [56:27] wrong. And I highly recommend you [56:28] reflect before you lose those valuable [56:30] skills. It's a really important time to [56:32] be on top of these things now more than [56:33] ever. and letting those skills atrophy [56:36] will hurt your career long term. That's [56:38] all I have to say on this for now.  📄 **Full text:** ![[Full Document Contents/Articles/We All Fell for It….md|We All Fell for It… by YouTube]] ## Highlights - architectural level can spot the issues in these thousands of lines of generated code before they become a problem. Yet, in an ironic twist of fate, it's the individual's critical thinking skills and cognitive clarity that AI tooling has now been proven to impact negatively. This is all around the term cognitive debt, which is a really good phrasing. Many relevant people like Simon Willis and Martin Fowler are describing the experience of cognitive debt directly. They talk about getting lost in their own projects and finding it harder to confidently add new features. They can move faster, but they ([View Highlight](https://read.readwise.io/read/01krbpmsacggrehaj7pfqcr17m)) - Tags: 👻 ai highlighted - the details of all of the context of stuff in your head. The problem is I perceive it here is that more people became theos because of AI. I used to ship like five plus projects a year before AI cuz I just loved building things and putting them out there for people. That took a lot of not like expertise in the traditional sense, but it was a just like the way I built, the way I thought about things and how I would cut project scope down to get a deliverable, usable version as efficiently as possible. Hell, this is why I made the T3 stack. I wanted to be ([View Highlight](https://read.readwise.io/read/01krbpmsczcryak69x1zh46z9n)) - Tags: 👻 ai highlighted - easier to build things with confidence rapidly that would work reliably without having to fully understand all of the pieces. I was kind of an early vibe coder. Not because I was using AI to write all my code, but because as soon as it worked, I would move on to the next thing and forget what the hell I had just done. It was just like willy-nilly deleting giant chunks of code, writing code mods to update thousands of things, hoping that it worked and just checking if the build came out correct in the end. I have been ([View Highlight](https://read.readwise.io/read/01krbpmsg0b2azszsdf8j2yttr)) - Tags: 👻 ai highlighted - idea. Erase the code. I love that this dev is so deep that code autocorrects to codeex. It writes the code, then agents review the code, etc. We're supposed to be architects who only look at outcomes and not the code. For context, I have 9 years of experience. I'm 31, a father of a 1-year-old, so let's agree that a side project after hours is not an option. Every time I use AI to do everything, I feel like I'm losing my skills, that I'm becoming a worse professional, etc. Especially that if you want to get a new job, you're mainly and mostly graded based on your technical skills. Letting AI do 100% coding fried my brain. Help. ([View Highlight](https://read.readwise.io/read/01krbpmsmp1sa3rnrbx12k9yae)) - Tags: 👻 ai highlighted - AI reliance and cognitive decline. I find myself using more and more AI to speed my efficiency. Whether it's organizing a schedule or a quick screening of code to actually writing small snippets. There are definitely people experiencing this. I was afraid I would experience this and somehow haven't. I I know I keep making the same comparison over and over again. I think the fact that my job wasn't just coding and hasn't been for a while prepped me better for this. I've had a team of ([View Highlight](https://read.readwise.io/read/01krbpmspxhgk40pgz0zzacaxw)) - Tags: 👻 ai highlighted - engineers for the better part of a decade at this point. And realizing my best use of my time isn't being in the weeds writing the code. It's helping the team execute more effectively while understanding the system well enough to help them debug when things go wrong. I write less than 5% of the code across our products, but I solve over half the outages. And I'm really proud of that. My understanding of the system has gone up, not down over time. And the AI tools are helping me maintain that ([View Highlight](https://read.readwise.io/read/01krbpmsx869r6921jxh0h7yaa)) - Tags: 👻 ai highlighted