Industry Wide AI Psychosis - CourtneyR.dev's 2nd Brain

Industry Wide AI Psychosis ![rw-book-cover](https://img.youtube.com/vi/zdXsGF1hiZk/maxresdefault.jpg) 🔗 **Source:** [Industry Wide AI Psychosis](https://www.youtube.com/watch?v=zdXsGF1hiZk) > [!note]+ Document Notes > tags: [ai-psychosis, software-engineering, technical-debt, infrastructure-automation] > author: [MISSING] > source: [MISSING] > reference: [https://www.youtube.com/watch?v=zdXsGF1hiZk] > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Industry Wide AI Psychosis >  ## 🧭 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 - Mitchell Hashimoto (HashiCorp founder) warns about "AI psychosis" in companies, where teams adopt an irrational "MTTR is all you need" mentality for software development. - The discussion draws parallels to cloud infrastructure transitions, where over-reliance on mean time to recovery (MTTR) led to systemic problems despite appearing healthy by local metrics. - Key concern: AI code generation may enable massive scale mistakes, creating 500,000 lines of problematic code instead of 30,000, making architectural decisions exponentially more costly. - The speaker (appears to be a developer/content creator) advocates for balanced AI adoption based on evolving capabilities rather than categorical acceptance or rejection. - Industry discourse often disconnects from organizational reality, with public claims about engineering obsolescence contradicting actual hiring patterns and operational needs. ## 📖 Main Content The video centers on a Twitter thread by Mitchell Hashimoto discussing what he terms "AI psychosis" - an irrational enthusiasm for AI automation in software development that mirrors problematic patterns from cloud infrastructure adoption. ### Core Infrastructure Analogy Hashimoto draws from his experience with infrastructure automation, specifically the debate between MTBF (Mean Time Between Failures) and MTTR (Mean Time To Recovery). During cloud transitions, some organizations adopted an extreme MTTR-focused approach, believing rapid automated fixes could compensate for ignoring system resilience entirely. The AI parallel: companies now believe AI agents can fix bugs so quickly and at scale that traditional quality practices become unnecessary. This "MTTR is all you need" mentality treats software development like infrastructure operations, assuming automated recovery eliminates the need for prevention. ### Test Coverage Fallacy The speaker demonstrates a critical flaw in over-relying on test coverage metrics. Using a simple JavaScript function example, they show how 100% test coverage can coexist with obvious bugs - tests only catch errors you already know to look for. The broader point: automated metrics can show local health while global comprehensibility degrades. ### Scale Amplification Problem A crucial insight emerges about AI's impact on mistake amplification. Previously, a bad architectural decision might produce 30,000 lines of problematic code over months, allowing teams to recognize and correct course. With AI acceleration, the same bad decision now produces 500,000 lines of code, making the cost of architectural errors exponentially higher. This creates a paradox: while AI makes individual coding tasks faster, it makes upfront architectural wisdom more valuable, not less. ### Mature vs. New Codebase Dynamics The discussion highlights how AI effectiveness varies dramatically between contexts. In mature, well-established codebases with years of accumulated knowledge, AI can effectively automate routine maintenance and bug fixes. However, this success doesn't translate to greenfield projects where foundational architectural decisions lack historical context for AI to reference. ### Public Discourse vs. Organizational Reality Multiple voices note disconnection between public AI discourse and actual organizational practices. Claims about engineering obsolescence don't match hiring patterns (customer service jobs have actually increased), and many strong technical leaders privately maintain more nuanced, cautious approaches to AI adoption. ## 🗒️ Notes #### ⏱️ [00:01:30](https://www.youtube.com/watch?v=zdXsGF1hiZk?t=90) Mitchell Hashimoto's AI Psychosis Tweet - References companies operating under "almost absolute MTTR is all you need mentality" - Parallel to infrastructure cloud automation lessons learned - Personal difficulty discussing this with friends due to immediate dismissals #### ⏱️ [00:05:15](https://www.youtube.com/watch?v=zdXsGF1hiZk?t=315) Test Coverage Demonstration - Live coding example showing 100% test coverage with obvious bugs - "Tests catch bugs that you already know about and exist" - Critique of "full test coverage" as magical protection #### ⏱️ [00:08:45](https://www.youtube.com/watch?v=zdXsGF1hiZk?t=525) George Hotz/TinyGrad Reference - TinyGrad team's AI criticism despite deep AI expertise - Example of technically sophisticated actors maintaining skeptical positions - Contrast between public AI enthusiasm and expert caution #### ⏱️ [00:12:20](https://www.youtube.com/watch?v=zdXsGF1hiZk?t=740) Scale Amplification Problem - Bad decisions now produce 500,000 lines instead of 30,000 - "Coding is roughly 20% of our time as software engineers" - "Typing is cheap. Wisdom is expensive" #### ⏱️ [00:15:10](https://www.youtube.com/watch?v=zdXsGF1hiZk?t=910) Gary Tan Blog Example - Ruby on Rails blog requiring 250,000+ lines of code - Illustration of architectural complexity explosion - Question about future library creation and interface design ## 📚 References - [Mitchell Hashimoto's Twitter thread on AI psychosis](https://twitter.com/mitchellh) - [HashiCorp](https://hashicorp.com) - Infrastructure automation company - [TinyGrad](https://tinygrad.org) - AI/ML framework - [Sentry](https://sentry.io) - Error monitoring platform founded by David Cramer ## 🗣️ Paraphrase Software industry veteran Mitchell Hashimoto warns that many companies have developed an irrational relationship with AI development tools, similar to problematic patterns seen during cloud infrastructure adoption. Just as some organizations once believed automated failure recovery could replace system resilience, companies now assume AI agents can fix bugs so rapidly that traditional quality practices become obsolete. This "AI psychosis" manifests in dismissive responses to quality concerns, with teams citing metrics like test coverage as magical protection. However, these local health indicators can mask global system degradation - automated tools only catch anticipated problems, not architectural blindspots. The scale amplification effect makes this particularly dangerous: while AI accelerates individual coding tasks, it proportionally amplifies the cost of poor architectural decisions. A mistake that previously generated 30,000 lines of manageable technical debt now produces 500,000 lines of systemic problems. ## 📰 Newsletter **🤖 The AI Reality Check WordPress Developers Need** This week's deep dive explores a fascinating discussion about "AI psychosis" in software development - that irrational exuberance some teams develop around AI coding tools. HashiCorp's founder draws clever parallels to infrastructure automation lessons, where "move fast and fix later" approaches created more problems than they solved. For WordPress developers, this hits close to home. We've all seen plugins with 100% test coverage that still break sites, or themes generated at lightning speed that create maintenance nightmares. The key insight? AI makes typing faster, but architectural wisdom more valuable than ever. The sweet spot seems to be mature codebases where AI can learn from years of accumulated knowledge - think Core contributions or established plugin ecosystems. But for greenfield projects, those upfront planning conversations become exponentially more important when mistakes scale at AI speed. Worth bookmarking: the test coverage demo showing how metrics can lie, and the observation that customer service hiring has actually increased despite predictions of AI replacement. Sometimes the humans know something the hype doesn't. ## ✅ Action Items #### DevRel - Create workshop materials on "AI-Assisted Development Best Practices" addressing quality vs. speed tradeoffs - Develop case studies comparing AI effectiveness in mature vs. greenfield WordPress projects - Document patterns for maintaining code review quality at AI-accelerated development speeds #### Community - Host discussion series on sustainable AI adoption practices for WordPress development - Create guidelines for AI tool evaluation focusing on long-term codebase health over short-term productivity - Establish mentorship programs pairing AI-native developers with architectural experience #### WordPress - Core: Review contribution guidelines for AI-generated patches, emphasizing architectural review importance - Core Performance: Investigate performance implications of AI-generated code patterns in WordPress context - Documentation: Create guidance on responsible AI tool usage for WordPress development - Training: Develop curriculum addressing AI tool capabilities and limitations for different skill levels ## 🧪 Hypotheses - Teams using AI tools without mature architectural practices will create exponentially more technical debt than traditional development approaches - AI effectiveness in software development correlates strongly with existing codebase maturity and documentation quality - Organizations publicly embracing "AI-first" development maintain private quality gates and human oversight not reflected in public discourse - Customer service and QA roles will expand rather than contract as AI tools enable higher volume, lower initial quality output - The value differential between junior and senior developers will increase as AI handles routine tasks but amplifies the cost of poor architectural decisions ### 📊 Methodology - Longitudinal study tracking technical debt accumulation in AI-assisted vs. traditional development teams over 12 months - Comparative analysis of bug density and resolution complexity in mature vs. greenfield AI-assisted projects - Survey research on private AI adoption policies vs. public statements across technology organizations - Economic analysis of support staffing changes in organizations adopting AI development tools - Skills premium analysis comparing compensation trends for architectural vs. implementation-focused developer roles ### ❓ Questions - How can organizations maintain architectural discipline while capturing AI productivity benefits? - What quality gates effectively prevent AI-amplified technical debt without negating speed advantages? - How do we distinguish between AI hype cycles and genuine capability shifts in development practices? - What new forms of technical leadership emerge when implementation speed outpaces architectural planning? - How should educational programs balance AI tool proficiency with foundational software design principles? ### 🔮 Future Research - Long-term studies on AI-assisted codebase maintainability and evolution patterns - Investigation of emergent quality assurance practices in high-velocity AI development environments - Analysis of changing skill requirements and career progression paths in AI-augmented software development - Research on cognitive load and decision fatigue in developers managing AI-accelerated development cycles - Study of organizational learning patterns when traditional software development wisdom conflicts with AI-enabled possibilities ### 💡 Implications **Practice**: Development teams need new frameworks for architectural decision-making that account for AI's scale amplification effects. Traditional code review practices may inadequately address the volume and complexity of AI-generated code. **Policy**: Organizations require nuanced AI adoption policies that distinguish between appropriate use cases (routine maintenance in mature codebases) and high-risk applications (architectural decisions in new projects). **Education**: Computer science and coding bootcamp curricula must balance AI tool proficiency with deepened focus on software architecture, system design, and long-term maintainability principles. **Security**: The scale amplification effect applies to security vulnerabilities, requiring enhanced security review processes and potentially new categories of automated security analysis tools. **Economic**: The increasing value differential between architectural and implementation skills may reshape technology career paths and compensation structures, with senior roles commanding higher premiums. ### 🧠 Learning Styles Assessment Reading level estimate: **Flesch-Kincaid Grade 12.5** - Technical content with industry jargon requiring professional software development background. #### 👀 Visual learners - **Present**: Code examples demonstrating test coverage gaps, Twitter thread screenshots - **Improve**: Architecture diagrams showing technical debt accumulation patterns, infographics comparing mature vs. greenfield AI effectiveness, visual timeline of infrastructure automation lessons #### 🔊 Aural learners - **Present**: Video format with spoken explanation and commentary - **Improve**: Podcast-style discussion segments, audio summary of key technical concepts, interview format with multiple expert perspectives #### 🗣️ Verbal learners - **Present**: Clear definitions of MTBF/MTTR, analogies between infrastructure and software development - **Improve**: Glossary of technical terms, more extensive analogies explaining complex concepts, story-driven examples of AI adoption successes and failures #### 🧩 Kinesthetic learners - **Present**: Live coding demonstration, hands-on test coverage example - **Improve**: Interactive exercises for evaluating AI-generated code quality, step-by-step checklists for AI tool adoption, practical workshops on architectural decision-making #### 🧠 Logical learners - **Present**: Clear cause-effect relationships between AI adoption and technical debt, structured argument progression - **Improve**: Decision trees for AI tool selection, quantitative metrics for measuring AI adoption success, formal frameworks for architectural risk assessment #### 🧑‍🤝‍🧑 Social learners - **Present**: Discussion of industry discourse, multiple expert perspectives referenced - **Improve**: Forum discussion prompts, peer review exercises for AI-generated code, collaborative workshops on team AI adoption strategies #### 🧘‍♀️ Solitary learners - **Present**: Individual reflection on personal AI adoption experiences - **Improve**: Self-assessment questionnaires for AI tool readiness, private journaling prompts about development practice evolution, independent project ideas for testing concepts #### 🌿 Naturalistic learners - **Present**: Ecosystem thinking about software development evolution, organic growth metaphors for technical debt - **Improve**: Analogies to natural systems for understanding emergent complexity, sustainability frameworks for long-term codebase health, biological metaphors for code evolution ### 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Clear heading structure, descriptive video title - **Improve**: Transcript formatting with proper headings, aria-labels for timestamp links, alt text for any referenced screenshots or diagrams #### Keyboard navigation - **Present**: Standard YouTube video controls - **Improve**: Skip links to transcript sections, keyboard shortcuts for timestamp navigation, accessible chapter markers #### Contrast and readability - **Present**: Standard video player interface - **Improve**: High contrast transcript option, larger text size options, customizable color schemes for reading interface #### Text resizing and reflow - **Present**: Responsive transcript display - **Improve**: Ensure transcript remains readable at 200% zoom, test reflow behavior on mobile devices, prevent horizontal scrolling #### Media and captions - **Present**: Video with audio narration - **Improve**: Add closed captions with speaker identification, provide downloadable transcript, include audio descriptions for visual code examples #### Forms and interactions - **Present**: Basic video player interactions - **Improve**: Accessible feedback for timestamp bookmarking, error handling for failed video loads, clear labels for any interactive elements #### Standards reference - Address WCAG 2.2 AA criteria for video content, transcript formatting, and navigation elements. ### 🌍 DEIB Assessment #### Cultural breadth - **Present**: US-centric software development perspective, English-only content - **Improve**: Include global perspectives on AI adoption in different technological contexts, consider varied regulatory environments, provide multilingual transcript options #### Inclusive language - **Present**: Technical jargon defined in context, casual but professional tone - **Improve**: Add plain-language glossary, avoid industry insider humor that excludes newcomers, expand abbreviations on first use #### Neurodiversity support - **Present**: Clear topic structure, verbal explanation of visual code examples - **Improve**: Provide written summary alongside video content, use consistent formatting patterns, offer alternative consumption formats (audio-only, text-only) #### Representation - **Present**: Multiple technical expert perspectives, varied company sizes and contexts - **Improve**: Include perspectives from developers with different career stages and backgrounds, address how AI adoption affects underrepresented groups in tech, consider accessibility implications of AI-generated code #### Psychological safety - **Present**: Respectful discussion of different viewpoints, acknowledgment of uncertainty - **Improve**: Explicitly welcome questions about basic concepts, provide content warnings for discussions of job displacement, create space for disagreement with presented viewpoints ### ✅ Logical Validity #### Strong reasoning - **Deductive strength**: The MTBF/MTTR infrastructure analogy provides solid logical foundation for understanding AI adoption risks (00:03:00). The parallel structure helps predict likely failure modes. - **Inductive evidence**: The test coverage demonstration (00:05:15) effectively shows how local metrics can mask global problems, supporting the broader argument about AI psychosis symptoms. - **Causal reasoning**: The scale amplification argument (00:12:20) clearly establishes how AI tools change the cost-benefit calculation for architectural decisions, with concrete examples. #### Fallacies - **False dichotomy** (00:02:30): The discussion sometimes presents AI adoption as binary "psychosis vs. rationality" when most organizations likely fall on a spectrum of adoption approaches. - **Hasty generalization** (00:08:45): Using Gary Tan's blog as evidence of broader AI overcomplication may not represent typical use cases. - **Ad hominem tendency** (00:01:00): The speaker's dismissive tone toward "full test coverage" advocates risks undermining otherwise valid points about test limitations. #### Tone of voice - **Conversational and engaging**: Uses humor and personal anecdotes to maintain interest while discussing technical concepts - **Respectfully skeptical**: Acknowledges legitimate AI benefits while questioning unrealistic claims - **Industry-insider**: Assumes familiarity with software development practices and personalities, potentially excluding some audiences ### 🛡️ DARVO Analysis No significant DARVO patterns detected in this content. The discussion maintains focus on technical practices rather than personal attacks or responsibility reversal. The speaker acknowledges their own evolving position on AI tools and avoids positioning themselves as victim when discussing industry criticism. **Emotional cues**: Some frustration evident when discussing "test coverage" claims and industry hype, but directed at ideas rather than individuals. Maintains respect for named technical leaders even while disagreeing with approaches. ## 🎯 Conclusion The "AI psychosis" phenomenon highlights a critical tension in software development: the gap between AI tools' impressive capabilities and organizations' readiness to use them wisely. The infrastructure automation analogy provides valuable guidance - previous generations learned that automated recovery cannot substitute for system resilience. For WordPress developers and the broader software community, the key insight is scale amplification. AI doesn't just make good developers faster; it makes architectural mistakes exponentially more expensive. This paradox means that foundational skills - system design, architectural thinking, and long-term maintenance planning - become more valuable, not less, in an AI-accelerated world. The path forward requires nuanced adoption strategies that match AI tool capabilities to appropriate contexts: routine maintenance in mature codebases where AI can learn from accumulated wisdom, balanced with heightened architectural oversight for greenfield projects where mistakes compound at machine speed. --- ## Full Transcript [00:00] I saw this tweet. I actually I wanted to [00:01] take a moment to kind of look through [00:02] this cuz this is actually you know, it's [00:04] very interesting stuff going on right [00:06] here. It says this I by the way, this is [00:08] Mitchell Hashimoto. If you don't know [00:09] Mitchell Hashimoto, HashiCorp, I know. I [00:12] cannot believe to think about this for a [00:14] second. Mitchell Hashimoto named his [00:17] last name after the corporation he [00:20] started HashiCorp. Can you believe that? [00:21] Like this guy kind of honestly kind of [00:24] crazy that someone would actually go out [00:26] there and change their last name just to [00:28] just to match their companies. It's [00:30] ridiculous. I know. Dedication. I [00:32] strongly believe there's an entire Let's [00:34] see, there are entire companies right [00:35] now under heavy AI psychosis and it's [00:37] possible to have irrational [00:39] conversations about it with them. Yes, I [00:41] do think this is true. You do meet [00:43] people that are so I mean, that's $1.3 [00:45] million spent by a single person in 30 [00:48] days. I'm just saying, you can't Dude, [00:50] do you ever wonder why these AI [00:52] companies are telling you that coding's [00:54] so over? Can you believe how much money [00:56] they can make per per user here? So I [00:58] mean, they're going to make a lot of [00:59] money per person. Anyways, all right, [01:01] let's go back to this. All right. I [01:03] can't name any specific people because [01:05] they include personal friends I deeply [01:06] respect, but I worry about how this [01:08] plays out. I lived through the great [01:10] MTBF versus MTTR meantime between [01:12] failures versus meantime to recovery [01:14] reckoning of infrastructure during the [01:16] transition to the cloud and cloud [01:17] automation. Again, he did Terraform. He [01:20] knows a lot about clouds. Bro, if I ever [01:22] had a if I ever had to have an absolute [01:24] answer to how you should do things, I [01:25] would probably listen to this guy. All [01:26] those arguments are rearing their ugly [01:28] heads again, but it's but now it's the [01:31] whole software development industry, [01:32] maybe the whole world really. It's [01:34] frightening because the psychosis folks [01:36] operate under an almost absolute MTTER [01:39] is all you need mentality. It's fine to [01:41] ship bugs because the agents will fix [01:43] them so quickly and at scale that ham uh [01:45] humans can't do. They do say that. Uh we [01:47] don't uh let's see, we learned in [01:49] infrastructure that MTTR is great, but [01:51] you can't yeet resilient system [01:52] entirely. The main issue is I don't even [01:55] know how to bring this up uh to people I [01:57] know personally, which is probably kind [01:59] of crazy, right? Like if you know [02:01] someone personally and you want to be [02:02] able to just like sit down with them and [02:04] talk to them, it's crazy that you can't [02:06] even just like sit down with your [02:08] friends and talk to them, right? Like [02:10] that's that has to be such a weird [02:12] thing. I can't It's It's crazy thing [02:13] he's talking about Trash Dev. Yeah, [02:15] right. Trash would wish he could be [02:16] friends with with Hashi. I mean, it is [02:18] like that's some serious weird problem [02:20] because I think one of the big things [02:22] that is going on with AI that makes it [02:23] so unique is people have this like weird [02:25] personal relationship with AI, if that [02:27] makes sense. Like they actually they [02:29] describe AI AI like they're describing [02:31] talking to people. It's they It's really [02:34] weird. And so I feel like sometimes when [02:35] you say anything negative towards it, [02:37] it's like you're not only just saying [02:38] something negative towards say, you [02:40] know, at the end of the day a text [02:41] generator. You're actually like saying [02:43] something negative towards somebody that [02:44] they personally are like I am friends [02:46] with this and this hurts me deeply. Like [02:48] me personally, when you talk negatively [02:50] about Jippity 55, you're talking [02:51] negatively about because you're talking [02:53] negatively about me because that's who I [02:55] am. I am I am Jippity 55. Let's see. [02:58] Because bringing this topic Let's see. [03:00] Up leads immediately Let's see. Oh my [03:02] goodness. Bringing Because bringing this [03:04] topic up leads to immediately dis- [03:06] immediately dismissals. Okay, there [03:08] Okay, so it's not me. Because bringing [03:10] this topic up leads immediate to [03:12] immediate dismissals. Like no, no, it [03:15] has full test coverage, which by the [03:16] way, if any like I cannot take a single [03:19] human seriously if your answer is, "Oh, [03:21] I don't worry about it cuz it has full [03:22] test coverage." I have never met [03:24] somebody that's not a bigger idiot than [03:26] says those words. Like those words are [03:28] for dumb people. Like I'm not saying [03:30] full test coverage isn't bad. Like I [03:32] actually think it's great. Like that's [03:33] good. Like that's that's a good thing. [03:35] That's good. That's good. [03:37] >> [laughter] [03:38] >> But to say that you don't need to worry [03:39] because of it is just like, "Brother, [03:41] you do know that test catch bugs that [03:43] already you already know about and [03:45] exist, right?" No one's ever been No one [03:47] ever gets caught. Check this out. Are [03:49] you guys ready for this one? We'll go [03:50] like this. R [03:51] Let's have that as a number. There we [03:53] go. And let's have a count number, [03:56] right? And we're going to go like this. [03:57] Are you guys ready? Four, let I, boom. [04:00] Return. Oh, I Oh, yeah, okay. Why are [04:03] you Why are you not doing that? No, not [04:04] R, you idiot. It should be count. I [04:06] didn't specify the return value. Why is [04:08] What is going on? Why Why are you not [04:10] leaving? Anyways. All right, so there we [04:12] go. Awesome. If we were to test this and [04:14] this was our test, guess what? We would [04:16] get 100% test coverage. But if I just do [04:18] that, guess what? There's a bug. 100% [04:20] test coverage and everything works fine. [04:22] Bug. It's like that easy. Just because [04:26] you have 100% test coverage does in fact [04:28] mean or does not in fact mean you have [04:31] well operating code. It's crazy that [04:34] people don't understand this. It's like [04:35] so super ridiculously obvious. All [04:37] right. Our bug reports are going down or [04:39] something which which just don't paint [04:42] the whole picture. We already learned [04:44] this lesson once in infrastructure. You [04:45] cannot automate yourself into a very [04:47] resilient catastrophe machine. Systems [04:50] can appear healthy by local metrics [04:52] while globally becoming [04:53] incomprehensible. Bug reports can go [04:55] down while latent risk explodes. Test [04:57] coverage can rise while systematic [04:59] understanding falls. Changes happens so [05:02] fast that nobody notices the underlying [05:05] architecture decay. I work. This is [05:07] good. This is really really good stuff. [05:09] This is exactly what you want to be [05:10] hearing from somebody. And here's the [05:12] crazy part is that By the way, this is [05:14] George Hotz. Love George Hotz. This is [05:16] one of my favorite people in the [05:18] universe talking about AI cuz his takes [05:19] are stood. We should just have the [05:21] greatest tiny grad takes. I just want [05:24] you to think about this for a second. [05:25] Tiny grad. Tiny grad is a place that if [05:27] you go to tinygrad.org, they have their [05:29] tiny boxes, which are all these gigantic [05:31] computing machines. Absolutely just [05:34] incredible stuff, right? And then they [05:36] just go on a non-stop Twitter spree, [05:39] just destroying people about AI all the [05:42] time. One of my Hands down, one of my [05:44] favorite. They're just one of my [05:46] favorite groups ever. Super good. [05:49] Super super good at AI. Totally knows a [05:52] lot of stuff. And then just just craps [05:55] on people all the time. Oh, but here's [05:57] the crazy part. Like if you go actually [05:58] right here, this is Mitchell's response [06:00] to Kramer. We'll read Kramer. Kramer [06:01] also Kramer very good guy. You're not [06:03] one of the alluded let's see one of the [06:05] alluded two people nor is your company. [06:07] His company Century by the way, he [06:08] founded Century. And also just for the [06:10] peanut gallery, I almost exclusively [06:12] write code using agents nowadays. So [06:14] this guy who almost exclusively writes [06:16] code with agents nowadays, in fact, [06:18] thinks that most people are crazy and [06:21] they have no idea what they're talking [06:22] about. Like that is just like it is just [06:24] so beautiful. It's just so dang [06:26] beautiful the craziness of the world we [06:29] we live in. Let's just read this one. [06:30] There's a lack of grounding with many [06:31] folks. However, counterpoint, most [06:33] strong leaders aren't very public with [06:34] their opinions especially on this [06:36] platform and surprising amount of them [06:37] are very grounded in the way they are [06:39] adopting things. They look at [06:40] information the same way we do, have [06:43] made similar well-reasoned decisions and [06:44] are cautiously moving forward with [06:46] increasingly forward-looking approaches. [06:48] I think it's important Let's see, I [06:50] think it's important folks continue to [06:52] push back on the two futuristic opinions [06:54] amongst corporate leaders and others. [06:56] But moderation is always the key [06:57] component. Facts change over time and [06:59] you should be willing to change your way [07:01] of thinking as they do. Yes, which I I [07:03] get this crap all the time like I can't [07:04] believe I use AI at all. So it's just [07:07] like, well, yeah, it's true. And they're [07:08] like, well, didn't 2 years ago you said [07:10] you hated AI. I'm like, yeah, true. Cuz [07:12] 2 years ago, if you outsourced all of [07:14] your writing of your code to AI 2 years [07:16] ago, like you're kind of a dummy, you [07:18] know that, right? Like why would I ever [07:20] trust your opinion if you if you looked [07:22] at Jippity 3.5 and said, that replaces [07:24] me. That that right there replaces me. [07:27] It's just like, bro bro brother. [07:29] >> [laughter] [07:31] >> That is absolutely terrifying. Just [07:33] makes no sense. 2 years ago, there's not [07:35] a chance in hell I'd be generating code [07:37] with an LLM. Yes, totally agree. But But [07:40] I do it exclusively. I don't do it [07:41] exclusively. I'm still trying to figure [07:42] out how to even make it do it the way I [07:44] like to code. I don't know how to do it [07:46] yet. I'm going to keep on trying to bang [07:47] on that. Uh haven't figured it out yet, [07:49] but we'll we'll figure it out. Maybe I [07:51] just code so crappy, honestly, that the [07:52] machines can't even do it. Like that's [07:54] my only That is like literally my only [07:56] takeaway is that I think that the [07:58] machines look at how I code and they [07:59] said, "You know what, bro? That ain't [08:01] it." I can tell you this much, that [08:02] ain't it. My adoption stance have [08:04] changed over time as the technology has [08:06] changed, but there are also many [08:07] problems that I still see with the tech [08:09] today that were visible 6 months ago, [08:11] let alone 2 years back. I don't see a [08:13] lot of evidence for some of the things [08:14] that have become popular opinion. For [08:16] personal favorite being engineering [08:18] being a less valuable skill. Yes, if [08:20] anything being able to move faster only [08:22] means that engineering is more is more [08:24] valuable. It's like completely the [08:26] inverse. [08:27] Uh anything beyond like There's a lot of [08:29] people that produce really simple sites, [08:31] simple marketing things. There's a lot [08:32] of these basic YC companies that their [08:34] only goal's to just get across the [08:36] finish line, make some money, and like [08:38] try to escape out and get a bunch of [08:40] funding. So, they have a very different, [08:42] you know, calculus they're running. So, [08:44] okay, whatever. But I like, you know, [08:45] you can't just go to a place like Google [08:47] and start being like, "Hey, yo. Don't [08:49] worry. I got your cloud infrastructure, [08:50] bro. I got your cloud infrastructure, [08:52] and I'm just going to take care of it." [08:54] I think the biggest issue that is pretty [08:56] widely visible is that the public [08:58] discourse is often widely disconnected [08:59] from reality inside these organizations. [09:01] AI is causing layoffs. We're going We're [09:03] not going to hire new grads. Engineering [09:04] is dead, etc. Those are toxic and do not [09:06] reflect real truths. Yeah, it seems like [09:08] people there's been a in The funny part [09:11] is customer service hires and jobs have [09:14] increased, which you'd think that it's [09:16] actually like the opposite, right? I I I [09:19] always personally assumed that customer [09:20] service would be one of the first ones [09:22] to go. Yeah, there's been an increase in [09:23] the last little bit of time, but I'm [09:25] curious where that's going. Like I I [09:26] can't imagine that's going to last. Like [09:28] in my head that just would never last. [09:30] Anyways, I wanted to read this because I [09:31] didn't I didn't It's just so interesting [09:33] like how much we're seeing in real time [09:35] people just doing things in which I [09:37] think look good on paper right now and [09:40] we're just building towards a weird kind [09:42] of world. Like I don't know where we're [09:43] going to be in 6 months. I genuinely [09:45] don't know how much software is going to [09:46] be just utter horse crap in 6 months. [09:49] Cuz remember, like to to actually take a [09:51] good project and make it bad, like okay, [09:53] there's a lot of things going on. Let [09:54] Let's just hold on. Let's just try to [09:56] walk through this in a more thoughtful [09:58] manner instead of just yapping with no [09:59] direction. So, a lot of people that are [10:01] yapping about this is that they actually [10:03] have Oh, yeah, there you go. Whoever [10:04] said you needed those straight lines. [10:05] Look at that straight line. They already [10:07] have a code base that has already had [10:09] like 10 years of thought put into it. [10:11] And so, now they're using AI and they're [10:13] saying things like, "Oh, dude, it's it's [10:14] it it's so over." Which is kind of crazy [10:17] because the AI has so much information [10:20] to go off of in these larger code bases [10:22] that they can run nicely. And so, it's [10:23] just like, "Yeah, I guess in some sense [10:25] you're saying that it's so over because [10:26] now you can do a lot of your tasks that [10:28] you were able that took you, say, 1 day [10:30] to do, you can now do in, you know, 15 [10:32] minutes." Okay. True. Like I can see [10:35] this being the case because there's just [10:36] a lot of simple stuff, especially in a [10:38] really, really old, well-established [10:40] software. But like, how many people and [10:43] time and discussions went into this [10:45] software to just generally get it in the [10:47] right shape? Like I've worked in [10:48] long-running software. I know how [10:50] disaster it is internally. But it's [10:52] absolutely crazy how people think that [10:54] this This right here is any indication [10:57] into like a brand new project. It's not [10:59] any indication into a brand new project. [11:01] There's so much stuff that can be taken [11:04] and absorbed from that you don't even [11:05] understand just because you have such an [11:07] old, old code base. And so, when I see [11:10] people talk about how like jobs are [11:12] over, a lot of times I look at this [11:13] stuff and I'm just like, "Okay, in some [11:15] sense you're right." Like there are a [11:16] whole set of things that are just going [11:18] away. Like a lot of these simple bug [11:19] fixes, especially in mature code bases, [11:20] you can actually kind of do a whole [11:22] bunch of automation on and the amount of [11:24] time it takes to really, you know, [11:26] actually massage them and make them [11:27] happen is significantly smaller. But [11:29] there's so much more thought that has to [11:31] go into uh code bases because they can [11:33] grow at such a faster rate now. Like [11:35] when you make a bad decision here, it [11:38] costs so much more. It used to only cost [11:40] a little bit because you'd be like, [11:42] "Okay, I think this is the right way to [11:43] go. We all agree on this. Let's start [11:45] going." And then within 1 month, you're [11:46] like, "Dude, we produced like 30,000 [11:48] lines of code together. And yeah, this [11:51] is not good. What we've done is not [11:52] good." Now, it's like, "Okay, what we [11:54] produced is like 500,000 lines of code [11:56] and it's an absolute disaster." Coding [11:57] is roughly 20% of our time as software [11:59] engineers. Typing is cheap. Wisdom is [12:01] expensive. Wisdom is super expensive. [12:02] Yes, I also am very curious about this, [12:04] which is what happens like how does [12:05] effect get created today? I feel like [12:07] we're going to see less new libraries [12:09] because so many [12:10] so many people don't really concern [12:12] themselves with the interfaces anymore. [12:13] Right? There's so many people that have [12:14] like that would have been great at [12:16] creating something, but instead be like, [12:18] "Oh, I just don't have to think about it [12:19] anymore." Right? We got Jai. Yes, Gary [12:21] Tan's blog is a very interesting [12:23] example. He took Ruby on Rails, which is [12:25] a language designed to be a blog and [12:27] somehow wrote 250,000 [12:29] lines of code plus 250,000 lines of test [12:32] to have a blog that's generated in a [12:35] language written for a blog. Crazy. [12:37] Absolutely crazy. What's up, baby? [12:39] Anyways, just wanted to yap about that [12:40] for a little bit. It's kind of [12:41] interesting. Kind of weird. I'm curious [12:43] about all this. I'm curious where it's [12:45] all going to go. What's going to happen [12:47] in, you know, in 5 years? I have no [12:49] idea. Oh, what's going to happen really [12:51] in 5 months? I have no idea. I just [12:53] assume that things are going to be nuts.  ## Highlights - 08:45): Using Gary Tan's blog as evidence of broader AI overcomplication may not represent typical use cases. - Note: 🔍 Fallacy: Hasty Generalization #fallacy/hasty-generalization - 01:00): The speaker's dismissive tone toward "full test coverage" advocates risks undermining otherwise valid points about test limitations. - Note: 🔍 Fallacy: Ad Hominem #fallacy/ad-hominem