I Hate That This Is True - CourtneyR.dev's 2nd Brain

I Hate That This Is True ![rw-book-cover](https://img.youtube.com/vi/rTMRlqT8Q8c/maxresdefault.jpg) 🔗 **Source:** [I Hate That This Is True](https://www.youtube.com/watch?v=rTMRlqT8Q8c) > [!note]+ Document Notes > tags: [ai-impact-engineering, software-engineering-quality, developer-skill-assessment, ai-productivity-tools, technical-leadership] > author: [MISSING] > source: [MISSING] > reference: https://www.youtube.com/watch?v=rTMRlqT8Q8c > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: I hate that this is true >  ## 🧭 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) ## 📝 Summary - AI coding assistants like Claude Code paradoxically make weak engineers less harmful by raising the quality floor - The Mythical Man Month principle still applies: adding more engineers to teams often slows progress - Two types of "weak" engineers: inexperienced but motivated vs. experienced but unmotivated - AI accelerates learning for motivated engineers while enabling stagnation for lazy ones - The performance gap between good and bad engineers will widen dramatically as AI tools improve - Bottom 30% of engineers face potential displacement as AI reduces tolerance for poor performance ## 📖 Main Content The core argument centers on Sean God's article "AI makes weak engineers less harmful" and how AI coding tools fundamentally change team dynamics. The analysis reveals that software engineering ability follows a heavy-tailed distribution where exceptional engineers vastly outperform average ones, while weak engineers often create net-negative value by generating problems for colleagues. The speaker introduces a crucial distinction between two types of weak engineers using a two-dimensional framework: experience level versus capability. "Prodigy corner" engineers have high capability but low experience (like Mel, who built complex systems before knowing what endpoints were), while experienced but low-capability engineers represent the truly problematic category. AI tools like Claude Code create different outcomes for each group. For motivated, learning-oriented engineers, AI acts as an "infinite learning machine" that accelerates skill development. These engineers use AI to explore theories, ask follow-up questions, and build understanding faster than traditional mentorship allows. Conversely, unmotivated engineers use AI as a crutch that prevents learning. They become "thin wrappers around Claude Code," copying and pasting responses without developing deeper understanding. This creates a false sense of productivity while hampering long-term growth. The Mythical Man Month principle remains relevant: adding more people to projects typically slows progress due to coordination overhead. This explains why small, highly-paid teams often outperform larger teams of average engineers. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=0) Opening premise on AI impact - AI powerful for great and okay engineers, but requires knowing what to tell it - Hot take: lackluster engineers actually better off with AI despite potential for more damage - AI steers people toward better technical decisions #### ⏱️ [00:03:12](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=192) Heavy-tailed distribution of engineering ability - Strongest engineers produce way more useful output than average - Weakest engineers often net negative, creating problems for colleagues - Engineering gaps cause team friction more than individual weakness #### ⏱️ [00:06:45](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=405) Mythical Man Month relevance - Adding manpower to late software projects makes them later - New engineers often not taught this classic principle - Coordination overhead can negate benefits of additional team members #### ⏱️ [00:12:30](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=750) Two-dimensional engineer assessment - Experience vs capability creates four quadrants - "Prodigy corner": high capability, low experience (example: Mel) - Growth potential matters more than current skill level - Time investment in people varies based on retention expectations #### ⏱️ [00:15:45](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=945) Claude Code impact on quality floor - LLMs raise floor for weak engineers significantly - Instead of obviously broken PRs, now get "standard LLM pull requests" - Functional at line-by-line level even if wrong in other ways #### ⏱️ [00:18:20](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=1100) Blog post disaster story - Two weeks fighting with principal engineer over video embeds - Engineer converted MP4s to 200MB GIFs, then to broken Twitch embeds - Demonstrates how bad engineers can waste enormous time and resources #### ⏱️ [00:25:15](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=1515) Learning acceleration for motivated engineers - Mel example: built complex systems without knowing what endpoints were - AI enables asking "dumb questions" without human judgment - Motivated engineers use AI to curve upward faster #### ⏱️ [00:28:40](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=1720) Stagnation risk for unmotivated engineers - Some engineers flatline when AI makes learning optional - Relying on AI without understanding creates long-term career risk - Company pays human salary for copilot subscription value #### ⏱️ [00:31:50](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=1910) Anti-React dev archetype - Engineers with strong wrong opinions resist AI guidance - Enforce bad beliefs into agents, limiting productivity - Alex Russell example: brilliant performance analysis, problematic React takes #### ⏱️ [00:35:20](https://www.youtube.com/watch?v=rTMRlqT8Q8c&t=2120) Future predictions - Bottom 30% of engineers face rough times ahead - Gap between good and bad engineers will widen dramatically - Continuous learning becomes essential for career survival ## 📚 References - [Sean God's article on AI and weak engineers](referenced but URL not provided) - [The Mythical Man Month by Fred Brooks](classic software project management book) - [Alex Russell's performance inequality research](web performance analysis) - [WorkOS OMD protocol](agent-ready authentication) ## 🗣️ Paraphrase AI coding assistants create a paradoxical situation where the weakest engineers become less harmful to their teams. While these tools enable weak engineers to produce more code and potentially cause more damage, they also guide them toward better technical decisions and prevent the most egregious errors. The key insight is that "weakness" in engineering has multiple dimensions. Inexperienced but motivated engineers benefit enormously from AI tools, which act as patient tutors for accelerated learning. However, experienced but unmotivated engineers use AI as a crutch that prevents growth and creates false productivity. This dynamic will likely lead to a widening skill gap in the industry. Engineers who embrace AI for learning and growth will advance rapidly, while those who use it to avoid learning will find themselves increasingly obsolete. The bottom tier of the engineering workforce faces displacement as AI reduces organizational tolerance for poor performance. ## 📰 Newsletter **AI's Surprising Impact on Engineering Teams** Here's a counterintuitive take that's gaining traction: AI coding tools might actually make your worst engineers less harmful. While we've been worried about AI enabling sloppy code, it turns out LLMs like Claude Code raise the quality floor significantly. The real division isn't between AI users and non-users, but between engineers who use AI to learn faster versus those who use it to avoid learning altogether. Motivated developers are leveraging these tools as "infinite learning machines" to accelerate their growth, while others become thin wrappers around AI responses. For WordPress developers, this has immediate implications. AI tools can help newer contributors understand complex codebases faster and ask "dumb questions" without judgment. But teams need to distinguish between engineers using AI for growth versus those using it as a crutch. **Resources:** - [Claude Code](https://claude.ai) for AI-assisted development - [The Mythical Man Month](https://en.wikipedia.org/wiki/The_Mythical_Man-Month) for team scaling principles - Consider how AI integration affects your development workflow and team dynamics ## ✅ Action Items #### DevRel - Create guidelines for AI tool usage in developer education materials - Develop workshops on effective AI prompting for code learning - Design mentorship programs that combine AI assistance with human guidance - Track which AI-assisted learning paths produce strongest developers #### Community - Establish best practices for AI usage in open source contributions - Create "AI-assisted learning" tracks for contributor onboarding - Develop rubrics for evaluating AI-generated code contributions - Build support systems for engineers transitioning to AI-enhanced workflows #### WordPress - **Core:** Evaluate impact of AI-generated contributions on code quality standards - **Training:** Integrate AI-assisted learning modules into developer curriculum - **Community:** Host discussions on AI ethics and best practices in WordPress development - **Documentation:** Update coding standards to address AI-generated code review processes ## 🧪 Hypotheses - Engineers using AI primarily for learning will show faster skill advancement than traditional learning paths - Teams with clear AI usage guidelines will have better outcomes than those without policies - The performance gap between motivated and unmotivated engineers will double within 18 months - Organizations will shift hiring criteria to emphasize learning ability over current skill level - Junior engineers with AI access will outperform mid-level engineers without AI within 2 years ### 📊 Methodology - Longitudinal study tracking engineer skill development with and without AI tools - Comparative analysis of code quality metrics before and after AI adoption - Survey of engineering managers on team productivity changes - Analysis of GitHub contribution patterns for AI-assisted vs traditional development - Performance benchmarking across different engineer experience levels ### ❓ Questions - How can organizations identify engineers using AI as a learning accelerator versus a crutch? - What metrics best predict which engineers will thrive in AI-assisted development? - How should code review processes adapt to evaluate AI-generated contributions? - What role should AI literacy play in engineering hiring decisions? - How can teams prevent AI from becoming a barrier to fundamental learning? ### 🔮 Future Research - Long-term career trajectories of AI-native developers - Impact of AI tools on engineering education curricula - Organizational structures that optimize human-AI collaboration - Cultural factors affecting AI adoption in development teams - Evolution of engineering skill requirements in AI-augmented environments ### 💡 Implications **Practice:** Teams need frameworks for distinguishing productive AI usage from dependency. Code review processes must evolve to evaluate AI-generated contributions effectively. **Education:** Engineering education should emphasize AI collaboration skills alongside fundamental programming concepts. "Learning how to learn with AI" becomes a core competency. **Hiring:** Organizations may shift focus from current technical skills to learning velocity and AI collaboration ability. Interview processes need updating for AI-augmented development reality. **Career Development:** Engineers must actively choose growth-oriented AI usage patterns to remain competitive. Continuous learning becomes even more critical for career longevity. ### 🧠 Learning Styles Assessment **Reading level estimate:** Flesch-Kincaid Grade Level 12-14 (college level) #### 👀 Visual learners - **Present:** Two-dimensional skill framework diagram, trend line visualizations - **Improve:** Add flowcharts for AI usage decision trees, before/after code quality charts, team structure diagrams #### 🔊 Aural learners - **Present:** Video format with clear narration and examples - **Improve:** Podcast version, audio summaries of key points, discussion guides for team meetings #### 🗣️ Verbal learners - **Present:** Clear analogies (AI as "infinite learning machine"), defined technical terms - **Improve:** Glossary of AI development terms, story-driven case studies, plain-language summaries #### 🧩 Kinesthetic learners - **Present:** Practical examples with specific tools and workflows - **Improve:** Hands-on exercises for AI prompting, step-by-step implementation guides, interactive coding challenges #### 🧠 Logical learners - **Present:** Clear cause-effect relationships, structured argument progression - **Improve:** Decision matrices for AI tool selection, quantitative skill progression models, logical frameworks for evaluation #### 🧑‍🤝‍🧑 Social learners - **Present:** Team dynamics discussion, collaborative problem-solving examples - **Improve:** Group discussion prompts, peer review frameworks, team assessment tools #### 🧘‍♀️ Solitary learners - **Present:** Self-reflection prompts about current AI usage patterns - **Improve:** Personal skill assessment worksheets, individual learning plans, private journaling questions ### 📊 Accessibility Assessment #### Screen reader semantics - **Present:** Clear heading structure, descriptive content - **Improve:** Alt text for diagrams, ARIA labels for interactive elements, semantic markup for code examples #### Keyboard navigation - **Present:** Standard video controls - **Improve:** Transcript with timestamp navigation, keyboard shortcuts for video sections #### Contrast and readability - **Present:** High contrast in video presentation - **Improve:** Ensure subtitle contrast meets WCAG standards, provide text alternatives for visual elements #### Text resizing and reflow - **Present:** Responsive design considerations - **Improve:** Ensure content reflows properly at 200% zoom, test with various screen sizes #### Media and captions - **Present:** Full transcript provided - **Improve:** Add time-synced captions, provide downloadable transcript, include speaker identification ### 🌍 DEIB Assessment #### Cultural breadth - **Present:** Focus on tech industry experiences - **Improve:** Include diverse geographic perspectives on AI adoption, consider cultural differences in learning styles #### Inclusive language - **Present:** Generally neutral technical language - **Improve:** Avoid assumptions about educational background, provide context for industry-specific terms #### Neurodiversity support - **Present:** Clear structure with timestamps and headings - **Improve:** Add content warnings for stress-inducing examples, provide multiple format options #### Representation - **Present:** Mix of individual examples and general principles - **Improve:** Include diverse voices and experiences, acknowledge different paths into tech #### Psychological safety - **Present:** Acknowledges learning struggles without judgment - **Improve:** Emphasize growth mindset, provide resources for engineers feeling overwhelmed by AI changes ### ✅ Logical Validity #### Strong reasoning - **Mythical Man Month application:** Correctly applies classic principle to modern AI context, explains why team size affects productivity - **Two-dimensional framework:** Logical separation of experience and capability as independent variables - **Causal analysis:** Clear connection between AI usage patterns and long-term career outcomes #### Fallacies - **Hasty generalization:** Extrapolating from limited personal examples to broad industry predictions. Fix: Include more diverse data sources and acknowledge limitations - **False dichotomy:** Presenting only two types of weak engineers. Fix: Acknowledge spectrum of engineer types and motivations - **Anecdotal evidence:** Heavy reliance on personal stories. Fix: Supplement with industry research and broader data #### Tone of voice - **Conversational and direct:** Uses casual language ("I hate that this is true") while maintaining technical credibility - **Opinionated but analytical:** Strong personal views supported by logical frameworks and examples ### 🛡️ DARVO Analysis No evidence of DARVO tactics detected. The content focuses on industry analysis rather than defensive positioning. The speaker acknowledges their own limitations and biases while presenting arguments. ## 🎯 Conclusion AI coding assistants are fundamentally reshaping engineering team dynamics, but not in the ways most people expect. Rather than simply making everyone more productive, they're creating a divergence between engineers who use AI to accelerate learning and those who use it to avoid learning. The practical implication for engineering leaders is clear: focus on identifying and nurturing engineers who demonstrate curiosity and growth mindset, regardless of current skill level. The "prodigy corner" engineers who ask smart questions about things they don't yet know will likely outperform experienced engineers who rely on AI to avoid learning new concepts. For individual engineers, the message is equally clear: embrace AI as a learning accelerator, not a replacement for understanding. The engineers who survive and thrive in the coming years will be those who maintain their curiosity and use AI tools to explore, experiment, and grow rather than simply to complete tasks. --- ## Full Transcript [00:00] I think we've established that AI is [00:01] really powerful for great and even okay [00:03] engineers like myself. It's really good [00:06] at doing what you tell it to, but you [00:08] have to tell it the right thing. What [00:09] about the rest of the engineers, though? [00:11] The lackluster ones that are shipping [00:13] React into things that it shouldn't be [00:15] in, or are desperate to squeeze [00:16] JavaScript into stuff that makes no [00:18] sense, or just writing terrible Python [00:20] code that powers things it absolutely [00:22] shouldn't, causing outages at companies [00:23] that just make you want to die. Here's [00:25] where my hot take comes in. I think [00:27] those engineers are actually better off [00:29] as a result of AI. On one hand, they're [00:32] able to do way more and as a result of [00:35] that, they can cause more damage [00:36] theoretically speaking, but I find that [00:39] AI tends to steer people in a better [00:41] direction. I think this is awesome and [00:42] that we don't appreciate it enough. And [00:45] I want to go into what I mean by this [00:47] and why I think it's a good trend and [00:49] how exciting this could potentially be [00:51] for the future of software. I think [00:53] we're all too focused on the slop side [00:55] and not about the floor being raised. [00:57] And I want to dig into that a bit with [00:58] y'all. One of the many things benefiting [01:01] here is that AI tends to make better [01:03] decisions about what to bring into your [01:05] projects than bad developers would by [01:07] themselves. They might stick some [01:08] mediocre technologies where they don't [01:10] belong. Things like Flutter or [01:11] JavaScript in places that they [01:12] absolutely shouldn't be. Now, thanks to [01:14] AI, they're making better technical [01:16] decisions. Even I'm starting to use [01:18] stuff like Rust more. It's important to [01:20] build on top of good things like today's [01:21] sponsor. I have a question for you. Is [01:23] your app agent ready? I don't just mean, [01:25] does it have an LLM's text or some [01:27] crappy markdown file that describes how [01:29] to use it? What I mean is, can it be [01:31] signed up for with an agent? If I'm [01:32] trying to use your service or something [01:34] like it, and I ask my Codeex instance to [01:36] go sign up for me, can it do it? And if [01:39] it can, does it have to use a bunch of [01:40] weird browser stuff? If so, you're [01:42] clearly not using today's sponsor, Work [01:44] OS. They already have Oth for enterprise [01:46] figured out. But as enterprises are [01:47] moving more and more towards agents, [01:48] they realize there needs to be a better [01:50] way to do that, which is why they [01:51] introduced OMD. The point of OMD is to [01:54] make it easy to set up Oth on services [01:56] for agents. So if you're building an app [01:58] that agents should be able to register [01:59] your users with, OMD makes it trivial to [02:01] do. It's already been adopted by [02:03] Cloudflare, Firecrawl, Resend, Monday, [02:05] and more. And it makes sense why. It's [02:07] an open protocol that allows for your [02:09] agents to register for web services. [02:11] Forms are just not the right solution [02:13] for agents. I was experiencing this [02:14] earlier today when I was trying to fix [02:16] things in a Google dashboard and I tried [02:17] having codeex use the website and it [02:20] couldn't even find the field to put the [02:21] email address because they used the [02:23] wrong treatment and it was a little too [02:25] faded out for the agent to notice and I [02:27] had to stop it, hop in and type it [02:29] myself. That's just one of the hundreds [02:30] of issues you can encounter from captas [02:32] to dashboards to ooth consent screens [02:35] and none of that makes sense for agents. [02:36] A lot of these flows worked great when [02:38] humans were the ones navigating the web, [02:40] but reality is different. And if you [02:42] don't have an agentready system, you're [02:44] falling behind. And I'm going to be [02:45] real. If any other company made this, [02:46] I'd be really skeptical. But it wasn't [02:48] any company. It was work OS. The guys [02:50] behind O for OpenAI, Anthropic, Cursor, [02:53] Perplexity, Versell, and you could read [02:54] the screen. You know, everyone uses Work [02:56] OS, even T3 chat. Build O that's [02:58] reliable for you and your agents at [02:59] soyb.link/works. [03:01] Sorry about the fake start there. You [03:03] got to do your job, you know. sneak in a [03:06] Flutter junk, drop an ad quick, and then [03:08] dig into an article that I'm sure won't [03:09] piss anyone off. Should be a fun one. [03:11] Sean God wrote this article, and as soon [03:13] as I saw it, I knew it would have to be [03:14] a video. AI makes weak engineers less [03:17] harmful. I have personally seen this, [03:20] and I am sure I'll have a lot of [03:21] thoughts. Like other kinds of puzzle [03:23] solving, software engineering ability is [03:25] strongly heavy- tailed. The strongest [03:28] engineers produce way more useful output [03:30] than the average, and the weakest [03:31] engineers often are actively net [03:33] negative. Instead of moving projects [03:35] along, they create problems that their [03:37] colleagues have to spend time solving. [03:39] I'll drop an even hotter take here. This [03:42] isn't so much that like weak engineers [03:44] cause problems as engineering gaps cause [03:48] problems. If you have an exceptional [03:50] engineer, like a top 1enter, and then a [03:53] pretty good engineer, that exceptional [03:55] engineer is going to get really [03:56] frustrated that the pretty good engineer [03:58] is like changing things they might not [03:59] want to or getting in their way. You can [04:01] ask any of the engineers on my team. I [04:03] do this to them all of the time. I'm [04:05] good at moving fast. I'm good at [04:06] understanding systems. My actual code [04:09] can vary in quality depending on how [04:10] much effort I'm putting in. And I can [04:12] absolutely be a detriment to my team. To [04:14] the point where a lot of our culture now [04:16] is that I show what I'm thinking of via [04:18] a poll request with no intention of it [04:20] ever being merged and then the team [04:22] looks at it, tries what I had in mind, [04:24] and then goes and builds it correctly. [04:26] Figuring out how to keep engineering [04:28] quality gaps from getting your best [04:30] engineers pissed is essential. This is [04:32] really big for retention in particular. [04:34] Great engineers hate working around [04:36] engineers that are meaningfully worse. [04:38] So, you got to figure out how to balance [04:41] things so those engineers don't get in [04:42] their way or just don't last very long. [04:44] But because these weak engineers get in [04:46] the way, many tech companies will try [04:48] and build small, ludicrously well-paid [04:50] teams instead of large teams of more [04:52] average engineers. And why so far this [04:54] seems to be a winning strategy. Yeah, [04:56] absolutely agree. This definitely is the [04:57] winning strat. The bigger the team, the [05:00] higher the chance people get in each [05:01] other's way. I recently learned that new [05:03] engineers aren't being taught about the [05:04] mythical man month anymore. And that [05:06] makes me sad because I remember learning [05:08] about this in college and how hard it [05:10] clicked for me. Actually, I think this [05:11] came up in my like high school CS [05:12] classes where I was just like doing very [05:14] basic like Java programming and VB stuff [05:17] when I was young. Yes, they were still [05:19] teaching Visual Basic when I was a kid [05:20] cuz I am that old. The Mythical Man [05:22] month by Fred Brooks is a classic book [05:23] on software project management famous [05:25] for the central argument that adding [05:26] manpower to a late software project [05:28] makes it later. This is very unintuitive [05:31] for people. Adding more people to a [05:33] project does not make it faster. I know [05:36] people aren't being taught this because [05:38] I have to experience it every day. When [05:40] I explain that like the T3 chat mobile [05:42] app is delayed and will hopefully come [05:44] out soon, that all of these features [05:46] people want in T3 code are delayed and [05:48] Julius is working on one thing at a [05:50] time. The immediate response is, oh, why [05:52] not bring on more people? You have this [05:54] awesome community of people who will be [05:55] more than happy to contribute. In some [05:57] ways, yes. But at the same time, the [06:00] work to orchestrate all of them, to [06:02] onboard all of them does as much to slow [06:04] down as it does to speed up. At best, [06:06] they counteract. At worst, they slow you [06:09] down. And I cannot tell you how many [06:10] times I've experienced this personally [06:12] with my own company and with other [06:14] businesses I've worked at where [06:16] expanding the team makes things slower. [06:18] This is part of why I was useful at [06:20] companies like Twitch. Not because I [06:22] could debug us out of really hard [06:24] situations, but if a road map was not [06:26] going to be hit and a deadline was going [06:28] to be missed, I could come in and trim [06:30] correctly to get us where we need to be [06:33] faster. I was almost like the [06:35] counterpoint to this problem where I'm [06:38] the one person you can add that will [06:39] speed things up. They might end up [06:41] slightly buggier. They might end up with [06:42] less features, but they'll get [ __ ] [06:44] done and they'll get done in time [06:45] without too big of compromises. But this [06:47] is a very rare thing and most engineers [06:49] when added to a team will slow it down [06:51] even if that engineer is exceptional. [06:53] The additional overhead of managing a [06:55] bigger team and getting them onboarded [06:57] will slow down the people who are [06:58] working enough that things get slowed [07:00] down overall. Very important concept. [07:02] There's a reason there's a book about it [07:03] that has been cited for the last 40 [07:05] years. It's because it's a real thing. [07:07] Back to the article. Being effective in [07:08] a large tech company is often about [07:10] managing this phenomenon. trying to [07:12] arrange things so the most competent [07:14] people land on projects that you want to [07:15] have succeed and the least competent [07:17] ones are shunted out of the way. For [07:19] instance, if you're a technical lead on [07:21] a project, you more or less have to [07:22] ensure that the most critical pieces are [07:24] in the hands of people who won't screw [07:26] them up. Whether by directly assigning [07:28] the work or by making sure someone else [07:29] can sit on the shoulder of the engineer [07:31] that you're worried about. This is not [07:33] like a single spectrum. You can't draw a [07:35] left to right where on one side [07:36] engineers are bad and the other they're [07:38] incredible. There is multiple dimensions [07:40] to this spectrum here. One of them is [07:43] your experience. How long have you been [07:45] here for? I would take a four out of 10 [07:47] engineer that's been coding for a year [07:50] over a seven out of 10 engineer that's [07:51] been coding for 20 years because that [07:53] four out of 10 has so much growth [07:55] potential and a little bit of time put [07:57] into them might slow us down right now, [07:59] but that could be paid off later [08:01] massively if I can level them up to get [08:03] to that like 8, nine, even 10 range. The [08:05] time you invest in a person to get them [08:08] sped up is an important factor to [08:10] consider as well. And I find that most [08:12] of the people who aren't considerate of [08:13] this either just aren't leaders, they're [08:15] more IC's, they're focused on their [08:16] deliverables and their tickets, or to be [08:18] a little crude, they work at a company [08:20] with really shitty retention and they're [08:22] not used to investing in people because [08:23] if somebody gets good, they just leave [08:24] and get paid better somewhere else. So [08:27] things to consider here. All of that [08:29] said, Claude Code changed this. Frontier [08:32] LLMs don't have the taste or the system [08:34] familiarity of a strong engineer, but [08:36] they've absolutely raised the floor for [08:38] weak engineers. Yep, now we're cooking. [08:41] Instead of getting a poll request that [08:43] could never possibly work or would cause [08:45] immediate problems, the worst you'll now [08:47] see is a standard LLM pull request. [08:49] Wrong in some ways, baffling in others, [08:51] but at least functional on the line by [08:53] line level and not so obviously [08:55] incorrect that someone with no knowledge [08:56] of the codebase could point it out. [08:58] That's a huge improvement. Absolutely. [09:00] Yes. I have seen some of the stupidest [09:02] PRs imaginable. Both when I worked at a [09:05] company where there was a lot of [09:06] different technologies being on the only [09:08] elixir codebase at the company when [09:10] everybody else is doing JavaScript, Ruby [09:12] and Go resulted in getting some PRs that [09:15] were uh questionable that just [09:18] fundamentally didn't understand anything [09:19] about what was going on. That's kind of [09:22] over now. The types of people who would [09:25] throw those shitty PRs around are the [09:27] types of people who lean heavily on [09:29] tools like Claude Code. And as such, [09:31] those people have meaningfully improved [09:33] the quality of what they're shipping. [09:35] You can try this out yourself. Attempt [09:36] to deliberately make mistakes while [09:38] working with a coding agent. You'll find [09:39] that the agent pushes back hard against [09:41] many obvious errors like caching user [09:44] data without a user specific key, [09:46] writing infinite loops that might never [09:47] terminate, or leaking open files. Of [09:50] course, the agent will still miss subtle [09:52] errors, particularly ones that require [09:54] understanding of other parts of the [09:55] codebase. Yep, working with the least [09:58] effective engineers is now sometimes [10:00] like working with a claude opus or [10:01] codeex instance directly that you're [10:03] communicating with over Slack. I've said [10:05] this for a bit, but like part of why I'm [10:07] good at working with agents is because I [10:09] had to work with engineers and run teams [10:11] for the better part of 10 years now. And [10:14] the quality of engineers varies wildly. [10:17] And how much effort you have to put into [10:18] prompting them, so to speak, varies [10:20] wildly, too. Some engineers can take a [10:22] vague ticket and build something [10:24] incredible. Some engineers can have 30 [10:26] perfectly detailed tickets for really [10:28] simple things and still [ __ ] it up [10:30] before they even get to the PR. [10:31] Occasionally, it's literally that. Your [10:34] colleague is just taking your message, [10:35] pasting it into clawed code, and then [10:37] pasting back the response. It's [10:39] annoying, but it's still a much better [10:40] experience than working with that kind [10:41] of engineer directly. Yep. [10:45] Let me give an example. This is going to [10:47] be a funny one. The team I worked with [10:49] on ModView was genuinely some of the [10:51] best people I've ever worked with in my [10:52] life. If I had any need for engineers, I [10:55] would hire any of them in a heartbeat. [10:57] They're awesome. I loved working with [10:58] them. The fact that we got this project [11:00] built as fast as we did with crazy [11:02] deadlines is something I'm still proud [11:03] of, and I'm more proud of the team than [11:05] anything. They really stepped up and [11:06] made [ __ ] happen. There were multiple [11:08] times where like fundamental theories I [11:10] had proposed on how to build this [11:11] weren't panning out and I was ready to [11:13] just give up and throw it all away and [11:15] one of them would step up and be like, [11:16] "No, I think that there's an angle here [11:18] that will work and then just show up the [11:20] next day with the thing I was convinced [11:21] was entirely broken working." Incredible [11:23] experience, incredible engineers. I [11:25] would endorse the [ __ ] out of any of [11:26] them anytime. I even gave up a promotion [11:28] in order to get one of them promoted [11:29] more aggressively because we only had so [11:31] much room for that. It is what it is. [11:32] Loved working on ModView. Really proud [11:34] of the product. It's still in my opinion [11:36] the most polished and reliable product [11:38] which has shipped in a very long time. [11:40] So why am I talking about this in a [11:42] video about bad engineers? Because I'm [11:44] not showing you Mod View. I'm showing [11:45] you the blog post where Mod View was [11:48] announced. This blog post cost me more [11:50] sanity than anything I've ever built in [11:53] my life. Because this blog was [11:55] maintained by one engineer whose [11:57] full-time job was posting things on the [12:00] blog. See this broken purple thing here? [12:05] That's supposed to be a demo. This is [12:08] supposed to be a video that my designer [12:11] meticulously crafted and made. She like [12:13] learned After Effects to make the best [12:16] possible video to demonstrate the [12:18] product and it's now a purple screen. [12:20] And not only that, she made a bunch of [12:22] these and they're all now just purple [12:24] screens. [12:26] So what happened? [12:28] I lost a month of time and quite [12:31] possibly a promotion for how hard I [12:33] crashed out over this. [12:35] We wrote this blog post in Google Docs. [12:38] We embedded links to the files for each [12:41] of these videos that were simple MP4 [12:43] files that we had on Google Drive and we [12:45] sent that to the engineer who runs the [12:48] blog because we there was no CRM. There [12:50] was no way for us to write it. We just [12:51] sent them the content in hopes that they [12:54] would make the post and they did. but he [12:57] wanted to have the videos embedded and [13:00] he didn't know how to do that. So he [13:02] converted all of these 4K resolution 20 [13:06] plus second long MP4 files into 80 to [13:10] 200 megabyte GIFs and embedded those 200 [13:13] megabyte GIFs directly in the blog post. [13:16] The page took almost a gig to load. My [13:18] chat is reacting correctly to this [13:20] information. I said, "What the actual [13:23] hell are you doing? We gave you video [13:25] files. please embed the video files. [13:31] So he responded by uploading all of the [13:33] videos to Twitch's at the time still [13:35] almost functioning but not quite VOD [13:38] platform where you could upload a video [13:40] and then use their not really [13:41] functioning iframe embeds to embed the [13:43] videos. So each of these simple [13:46] autoplaying demos of the product became [13:49] a really shitty Twitch player that you [13:51] had to hit play on, wait a few seconds, [13:53] and then it would start to play part of [13:55] that 20 second video that was supposed [13:57] to be a loop. I said, "What the actual [13:59] [ __ ] again?" So I went and converted all [14:02] of these properly myself to webm files [14:05] that I knew would be embeddible in the [14:06] browser. I sent those to him. He said, [14:09] "I don't see how this will be different, [14:10] but sure." Then he uploaded the web m to [14:13] Twitch the same way and switched over [14:14] the URLs. I said, "What the [ __ ] Do you [14:17] just not understand anything that's [14:19] going on here?" And then wrote the HTML [14:22] he's supposed to be putting in and [14:24] tested it myself by inspecting element, [14:26] but he didn't know where the video files [14:28] would be. So I spun up an S3 bucket [14:30] public. Had to get security permission [14:33] to do it to host these files myself so I [14:36] could give him the HTML to put in the [14:38] page to finally have these simple web ms [14:41] that I did all of the work for embedded [14:43] so they would play automatically [14:44] correctly. And then he used a shitty CRM [14:46] to paste them in. And the result, I [ __ ] [14:50] you not, was the plain text of the video [14:52] element I sent him. This was two weeks [14:55] of back and forth. Ultimately, I gave up [14:58] and told them to go back to the version [15:00] that had the video embeds from Twitch [15:02] that is now broken and in this state. I [15:05] need you all to be so real with me. [15:07] First off, is it acceptable that I [15:09] crashed out so hard I almost got fired [15:11] over this because I think it's totally [15:13] acceptable. I stayed a year and a half, [15:15] but I crashed out [ __ ] hard over this [15:17] one. Valid crash. Cool. Thank you guys. [15:21] I got in trouble for this one. This came [15:23] up during one of my promotion [15:24] discussions. Like it it is legitimately [15:27] possible I have lost tens of thousands [15:29] of dollars because of this crash out [15:31] because I didn't get a promotion because [15:32] of it. This is also one of the many [15:34] things that motivated me to say [ __ ] [15:35] this and quit and do my own thing. So it [15:37] worked out in the end. Why did I go to [15:38] my superiors? You think I didn't go to [15:39] my [ __ ] superiors? His title on [15:42] LinkedIn is principal engineer. [15:46] Insane. He's on a team alone. I think [15:49] the reason this could happen is because [15:50] he was so isolated nobody else noticed [15:52] how shitty he was. But now I have [15:54] question two. I need y'all to be real. [15:56] Do you think Claude Code would have been [15:58] better or worse than that engineer? [16:04] Thank you chat. I rest my case. Does he [16:07] for a chance work at Anthropic? Now [16:12] thank you. Back to the article. The [16:15] Slack interface is not ideal. Unlike [16:17] using cloud code directly, you sometimes [16:18] have to wait hours or even days for a [16:20] response. How about two weeks? And you [16:22] don't get visibility into the agents [16:24] thought process, but it's still helpful [16:26] on the margin. More compute being thrown [16:28] at your problem is better than less. Of [16:30] course, this isn't a great state of [16:31] affairs for the engineers in question, [16:33] who is almost certainly learning less [16:34] than if they were making their own bad [16:36] decisions. It's also a bad state of [16:37] affairs for the company, who is paying a [16:39] human salary and getting a co-pilot sub, [16:41] which they're also likely paying for. [16:43] After the current push to figure out [16:45] what value AI is adding to engineers, I [16:47] suspect there will be a push to figure [16:48] out what value engineers are adding to [16:50] AI and the engineers who aren't adding [16:52] much may find themselves out of a job. [16:54] Absolutely. As I said before, there's [16:56] many dimensions to this problem, but I'm [16:58] going to try and just do two axes. We [17:00] have the dumb and god axis where one [17:04] side the engineers embed webm via plain [17:07] text and on the other side they invent [17:09] the webm. But then we're going to have [17:12] the experience axis. Generally speaking, [17:16] there will be a trend here where the [17:18] newer you are, the dumber you are. And [17:20] the more experienced you are, the better [17:22] you are. This is absolutely the trend [17:25] that we would expect and hope for. But [17:28] there will always be outliers. You'll [17:30] have people like Nexel or Julius who [17:33] somehow are brand new, but also really [17:36] experienced. The quadrants are going to [17:38] be weird for this because of the nature [17:39] of it, but you get the idea. People who [17:42] are like Julius that had very little [17:44] real world experience but just [17:46] understood [ __ ] great are going to end [17:48] up there. But then there's people like [17:49] the guy I was working with who was like [17:51] 8 plus years in and just did not know [17:53] what he was doing at all. And the way [17:55] these people should be treated should be [17:58] meaningfully different. Each of these [18:00] quadrants deserves a different attitude [18:02] and a different attention. I'm going to [18:05] call this top right quadrant the normal [18:09] goods quadrant. These are people who [18:13] worked, they know what they're doing, [18:15] they get paid accordingly. They work to [18:17] get here. They are here now. If they use [18:19] AI, right, they will be slightly more [18:21] efficient. Not much to say about the [18:22] people up here. Then we have the [18:24] quadrant down here. What do I want to [18:26] call this? I'm going to call this one [18:28] the prodigy corner. This is people who [18:30] despite their experience, things just [18:32] click faster. They might not know how to [18:34] navigate your codebase just yet, but [18:36] they know how to solve problems with [18:38] code. Well, I'm going to give a really [18:40] silly example here. One of the services [18:42] that I built, the one that got me into Y [18:44] Combinator is Ping. It's a tool for [18:46] doing live stream collaboration. So, if [18:48] you want to bring a guest onto a show [18:49] like mine, this had a lot of complex web [18:52] application development problems, a lot [18:54] of complex WebRTC problems for doing the [18:56] video pipelines. This product was not [18:58] easy to build. It was also not easy to [19:00] contribute to because of all of the [19:02] different layers that are necessary to [19:03] build a service like this that is a web [19:05] app that is a Zoom clone that has [19:07] complex requirements around the WebRTC [19:09] layer and the quality expectations that [19:11] then embeds into OBS, a product that I'm [19:13] using to film this video right now. All [19:15] of these layers are complex and the [19:17] first engineer I hired to help me with [19:19] this, her name was Mel. She had almost [19:21] no experience in traditional application [19:24] development. She came from the game dev [19:25] world and it was actually funny enough [19:27] building a game engine in Zig. When she [19:30] applied for the role, there wasn't even [19:32] a role. I was a nobody, but I posted on [19:34] Twitter that I was building this. She [19:36] found my email on GitHub and wrote me [19:38] what is still to this day the best cold [19:40] email I think I've ever gotten when I [19:41] had like 400 followers on Twitter. Not [19:44] this Mel, by the way. Not Project [19:46] Melody. Mel was an engineer who saw my [19:48] post, was really hyped, found my email [19:51] and sent me a very thoughtful, cold [19:54] email of like, "Hey, I know this is a [19:55] long shot. No idea if you're hiring. No [19:57] idea if I'm even useful to you, but I [20:00] really like what you're building. I'm a [20:01] big fan of the like anime VTuber world [20:04] stuff, which I didn't know anything [20:05] about, by the way. I just had a friend [20:07] who was that told me that this is a good [20:09] direction to go in and worked out okay." [20:11] She was more from that space and was [20:12] really excited about this. So the [20:14] combination of her getting what we're [20:16] talking about and like who our customers [20:18] were even better than I did, but also [20:20] like being motivated enough to try and [20:22] figure out the end slide was exciting to [20:23] me. And I looked at her GitHub and was [20:25] impressed with the things she had built. [20:26] None of them were relevant to what we [20:28] were doing here, but they were complex [20:29] projects, especially for somebody who [20:31] didn't have dev experience before. I [20:33] think she had a job at like Starbucks or [20:34] something if I recall. I can't remember [20:35] for sure. So I expressed some concern [20:37] just about the difference between the [20:39] things she was building and what we were [20:40] building. This is also the early days of [20:42] the T3 stack. So, I told her a bit about [20:44] my stack and how we build this and that [20:46] I would come up with a programming [20:48] problem for her to try to show her [20:50] skills in the future. Within a day, she [20:53] emailed me back saying, "Oh, this [20:54] stack's actually really cool. I just [20:56] went and rebuilt my personal portfolio [20:58] with it and started building this other [20:59] app with it and then linked me to two [21:01] GitHub profiles of the things that she [21:03] was building using this, just two new [21:05] repos that she had spun up using the T3 [21:07] stack way before anyone knew what the T3 [21:09] stack was." I was like, "Oh [ __ ] you [21:11] you get this. you're in. So I hired her, [21:13] brought her on as my first and pretty [21:15] much all the product stuff that was [21:17] clearly speced that Mark and I were too [21:20] busy to build. She would be the one to [21:22] do. She helped a lot with the admin [21:23] panel. She built all of our video and [21:25] coding stuff that was used to like store [21:27] the recordings of the calls and then [21:29] send them to S3 so you could download [21:30] them. All that type of stuff was her. [21:32] Also was the one who patched a ton of [21:34] random things to. She was super helpful. [21:35] Loved working with Mel. One of the best [21:37] engineers I've ever gotten to watch grow [21:39] like that. About a year in after she [21:41] built all of this useful [ __ ] we [21:43] started working on the recording storage [21:45] system and I had to sit down with her [21:47] and Mark and one other ends at the time [21:50] and spec out what this would look like. [21:52] We pulled up Excaladraw. We drew out [21:54] what all these pieces would be, how [21:57] everything would work, how it would come [21:58] together. This was Mel's problem, but we [22:01] all specked it together. She was still [22:03] junior. At the end, I was like, "Any [22:05] questions?" This is also around the time [22:07] that I had implemented my stupid [22:08] questions rule where I required all new [22:10] hires to ask at least one dumb question [22:13] a day just to get them over the friction [22:15] of being scared to ask things and look [22:17] dumb. Mel internalized this so [22:19] incredibly well that she asked a [22:21] question that I'm still thinking about [22:23] now 5 years later. This makes sense and [22:25] I think I can do it. [22:29] One of the best engineers I've ever [22:30] worked with didn't know what an endpoint [22:32] was because it hadn't been relevant to [22:34] her yet. It wasn't relevant when she was [22:36] building a game engine. It wasn't [22:38] relevant in the T3 stack because we used [22:40] TRPC for everything. So, it was all just [22:42] calling functions. She just hadn't [22:44] needed to know what an endpoint was yet. [22:47] Incredible. But this is why I wanted to [22:49] highlight things here because if you [22:51] take a if I told you, I have this [22:54] engineer with a year of experience and [22:56] they just ask you what an endpoint is. [22:58] Should I fire them? Most people would [23:00] respond. But if I then framed it as this [23:02] engineer who came from an entirely [23:04] different field who's only been working [23:06] on tech for a year, built all this [23:08] awesome [ __ ] without even knowing what [23:10] an endpoint was yet. There's a huge [23:12] difference. Somebody in this top left [23:15] quadrant could ask what's an endpoint [23:16] and they should be fired. And somebody [23:18] in this bottom right quadrant could ask [23:19] the same question and it means something [23:21] entirely differently. It's impressive [23:23] that they got this far without knowing [23:24] those things. And also that she had the [23:26] balls to ask. The point I'm trying to [23:28] make is that someone like Mel is [23:31] disproportionately [23:33] positively impacted by these things. The [23:35] hottake I drew this for is to say people [23:38] in this bottom section benefit massively [23:40] from AI, but people on the left section [23:44] look less dumb because of AI. So left of [23:46] this line, dumb people look less dumb. [23:49] Below this line, less experienced people [23:52] can build experience faster. Imagine [23:54] somebody like Mel that was less bold, [23:57] more nervous. She was already pretty [23:58] nervous, but was comfortable working [23:59] with us in a way where she could ask [24:01] these questions. Imagine someone like [24:02] her that was too nervous to ask the [24:05] question. Maybe they don't have that [24:06] first job yet. Maybe they don't have the [24:08] community around them to ask these [24:10] questions and build this understanding [24:11] with. Who the [ __ ] do they ask? And how [24:13] useful is that answer? Imagine someone [24:16] like Mel that's a little more nervous [24:18] screenshots that diagram that she sees [24:19] in a video of mine or in a meeting she [24:21] watched or was in and then ask Claude [24:24] code about that. Then she can ask [24:26] follow-up questions and then better [24:28] herself and learn faster. She was so [24:30] motivated to learn all of these things [24:33] and be able to build solutions to the [24:35] problems her and her friends had. This [24:37] was a time before AI she kind of had to [24:38] use me like the AI where she would ask [24:40] me the questions. And this is the [24:42] framing I want to flip here is if you're [24:44] treating the employees like the agent [24:47] and you're prompting them and they're [24:48] going off and doing the thing like cool [24:49] fine whatever. I'm used to them treating [24:52] me that way asking me the questions [24:54] figuring out this stuff for me sometimes [24:55] just to get permission. Like how many [24:57] times have we all wrote the prompt would [24:59] it be dumb too and then something that's [25:01] like kind of dumb but could work. I love [25:03] getting those questions especially when [25:05] I had newer more junior engineers that [25:07] would ask the dumb question and we would [25:09] all get to learn as a result. that type [25:11] of person can 10x themselves so [25:14] efficiently now not because the AI [25:16] prevents them from learning but because [25:18] the AI accelerates their learning and [25:20] that's the difference I want to draw [25:21] here people who are in this section that [25:25] are experienced but not very good AI [25:28] makes them look smarter because they [25:30] don't have to put as much effort in to [25:32] do things but people who are prepared to [25:34] put in the effort who are excited to [25:36] better themselves in this bottom section [25:38] here they are the ones who are going to [25:40] win the hardest [25:41] I just realized why this diagram sucks. [25:43] Let me swap things around a little bit. [25:45] There. Fixed. Now up is good, down is [25:49] bad, left is new, right is experienced. [25:52] This is the normal trend line. People [25:54] who are above the trend line are [25:56] awesome. We want more of them. Anyone in [25:58] this area, anywhere on it really is [26:00] good. People who are below this line are [26:03] not. And if you find one of those rare [26:06] engineers in this top left section here, [26:08] the ones whose experience goes far [26:10] beyond their knowledge, people like Mel [26:13] who can build incredible systems before [26:15] they know what endpoints are. People [26:16] like Yash, our intern for T3 Chat, that [26:19] figure out how to reverse engineer a [26:21] Webpack bundles and insert additional [26:23] packages into them via user scripts, [26:25] which I've still to this day never seen [26:26] anybody else do. I have looked online. [26:29] There's no resources about that. Yos [26:31] just figured that out himself. I thought [26:33] Yos was in his 30s when I hit him up to [26:34] hire him. Turns out he was in high [26:36] school. Those people are the ones that [26:39] are going to take these tools and go way [26:41] further with them. And a mistake I want [26:43] to make sure people don't make and will [26:45] do my best to jump in front of is to [26:47] make sure y'all understand newer [26:49] engineers using AI does not mean they're [26:51] going to make themselves dumber. This is [26:53] a question of their motivation and their [26:55] capability. And this is something you [26:57] can't really change in a person. They [26:58] kind of have it or they don't. Engineers [27:00] who are above this line, generally [27:02] speaking, are going to use the AI to [27:05] better themselves and grow faster. An [27:08] engineer whose trend line might have [27:10] looked like this before, where they can [27:12] get to that good end point a little [27:14] faster. It might look like this now. [27:17] They might just curve straight up and [27:19] hit this god tier before they even hit [27:21] four years into their career. And I see [27:23] this happening to people. I know people [27:25] who just realize that AI is the infinite [27:28] learning machine. they can learn and [27:29] understand anything through it and have [27:32] grown way quicker as a result. So I [27:34] switched the trend line to white to make [27:35] that easier to understand because I want [27:36] to draw the opposite which is an [27:38] engineer that relies on these tools to [27:41] never have to learn and their curve [27:43] looks like this where the AI has [27:46] prevented them from bothering to learn [27:48] because they don't want to have to do [27:50] it. I think this actually perfectly [27:52] encapsulates what I'm imagining here and [27:54] like what AI does. It takes people who [27:56] were on this line, maybe slightly below, [27:57] slightly above, and lets them curve in [28:00] each direction. And there's even some [28:02] engineers who are like this, that were [28:04] doing okay, but then AI made it too easy [28:06] to not learn and just immediately [28:08] flatlined. I want to just make sure [28:10] we're not measuring by how good somebody [28:12] is at coding, but how good they are [28:14] relative to how long they've been doing [28:15] it for. Because there could be two [28:17] engineers that are starting at the same [28:19] point in this bottom corner. Maybe they [28:20] both start from zero and they both look [28:23] like they're relying on AI and they both [28:25] can be more productive because of AI. [28:27] Some of them are improving themselves, [28:28] others are hampering their growth. So to [28:31] this specific sentence in the article [28:33] where the bad engineers, the weak [28:35] engineers are learning less than if they [28:37] made their own bad decisions. I don't [28:39] necessarily agree. I think that [28:41] engineers who aren't motivated to learn, [28:43] this will absolutely be the case. But [28:45] the fact that an engineer who wants to [28:46] learn can try out all their different [28:48] theories and learn more effectively what [28:50] does and doesn't work is awesome. Worth [28:52] noting that if the company doesn't have [28:54] a lot of those engineers is just [28:55] traditional weak engineers. This is [28:56] going to be very bad for the company [28:58] who's paying a human salary and getting [29:00] a co-pilot subscription and then they're [29:03] not doing much. You can't talk to Claude [29:05] over Slack like you talk to normal [29:06] Claude. This is actually a very good [29:08] point. Isn't one of the things I love [29:09] about LLMs? You can call them [ __ ] [29:10] stupid and it's kind of okay. Someone [29:13] made an awesome package, Dev Rage, that [29:15] you can run with NPX Dev Rage, that [29:17] measures how often you swear to [29:19] different agents. Apparently, my claudis [29:22] got wiped again somehow, cuz I had a lot [29:23] more messages in here last time I ran it [29:25] not long ago, but uh yeah, I swear in [29:28] less than 2% of Codeex chats, but I [29:30] swear in over 3% of Cloud ones. There [29:33] was also a study that shows swearing at [29:35] agents can sometimes actually make them [29:36] perform better, which I find funny, but [29:38] you get the point. It's okay to be curt [29:41] to your agents. And more importantly [29:43] here, this is my hottest take. It's more [29:45] okay to throw the code away. Something [29:47] I've experienced that sucks is when [29:49] someone puts a lot of work into a thing [29:51] and then you have to throw it away. This [29:53] actually happened one of the [29:54] implementations of the recording stuff [29:55] that Mel was working on where we decided [29:57] that that feature was no longer what we [29:59] wanted. She had put a ton of work in and [30:01] we had to throw it out because it wasn't [30:02] the direction we wanted to go in [30:03] anymore. And I felt awful. When an [30:05] earlier career dev has only built like [30:07] three things and they put the most work [30:09] into the newest one and then you say, [30:11] "Sorry, we can't use this. We aren't [30:13] going to merge that." It feels so much [30:15] worse. And I don't know if y'all have [30:16] experienced this. I have guilt merged [30:18] before. I knew it wasn't the right [30:19] thing, but I merged it anyways cuz I [30:21] felt bad about it sitting there and them [30:22] not getting the hard work put into the [30:24] product. I don't feel that with LLMs. I [30:27] don't mind telling the LM code to like [30:30] [ __ ] off. That was actually one of my [30:31] favorite things with Elements. I no [30:33] longer felt that guilt. And I've told my [30:35] whole team, by the way, my PR should [30:37] never be treated as things we have to [30:38] merge. If you're not feeling it, just [30:40] close it. I'm not offended. But unlike [30:42] talking to LLM, if you're in Slack, a [30:45] human's going to read your message, even [30:46] if you're really just interacting with [30:47] an LLM. So now all you have between you [30:50] and the Claude sub is a person whose [30:52] feelings will get hurt when you tell [30:54] them their [ __ ] sucks. Skipping them and [30:56] going straight to the agent is better. [30:57] Not all net negative engineers use AI [30:59] tools like this. Many are strongly [31:01] convinced in their own wrong opinions [31:02] about how to build good software or they [31:04] mistrust AI in general or they believe [31:06] that relying heavily on LLM is not a [31:08] good way to improve. Oof. This is very [31:11] true. I've seen this myself. There's a [31:13] specific archetype of engineer that is [31:15] very rarely good. There's like a handful [31:18] that are, but I can list them on one [31:20] hand. I'm going to call these people the [31:23] anti-react devs. I'm going to put devs [31:26] in quotes because I don't actually think [31:27] any of these people build anything. The [31:29] people who immediately will say you [31:32] react whenever they learn anything used [31:34] it. Some of them can actually be pretty [31:38] talented and knowledgeable. Alex Russell [31:40] is one of the few that I can think of [31:42] here. Alex aka slightly late has some of [31:46] the best web research and performance [31:49] analysis stuff of any developer ever. I [31:51] regularly cite his performance [31:53] inequality gap content where he measures [31:55] the performance of different phone CPUs [31:58] at different price tiers every year. [32:00] Those are my favorite charts. Fun fact, [32:03] over the last four years, the $100 [32:06] Android phone, like even though there's [32:08] a new $100 Android phone every year, the [32:10] performance has not improved at all in [32:12] that time. In the 4-year window from the [32:14] Moto E30 to the Moto E15, CPU [32:17] performance has not improved at all. the [32:20] year-over-year improvements for any [32:21] given iPhone are bigger than the total [32:23] performance for a $100 Android phone. [32:26] This isn't like, oh, they are growing, [32:27] but at different rates. No, the bottom [32:29] doesn't grow at all. And this is a thing [32:31] I didn't understand until I started [32:32] reading Alex Russell's stuff. I did a [32:35] threehour long debate with Alex Russell [32:37] that's recorded and on YouTube somewhere [32:39] because I think when he talks about [32:40] React, he goes from one of the best [32:43] developers and insightful introspective [32:45] people in the webdev world to just [32:48] genuinely kind of [ __ ] dumb. And it's [32:50] crazy to see that dichotomy in somebody [32:52] where they're both really really smart [32:54] and in the weeds and know their [ __ ] [32:56] but they have such a grudge against the [32:57] thing that they cannot have an [32:58] intelligent conversation about it. [33:00] Imagine me with Flutter, but if Flutter [33:03] was actually good. That's the difference [33:05] here. And after he got removed from the [33:07] Chrome team, they had to hire different [33:08] people to come in and clean up the mess [33:10] because he had built so much bad blood [33:12] between framework authors like the React [33:15] team and the Chrome team. This is also [33:17] the person who's responsible for web [33:18] components. By the way, the point I'm [33:20] trying to make is that this is a smart [33:22] person who has a dumb take. And as a [33:25] result, there are a lot of much dumber [33:27] people that have the same dumb take who [33:30] will cite him as proof that they are [33:32] right and everyone else is wrong and [33:34] ignore the fact that the majority of the [33:36] web is now React. Not the majority of [33:38] websites, but the majority of hours [33:40] spent on the web are spent on sites [33:42] using React. That is just a fact. It is [33:44] what it is. That's why hiring reflects [33:45] the same. As a result, usually when [33:49] somebody comes out really strongly [33:50] against React, they're kind of dumb. [33:53] Generally speaking, the person who I'm [33:55] not saying I don't think this applies to [33:56] them is Primogen. Primagen doesn't like [33:59] React, but he's not anti-react. He just [34:02] doesn't like it and thinks it's used [34:03] wrong sometimes. That's a totally [34:05] reasonable take. He's not the type of [34:07] person who's going to reply to every [34:08] post on Twitter saying, "Ew, why' you [34:10] use React?" He just used it for some [34:12] things, didn't like it in a handful of [34:14] them, and tries to not use it going [34:15] forward as a result. That makes all the [34:17] sense in the world. Totally fine with [34:18] that. But if you give somebody who has [34:20] these deep-seated beliefs that are wrong [34:22] an agent, and the agent wants to go down [34:25] that react path, they'll tell it, "No, [34:27] don't do that. React is evil and [34:29] terrible. Do this other thing." And the [34:30] agent will be like, "Yeah, sure. You're [34:31] absolutely right." And do it. So, this [34:33] will reinforce their bad beliefs and [34:34] make them feel more productive despite [34:36] having these bad takes. And that is a [34:38] very real thing. And I agree that like [34:41] that type of person isn't going to be [34:43] very productive with LLMs because [34:45] they're too busy enforcing their [34:46] [ __ ] beliefs into the agents. I do [34:49] love the call out here that no strong [34:50] engineers are using AI tools like this. [34:52] Even when they're being lazy or sloppy, [34:54] a capable engineer will have enough [34:56] baseline taste to catch obvious AI [34:58] generated errors. So the phenomenon of [35:00] engineers becoming thin wrappers around [35:02] cloud code is limited to the kind of [35:04] engineers for whom this is an [35:05] improvement in their work product. Yep. [35:08] If an engineer couldn't build because [35:09] their taste was [ __ ] they might not [35:11] notice the LM doing shitty things, but [35:13] they'll still actually build something. [35:14] That's the other thing about these [35:15] anti-react people. I've never used any [35:17] software any of them make cuz none of [35:19] them make software. They just make rants [35:20] on Twitter. The thing this post isn't [35:22] saying that I think is worth noting, [35:25] it's hinting at it here with the Claude [35:27] over Slack stuff, is that when you break [35:29] down these two types of weaker engineers [35:31] where you have the ones who are weak cuz [35:33] they're new, but they're learning and [35:35] they're growing and using these tools to [35:37] go faster, then you have the weak ones [35:38] cuz they're lazy and got into code cuz [35:40] they wanted to make money and don't care [35:41] about it at all and they're using the AI [35:43] to not learn it and just keep doing [35:46] their thing. One of those types of [35:47] engineers is going to do quite well as [35:49] the industry changes and the other is [35:52] going to get really really [ __ ] [35:54] Imagine putting a filter in front of [35:56] clawed code that just takes all of your [35:58] technical advice and makes it bad. [36:00] Imagine a sub agent that goes between [36:01] you and your prompts that just takes the [36:04] thing you're asking it to do and says, [36:05] "Can you make this slightly dumber and [36:07] use worse technologies and then passes [36:09] that to the agent to go build it?" [36:10] That's effectively what a lot of these [36:12] people are and they have no place in the [36:14] industry as it changes. there's the only [36:16] thing they can be is an owner of the [36:17] thing when it fails. They're not [36:18] actually providing value directly. And [36:20] these systems are going to cause that to [36:22] collapse where in a previous world the [36:25] gap between a good engineer and a bad [36:27] engineer wasn't that big. Like if we [36:29] were to have the bars like a bad [36:31] engineer is a three out of 10 and a [36:33] great engineer is an eight or whatever. [36:36] The thing that has changed here in the [36:38] short term is that the bad engineers can [36:41] get a little bit better and the good [36:43] engineers can get a lot better. But as [36:45] the systems get better, the models get [36:47] smarter, the tools get stronger, the [36:49] good engineers are going to get better [36:50] and better, deliver more and at higher [36:52] quality. And the ones who are lazy, not [36:54] paying attention, just phoning it in, [36:56] they're going to get worse and worse. [36:58] the gap's going to widen massively and [37:00] everyone's going to be really confused [37:01] when it happens that they thought they [37:03] could just Google search results their [37:04] whole career and now they're letting the [37:06] AI do it, never actually understanding [37:08] things. The engineers who don't know [37:10] what an endpoint is and don't care to [37:12] learn it, not the ones who don't know [37:13] what it is and are nervous to learn [37:15] about it. That's the difference. And [37:16] that gap growing is going to crush these [37:19] people. And to put this bluntly, for [37:21] those who don't get it, which are this [37:23] type of person, they don't get things [37:24] generally. Life is about to get very [37:26] rough for the bottom 30% of engineers. [37:29] It just is. Engineers were so necessary [37:31] for so long that you could get a job [37:33] even if you sucked. That is no longer [37:35] the case. So get good or get a new job [37:39] because the future is going to be very [37:40] different from how it is now. And the [37:42] changes have already started. I'm just [37:44] trying to be realistic here. I'm not [37:46] saying that if you're a new engine, [37:47] you're screwed. I'm saying if you're an [37:49] unmotivated engineer, you're screwed. [37:51] And those who tend to watch videos like [37:53] this to learn about these things in [37:54] their spare time that are however many [37:55] minutes into this video, you're already [37:57] probably better than average. You're [37:59] going to be fine. Just ask your AI more [38:02] questions about things. Try to learn. [38:04] Write a journal every day about the [38:05] thing you learned in a given day. And if [38:08] you go to bed at the end of the day, you [38:09] update your journal and have nothing to [38:11] add, fix that before you go to bed. As [38:14] long as you keep learning and growing [38:15] and challenging yourself and pushing [38:17] yourself into places you don't fully [38:18] understand yet in hopes of growing and [38:20] learning, you're going to do great. But [38:22] if your goal is to see how much you can [38:24] get away with, not how much you can [38:25] grow, it's time to leave the field. [38:29] I think I've said all I have to here. [38:31] You all have a great opportunity right [38:32] now. I hope you take advantage of it. [38:34] And while weak engineers might look a [38:36] little stronger than they did before, [38:37] they're not going to last very long. But [38:39] if you're weak cuz you're new and you're [38:41] motivated to grow, you're going to do [38:42] great. Just make sure you never give up [38:44] on the learning side, as tempting as it [38:46] may be. I got nothing else to say on [38:47] this.  📄 **Full text:** ![[Full Document Contents/Articles/I Hate That This Is True.md|I Hate That This Is True by YouTube]] ## Highlights - they've absolutely raised the floor for weak engineers. Yep, now we're cooking. ([View Highlight](https://read.readwise.io/read/01kt1hxb45nwgz1p32febb3bab)) - Note: LLMs raise the quality floor for weak engineers (core thesis). - Tags: atom/literature/h1 - engineers can get a lot better. But as the systems get better, the models get smarter, the tools get stronger, the good engineers are going to get better and better, deliver more and at higher quality. And the ones who are lazy, not paying attention, just phoning it in, they're going to get worse and worse. ([View Highlight](https://read.readwise.io/read/01kt1hxffhpf3ccgrpp8ywwbft)) - Note: AI widens the gap: strong engineers improve a lot, lazy ones get worse. - Tags: atom/literature/h2