Why Linus and DHH are vibe coding now - CourtneyR.dev's 2nd Brain

Why Linus and DHH are vibe coding now 🔗 **Source:** [Why Linus and DHH are vibe coding now](https://www.youtube.com/watch?v=5vp9ypOUgMw) > [!note]+ Document Notes > tags: [ai-coding, software-engineering, developer-skills] > author: Theo - t3.gg > source: YouTube > reference: [https://www.youtube.com/watch?v=5vp9ypOUgMw] > date created: 2024-12-28 15:30 > > # 🏷️ Title: Why Linus and DHH are vibe coding now >  ## 🧰 Action Inbox - [H1] Develop clarity skills for better AI prompting — essential for delegation #skills - [H2] Practice decomposing work into agent-compatible units — orchestration training #workflow - [H3] Focus on delegation and orchestration over individual coding capability — career growth #management ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Cursor Engineering Blog](https://cursor.sh/blog) - [DHH's Blog Post on AI Agents](https://dhh.dk/) ## 📝 Summary - Senior developers like DHH, Linus Torvalds, and others are embracing AI coding tools despite initial skepticism - The shift indicates AI tools have matured beyond simple autocomplete to production-grade code generation - Success with AI coding correlates with senior developer skills: clarity, delegation, and orchestration rather than raw coding ability - This represents a fundamental shift in software engineering from individual capability to team/system management - AI adoption forces developers to develop management and communication skills earlier in their careers ## 📖 Main Content The video explores why prominent senior developers have recently embraced AI coding tools after initial resistance. Theo argues this shift occurs because AI coding success depends on skills that senior developers have developed: clear communication, work decomposition, and orchestration abilities. DHH recently "promoted" AI agents in his workflow from learning aids to production contributors. Linus Torvalds admitted to "vibe coding" for non-critical projects, using AI to generate Python visualization code for audio effects. Anti-res replaced 3,800 lines of C++ with AI-generated C code, having different AI models review each other's work. The key insight is that effective AI coding requires the same skills needed for team leadership: writing clear specifications, breaking work into manageable chunks, and reviewing output effectively. Junior developers often struggle with AI tools because they lack the domain knowledge to properly evaluate generated code, while senior developers can quickly assess correctness and provide better prompts. This trend suggests the industry is shifting from valuing individual coding capability toward orchestration and delegation skills, making management abilities essential for all developers. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/5vp9ypOUgMw?t=0) — [H1] Senior developers embracing AI coding - Key idea: Prominent developers like DHH, Linus, and Anti-res are now actively using AI tools - Evidence: "It feels like there's just been an explosion in these really talented developers suddenly embracing AI tools" #### ⏱️ [02:15](https://youtu.be/5vp9ypOUgMw?t=135) — [H2] DHH's paradigm shift on AI agents - Key idea: DHH promoted AI agents from learning aids to production contributors - Evidence: "They are fully capable of producing production-grade contributions to real life code bases" #### ⏱️ [04:30](https://youtu.be/5vp9ypOUgMw?t=270) — [H2] Linus embraces vibe coding for non-critical work - Key idea: Linus uses AI for projects outside his core expertise - Evidence: "I cut out the middleman and just use Google Anti-gravity to do the audio sample visualizer" #### ⏱️ [06:45](https://youtu.be/5vp9ypOUgMw?t=405) — [H3] Building tools to solve adjacent problems - Key idea: AI enables creating small utilities and experiments rather than modifying large codebases - Evidence: "A problem you have in a big codebase might not be best solved in that big codebase" #### ⏱️ [09:20](https://youtu.be/5vp9ypOUgMw?t=560) — [H2] Anti-res replaces C++ with AI-generated C - Key idea: Replaced 3,800 lines of C++ template library with minimal C implementation - Evidence: "This code was written by Claude using Opus 4.5 and tested carefully" #### ⏱️ [11:15](https://youtu.be/5vp9ypOUgMw?t=675) — [H1] Senior developers accept more AI output - Key idea: Data shows senior engineers accept more agent-generated code than juniors - Evidence: "Senior engineers accept more agent output than juniors" #### ⏱️ [13:30](https://youtu.be/5vp9ypOUgMw?t=810) — [H2] Defining junior to senior developer progression - Key idea: Growth involves capability and clarity improvements - Evidence: "The way I would frame the gap is a combination of capability and clarity" #### ⏱️ [16:45](https://youtu.be/5vp9ypOUgMw?t=1005) — [H1] Senior to staff requires delegation and orchestration - Key idea: Advanced roles depend on managing others, not individual coding speed - Evidence: "One programmer can only do so much... delegation and orchestration" #### ⏱️ [20:20](https://youtu.be/5vp9ypOUgMw?t=1220) — [H2] Capability skills matter less for AI coding - Key idea: Traditional coding skills are less important than communication and delegation - Evidence: "Being good at clarity when describing what you want to build is really useful when prompting an agent" #### ⏱️ [23:15](https://youtu.be/5vp9ypOUgMw?t=1395) — [H3] Industry overindexed on coding capability - Key idea: GitHub contribution charts and code output have been poor success metrics - Evidence: "How much code you ship has always been how we measure competence" #### ⏱️ [26:30](https://youtu.be/5vp9ypOUgMw?t=1590) — [H2] Linus as original "vibe coder" - Key idea: Linus delegates implementation based on clear specifications - Evidence: "He sends an idea to the email list, somebody makes changes, emails him the patch" #### ⏱️ [28:45](https://youtu.be/5vp9ypOUgMw?t=1725) — [H3] Anti-AI developers lack delegation skills - Key idea: Developers opposing AI tools often haven't developed team management skills - Evidence: "They tend to be lacking in delegation and orchestration areas" #### ⏱️ [31:20](https://youtu.be/5vp9ypOUgMw?t=1880) — [H1] AI forces management skill development - Key idea: Working with AI agents teaches delegation, review, and orchestration - Evidence: "You can become a good manager this way" #### ⏱️ [34:15](https://youtu.be/5vp9ypOUgMw?t=2055) — [H2] Delegation feels inefficient but scales better - Key idea: Having others build features takes longer initially but creates sustainable ownership - Evidence: "This thing that would have taken me a day might take a week or two instead" #### ⏱️ [37:30](https://youtu.be/5vp9ypOUgMw?t=2250) — [H1] We're all managers now - Key idea: All developers need to develop management and delegation skills - Evidence: "More devs need to get better at spreading their work out across people or agents" ## 📚 References - [Cursor Engineering Blog Post](https://cursor.sh/blog) - [DHH Blog on AI Agents](https://dhh.dk/) - [Theo's Video on Not Falling Behind with AI](https://www.youtube.com/channel/UCDIBBmkZIB2hjBsk5-2V9BQ) ## 🗣️ Paraphrase - Senior developers are adopting AI coding tools because they have the communication and delegation skills needed to work effectively with agents - The most successful AI coding requires breaking down problems clearly and reviewing output effectively, not writing code faster - Traditional software engineering is evolving from individual coding ability toward team orchestration and system thinking ## 📰 Newsletter The landscape of AI-assisted development is shifting dramatically as industry veterans embrace tools they once dismissed. DHH, Linus Torvalds, and other senior developers are moving beyond simple autocomplete to letting AI generate production code. The key insight? Success with AI coding isn't about raw programming ability—it's about the same skills that make great tech leads: clear communication, effective delegation, and strong code review practices. For WordPress developers, this suggests focusing on: - Writing clearer specifications for features and fixes - Breaking large customizations into smaller, manageable pieces - Developing stronger code review and quality assessment skills - Building tools and utilities to solve problems adjacent to main projects The future favors developers who can orchestrate work effectively, whether with human teams or AI agents. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Education: Develop workshops on AI-assisted development practices for different skill levels - Developer experience: Create templates and examples for effective AI prompting in development workflows - Developer marketing: Showcase senior developer adoption patterns to validate AI tool legitimacy #### Community - Maintainers: Develop guidelines for AI-generated code review and acceptance criteria - Contributors: Create mentorship programs pairing experienced code reviewers with AI tool users - Ecosystem: Establish cross-project standards for AI-generated code quality and documentation #### WordPress - Core: Evaluate AI assistance policies for core contributions and establish review standards - Documentation: Create guides for using AI tools effectively in WordPress development contexts - Training: Develop lesson plans teaching delegation and orchestration skills alongside technical skills ## 🧪 Hypotheses - Senior developers succeed with AI coding because they possess better specification writing and code review skills - The shift to AI-assisted development will accelerate the need for management skills at all career levels - Developers who resist AI tools may be those who haven't developed strong delegation and communication abilities - Libraries will be replaced by AI-generated code based on specifications and prompts ### 📊 Methodology - Survey correlation between team leadership experience and AI tool adoption success - Analyze code review patterns between junior and senior developers using AI assistance - Study the relationship between communication clarity and AI output quality ### ❓ Questions - How will code ownership and maintenance change when AI generates significant portions of codebases? - What new skills will become essential as AI handles more implementation details? - How should engineering career progression adapt to emphasize orchestration over individual capability? ### 🔮 Future Research - Long-term maintainability patterns of AI-generated code in production systems - Optimal team structures mixing human leadership with AI implementation - Impact of AI coding on junior developer skill development pathways ### 💡 Implications - Practice: Developers need to prioritize communication and delegation skills development - Education: Computer science curricula should include team management and specification writing - Career: Individual coding speed becomes less valuable than system design and coordination abilities - Industry: Software teams may restructure around orchestration roles rather than pure implementation ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Clear progression charts showing skill development across career levels - Improve: Workflow diagrams showing AI integration patterns, organizational charts #### 🔊 Aural learners - Present: Podcast-style discussion format with examples and anecdotes - Improve: Interview segments with actual senior developers using AI tools #### 🗣️ Verbal learners - Present: Clear definitions of capability vs clarity vs orchestration, detailed analogies - Improve: More concrete examples of prompting strategies and specification writing #### 🧩 Kinesthetic learners - Present: Practical examples of code generation and review processes - Improve: Step-by-step guides for implementing AI workflows, hands-on exercises #### 🧠 Logical learners - Present: Clear progression framework from junior to senior to staff roles - Improve: Specific metrics for measuring delegation success, decision trees for AI adoption #### 🧑‍🤝‍🧑 Social learners - Present: Discussion of team dynamics and collaboration patterns - Improve: Framework for peer learning AI tools, community adoption strategies #### 🧘‍♀️ Solitary learners - Present: Individual skill assessment framework and career reflection prompts - Improve: Self-evaluation checklists for management readiness #### 🌿 Naturalistic learners - Present: Evolution metaphors for career development and industry change - Improve: Ecosystem thinking about developer roles and AI tool integration ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy and logical content flow - Improve: Better alt text for any embedded examples or screenshots #### Keyboard navigation - Present: Standard video controls and transcript availability - Improve: Timestamped navigation and chapter markers #### Contrast and readability - Present: High contrast video with clear audio narration - Improve: Ensure any code examples meet contrast requirements #### Media and captions - Present: Full transcript provided with content - Improve: Synchronized captions with technical term definitions ### 🌍 DEIB Assessment #### Cultural breadth - Present: Examples from diverse technical leaders and open source maintainers - Improve: Include perspectives from underrepresented groups in tech leadership #### Inclusive language - Present: Gender-neutral terms, avoids exclusionary jargon - Improve: Acknowledge different career paths and non-traditional backgrounds #### Neurodiversity support - Present: Clear section structure and consistent formatting - Improve: Multiple examples for each concept, varied explanation styles #### Representation - Present: Multiple technical role models from different backgrounds - Improve: Broader range of company sizes and geographic representation ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from skills analysis to AI adoption patterns - Inductive strength: Multiple examples support general conclusions about senior developer adoption - Causal reasoning: Links delegation skills to AI success with clear mechanisms - Analogical strength: Team management analogies effectively explain AI collaboration patterns #### Fallacies - Hasty generalization: Assumes all anti-AI developers lack management skills without comprehensive evidence - False dichotomy: Implies developers must choose between individual capability and delegation skills #### Tone of voice - Overall tone: Confident and assertive with some provocative elements to drive engagement ### 🛡️ DARVO Analysis - Deny: No patterns of denial present - Attack: Some criticism of anti-AI developers but focused on skill gaps rather than personal attacks - Reverse victim/offender: No victim/offender reversal present - Emotional cues and rhetoric: Uses strong language about industry change but maintains focus on skill development ## 🎯 Conclusion The adoption of AI coding tools by senior developers signals a fundamental shift in software engineering toward orchestration and delegation skills. Success with AI isn't about coding faster—it's about communicating clearly, breaking down work effectively, and reviewing output critically. This evolution forces all developers to develop management capabilities earlier in their careers, making team leadership skills essential for individual productivity. The future belongs to developers who can effectively coordinate both human and AI contributions rather than those who simply write code quickly. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Senior developers embrace AI after developing delegation skills > [!quote] [Why Linus and DHH are vibe coding now](https://www.youtube.com/watch?v=5vp9ypOUgMw) by --- ## Full Transcript [00:00] AI coding is really, really cool if you [00:02] suck at writing code yourself. That's [00:03] why we're only seeing junior devs who [00:05] are using these tools. People like Dan [00:06] Abramov, the creator of React, or DHH, [00:09] the creator of Rails, or Lionus Torva, [00:11] the creator of Linux, or Anti-Res, the [00:13] creator of Reddus. Wait, they're not [00:14] junior. What the hell's going on? Oh [00:17] boy. It feels like there's just been an [00:20] explosion in these really talented [00:22] developers suddenly embracing and taking [00:25] on these AI tools. It's been wild to [00:28] watch. On one hand, they're a bit late, [00:30] but on the other, it still feels like [00:32] we're all so so early. And a lot of [00:35] these people, even the ones that I'm not [00:36] necessarily the most fond of, have [00:38] historically cared a lot about their [00:40] craft and the details and doing things [00:42] right. Which is why it's kind of crazy [00:45] to see all of them embracing AI the way [00:48] they are now. If I'm being honest, I [00:50] don't know many devs who are shipping a [00:52] lot of code that aren't embracing these [00:54] tools at this point, especially [00:56] experienced developers. And there's a [00:58] lot of reasons for that. I've been [01:00] thinking a lot about this post from Eric [01:02] over at Cursor. Turns out senior [01:04] engineers accept more agent output than [01:06] juniors. This is a very interesting [01:08] observation. And I have so much to talk [01:10] about. One thing I have to talk about [01:12] first though is today's sponsor. AI [01:14] models are pretty smart, but they get [01:15] way smarter when they have access to a [01:17] browser. And no, using curl and bash [01:19] doesn't count. I'm talking an actual [01:20] browser where they can click buttons, [01:22] sign in, and do real work. That's why I [01:24] love today's sponsor, Kernel. They're [01:26] the fastest way to get a browser out for [01:27] your agents to use. And I mean fast in a [01:29] lot of different ways. They spin up in [01:31] under 400 milliseconds. It takes under [01:33] 10 minutes to get started using them. [01:35] Yes, really. And also, just a quick [01:37] anecdote, I reported a bug with an older [01:40] version of their package because I [01:41] hadn't upgraded yet. And within 10 [01:44] minutes, mind you, at 900 p.m., within [01:47] 10 minutes, they had shipped a fix. That [01:50] kind of response time is essential for [01:52] real businesses, which is why companies [01:53] like Cash App have already made the move [01:55] over to kernel. Here's an example action [01:56] from one of their example runners. We [01:58] give it a name, create browser for [02:00] testing. In this case, it is a promise [02:03] that takes in the context. It creates a [02:05] browser and then leaves it on because [02:07] this is a browser we want to be able to [02:09] use for things. So, you run the command [02:10] and now you have a URL to a reall life [02:13] browser running in the cloud that you or [02:15] your agents can use. Give your agents [02:17] access to the entire web at soy.v.link/ [02:19] link/ colonel. And yes, I'm still sick. [02:21] Sorry. I uh have the terrible upper [02:24] respiratory thing going around SF and [02:26] the bay right now. Hopefully, I'll have [02:28] my voice back proper very soon. I [02:30] started thinking about this video when [02:31] DHH made this blog post about promoting [02:34] AI agents. What he's specifically [02:36] referring to is that the role these [02:37] agents have in his day-to-day work has [02:39] changed and he is promoting them [02:41] effectively to a higher level of [02:43] involvement in his work and day-to-day. [02:45] As he says here, "I'm ready to give the [02:47] current crop of AI agents a promotion. [02:49] They're no longer just here to help me [02:51] learn or answer my questions or check my [02:53] work. They are fully capable of [02:54] producing production-grade contributions [02:56] to real life code bases." Pure vibe [02:58] coding remains an aspirational dream for [03:00] professional work for me for now. [03:03] Supervised collaboration though is here [03:05] today. I've worked alongside agents to [03:07] fix small bugs, finish substantial [03:08] features, and get several drafts on [03:10] major new initiatives. The paradigm [03:12] shift finally feels real. Yeah. So, if [03:16] you are talking about these things as [03:17] though they're only useful for people [03:19] working on small side projects or [03:21] everyone's favorite comment, Theo [03:22] doesn't know anything about real big [03:24] code bases. He only works on startup [03:26] scale. Your god and save your DHH is now [03:29] on our side. It's happened. These tools [03:31] are no longer just ways to quickly edit [03:34] some CSS on a page or look into how [03:38] something works or answer questions. [03:40] They are commanding real systems and [03:42] doing real work. How you choose to use [03:45] and embrace that can vary a lot. For [03:47] example, Lionus who recently said that [03:49] vibe coding is okay as long as it's not [03:51] used for anything that matters. [03:53] Specifically using the definition of [03:55] vibe coding where you aren't reading the [03:57] code, you are just generating it to go [03:59] do something. And he is putting his [04:01] money where his mouth is and does this [04:02] himself. He put up a repo recently for [04:05] digital audio effects audio noise and he [04:07] wanted to do some visualizers in it. And [04:09] when he did that, he decided that his [04:11] knowledge of Python and visualizations [04:13] with it aren't really his strength. And [04:15] rather than try to learn it and do it [04:18] himself or go do a bunch of Googling, he [04:20] actually vibecoded it himself. I know [04:23] more about analog filters, and that's [04:24] not saying much than I do about Python. [04:26] It started out as my typical Google and [04:28] do the monkey see monkey do kind of [04:30] programming, but then I cut out the [04:31] middleman himself and just use Google [04:34] Anti-gravity to do the audio sample [04:36] visualizer. While I don't necessarily [04:38] think anti-gravity is the best tool to [04:40] embrace the modern AI coding experience, [04:43] the fact that he is seeing value here is [04:45] huge. If you haven't already watched my [04:47] video on not falling behind with AI [04:49] stuff, I highly recommend watching that [04:51] because I go in depth on a lot of pieces [04:53] on how to embrace and catch up on these [04:55] things. One of the things that I really [04:58] tried to push here is this idea of [05:00] thinking out of the box. What are some [05:02] things that you would build if you had [05:04] more time and knowledge, but don't? so [05:07] you can't like just little one-off tools [05:09] that you wish existed. Those could be a [05:11] library that exists but doesn't quite do [05:13] what you want or some web app to manage [05:15] something in a game that you play. What [05:18] tools, what accessories, what pieces of [05:21] software don't exist that you wish did. [05:23] And the more you can think in this way [05:25] where you realize that a problem you [05:26] have in a big codebase might not be best [05:29] solved in that big codebase, maybe it's [05:31] better solved in a small random repo [05:33] next to it that lets you debug something [05:35] or look into something or experiment. If [05:37] you have a theory about a certain [05:39] library you want to play with in your [05:40] project, but implementing it in that [05:42] project is too complex, you go spin up [05:44] something to test it out and test the [05:45] limits. If you're curious what different [05:47] AI models are capable of, you can build [05:49] your own evals and scaffolding to test [05:51] those things without having to actually [05:53] look at write or much less read the code [05:56] yourself. The thing to understand here [05:58] is that AI can write code that works and [06:00] solves useful problems. How big of [06:03] problems you let it solve and how much [06:04] you embrace that code is for you to [06:07] understand and decide on yourself. One [06:09] way of thinking about it is how much are [06:11] you willing to let that code execute [06:13] before it's worth reading. If you're [06:15] writing some code to just run once or [06:17] twice on your own machine, who cares? If [06:19] you're writing code to actually ship to [06:21] prod, maybe you go the more DHH way [06:23] where you're treating it like a co-orker [06:24] that you're working with and reading [06:26] with. It's also worth noting that DHH [06:28] just a few months ago didn't think that [06:30] these things were particularly good. He [06:33] did a Lex Freedman podcast where he [06:34] talks about this and said that he [06:36] doesn't think these are great beyond the [06:38] AI autocomplete. Actually, he says that [06:40] that's not even that great overall. But [06:42] now with tools like open code, he is [06:44] much more heavily using these things. [06:46] Another great example comes from this PR [06:48] that was just filed by anti-res, the [06:50] creator of Reddus. There's a dependency [06:52] in Reddus for fast float, which is a C++ [06:55] dependency. He is annoyed having this [06:58] giant pile of C++ in the codebase, [07:00] especially if you use C++, you know how [07:02] annoying it is to manage external code. [07:04] It's rough. He's trying to get more and [07:05] more of the C++ out. and he replaced [07:08] this 3,800 line C++ template library [07:10] with a minimal pure C implementation. [07:13] And he has this note here. This code was [07:15] written by Claude Code using Opus 4.5 [07:17] and tested carefully, both hand tested [07:19] and tested against the original [07:20] implementation in a synthetic way. The [07:22] code review was independently performed [07:23] by Codeex GPT 5.2. Isn't that wonderful? [07:27] He did thoroughly review it with a [07:29] different model. Yeah. And he posts all [07:32] the results. It ends up being [07:33] significantly faster and building faster [07:35] and having less steps. all good things. [07:37] This also touches on a topic I'm [07:39] probably going to do a whole separate [07:40] video on, which is the idea that [07:41] libraries, as we know and understand [07:43] them now, are going to start dying in [07:45] favor of prompts and specs. So, why is [07:48] it that these specific senior devs are [07:50] all embracing these tools, but a handful [07:52] of other ones aren't? This is where my [07:54] hot takes are going to come in, and [07:55] we're going to start with Eric's post [07:57] here. As Eric said, senior devs tend to [08:00] accept more agent output than juniors [08:02] do. This is for a handful of reasons. [08:04] They write higher signal prompts with [08:06] tighter specs and minimal ambiguity. [08:08] They decompose work into agent [08:10] compatible units. They have stronger [08:12] priors for correctness, making reviews [08:14] faster and more accurate. And juniors [08:16] generate plenty, but they lack the [08:18] verification heristics to confidently [08:20] greenlight output. Also, you'll notice [08:22] here management and executives tend to [08:25] accept quite a bit more, especially on [08:27] the higher bound here. Staff does even [08:29] more as well. The amount of code being [08:31] accepted varies depending on your level. [08:33] Let's talk a bit about why this is the [08:36] case. Going to ask you a hypothetical [08:38] question. What makes a junior dev into a [08:41] senior dev? Just think about this. How [08:44] would you define the difference between [08:45] a junior dev and a senior one? I'll let [08:47] chat participate for this as well. Seen [08:50] a lot of pieces here. Mostly people [08:51] saying experience differences confidence [08:54] and knowledge. Seniors better at [08:57] everything. One interesting one here is [09:00] talks less which I don't necessarily [09:03] agree with. The way I would frame the [09:06] gap is a combination of two big things. [09:09] Capability and clarity. These are the [09:12] key skills you level up as you improve [09:15] as a developer. Your capability goes up [09:17] when you can do more work in less time [09:19] with a better understanding and a lower [09:21] failure rate. The clarity is really [09:24] important though as your communication [09:26] skills improve and you get better at [09:28] talking about the things you're working [09:29] on and sharing them the right ways with [09:31] the right people at the right level of [09:33] detail. The next question, how about the [09:36] gap from senior to staff? What makes [09:38] this this one's a lot harder? Some [09:41] people are saying a title has been [09:43] employed at Fang. You're now a business [09:45] manager able to find large scopes making [09:48] more stuff in parallel. Some people are [09:50] catching on to it. responsibility. [09:53] Interesting. The ability to ask for pay [09:55] and title rises. Eh, I would argue it's [09:58] delegation and orchestration. The harsh [10:01] reality is that one programmer can only [10:04] do so much. And as you scale up and [10:07] level up, you realize quickly the cap of [10:10] your own capability as an individual [10:12] typing code in a keyboard into a [10:14] computer. It does not matter how fast a [10:17] typer you are or how good you are at [10:19] whatever programming languages and tools [10:21] you use at a certain point. And if you [10:23] continue trying to just skill up in your [10:26] independent individual capability, you [10:29] will hit a ceiling. Some people have an [10:31] inherently higher ceiling for that than [10:33] others. But it is effectively impossible [10:36] for one really talented person to go as [10:40] fast and as thorough as a team of well [10:44] organized and orchestrated people being [10:46] led by somebody with a clear vision. So [10:48] there's a couple pieces here that I want [10:50] to focus on. Capability is what most [10:52] people think of when they think of the [10:53] level of an engineer. Like the more [10:56] senior you are in your title, the better [10:58] you are at writing code. And [11:00] hypothetically speaking, the more well [11:02] you'd be able to perform in like a [11:04] competitive programming exercise, the [11:06] faster you could build a solution to a [11:08] problem independently. I would argue all [11:10] of these skills are different as you [11:12] level up. Here's a lame way of looking [11:15] at this. If you were to measure these [11:17] capabilities by level, this is rough [11:20] averages from my experience working with [11:23] people in the industry. The capability [11:26] of a fresh out of college junior dev not [11:28] going to be super high. Their clarity is [11:30] in their ability to clearly describe [11:33] what they're working on, why they're [11:34] doing it, what problems they're running [11:36] into, and what is important about the [11:38] work they're doing also going to be very [11:40] low because they don't know what details [11:41] do and don't matter yet. I can't tell [11:44] you how many times I was reviewing a [11:46] junior developer's plan for some work [11:48] and they talk about things like the [11:50] syntax or the language or whatever. Like [11:53] none of that matters, especially if [11:55] you're working in an existing codebase. [11:56] Like I don't need a section on how you [11:58] expect to format the hooks in your React [12:00] code. I don't care. Very common thing [12:03] people do early in their careers. And [12:06] their ability to delegate and [12:07] orchestrate is obviously zero. They [12:08] don't know how to break up work yet [12:09] because they don't even know what the [12:10] work they're doing is yet. Senior, you [12:12] start to see massive jumps in capability [12:14] and meaningful jumps in clarity. But [12:16] delegation orchestration usually still [12:18] aren't strengths yet. But you'll notice [12:21] here, the senior is already very close [12:23] to tapped out both on capability and [12:26] clarity. So getting better at writing [12:28] code and getting better at writing about [12:30] the code you're writing does not [12:31] guarantee you anything. It's not going [12:33] to get you a promotion. Being better at [12:35] writing code is not going to be a [12:37] meaningful improvement because like [12:39] junior to senior, that's a 3x. senior to [12:41] staff. Even if they were to be like 10 [12:43] out of 10 or an 11 out of 10, you went [12:45] from 3xing between these two to a 20% [12:48] increase here at best. It's just not [12:51] worth it. There's obviously a midle that [12:53] goes between these, but I don't care. [12:54] That's what we're here to talk about. [12:55] I'm trying to clarify the differences [12:57] between these roles. It doesn't really [12:59] matter how good the staff dev is at just [13:02] writing code themselves because most [13:04] quality staff devs aren't doing that [13:06] anymore. They are now much more focused [13:09] on how the work gets done, not how they [13:12] will do the work. Ideally, a good staff [13:15] dev is not diving into the details [13:17] anywhere near as much. The best feeling [13:20] I had early in my career was when the [13:22] senior and staff devs on the teams I was [13:24] working with and around me when I was a [13:26] junior would have their moment of [13:28] realization that I knew enough of what I [13:30] was doing that they could hand things [13:32] off to me. And a lot of that came from [13:34] when I went above the expectation for [13:36] clarity in my earlier career stage when [13:39] I was better at describing what was [13:41] happening and why and why a specific [13:43] solution wouldn't work. That built [13:46] massive confidence out of the staff in [13:48] principal engineers that I was working [13:50] with. This seems like a weird tangent to [13:52] go on in a video about AI software [13:54] development, right? But what if I told [13:56] you this skill does not matter anywhere [13:58] near as much when you're doing AI code? [14:01] And these skills matter significantly [14:04] more. Huh? Turns out being good at [14:07] clarity when you're describing what you [14:09] want to build, what's going wrong with [14:11] it, what problems exist, and how they [14:12] should be solved, is really useful when [14:14] you're prompting an agent to do it. [14:16] Turns out delegation, when you're trying [14:17] to break up big pieces of work into [14:19] small chunks that can be independently [14:21] resolved by various parties, be it an [14:23] agent or earlier stage developer, is [14:26] really useful for agents. and [14:27] orchestration obviously very key for all [14:31] of this. The harsh reality here is that [14:33] capability has been overindexed on for a [14:36] long time in our industry. The amount of [14:39] code that you can independently write [14:41] has been this weird flex people love to [14:44] do and even still to this day people [14:46] love bragging about their GitHub [14:47] contribution chart on their GitHub [14:50] profile because how much code you ship [14:52] has always been how we measure your [14:54] competence as a developer. I've never [14:56] liked this, even though it was a measure [14:58] that made me look pretty good because I [15:00] used to ship a ton of code. Learning [15:03] that these other pieces in particular, [15:04] delegation and orchestration are [15:06] essential to success as you level up and [15:09] make bigger, more important software was [15:11] a really, really tough thing for me to [15:13] get over. But I also think this is why I [15:15] have been enjoying these tools so much [15:18] because I got over this in 2021 when I [15:21] quit my job, made a startup, and now was [15:23] blocking myself constantly and blocking [15:25] my team too. These are skills I needed [15:28] to level up on in order to do the work [15:31] that I do. And believe it or not, [15:33] everyone we've just talked about, [15:35] anti-res, Lionus, DHH, Michael, the [15:39] creator of Effect, all of these people [15:41] have also really focused in on these [15:44] skills. Many of them still love writing [15:46] code themselves. But Lionus doesn't [15:48] write a whole lot of code in the Linux [15:50] kernel anymore. It's very rare he [15:51] actually writes a contribution. Usually, [15:53] he sends an idea to the email list, and [15:56] somebody who he trusts will go make the [15:57] changes, email him the patch, and if he [15:59] likes it, he'll apply it. He's [16:01] effectively the first vibe coder in this [16:03] sense. He's actually reading the code. [16:05] So that definition of vibe coding [16:06] doesn't necessarily match, but the idea [16:08] being writing down a clear, concise [16:11] description of what you want and how you [16:12] want it done, seeing a result, and then [16:15] bringing it into the codebase. It [16:17] doesn't matter if it's an AI doing it or [16:19] if it's a human doing it. These are the [16:20] same thing. I see people having this [16:22] realization in chat right here. It's [16:24] true. People overindex on code don't [16:27] understand what it means to be an [16:28] engineer rather than just a programmer. [16:30] Yep. Software engineering is moving [16:32] towards actual engineering. This [16:33] orchestration super important and that's [16:36] what's changing. And I don't want to [16:38] call anybody out in particular, but if [16:41] you do go look at the people who are [16:44] really weirdly anti- AI code stuff, I [16:47] won't say a thing about their capability [16:49] because a lot of them are very very [16:51] capable engineers and have built [16:53] incredible things. But if you look at [16:54] their history, you look at the work [16:56] they've done, you look at the ways that [16:58] they've worked, the job roles they've [16:59] had, and the teams they've run, if [17:01] they've run teams, they tend to be [17:03] lacking in these other areas, especially [17:05] delegation and orchestration. That [17:07] doesn't mean they're junior devs. It [17:09] simply means that the skills that make [17:11] you really capable with these tools are [17:13] skills that are not their strengths. And [17:15] if you're a n out of 10 capability [17:18] engineer where you can write incredible [17:20] code, but you're not as good at running [17:21] a team or delegating across employees, [17:25] this is going to be a lot harder for [17:26] you. Thankfully, this is how we have [17:28] mostly done titles in software dev where [17:31] senior is as high as you can get purely [17:33] on your ability to write code and then [17:35] the rest tends to come from your ability [17:37] to communicate, operate, and run teams. [17:40] And agents are a really cool way to [17:42] level the skill up early. And here's [17:43] where we get to my favorite part. You [17:45] can become a good manager this way. I [17:47] think this is going to force a ton of [17:50] developers to get better at things like [17:53] clarity in their requirements, at [17:55] managing work being done in parallel, at [17:58] rejecting work that isn't quite at the [18:00] bar. The only thing that it won't teach [18:02] them is politeness. Because it's a lot [18:04] easier to tell an agent, "Your PR sucks. [18:06] I'm closing it." than it is to tell a [18:08] person on your team. But these skills [18:10] are so important. Just like on a human [18:12] level, if you want to do more and be [18:15] more capable, you have to get good at [18:18] delegation and orchestration. You have [18:20] to improve your ability to bring others [18:22] into the work who might not be as good [18:24] as you are at writing the code. Cuz [18:26] that's one of the weirdest feelings [18:27] you'll have the first time you have it. [18:29] I still have the weird feeling here and [18:30] there when I have work that I know [18:32] exactly how I would do it that I could [18:34] go build in a day and instead of doing [18:37] that, I choose to give it to somebody on [18:39] the team who will not take a day. [18:41] They'll take three or four days and the [18:44] result the first time won't be quite as [18:46] good as what I did and then I'm going to [18:47] have to give them a bunch of feedback [18:48] and then wait for the next rendition and [18:50] this thing that would have taken me a [18:52] day might take a week or two instead. [18:54] That feels like a failure. And it feels [18:56] even worse if you measure your [18:57] capability and you measure your value by [19:00] how much code you're shipping. If you [19:02] spend your day in meetings taking tasks [19:04] that would have taken you a day and [19:05] breaking them out to take multiple weeks [19:07] for other engineers, you're going to [19:09] feel like you're not doing and it's [19:10] going to suck. But then one of those [19:13] things works and it ships and there's a [19:15] bug and the person who wrote the code [19:17] goes and fixes that bug. That's when it [19:19] clicks why you do it this way because [19:21] you can't possibly do all of those [19:24] one-day tasks and then maintain those [19:26] one-day pieces of work over time. But if [19:29] other people build it in ways they [19:31] understand, it spreads ownership and [19:33] understanding across the team in a way [19:36] that lets you ship more with more [19:37] confidence and spread the work around. [19:40] It's not just the work with a team, it's [19:42] the ownership, too. And that's the one [19:44] piece you lose with the AI. Claude Code [19:46] isn't going to own a mistake that it [19:48] made. It's not going to understand why [19:50] there's a problem and fix it for you [19:52] automatically. You can try to [19:53] orchestrate tooling to make that kind of [19:55] happen, but just due to how context [19:56] Windows works, they're not going to [19:58] remember why they did a thing. So, there [20:00] are some skills you won't learn this [20:01] way. But the general idea of letting go [20:04] and realizing your time isn't best spent [20:06] writing the code in the code file in [20:08] your editor. It's better spent thinking [20:10] about the system and how the pieces come [20:12] together and making the details less [20:15] your problem. That is key. And I think [20:18] the best AI developers are the ones who [20:20] have realized this. The people who are [20:22] going the furthest with these tools [20:23] aren't the people who just learned to [20:24] code. It's the people who have been [20:27] coding for a long time and realize these [20:29] tools are way, way easier and cheaper [20:32] than hiring a team of 20 people and [20:34] getting them all onboarded. So, as [20:36] crappy as it is to reduce things this [20:37] way, I really think the anti-AI people [20:40] just haven't run teams well and don't [20:42] understand this part. And that's fine. [20:44] Most developers don't. Historically, [20:47] there have been like one person in this [20:49] column for every 50 people in this [20:51] column. The majority of devs don't have [20:54] these skills. That has to change. More [20:56] and more devs need to level up their [20:58] ability to clearly explain what they're [21:00] doing and why they're doing it. More [21:02] devs need to get better at spreading [21:03] their work out across people or agents, [21:06] orchestrating all of it, and keeping all [21:08] of it together. We're all managers now. [21:10] If you don't want to be a manager, [21:12] that's fine. I don't know how long your [21:14] job's going to last, but we all need to [21:16] do this. And the more you do this, and [21:18] the better you get at this, the more [21:20] these tools will be useful to you, and [21:23] the bigger the things you can tackle [21:25] will become. I'm sure this comment [21:26] section won't be a disaster. Seriously [21:28] though, I hope you take this as what it [21:30] is, an opportunity to skill up your [21:32] comms and your clarity as you describe [21:34] the work that you want done rather than [21:35] an attack on your capability of writing [21:37] software. The future is exciting, but [21:40] only if you let it be. And I'm really [21:41] excited about where things are going. [21:43] Let me know what you all think. And [21:44] until next time, peace nerds.  ## 📺 Video ![](https://www.youtube.com/watch?v=5vp9ypOUgMw) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: Why Linus and DHH are vibe coding now ## 🧰 Action Inbox - [H1] Develop clarity skills for better AI prompting — essential for delegation #skills - [H2] Practice decomposing work into agent-compatible units — orchestration training #workflow - [H3] Focus on delegation and orchestration over individual coding capability — career growth #management ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Cursor Engineering Blog](https://cursor.sh/blog) - [DHH's Blog Post on AI Agents](https://dhh.dk/) ## 📝 Summary - Senior developers like DHH, Linus Torvalds, and others are embracing AI coding tools despite initial skepticism - The shift indicates AI tools have matured beyond simple autocomplete to production-grade code generation - Success with AI coding correlates with senior developer skills: clarity, delegation, and orchestration rather than raw coding ability - This represents a fundamental shift in software engineering from individual capability to team/system management - AI adoption forces developers to develop management and communication skills earlier in their careers ## 📖 Main Content The video explores why prominent senior developers have recently embraced AI coding tools after initial resistance. Theo argues this shift occurs because AI coding success depends on skills that senior developers have developed: clear communication, work decomposition, and orchestration abilities. DHH recently "promoted" AI agents in his workflow from learning aids to production contributors. Linus Torvalds admitted to "vibe coding" for non-critical projects, using AI to generate Python visualization code for audio effects. Anti-res replaced 3,800 lines of C++ with AI-generated C code, having different AI models review each other's work. The key insight is that effective AI coding requires the same skills needed for team leadership: writing clear specifications, breaking work into manageable chunks, and reviewing output effectively. Junior developers often struggle with AI tools because they lack the domain knowledge to properly evaluate generated code, while senior developers can quickly assess correctness and provide better prompts. This trend suggests the industry is shifting from valuing individual coding capability toward orchestration and delegation skills, making management abilities essential for all developers. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/5vp9ypOUgMw?t=0) — [H1] Senior developers embracing AI coding - Key idea: Prominent developers like DHH, Linus, and Anti-res are now actively using AI tools - Evidence: "It feels like there's just been an explosion in these really talented developers suddenly embracing AI tools" #### ⏱️ [02:15](https://youtu.be/5vp9ypOUgMw?t=135) — [H2] DHH's paradigm shift on AI agents - Key idea: DHH promoted AI agents from learning aids to production contributors - Evidence: "They are fully capable of producing production-grade contributions to real life code bases" #### ⏱️ [04:30](https://youtu.be/5vp9ypOUgMw?t=270) — [H2] Linus embraces vibe coding for non-critical work - Key idea: Linus uses AI for projects outside his core expertise - Evidence: "I cut out the middleman and just use Google Anti-gravity to do the audio sample visualizer" #### ⏱️ [06:45](https://youtu.be/5vp9ypOUgMw?t=405) — [H3] Building tools to solve adjacent problems - Key idea: AI enables creating small utilities and experiments rather than modifying large codebases - Evidence: "A problem you have in a big codebase might not be best solved in that big codebase" #### ⏱️ [09:20](https://youtu.be/5vp9ypOUgMw?t=560) — [H2] Anti-res replaces C++ with AI-generated C - Key idea: Replaced 3,800 lines of C++ template library with minimal C implementation - Evidence: "This code was written by Claude using Opus 4.5 and tested carefully" #### ⏱️ [11:15](https://youtu.be/5vp9ypOUgMw?t=675) — [H1] Senior developers accept more AI output - Key idea: Data shows senior engineers accept more agent-generated code than juniors - Evidence: "Senior engineers accept more agent output than juniors" #### ⏱️ [13:30](https://youtu.be/5vp9ypOUgMw?t=810) — [H2] Defining junior to senior developer progression - Key idea: Growth involves capability and clarity improvements - Evidence: "The way I would frame the gap is a combination of capability and clarity" #### ⏱️ [16:45](https://youtu.be/5vp9ypOUgMw?t=1005) — [H1] Senior to staff requires delegation and orchestration - Key idea: Advanced roles depend on managing others, not individual coding speed - Evidence: "One programmer can only do so much... delegation and orchestration" #### ⏱️ [20:20](https://youtu.be/5vp9ypOUgMw?t=1220) — [H2] Capability skills matter less for AI coding - Key idea: Traditional coding skills are less important than communication and delegation - Evidence: "Being good at clarity when describing what you want to build is really useful when prompting an agent" #### ⏱️ [23:15](https://youtu.be/5vp9ypOUgMw?t=1395) — [H3] Industry overindexed on coding capability - Key idea: GitHub contribution charts and code output have been poor success metrics - Evidence: "How much code you ship has always been how we measure competence" #### ⏱️ [26:30](https://youtu.be/5vp9ypOUgMw?t=1590) — [H2] Linus as original "vibe coder" - Key idea: Linus delegates implementation based on clear specifications - Evidence: "He sends an idea to the email list, somebody makes changes, emails him the patch" #### ⏱️ [28:45](https://youtu.be/5vp9ypOUgMw?t=1725) — [H3] Anti-AI developers lack delegation skills - Key idea: Developers opposing AI tools often haven't developed team management skills - Evidence: "They tend to be lacking in delegation and orchestration areas" #### ⏱️ [31:20](https://youtu.be/5vp9ypOUgMw?t=1880) — [H1] AI forces management skill development - Key idea: Working with AI agents teaches delegation, review, and orchestration - Evidence: "You can become a good manager this way" #### ⏱️ [34:15](https://youtu.be/5vp9ypOUgMw?t=2055) — [H2] Delegation feels inefficient but scales better - Key idea: Having others build features takes longer initially but creates sustainable ownership - Evidence: "This thing that would have taken me a day might take a week or two instead" #### ⏱️ [37:30](https://youtu.be/5vp9ypOUgMw?t=2250) — [H1] We're all managers now - Key idea: All developers need to develop management and delegation skills - Evidence: "More devs need to get better at spreading their work out across people or agents" ## 📚 References - [Cursor Engineering Blog Post](https://cursor.sh/blog) - [DHH Blog on AI Agents](https://dhh.dk/) - [Theo's Video on Not Falling Behind with AI](https://www.youtube.com/channel/UCDIBBmkZIB2hjBsk5-2V9BQ) ## 🗣️ Paraphrase - Senior developers are adopting AI coding tools because they have the communication and delegation skills needed to work effectively with agents - The most successful AI coding requires breaking down problems clearly and reviewing output effectively, not writing code faster - Traditional software engineering is evolving from individual coding ability toward team orchestration and system thinking ## 📰 Newsletter The landscape of AI-assisted development is shifting dramatically as industry veterans embrace tools they once dismissed. DHH, Linus Torvalds, and other senior developers are moving beyond simple autocomplete to letting AI generate production code. The key insight? Success with AI coding isn't about raw programming ability—it's about the same skills that make great tech leads: clear communication, effective delegation, and strong code review practices. For WordPress developers, this suggests focusing on: - Writing clearer specifications for features and fixes - Breaking large customizations into smaller, manageable pieces - Developing stronger code review and quality assessment skills - Building tools and utilities to solve problems adjacent to main projects The future favors developers who can orchestrate work effectively, whether with human teams or AI agents. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Education: Develop workshops on AI-assisted development practices for different skill levels - Developer experience: Create templates and examples for effective AI prompting in development workflows - Developer marketing: Showcase senior developer adoption patterns to validate AI tool legitimacy #### Community - Maintainers: Develop guidelines for AI-generated code review and acceptance criteria - Contributors: Create mentorship programs pairing experienced code reviewers with AI tool users - Ecosystem: Establish cross-project standards for AI-generated code quality and documentation #### WordPress - Core: Evaluate AI assistance policies for core contributions and establish review standards - Documentation: Create guides for using AI tools effectively in WordPress development contexts - Training: Develop lesson plans teaching delegation and orchestration skills alongside technical skills ## 🧪 Hypotheses - Senior developers succeed with AI coding because they possess better specification writing and code review skills - The shift to AI-assisted development will accelerate the need for management skills at all career levels - Developers who resist AI tools may be those who haven't developed strong delegation and communication abilities - Libraries will be replaced by AI-generated code based on specifications and prompts ### 📊 Methodology - Survey correlation between team leadership experience and AI tool adoption success - Analyze code review patterns between junior and senior developers using AI assistance - Study the relationship between communication clarity and AI output quality ### ❓ Questions - How will code ownership and maintenance change when AI generates significant portions of codebases? - What new skills will become essential as AI handles more implementation details? - How should engineering career progression adapt to emphasize orchestration over individual capability? ### 🔮 Future Research - Long-term maintainability patterns of AI-generated code in production systems - Optimal team structures mixing human leadership with AI implementation - Impact of AI coding on junior developer skill development pathways ### 💡 Implications - Practice: Developers need to prioritize communication and delegation skills development - Education: Computer science curricula should include team management and specification writing - Career: Individual coding speed becomes less valuable than system design and coordination abilities - Industry: Software teams may restructure around orchestration roles rather than pure implementation ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Clear progression charts showing skill development across career levels - Improve: Workflow diagrams showing AI integration patterns, organizational charts #### 🔊 Aural learners - Present: Podcast-style discussion format with examples and anecdotes - Improve: Interview segments with actual senior developers using AI tools #### 🗣️ Verbal learners - Present: Clear definitions of capability vs clarity vs orchestration, detailed analogies - Improve: More concrete examples of prompting strategies and specification writing #### 🧩 Kinesthetic learners - Present: Practical examples of code generation and review processes - Improve: Step-by-step guides for implementing AI workflows, hands-on exercises #### 🧠 Logical learners - Present: Clear progression framework from junior to senior to staff roles - Improve: Specific metrics for measuring delegation success, decision trees for AI adoption #### 🧑‍🤝‍🧑 Social learners - Present: Discussion of team dynamics and collaboration patterns - Improve: Framework for peer learning AI tools, community adoption strategies #### 🧘‍♀️ Solitary learners - Present: Individual skill assessment framework and career reflection prompts - Improve: Self-evaluation checklists for management readiness #### 🌿 Naturalistic learners - Present: Evolution metaphors for career development and industry change - Improve: Ecosystem thinking about developer roles and AI tool integration ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy and logical content flow - Improve: Better alt text for any embedded examples or screenshots #### Keyboard navigation - Present: Standard video controls and transcript availability - Improve: Timestamped navigation and chapter markers #### Contrast and readability - Present: High contrast video with clear audio narration - Improve: Ensure any code examples meet contrast requirements #### Media and captions - Present: Full transcript provided with content - Improve: Synchronized captions with technical term definitions ### 🌍 DEIB Assessment #### Cultural breadth - Present: Examples from diverse technical leaders and open source maintainers - Improve: Include perspectives from underrepresented groups in tech leadership #### Inclusive language - Present: Gender-neutral terms, avoids exclusionary jargon - Improve: Acknowledge different career paths and non-traditional backgrounds #### Neurodiversity support - Present: Clear section structure and consistent formatting - Improve: Multiple examples for each concept, varied explanation styles #### Representation - Present: Multiple technical role models from different backgrounds - Improve: Broader range of company sizes and geographic representation ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from skills analysis to AI adoption patterns - Inductive strength: Multiple examples support general conclusions about senior developer adoption - Causal reasoning: Links delegation skills to AI success with clear mechanisms - Analogical strength: Team management analogies effectively explain AI collaboration patterns #### Fallacies - Hasty generalization: Assumes all anti-AI developers lack management skills without comprehensive evidence - False dichotomy: Implies developers must choose between individual capability and delegation skills #### Tone of voice - Overall tone: Confident and assertive with some provocative elements to drive engagement ### 🛡️ DARVO Analysis - Deny: No patterns of denial present - Attack: Some criticism of anti-AI developers but focused on skill gaps rather than personal attacks - Reverse victim/offender: No victim/offender reversal present - Emotional cues and rhetoric: Uses strong language about industry change but maintains focus on skill development ## 🎯 Conclusion The adoption of AI coding tools by senior developers signals a fundamental shift in software engineering toward orchestration and delegation skills. Success with AI isn't about coding faster—it's about communicating clearly, breaking down work effectively, and reviewing output critically. This evolution forces all developers to develop management capabilities earlier in their careers, making team leadership skills essential for individual productivity. The future belongs to developers who can effectively coordinate both human and AI contributions rather than those who simply write code quickly. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Senior developers embrace AI after developing delegation skills > [!quote] [Why Linus and DHH are vibe coding now](https://www.youtube.com/watch?v=5vp9ypOUgMw) by --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=5vp9ypOUgMw)* **[00:00]** AI coding is really, really cool if you suck at writing code yourself. That's why we're only seeing junior devs who are using these tools. People like Dan Abramov, the creator of React, or DHH, the creator of Rails, or Lionus Torva, the creator of Linux, or Anti-Res, the creator of Reddus. Wait, they're not junior. What the hell's going on? Oh boy. [snorts] It feels like there's just been an explosion in these really talented developers suddenly embracing and taking on these AI tools. It's been wild to watch. On one hand, they're a **[00:30]** bit late, but on the other, it still feels like we're all so so early. And a lot of these people, even the ones that I'm not necessarily the most fond of, have historically cared a lot about their craft and the details and doing things right. Which is why it's kind of crazy to see all of them embracing AI the way they are now. If I'm being honest, I don't know many devs who are shipping a lot of code that aren't embracing these tools at this point, especially experienced developers. And there's a lot of reasons for that. I've been thinking a lot about this post from **[01:01]** Eric over at Cursor. Turns out senior engineers accept more agent output than juniors. This is a very interesting observation. And I have so much to talk about. One thing I have to talk about first though is today's sponsor. AI models are pretty smart, but they get way smarter when they have access to a browser. And no, using curl and bash doesn't count. I'm talking an actual browser where they can click buttons, sign in, and do real work. That's why I love today's sponsor, Kernel. They're the fastest way to get a browser out for your agents to use. And I mean fast in a lot of different ways. They spin up in under 400 milliseconds. It takes under **[01:33]** 10 minutes to get started using them. Yes, really. And also, just a quick anecdote, I reported a bug with an older version of their package because I hadn't upgraded yet. And within 10 minutes, mind you, at 900 p.m., within 10 minutes, they had shipped a fix. That kind of response time is essential for real businesses, which is why companies like Cash App have already made the move over to kernel. Here's an example action from one of their example runners. We give it a name, create browser for testing. In this case, it is a promise that takes in the context. It creates a **[02:05]** browser and then leaves it on because this is a browser we want to be able to use for things. So, you run the command and now you have a URL to a reall life browser running in the cloud that you or your agents can use. Give your agents access to the entire web at soy.v.link/ link/ colonel. And yes, I'm still sick. Sorry. I uh have the terrible upper respiratory thing going around SF and the bay right now. Hopefully, I'll have my voice back proper very soon. I started thinking about this video when DHH made this blog post about promoting AI agents. What he's specifically **[02:36]** referring to is that the role these agents have in his day-to-day work has changed and he is promoting them effectively to a higher level of involvement in his work and day-to-day. As he says here, "I'm ready to give the current crop of AI agents a promotion. They're no longer just here to help me learn or answer my questions or check my work. They are fully capable of producing production-grade contributions to real life code bases." Pure vibe coding remains an aspirational dream for professional work for me for now. Supervised collaboration though is here today. I've worked alongside agents to **[03:07]** fix small bugs, finish substantial features, and get several drafts on major new initiatives. The paradigm shift finally feels real. Yeah. So, if you are talking about these things as though they're only useful for people working on small side projects or everyone's favorite comment, Theo doesn't know anything about real big code bases. He only works on startup scale. Your god and save your DHH is now on our side. It's happened. These tools are no longer just ways to quickly edit some CSS on a page or look into how **[03:38]** something works or answer questions. They are commanding real systems and doing real work. How you choose to use and embrace that can vary a lot. For example, Lionus who recently said that vibe coding is okay as long as it's not used for anything that matters. Specifically using the definition of vibe coding where you aren't reading the code, you are just generating it to go do something. And he is putting his money where his mouth is and does this himself. He put up a repo recently for digital audio effects audio noise and he wanted to do some visualizers in it. And **[04:09]** when he did that, he decided that his knowledge of Python and visualizations with it aren't really his strength. And rather than try to learn it and do it himself or go do a bunch of Googling, he actually vibecoded it himself. I know more about analog filters, and that's not saying much than I do about Python. It started out as my typical Google and do the monkey see monkey do kind of programming, but then I cut out the middleman himself and just use Google Anti-gravity to do the audio sample visualizer. While I don't necessarily think anti-gravity is the best tool to **[04:40]** embrace the modern AI coding experience, the fact that he is seeing value here is huge. If you haven't already watched my video on not falling behind with AI stuff, I highly recommend watching that because I go in depth on a lot of pieces on how to embrace and catch up on these things. One of the things that I really tried to push here is this idea of thinking out of the box. What are some things that you would build if you had more time and knowledge, but don't? so you can't like just little one-off tools that you wish existed. Those could be a **[05:11]** library that exists but doesn't quite do what you want or some web app to manage something in a game that you play. What tools, what accessories, what pieces of software don't exist that you wish did. And the more you can think in this way where you realize that a problem you have in a big codebase might not be best solved in that big codebase, maybe it's better solved in a small random repo next to it that lets you debug something or look into something or experiment. If you have a theory about a certain library you want to play with in your project, but implementing it in that **[05:42]** project is too complex, you go spin up something to test it out and test the limits. If you're curious what different AI models are capable of, you can build your own evals and scaffolding to test those things without having to actually look at write or much less read the code yourself. The thing to understand here is that AI can write code that works and solves useful problems. How big of problems you let it solve and how much you embrace that code is for you to understand and decide on yourself. One way of thinking about it is how much are you willing to let that code execute **[06:13]** before it's worth reading. If you're writing some code to just run once or twice on your own machine, who cares? If you're writing code to actually ship to prod, maybe you go the more DHH way where you're treating it like a co-orker that you're working with and reading with. It's also worth noting that DHH just a few months ago didn't think that these things were particularly good. He did a Lex Freedman podcast where he talks about this and said that he doesn't think these are great beyond the AI autocomplete. Actually, he says that that's not even that great overall. But now with tools like open code, he is **[06:44]** much more heavily using these things. Another great example comes from this PR that was just filed by anti-res, the creator of Reddus. There's a dependency in Reddus for fast float, which is a C++ dependency. He is annoyed having this giant pile of C++ in the codebase, especially if you use C++, you know how annoying it is to manage external code. It's rough. He's trying to get more and more of the C++ out. and he replaced this 3,800 line C++ template library with a minimal pure C implementation. And he has this note here. This code was **[07:15]** written by Claude Code using Opus 4.5 and tested carefully, both hand tested and tested against the original implementation in a synthetic way. The code review was independently performed by Codeex GPT 5.2. Isn't that wonderful? He did thoroughly review it with a different model. Yeah. And he posts all the results. It ends up being significantly faster and building faster and having less steps. all good things. This also touches on a topic I'm probably going to do a whole separate video on, which is the idea that libraries, as we know and understand them now, are going to start dying in **[07:45]** favor of prompts and specs. So, why is it that these specific senior devs are all embracing these tools, but a handful of other ones aren't? This is where my hot takes are going to come in, and we're going to start with Eric's post here. As Eric said, senior devs tend to accept more agent output than juniors do. This is for a handful of reasons. They write higher signal prompts with tighter specs and minimal ambiguity. They decompose work into agent compatible units. They have stronger priors for correctness, making reviews faster and more accurate. And juniors **[08:16]** generate plenty, but they lack the verification heristics to confidently greenlight output. Also, you'll notice here management and executives tend to accept quite a bit more, especially on the higher bound here. Staff does even more as well. The amount of code being accepted varies depending on your level. Let's talk a bit about why this is the case. Going to ask you a hypothetical question. What makes a junior dev into a senior dev? Just think about this. How would you define the difference between a junior dev and a senior one? I'll let **[08:47]** chat participate for this as well. Seen a lot of pieces here. Mostly people saying experience differences confidence and knowledge. Seniors better at everything. One interesting one here is talks less which I don't necessarily agree with. The way I would frame the gap is a combination of two big things. Capability and clarity. These are the key skills you level up as you improve as a developer. Your capability goes up when you can do more work in less time **[09:19]** with a better understanding and a lower failure rate. The clarity is really important though as your communication skills improve and you get better at talking about the things you're working on and sharing them the right ways with the right people at the right level of detail. The next question, how about the gap from senior to staff? What makes this this one's a lot harder? Some people are saying a title has been employed at Fang. You're now a business manager able to find large scopes making more stuff in parallel. Some people are **[09:50]** catching on to it. responsibility. Interesting. The ability to ask for pay and title rises. Eh, I would argue it's delegation and orchestration. The harsh reality is that one programmer can only do so much. And as you scale up and level up, you realize quickly the cap of your own capability as an individual typing code in a keyboard into a computer. It does not matter how fast a typer you are or how good you are at whatever programming languages and tools **[10:21]** you use at a certain point. And if you continue trying to just skill up in your independent individual capability, you will hit a ceiling. Some people have an inherently higher ceiling for that than others. But it is effectively impossible for one really talented person to go as fast and as thorough as a team of well organized and orchestrated people being led by somebody with a clear vision. So there's a couple pieces here that I want to focus on. Capability is what most **[10:52]** people think of when they think of the level of an engineer. Like the more senior you are in your title, the better you are at writing code. And hypothetically speaking, the more well you'd be able to perform in like a competitive programming exercise, the faster you could build a solution to a problem independently. I would argue all of these skills are different as you level up. Here's a lame way of looking at this. If you were to measure these capabilities by level, this is rough averages from my experience working with **[11:23]** people in the industry. The capability of a fresh out of college junior dev not going to be super high. Their clarity is in their ability to clearly describe what they're working on, why they're doing it, what problems they're running into, and what is important about the work they're doing also going to be very low because they don't know what details do and don't matter yet. I can't tell you how many times I was reviewing a junior developer's plan for some work and they talk about things like the syntax or the language or whatever. Like **[11:53]** none of that matters, especially if you're working in an existing codebase. Like I don't need a section on how you expect to format the hooks in your React code. I don't care. Very common thing people do early in their careers. And their ability to delegate and orchestrate is obviously zero. They don't know how to break up work yet because they don't even know what the work they're doing is yet. Senior, you start to see massive jumps in capability and meaningful jumps in clarity. But delegation orchestration usually still aren't strengths yet. But you'll notice here, the senior is already very close **[12:23]** to tapped out both on capability and clarity. So getting better at writing code and getting better at writing about the code you're writing does not guarantee you anything. It's not going to get you a promotion. Being better at writing code is not going to be a meaningful improvement because like junior to senior, that's a 3x. senior to staff. Even if they were to be like 10 out of 10 or an 11 out of 10, you went from 3xing between these two to a 20% increase here at best. It's just not worth it. There's obviously a midle that goes between these, but I don't care. **[12:54]** That's what we're here to talk about. I'm trying to clarify the differences between these roles. It doesn't really matter how good the staff dev is at just writing code themselves because most quality staff devs aren't doing that anymore. They are now much more focused on how the work gets done, not how they will do the work. Ideally, a good staff dev is not diving into the details anywhere near as much. The best feeling I had early in my career was when the senior and staff devs on the teams I was working with and around me when I was a **[13:26]** junior would have their moment of realization that I knew enough of what I was doing that they could hand things off to me. And a lot of that came from when I went above the expectation for clarity in my earlier career stage when I was better at describing what was happening and why and why a specific solution wouldn't work. That built massive confidence out of the staff in principal engineers that I was working with. This seems like a weird tangent to go on in a video about AI software development, right? But what if I told you this skill does not matter anywhere **[13:58]** near as much when you're doing AI code? And these skills matter significantly more. Huh? Turns out being good at clarity when you're describing what you want to build, what's going wrong with it, what problems exist, and how they should be solved, is really useful when you're prompting an agent to do it. Turns out delegation, when you're trying to break up big pieces of work into small chunks that can be independently resolved by various parties, be it an agent or earlier stage developer, is really useful for agents. and orchestration obviously very key for all **[14:31]** of this. The harsh reality here is that capability has been overindexed on for a long time in our industry. The amount of code that you can independently write has been this weird flex people love to do and even still to this day people love bragging about their GitHub contribution chart on their GitHub profile because how much code you ship has always been how we measure your competence as a developer. I've never liked this, even though it was a measure that made me look pretty good because I used to ship a ton of code. Learning **[15:03]** that these other pieces in particular, delegation and orchestration are essential to success as you level up and make bigger, more important software was a really, really tough thing for me to get over. But I also think this is why I have been enjoying these tools so much because I got over this in 2021 when I quit my job, made a startup, and now was blocking myself constantly and blocking my team too. These are skills I needed to level up on in order to do the work that I do. And believe it or not, **[15:33]** everyone we've just talked about, anti-res, Lionus, DHH, Michael, the creator of Effect, all of these people have also really focused in on these skills. Many of them still love writing code themselves. But Lionus doesn't write a whole lot of code in the Linux kernel anymore. It's very rare he actually writes a contribution. Usually, he sends an idea to the email list, and somebody who he trusts will go make the changes, email him the patch, and if he likes it, he'll apply it. He's effectively the first vibe coder in this **[16:03]** sense. He's actually reading the code. So that definition of vibe coding doesn't necessarily match, but the idea being writing down a clear, concise description of what you want and how you want it done, seeing a result, and then bringing it into the codebase. It doesn't matter if it's an AI doing it or if it's a human doing it. These are the same thing. I see people having this realization in chat right here. It's true. People overindex on code don't understand what it means to be an engineer rather than just a programmer. Yep. Software engineering is moving towards actual engineering. This **[16:33]** orchestration super important and that's what's changing. And I don't want to call anybody out in particular, but if you do go look at the people who are really weirdly anti- AI code stuff, I won't say a thing about their capability because a lot of them are very very capable engineers and have built incredible things. But if you look at their history, you look at the work they've done, you look at the ways that they've worked, the job roles they've had, and the teams they've run, if they've run teams, they tend to be lacking in these other areas, especially **[17:05]** delegation and orchestration. That doesn't mean they're junior devs. It simply means that the skills that make you really capable with these tools are skills that are not their strengths. And if you're a n out of 10 capability engineer where you can write incredible code, but you're not as good at running a team or delegating across employees, this is going to be a lot harder for you. Thankfully, this is how we have mostly done titles in software dev where senior is as high as you can get purely on your ability to write code and then **[17:35]** the rest tends to come from your ability to communicate, operate, and run teams. And agents are a really cool way to level the skill up early. And here's where we get to my favorite part. You can become a good manager this way. I think this is going to force a ton of developers to get better at things like clarity in their requirements, at managing work being done in parallel, at rejecting work that isn't quite at the bar. The only thing that it won't teach them is politeness. Because it's a lot easier to tell an agent, "Your PR sucks. **[18:06]** I'm closing it." than it is to tell a person on your team. But these skills are so important. Just like on a human level, if you want to do more and be more capable, you have to get good at delegation and orchestration. You have to improve your ability to bring others into the work who might not be as good as you are at writing the code. Cuz that's one of the weirdest feelings you'll have the first time you have it. I still have the weird feeling here and there when I have work that I know exactly how I would do it that I could go build in a day and instead of doing **[18:37]** that, I choose to give it to somebody on the team who will not take a day. They'll take three or four days and the result the first time won't be quite as good as what I did and then I'm going to have to give them a bunch of feedback and then wait for the next rendition and this thing that would have taken me a day might take a week or two instead. That feels like a failure. And it feels even worse if you measure your capability and you measure your value by how much code you're shipping. If you spend your day in meetings taking tasks that would have taken you a day and breaking them out to take multiple weeks **[19:07]** for other engineers, you're going to feel like you're not doing and it's going to suck. But then one of those things works and it ships and there's a bug and the person who wrote the code goes and fixes that bug. That's when it clicks why you do it this way because you can't possibly do all of those one-day tasks and then maintain those one-day pieces of work over time. But if other people build it in ways they understand, it spreads ownership and understanding across the team in a way that lets you ship more with more **[19:37]** confidence and spread the work around. It's not just the work with a team, it's the ownership, too. And that's the one piece you lose with the AI. Claude Code isn't going to own a mistake that it made. It's not going to understand why there's a problem and fix it for you automatically. You can try to orchestrate tooling to make that kind of happen, but just due to how context Windows works, they're not going to remember why they did a thing. So, there are some skills you won't learn this way. But the general idea of letting go and realizing your time isn't best spent writing the code in the code file in **[20:08]** your editor. It's better spent thinking about the system and how the pieces come together and making the details less your problem. That is key. And I think the best AI developers are the ones who have realized this. The people who are going the furthest with these tools aren't the people who just learned to code. It's the people who have been coding for a long time and realize these tools are way, way easier and cheaper than hiring a team of 20 people and getting them all onboarded. So, as crappy as it is to reduce things this way, I really think the anti-AI people **[20:40]** just haven't run teams well and don't understand this part. And that's fine. Most developers don't. Historically, there have been like one person in this column for every 50 people in this column. The majority of devs don't have these skills. That has to change. More and more devs need to level up their ability to clearly explain what they're doing and why they're doing it. More devs need to get better at spreading their work out across people or agents, orchestrating all of it, and keeping all of it together. We're all managers now. **[21:10]** If you don't want to be a manager, that's fine. I don't know how long your job's going to last, but we all need to do this. And the more you do this, and the better you get at this, the more these tools will be useful to you, and the bigger the things you can tackle will become. I'm sure this comment section won't be a disaster. Seriously though, I hope you take this as what it is, an opportunity to skill up your comms and your clarity as you describe the work that you want done rather than an attack on your capability of writing software. The future is exciting, but only if you let it be. And I'm really **[21:41]** excited about where things are going. Let me know what you all think. And until next time, peace nerds.