What happens now - CourtneyR.dev's 2nd Brain

What happens now? 🔗 **Source:** [What happens now?](https://www.youtube.com/watch?v=28z6OjsNsUk) > [!note]+ Document Notes > tags: [ai-development, software-engineering, code-generation] > author: Theo - t3.gg > source: YouTube > reference: https://www.youtube.com/watch?v=28z6OjsNsUk > date created: 2025-01-07 15:30 > > # 🏷️ Title: What happens now? The Shift from Expensive Code to Disposable Software >  ## 🧰 Action Inbox - [H1] Experiment with disposable software approach — try building one-off solutions instead of seeking SaaS #experimentation - [H2] Develop communication and distribution skills — focus on why software matters, not just how it works #career-development - [H3] Practice orchestration mindset — treat AI tools like team members to coordinate #ai-tools ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Chris Gregory's article](URL) - referenced inspiration for the discussion - [SpaceTime Database](https://spacetime.link/) - featured sponsor - [t3.gg](https://t3.gg) - Theo's website ## 📝 Summary - **What happened**: AI code generation tools (Claude Code, Cursor, OpenCode) have made writing code extremely cheap, shifting the software development paradigm from expensive, permanent solutions to disposable, single-use tools - **Why it matters**: This represents a fundamental change in how software is created and used - similar to when compilers abstracted away assembly code - where the barrier to creating software has collapsed but distribution and communication have become more critical - **Key stakeholders**: Software developers, founders, businesses using internal tools, content creators, and anyone building digital products - **Risks and tradeoffs**: While code generation is now trivial, most generated code runs zero to one times; engineering skills are shifting from coding ability to system orchestration and communication - **Bottom line**: Code became a commodity, but software value now depends entirely on solving real problems and effectively communicating that value to users ## 📖 Main Content The fundamental economics of software development have shifted. Where code was once expensive and carefully maintained, AI tools have made code generation so cheap that most code is now written once and discarded. This creates a new category of "disposable software" - tools built to solve immediate, specific problems rather than long-term platforms. The shift parallels historical transitions like the move from assembly to higher-level languages. Just as compilers abstracted away low-level details, AI tools are abstracting away the mechanics of coding itself. However, this doesn't eliminate the need for engineers - it transforms their role from code writers to system architects and orchestrators. The real bottleneck has moved from technical implementation to problem identification, communication, and distribution. Tools like Claude Code function more like "Excel for developers" - powerful utilities for immediate problem-solving rather than permanent infrastructure. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/28z6OjsNsUk?t=0) — [H1] The fundamental shift in code economics - Key idea: Code has historically been expensive, requiring large teams of well-paid engineers - Evidence: "Code has always been really expensive... That's why so many companies had to employ such a large number of expensive engineers" #### ⏱️ [02:30](https://youtu.be/28z6OjsNsUk?t=150) — [H2] Code abundance vs software scarcity paradox - Key idea: Code is now prolific but software has become more expensive than ever - Evidence: "Code is now prolific. There is more of it than ever. But software... has become as if not more expensive as a result" #### ⏱️ [04:15](https://youtu.be/28z6OjsNsUk?t=255) — [H1] Historical parallel to compiler revolution - Key idea: This shift mirrors the transition from assembly to high-level languages - Evidence: "This is similar to when compilers happened where all of a sudden code wasn't this really hard to reason about stuff" #### ⏱️ [07:00](https://youtu.be/28z6OjsNsUk?t=420) — [H2] The rise of disposable software - Key idea: Software no longer needs to be built for longevity - single-use tools are now viable - Evidence: "Programs that weren't worth writing before because the use case was too small and the effort was too high now are absolutely worth it" #### ⏱️ [12:45](https://youtu.be/28z6OjsNsUk?t=765) — [H1] Shift from execution to orchestration - Key idea: Senior developers excel with AI tools because they're used to orchestrating people - Evidence: "Claude code just feels like another person that you're orchestrating that is way more capable but way less good at planning" #### ⏱️ [18:30](https://youtu.be/28z6OjsNsUk?t=1110) — [H2] Most code runs zero to one times - Key idea: The average usage per line of code is plummeting due to disposable software - Evidence: "The vast majority of that code will be run zero to one times. The vast majority of it" #### ⏱️ [22:15](https://youtu.be/28z6OjsNsUk?t=1335) — [H3] Dynamic code generation per request - Key idea: Future endpoints might generate new code for each request rather than executing static binaries - Evidence: "The idea that a user can do a thing and the result isn't that an existing binary is executed... but maybe the endpoint generates new code specific to the shape of the payload" #### ⏱️ [28:00](https://youtu.be/28z6OjsNsUk?t=1680) — [H2] Lowered threshold for problem-solving - Key idea: The size of problems worth solving with code has dramatically decreased - Evidence: "The size of problem that's worth solving with code has gotten way way smaller" #### ⏱️ [33:45](https://youtu.be/28z6OjsNsUk?t=2025) — [H1] Excel for developers analogy - Key idea: AI coding tools are like Excel - flexible utilities for immediate problem-solving, not permanent foundations - Evidence: "Cloud code is Excel for devs, a powerful, flexible utility for solving immediate problems rather than Shopify for founders" #### ⏱️ [38:20](https://youtu.be/28z6OjsNsUk?t=2300) — [H2] The brittleness problem - Key idea: AI-generated solutions often break when they encounter real-world complexity - Evidence: "The subscription tracker you vibe coded breaks the moment a bank changes their CSV export formats" #### ⏱️ [42:10](https://youtu.be/28z6OjsNsUk?t=2530) — [H1] Distribution becomes the new bottleneck - Key idea: With code generation democratized, the ability to reach and communicate with users is the limiting factor - Evidence: "We've entered an era where the ability to generate code is no longer the bottleneck. The real challenge has shifted to distribution" #### ⏱️ [48:30](https://youtu.be/28z6OjsNsUk?t=2910) — [H2] The airplane landing delusion - Key idea: Most people overestimate their ability to succeed at complex tasks if given basic tools - Evidence: "34% of men answer yes to this question... the majority of men think they can land the plane" #### ⏱️ [55:15](https://youtu.be/28z6OjsNsUk?t=3315) — [H1] Motivation still required for success - Key idea: If learning to code was too difficult before, the remaining challenges of building successful software will be equally daunting - Evidence: "If coding was too hard for you to learn, now you can code for free. The rest is just as hard, if not harder" #### ⏱️ [58:45](https://youtu.be/28z6OjsNsUk?t=3525) — [H2] The 20:1 ratio collapse - Key idea: The ratio of engineers needed per product visionary has dramatically decreased - Evidence: "That ratio went from 20 to one to like one... So when I was the other 19 engineers, I don't know. I'm not trying to hire them" ## 📚 References - [Chris Gregory's article on code vs software costs](URL) - [SpaceTime Database](https://spacetime.link/) - [Rethinking Reactivity by Rich Harris](URL) - [Theo's YouTube channel](https://youtube.com/t3dotgg) ## 🗣️ Paraphrase - AI has made writing code extremely cheap, but this has paradoxically made good software more expensive because the real value lies in understanding what to build and communicating why it matters - We're moving from a world of permanent software platforms to disposable, single-use tools that solve immediate problems and are then discarded - The role of engineers is shifting from code writers to system orchestrators who manage complexity and communicate value, similar to how compilers shifted focus from assembly details to higher-level logic ## 📰 Newsletter 🚀 **The Great Code Commodity Shift is Here** AI tools like Claude Code have fundamentally changed the game - code generation is now virtually free, but that's created a fascinating paradox. While anyone can now build software in minutes, the real challenge has shifted to distribution and communication. **What This Means for WordPress Developers:** - Focus on understanding user problems deeply rather than just implementation details - Develop skills in system architecture and project orchestration - Master communication - explaining why your solution matters is now more valuable than how you built it The future belongs to developers who can bridge the gap between technical possibility and human need. Start experimenting with AI-assisted development, but invest equally in your ability to identify real problems and communicate solutions effectively. **Key Takeaway:** Code became a commodity. Problem-solving and communication became premium skills. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create content showing AI-assisted WordPress development workflows, measure engagement on disposable software concepts - Education: Design workshops on prompt engineering for WordPress-specific tasks, office hours for AI tool adoption - Developer experience: Document AI-friendly APIs, create scaffolding tools that work well with code generation - Developer marketing: Campaign around "WordPress + AI" positioning, content strategy for post-code world - Community management: Survey developers on AI adoption fears, moderate discussions on industry changes #### OSPO - Policy & Governance: Develop policies for AI-generated code contributions, licensing implications - License Compliance: Create scanning processes for AI-generated code, train on provenance tracking - Security Management: Establish vulnerability processes for rapidly-generated code, attestation frameworks - Software Inventory: SBOM strategy for disposable software, ownership tracking for ephemeral tools - Developer Support: AI tooling recommendations, consultation on orchestration approaches - Community Engagement: Fund AI accessibility tools, agreements with tool providers - Strategic Alignment: KPIs for AI adoption impact, OKRs around developer productivity shifts #### Community - Maintainers: Templates for AI-assisted project governance, roadmap support for tool integration - Contributors: Onboarding programs that include AI workflow training, first-issue programs with AI assistance - Sponsors: Transparent budgets for AI tooling costs, impact reports on productivity gains - Ecosystem: Cross-project coordination on AI tool standards, shared prompt libraries #### WordPress - Core: AI-assisted contribution workflows, issue triage automation, performance budget enforcement - Core Performance: AI-driven profiling analysis, automated optimization suggestions - Core AI: Integration guardrails for AI features, evaluation sets for WordPress-specific use cases - Core Program Team: Coordination tools for distributed AI-assisted work, retrospectives on tool adoption - Mobile: AI-assisted mobile app development workflows, automated testing approaches - Playground: AI-powered learning labs, reproducible environment generation - Community: AI-assisted meetup content generation, WordCamp talk suggestion systems - Training: AI-enhanced lesson plan creation, personalized learning path generation - Marketing: AI-assisted campaign development, automated social content creation - Support: AI-powered response suggestions, knowledge base enhancement automation - Design: AI-assisted UX audit tools, automated design token generation - Documentation: AI-enhanced content generation, automated gap analysis - Photos: AI-assisted content moderation, automated tagging systems - TV: AI-generated captions, automated content indexing - Polyglots: AI-assisted translation workflows, automated glossary consistency - Accessibility: AI-powered WCAG compliance checking, automated audit tooling - Meta: AI-enhanced .org roadmap planning, automated API reliability monitoring - CLI: AI-assisted command generation, automated scaffolding improvements - Hosting: AI-powered hosting optimization recommendations, automated performance monitoring - Tide: AI-enhanced code quality scoring, automated plugin improvement suggestions - Openverse: AI-assisted content moderation, automated metadata enhancement - Themes: AI-powered theme review assistance, automated mentoring content - Plugins: AI-enhanced security analysis, automated provenance verification #### The WPCC - Programs: AI-assisted fellowship matching, automated microgrant evaluation, productivity-based stipends - Projects: AI-enhanced governance templates, automated documentation generation - Funding: AI-assisted grant matching, automated milestone tracking, transparent ledger automation #### FAIR - Technical independence: AI-assisted metadata generation, automated provenance verification - Policies: AI-transparent funding decisions, automated anti-capture detection - Governance artifacts: AI-assisted charter generation, automated operator agreement compliance ## 🧪 Hypotheses - Organizations that invest in communication and distribution skills will outperform those focused solely on technical AI adoption - The average lifespan of software projects will decrease dramatically as disposable software becomes the norm - Engineers who develop orchestration mindsets will remain valuable while pure coders become commoditized - Distribution channels (social media, content creation, community building) will become more valuable than technical skills ### 📊 Methodology - Study design: Track productivity metrics before/after AI tool adoption across different developer skill levels - Data sources: GitHub commit patterns, project completion rates, developer survey data on time allocation - Experiments: A/B test projects with AI-assisted vs traditional development approaches, measure long-term maintenance costs ### ❓ Questions - Will the quality of software improve or degrade as the cost of creating it approaches zero? - How will software security evolve when most code is generated rather than carefully crafted? - What new business models emerge when code generation becomes a commodity? ### 🔮 Future Research - Long-term impact study on software quality and maintainability in the AI-assisted development era - Analysis of changing skill premiums in the software development job market - Investigation of new software distribution and discovery mechanisms for disposable software ### 💡 Implications - **Practice**: Daily development workflows must incorporate AI orchestration and communication skills alongside technical abilities - **Policy**: Organizations need new governance frameworks for AI-generated code quality and security - **Security**: Rapid code generation creates new attack vectors and requires automated security scanning approaches - **Education**: Computer science curricula should emphasize system design and communication over syntax and algorithms - **Funding**: Investment priorities should shift toward teams with strong distribution capabilities rather than just technical depth ### 🧠 Learning Styles Assessment Reading level estimate: 10-12 (College level, technical content with accessible explanations) #### 👀 Visual learners - Present: Charts and graphs showing productivity shifts, architectural diagrams - Improve: Timeline visualizations of the coding paradigm shift, infographics comparing traditional vs AI-assisted workflows #### 🔊 Aural learners - Present: Full video discussion format with detailed verbal explanations - Improve: Podcast version focusing on key concepts, audio summaries of main points #### 🗣️ Verbal learners - Present: Clear definitions, analogies (airplane landing, Excel for developers), extensive examples - Improve: Glossary of terms, more story-driven case studies #### 🧩 Kinesthetic learners - Present: --- ## Full Transcript [00:00] Over the last few decades, code has [00:01] always been really expensive. It's gone [00:03] down some amount from when we were doing [00:05] punch cards back in the day. But for the [00:07] most part, code has been an expensive [00:09] thing. That's why so many companies had [00:10] to employ such a large number of [00:12] expensive engineers. It's why we were [00:14] all pressured to go to college to learn [00:15] how to code so that we could make the [00:17] margins work a little better for those [00:19] companies. That's why we've heard of all [00:20] these crazy salaries being taken home by [00:22] these people throughout our entire lives [00:24] for the most part. I still remember back [00:26] in high school where I was pitched this [00:28] concept of Google being the coolest [00:30] place in the world to work. And here we [00:32] are today and everything is changing. [00:34] Code is no longer this super expensive [00:36] thing that we don't have a lot of. If [00:39] anything, code is now prolific. There is [00:41] more of it than ever. But software, the [00:43] thing that we actually want the code to [00:45] provide for us, has become as if not [00:48] more expensive as a result. It is really [00:50] weird to see this shift happening in [00:52] real time. Yes, this is an AI thing, but [00:54] it goes deeper than that. The software [00:57] we use is fundamentally changing because [00:59] the code underneath it is too. I'd go as [01:01] far as to say this is similar to when [01:03] compilers happened where all of a sudden [01:05] code wasn't this really hard to reason [01:07] about stuff that was weird syntax [01:09] managing memory. C made it so you could [01:12] write code that was a much easier thing [01:13] to understand as a human. And we stopped [01:15] thinking about the assembly code over [01:17] time. I think we're going in the same [01:19] direction with software as well, where [01:21] the software is the thing we care about, [01:22] but the code underneath matters less and [01:24] less. I just saw this article written by [01:26] Chris and inspired me to go deep on this [01:28] topic. It's a thing I've been thinking a [01:30] lot about. The higher level of the [01:32] things we use matters more than ever, [01:34] but the details are starting to matter [01:36] less. This hurts me as a developer who [01:38] cares a lot about software, but it also [01:40] excites me as a person who cares about [01:42] the experiences that they use every [01:44] single day. Do you know what you should [01:46] be using though? today's sponsor. Guys, [01:48] it's 2026. Why are we still writing our [01:50] databases like we're in the 90s? Why are [01:52] we running a SQL database so far away [01:54] from our own servers that we can't trust [01:56] it to do fast stuff? How would we handle [01:58] it if we wanted to do a real-time [01:59] experience like people sharing cursors [02:01] on the screen or a multiplayer game? Why [02:03] is our database such a limiting factor [02:05] in all of these things? Well, the reason [02:07] is that you haven't tried today's [02:08] sponsor yet, SpaceTime. These guys are [02:10] from the game industry. They know how to [02:12] make things that are performant with [02:14] insane amounts of throughput for small [02:16] sets of users and big ones, too. They [02:18] put a ton of time into building a [02:20] database platform to run their MMO and [02:22] realized it's useful outside of their [02:23] game. And then they realized it's useful [02:25] outside of gaming. And here we are today [02:27] with them shipping a full TypeScript [02:29] client as well as Rust and C#, by the [02:31] way, so that you can write TypeScript [02:33] code that will run on the same box that [02:35] the data is on. That just changes the [02:37] dynamics of everything. We're talking [02:38] about paradigms where a user can just [02:40] have their cursor's location written to [02:42] the database and everyone else can see [02:44] it with sync, by the way, without having [02:46] to do anything special at all. Things [02:47] that you would normally never do because [02:49] it will hose the database just don't [02:51] matter with a model like this. Write [02:53] your table definitions in Typescript, [02:54] which is awesome. It gives you full [02:56] stack type safety, too. As you guys [02:57] know, I love that. You can then create [02:58] reducer functions. And funny enough, the [03:00] default language is Rust. Just click the [03:01] TypeScript button, and you can see it's [03:03] literally five lines of super simple [03:05] Typescript. We have our table. We then [03:07] have our reducer where a user can now [03:09] insert a new user with an ID and a name. [03:11] You can even identify the sender to know [03:13] who is the one who is hitting this thing [03:14] because again these queries can face [03:16] users directly. They can just query and [03:19] mutate the data in the database and the [03:20] code in the database are the same thing. [03:23] So it all flies. They even have a React [03:24] library that works fully with their O [03:26] platform. Pretty cool thing to have for [03:28] a database that's much more focused on [03:30] the lower level stuff. But that's part [03:31] of what makes FaceTime magical. They [03:33] built these rocksolid super performant [03:34] primitives so that you can build a [03:36] scalable super performant application. [03:38] It's one of those products that unlocks [03:39] things you could never have built [03:40] before. And honestly, I'm so excited to [03:42] go build with it myself. Check them out [03:44] now at sidv.link/basetime. [03:46] Huge shout out to Chris Gregory for [03:47] letting me read this article and use it [03:48] as a reference point for the stream and [03:50] video. I'm super excited to dig in. This [03:52] is a thing I've been thinking a lot [03:53] about, and it's such a good way of [03:54] framing it, too. The barrier to entry [03:56] for building software has collapsed. The [03:59] barrier to building something that [04:00] matters hasn't moved an inch. Yep. Cloud [04:03] Code and Opus 4.5 have poured fuel on [04:06] the hype. LM tools existed before, but [04:08] they're better than ever now. So, a lot [04:10] more people are paying attention. But [04:12] we're not entering a golden age of SAS. [04:14] We're entering an era of personal [04:16] disposable software, where engineering [04:18] shifts from writing code to shaping [04:19] systems, and engineers are still [04:21] required for exactly that reason. This [04:23] disposable software piece in particular [04:25] is something that's really exciting to [04:27] me. Programs that weren't worth writing [04:29] before because the use case was too [04:31] small and the effort was too high now [04:33] are absolutely worth it because building [04:35] it is cheap. The thing that's expensive [04:37] is figuring out what exactly you want [04:39] and specking it out. If you can write [04:40] down a markdown file what exactly you [04:43] want, you can get the code much easier [04:45] now, which is super cool. The shift in [04:47] modern development. Cloud code is taking [04:49] over my feed right now. Open code more [04:51] so mine, but I feel you for sure. What's [04:53] interesting isn't just that devs are [04:55] jumping on it. it's that builders and [04:57] makers who previously relied on [04:58] platforms like lovable or replet are [05:00] migrating to it. I don't necessarily [05:01] agree there. I think what's much more [05:03] interesting is that senior and [05:05] experienced developers are starting to [05:06] embrace it too because they are both [05:08] seeing the value of these disposable [05:10] pieces of software. And also they are so [05:13] used to orchestrating people that claude [05:15] code just feels like another person that [05:17] you're orchestrating that is way more [05:19] capable but way less good at planning [05:22] and figuring out what it wants to do. [05:23] Lovable and replet are still totally [05:25] viable for shipping fast. But we're [05:26] seeing a clear shift as people [05:28] rediscover the inherent beauty of a CLI [05:30] first workflow. When you move the [05:31] interaction into the terminal, the [05:33] abstraction layer thins out. You aren't [05:34] just following a managed UI's happy [05:36] path. You're the one in control. Eh, I [05:39] feel like, especially now that I'm [05:40] hopping between the different CLI tools, [05:42] I feel more restricted than ever. Even [05:44] something as simple as typing in the [05:46] interface sucks. option delete does [05:49] something different between cla code and [05:51] open code and it's so annoying. Just for [05:54] an example quick, I'm gonna open up open [05:56] code and claude code in a random [05:58] directory. I'm going to type something. [06:01] Then I'm going to do a new line, [06:02] something else, another thing, and start [06:05] typing one more thing. Watch what [06:07] happens when I press option delete. It [06:10] deletes the new line. It should only [06:12] delete to the last alpha numeric. So, if [06:14] I do something like this, the option [06:18] delete should stop at the end of the [06:19] kebab casing. It doesn't always do that. [06:21] And I'm command- zinging right now, and [06:23] it doesn't bring it back. Whereas here, [06:26] option delete keeps me on the new line [06:28] like it should. It doesn't delete the [06:30] new line. And if I command Z, oh no, [06:32] Command Z also doesn't work here. That's [06:34] annoying. Yeah, I hate all of this. I [06:37] just want a real input box so badly. I [06:40] know terminals better than most people. [06:42] I have been a T-Mux person since I was [06:44] literally 14. Well, I was a GNU screen [06:46] person because I'm old enough that I was [06:48] a GNU screen person and now I'm a T-Ux [06:50] person. I'm trying to wean myself off it [06:52] and it's been really, really tough. That [06:54] all said, when I'm writing things with [06:56] multiple lines, which is very often with [06:58] these tools, I hate using the terminal [07:01] as my input. It's just bad. And a part [07:04] of why it's weird in open code is [07:05] they're using the alternative view mode [07:07] in the terminal, which means they're not [07:08] using the standard buffer. And the [07:10] standard buffer is what gives you these [07:12] standard behaviors. They have to [07:13] reimplement all of those behaviors in [07:15] open code in order for it to behave [07:17] well. That's also why their UI is so [07:19] much better than cloud code because [07:20] they're not just writing into the [07:21] standard buffer. But it means that weird [07:24] things I'm used to behaving certain ways [07:25] in my terminal have to be manually [07:27] re-implemented. And I don't feel in [07:29] control as a result. I don't feel like I [07:31] have this level of control of my [07:33] instances the way I do in more [07:36] traditional software. That said, I have [07:38] been using the CLI things a lot more and [07:39] they're cool as hell. I just don't [07:41] necessarily agree with the point that [07:43] the CLIs are giving you this level of [07:45] full control. This is the part I care a [07:47] lot more about though. The collapse of [07:48] the barrier to entry. What are people [07:50] actually building with these tools? If [07:51] you look around, the answer is almost [07:54] everything. Even just sty shipping is [07:57] absurd. Pete already had his hundred [08:00] million dollar exit from a big company, [08:02] so he doesn't have any traditional [08:04] reason to care a whole lot about what [08:07] can make money, but he isn't letting [08:08] that slow him down. He's putting out [08:10] more software than ever, and it's all [08:12] entirely free and open source, and [08:14] there's so much cool [ __ ] in here. [08:15] Claudebot's the one that's taking the [08:17] world by storm. A personal favorite of [08:19] mine is Codex Bar, which should be [08:21] somewhere in here. Oh, it's number three [08:23] there now. It used to be lower. Codex [08:25] bar is how I keep track of my remaining [08:27] rate limits across all of my different [08:28] subscriptions for AI stuff. Super cool. [08:31] The amount of [ __ ] Pete has shipped in [08:33] just the last few months is absurd. And [08:35] if you look at his GitHub contribution [08:37] chart, it is actually hilarious. He has [08:41] a screenshot of it cuz I think he broke [08:43] it. Yeah, he's doing like 530 commits on [08:46] some days because he just spins things [08:48] up and ships them. really now finally [08:51] comes down to like how good are your [08:52] ideas and how well can you describe [08:54] them? As the author puts it here, the [08:56] answer to what are people building? [08:58] Almost everything. In fact, we've [09:00] reached a point of saturation. On one [09:02] hand, we're witnessing the true [09:03] democratization of software creation. [09:05] The barrier to entry has effectively [09:06] collapsed. For the first time, non-devs [09:09] aren't just consumers of software. They [09:10] are the architects of their own tools. I [09:12] still think we're not quite there yet. [09:14] There are certain things that will help [09:16] us get there. What I'm more interested [09:17] in is the really skilled developers like [09:19] Pete and how much more they can ship by [09:22] using their existing orchestration [09:23] abilities and mindset and multiplying [09:26] that using these AI tools. In the past, [09:28] if you had a specific problem, you'd [09:29] spend hours searching for a SAS product [09:31] that solved 80% of it. Yep, been there [09:34] so many times. Today, the workflow [09:36] shifted. People are opening a CLI or a [09:38] voice interface and simply describing [09:39] what they need. We're seeing a surge in [09:41] personal software, things like [09:43] subscription trackers tailored to [09:44] specific budget styles, Chrome [09:46] extensions that solve very niche data [09:47] entry problems, fitness apps with an [09:49] interface exactly how the specific user [09:51] wants it. I've built all of these things [09:55] and more in just the last few weeks. [09:58] This is a massive shift. Software is [09:59] becoming a personal utility that you [10:01] generate rather than a commodity you [10:02] buy. This is a thing I think a lot [10:04] about. One of the craziest stats to [10:06] think about and I there is no way to [10:09] measure this sadly. How many times is [10:12] the average line of code run when you [10:15] are paid to write code in a real [10:16] codebase at work? How much do we expect [10:20] that code to run? This is a weird thing [10:22] to think about because it's not just [10:24] importance. When I was at Twitch, I [10:26] wrote some very important software that [10:28] only needed to run once for a migration. [10:31] I wrote some really important software [10:33] that only runs a few dozen times a week [10:35] because admins internally were using [10:37] those pieces of software. I also wrote [10:40] some things that really weren't too [10:41] important that run literally thousands [10:44] of times a minute because they are [10:46] facing users and there are millions of [10:48] those users. That all said, almost all [10:51] code that was being written was used at [10:54] least a few times and the average piece [10:56] of code, especially piece of code being [10:57] written by a professional developer, was [10:59] often run quite a bit. This is shifting. [11:02] The number of lines of code that are [11:04] being output in a given day has gone up [11:06] exponentially because these tools make [11:08] it so cheap to output code. And the vast [11:11] majority of that code will be run zero [11:12] to one times. The vast majority of it. [11:15] It is going to bring down the average [11:17] immensely. Doesn't matter that there's a [11:19] bunch of code that is run millions of [11:20] times a second if there are millions [11:22] more lines of code that are never run at [11:24] all. And this idea that a given piece of [11:27] code is being run way less is [11:29] fascinating to me. Another way of [11:31] thinking about it is given a specific [11:33] endpoint, what code runs. Traditionally, [11:36] when you hit an endpoint, there is [11:38] specific code bound to that endpoint. [11:41] There might be a switch statement or [11:42] something that chooses which sub code, [11:44] which functions run as a result of the [11:46] shape of the request. But the actual [11:48] payload, the binary that is executing [11:50] when you hit that endpoint is relatively [11:52] static until you ship a new update. I [11:55] think that's going to change too where [11:57] the average request is going to result [12:00] in code existing that might not have [12:02] before it. And that's a crazy idea. The [12:05] idea that a user can do a thing and the [12:07] result isn't that an existing binary is [12:10] executed to solve some problem, but [12:12] maybe the endpoint generates new code [12:14] specific to the shape of the payload. [12:16] that something new is created upon the [12:19] hitting of that endpoint. It's just a [12:22] weird inversion of how software's worked [12:24] our entire lives. That is just it's a [12:26] crazy thought to me. The closest thing [12:27] we've had before is I could send like a [12:29] payload of JavaScript text to an [12:31] endpoint that it would execute it and [12:33] send me a result. But the idea of an [12:35] endpoint no longer meaning a onetoone [12:38] binding with an existing piece of code, [12:40] an existing binary, and instead being [12:43] dynamic based on the shape of the [12:44] request and the user is just it's [12:46] [ __ ] with my brain a lot and I wanted [12:48] to talk about it here because it is [12:50] fundamentally different from how [12:51] software has worked all of our lives. [12:53] This idea that code is expensive enough [12:56] that a given endpoint should run the [12:57] code that we put all this time and money [12:59] into and that the average line of code [13:01] that a person's being paid to write is [13:03] valuable enough that we should be [13:04] holding it strong and maintaining it for [13:06] a long time. That's over. Now, this is a [13:09] huge fundamental change in how software [13:11] works that has been keeping I want to [13:13] say it's keeping me up at night, but [13:15] it's got me thinking in a very different [13:17] way than I have historically. from SAS [13:19] to scratch pads. This is another one of [13:21] those things I feel a lot where [13:23] historically I've been the guy who goes [13:25] and tries out the new SAS, tries out the [13:26] new database tool, the new framework, [13:28] all of those things. I'm not doing that [13:30] anywhere near as much anymore. When I [13:32] have an idea or I see something [13:33] interesting, I hop into my cloud code [13:36] directory on my computer. I just have [13:37] this CC sandbox where I whenever I have [13:40] an idea, I go screw with it and see what [13:42] comes out of it. It's been really fun to [13:44] play with. And instead of going to find [13:46] a solution online to a problem that I [13:48] have to go subscribe to and test out, I [13:50] just stick around in cloud code and it [13:51] works really well. In fact, I have it [13:54] building a full linear clone in Elixir [13:56] as an experiment in a Ralph loop in the [13:58] background that's been going for 21 [13:59] minutes and is still going. Excited to [14:02] see how that comes out. We're entering a [14:03] new era of software development where [14:04] the goal isn't always longevity. For [14:06] years, the industry has been obsessed [14:08] with building platforms and ecosystems. [14:10] Absolutely agree. The tide is shifting [14:12] now. It's towards something more [14:13] ephemeral. We're moving from SAS to [14:15] scratchpads. Yes, languages like Rust [14:18] were built for the name to Rust. The [14:20] point of Rust is that once you rewrite [14:22] something in Rust, you don't have to [14:24] worry about it anymore. Is it more [14:26] maintainable? Yes. But it's also way [14:29] more reliable and robust. And when you [14:31] write code properly in Rust, you don't [14:33] have to worry about it collapsing the [14:35] way other things do. Memory leaks, [14:36] probably not going to happen. weird [14:38] one-off runtime errors that you didn't [14:40] catch in the code. Probably not a thing [14:42] if you use all of the guards and the [14:44] checkers and things within the Rust [14:45] ecosystem properly. The Rust compiler [14:47] makes it way less likely you make the [14:49] types of mistakes that require software [14:51] to be iterated on and replaced. That [14:53] mattered a lot when software was [14:54] expensive. Now that it's cheap, it's [14:57] questionable if it matters at all. There [14:59] are certainly places where those things [15:00] matter, like in your kernel for your [15:02] system or in medical software or in [15:04] embedded systems that you can't change [15:05] the code for. But a random HTTP service [15:08] in Rust, come on. A lot of this new [15:11] software isn't meant to live forever. In [15:13] fact, it's the opposite. People are [15:14] increasingly building tools to solve [15:16] single specific problems exactly once [15:18] and then discarding them. I did this [15:20] four times the last two days. This is so [15:23] real. It's so cool realizing these weird [15:25] problems you have. Like I was setting up [15:27] a new Linux box, running a 5090 to do [15:30] some local inference stuff a few days [15:31] ago. Well, yesterday I built it. and I [15:33] was having a lot of annoying problems [15:35] getting it configured on the network. So [15:36] I spun up cloud code to go solve it and [15:39] ended up writing a bunch of scripts to [15:41] set it up itself because funny enough it [15:43] didn't have pseudo access. So it wrote [15:44] all of these scripts like thousand plus [15:47] line scripts to configure the exact [15:50] thing I wanted once so I could run one [15:53] command have my machine set up and then [15:55] throw away the code and never think [15:57] about it again. That's wild. That is [15:59] such a different way of doing things. I [16:01] never would have cared enough to do that [16:02] type of thing before. This is software [16:04] as a disposable utility designed for the [16:06] immediate now rather than the distant [16:07] later. What makes this viable today is a [16:10] specific technical philosophy. CLI first [16:12] interfaces, local data, and zero [16:14] onboarding. When you remove the friction [16:16] of signing up, configuring a database, [16:18] or navigating a complex UI, the cost of [16:19] creating a tool drops so low that [16:21] temporary becomes a feature, not a bug. [16:23] Yep. Like if you have to go learn a new [16:25] language or framework or tool or [16:28] ecosystem to try it out idea out or [16:30] solve some small problem, you're just [16:32] not going to if it's not big enough. And [16:34] the size of problem that's worth solving [16:37] with code has gotten way way smaller. [16:40] That's one of the coolest things. [16:41] Everybody has this threshold in their [16:44] head. Like if there are problems that [16:46] are large but easy to solve, obviously [16:48] you're going to try and solve them. If [16:50] there are problems that are difficult to [16:52] solve and not that big, you're obviously [16:54] not going to try and solve them. [16:56] Everybody has a line somewhere here. [16:58] Some people literally just do it [17:00] horizontally. I've seen this before [17:01] where there's a certain type of person [17:02] that doesn't really care about how hard [17:04] a problem is. They just care about how [17:05] much it bothers them. And if it bothers [17:07] them enough, they'll fix it no matter [17:09] how difficult it is. Somebody like [17:11] Lionus Torvalt is a good example here [17:12] where the problem of source code [17:14] management was annoying enough that he [17:16] decided to fix it. the problem of not [17:19] having access to Unix was annoying [17:20] enough that he decided to fix it. He [17:22] doesn't really think about how hard it [17:23] is. He just thinks about how much it [17:25] bothers him. There are also people who [17:26] are the opposite that they only think [17:28] about how difficult it is to solve. If a [17:30] problem is easy, it doesn't really [17:32] matter how big or small it is. They'll [17:34] just solve it anyways because it isn't [17:36] too hard for them to do. Most people [17:38] have a sliding scale more like this [17:39] though. Where as the problem gets more [17:42] difficult, the size of the problem has [17:44] to increase accordingly where everything [17:46] in this area here they are down to solve [17:49] because the size of the problem is [17:50] bigger than the difficulty. But [17:52] everything in this section here is less [17:54] likely to be solved because the problem [17:55] is annoying or tedious and the size of [17:57] it isn't very big. What's been fun for [17:59] me is this area of problems that aren't [18:02] very big but are hard enough that I [18:05] wouldn't bother with that's been [18:08] eradicated. This whole section here is [18:10] so fun to just vibe code it out. Like [18:12] when you're trying to transcode a bunch [18:14] of random old files or you're trying to [18:16] find a picture of your dog or you're [18:18] trying to reconfigure your Zish scripts [18:21] to do something different on your [18:23] machine. problems that maybe cost you a [18:25] few minutes every couple weeks that just [18:28] weren't worth dealing with before [18:30] suddenly can be solved. And what's [18:32] changing right now is the size of the [18:35] difficulty of the problems these tools [18:37] can resolve is just growing constantly. [18:40] Opus was arguably a shift where this [18:42] line went from here to like here. It's [18:45] hard to find the limit of what Opus [18:47] can't do given the right tools, the [18:49] right prompt, and the right set of evals [18:52] that it can use throughout its [18:53] development process. That's crazy. But [18:56] this is also why we're getting more and [18:57] more of these small one-off things and [18:59] why people are using these tools in such [19:01] cool ways to just solve a random problem [19:03] they have. I know I'm doing this a ton. [19:05] I've never written so much software that [19:06] I never bothered even putting in a git [19:08] repo. It's crazy to think that the [19:10] majority of the code I've written in the [19:12] past month, well written, is not even in [19:14] a git repo because I don't care because [19:16] it's just there to do one thing once. [19:18] I'm probably at like 50,000 lines of [19:20] code that I've just thrown away after [19:21] using it once in just the past couple [19:23] weeks. It's crazy. As Chris says here, [19:26] if it takes 5 minutes to spin up a [19:28] custom solution for a one-off task, you [19:30] don't need it to persist. You don't care [19:31] if you need it again in the future. You [19:32] just regenerate it the same way. Who [19:34] cares? The contrast with the traditional [19:36] SAS model is stark. SAS is inherently [19:38] built to optimize for retention, lock [19:40] in, and expansion. It's a business model [19:42] designed to keep you inside the [19:44] ecosystem in growing your footprint. [19:46] Bespoke tools, on the other hand, [19:47] optimize for immediiacy and control. [19:49] They don't care about your lifetime [19:51] value as a customer. They only care [19:52] about solving the task at hand. In many [19:54] ways, this is a return to how [19:55] spreadsheets were originally used. That [19:57] is such a cool comparison. Spreadsheets [19:59] are the start of so many incredible, [20:02] revolutionary things in software. One of [20:04] my favorite talks ever is Rethinking [20:06] Reactivity by Rich Harris. I still go [20:08] back to this every year or so, just to [20:11] let it break my brain again. And a huge [20:13] part of the intro for this video is [20:15] talking about spreadsheets and how [20:17] powerful they were, even when software [20:19] was still in really early days. And so [20:22] much what we're talking about now does [20:24] definitely remind me of the old [20:26] spreadsheet era in a really cool [20:28] nostalgic but also powerful way where [20:30] spreadsheets made computers go from this [20:32] thing that hardcore nerds could do like [20:35] silly games with and like solve some [20:37] complex math problems with into a useful [20:40] tool for day-to-day people. Managing the [20:43] invoices for their business or keeping [20:45] track of the schedule for their hair [20:47] salon. Spreadsheets made it possible for [20:49] anyone to do whatever they needed that [20:52] involved numbers and timings on a [20:54] computer without having to write [20:55] software and know how code worked. You [20:57] didn't open a spreadsheet to build a [20:58] permanent multi-year database, use it as [21:00] a scratch pad to reason through a [21:01] problem, calculate a result, and move [21:03] on. Yeah. In this new landscape, cloud [21:05] code is Excel for devs, a powerful, [21:07] flexible utility for solving immediate [21:09] problems rather than Shopify for [21:11] founders, which is built to be a [21:12] permanent foundation for a business. [21:14] It's about getting the job done than [21:15] letting the tool go. Absolutely agree [21:18] here. This is one of the piece I think a [21:19] lot of people are missing. If you happen [21:21] to be one of those people working on [21:22] problems that cloud code, codeex, [21:25] cursor, open code, whatever struggles [21:27] with even with the best models, I'd want [21:29] to see more cuz I just haven't seen much [21:31] there that isn't a prompting issue [21:32] honestly. But even if you are one of [21:34] those people in one of those spaces [21:36] where it's hard to use these tools to [21:39] solve real problems, there are people [21:41] there like Lionus Orvoltz, the creator [21:43] of Linux. That doesn't mean these tools [21:45] aren't useful to Lionus, though. In [21:46] fact, he's even been contributing to [21:48] code bases with them recently. Not the [21:50] code that matters for the actual [21:52] packages, but code for things like [21:54] visualizing his weird audio extension [21:56] thing that he's building. Code to [21:59] confirm the work you're doing works or [22:00] to test out a theory or to experiment [22:03] visualize. All these types of things [22:05] that used to be really annoying to do [22:07] went from really annoying to trivial, [22:10] especially in places that you might not [22:12] understand. Well, like if you're a web [22:13] dev or even a kernel dev that doesn't [22:15] know Python, well, using these Python [22:17] libraries is now trivial. But in order [22:19] to do that, you have to do this really [22:21] important thing that a lot of devs seem [22:23] to struggle with. Letting go. You have [22:25] to be okay with the fact that majority [22:27] of the code being written by you is [22:29] going to be thrown out. Most of it won't [22:32] even be run at all. Some of it will be [22:33] run once and then thrown away after. [22:35] It's a weird feeling, but once you get [22:36] over it, life gets way better. But this [22:39] is where the thesis of the article comes [22:41] in. Generating software quickly is one [22:43] thing. Making it survive contact with [22:45] the real world is a whole different [22:47] thing. Code is cheap. Software is still [22:49] expensive. Here's the reality of the [22:51] current AI native era. Code's become [22:53] cheap, but software remains incredibly [22:55] expensive. LMS have effectively killed [22:57] the cost of generating lines of code, [22:59] but they haven't touched the cost of [23:01] truly understanding a problem. We're [23:03] seeing a flood of these apps that were [23:04] built in a weekend, but most of these [23:06] are just thin wrappers around basic CRUD [23:08] operations and third party APIs. They [23:11] look impressive in a Twitter demo, but [23:13] they often crumble the moment they hit [23:14] the friction of the real world. I would [23:17] say this depends a lot on what the role [23:20] of the program is. Like we have [23:21] vibecoded a bunch of things for my [23:24] content channel. In particular, Ben is [23:26] going hard on rebuilding all of our [23:28] internal tooling for managing things [23:29] like which sponsors are on which videos [23:31] and how well are those videos [23:32] performing. That is more than holding up [23:34] to our real world test. Could that scale [23:37] to thousands of users? Maybe not. But it [23:40] is a piece of software that is resilient [23:42] that is on the cloud that we are using [23:44] every day without issue. So there's a [23:46] balance here again of like how many [23:48] users, how deep are the problems those [23:50] users are experiencing, how much variety [23:52] is there between the users and how does [23:54] the software we write scale against [23:56] that. But problems that are really [23:58] specific to you that don't need to have [24:01] these other considerations can be more [24:03] than real world ready. But it depends on [24:05] what world you're talking about. The [24:07] cost of software isn't the initial [24:08] writing. It's the maintenance, the edge [24:10] cases, the mounting UX debt, the [24:12] complexities of data ownership. These [24:14] fast solutions are very brittle. The [24:16] subscription tracker you vibe coded [24:18] breaks the moment a bank changes their [24:20] CSV export formats. The Chrome extension [24:22] dies the second a target website's DOM [24:24] shifts. The fitness app becomes unusable [24:26] as soon as a user needs robust offline [24:28] support or reliable data sync. For the [24:30] latter, use Convex. It helps a lot. On [24:32] that note though actually I think a lot [24:34] of these problems can be solved by [24:36] better tools to fix these things. Like [24:39] the CSV format change could be a in [24:42] between tool that will reformat the CSV [24:45] using AI or detect when the format [24:47] changes and adjust accordingly. Like the [24:49] these inputs and outputs being more [24:52] dynamic is a thing I expect to see in [24:54] the future where if an error rate is [24:56] detected on this input or output that it [24:59] can adjust the code accordingly [25:00] automatically. that I could absolutely [25:02] see happening and being really really [25:04] cool. Or things like offline support and [25:06] sync, those come down to the primitives [25:07] you're using to build the data layer. [25:09] And if those primitives evolve enough [25:11] that they work right out of the box, [25:13] these problems are solved just by using [25:15] the right tools. And more and more, I [25:17] think that's going to start happening. [25:19] Chris has been seeing lots of doomsaying [25:21] on Hacker News, Reddit, and Twitter [25:22] about the end of engineering. This [25:24] misses the point entirely. We aren't [25:25] witnessing the end of the profession. [25:27] We're entering a new era of it. I agree [25:29] here. I don't know what this will look [25:31] like long term though. Like how many [25:32] engineers do we need for this? What are [25:34] their data days like? Everybody asks me [25:36] what I think software dev will be like [25:37] in 2030. I don't know what it'll be like [25:39] in March. But I know it will be [25:42] different because it's very different [25:43] now than it was 3 months ago. And if you [25:45] haven't felt any differences, then you [25:47] haven't tried these things enough. The [25:48] value of an engineer shifting away from [25:50] the how of syntax and towards the what [25:52] and why of systems. Real engineering [25:54] lies in the abstractions and the [25:56] architecture as well as the [25:57] communications and the orchestration [25:59] across all of it. Like who is working on [26:02] what, when will it be done, what do we [26:04] expect from this. All of that is a a [26:06] skill that leaders have that traditional [26:08] programmers don't. And leveling up there [26:10] is super important. I just filmed a [26:12] video all about that about why senior [26:14] devs are liking these tools more. It's [26:15] all about knowing how to structure a [26:17] system that lasts, understanding why a [26:19] specific rate limiting strategy is [26:21] necessary, knowing how to manage a [26:23] distributed cache, and knowing exactly [26:24] when not to store environment variables. [26:27] Man, environment variables are possibly [26:29] like the single biggest problem a lot of [26:31] these tools have. That and [26:33] authentication, authorization, and all [26:35] of the layers around it makes all of [26:37] this more annoying than it should be. [26:38] I'm hopeful that we'll see leaps and [26:40] bounds type solutions that make this [26:42] stuff way better in the near future. [26:43] We're not there yet. A often feels [26:45] powerful because it hides the [26:47] complexity. But as an engineer, your job [26:48] is to manage that complexity, not ignore [26:50] it. The tools have changed, but the [26:52] fundamental requirement for engineering [26:53] rigor has never been higher. I don't [26:56] know if this will change or not. I've [26:57] been thinking about this a lot. Like if [26:58] the models get twice as good again, will [27:01] that rigor matter as much? I don't know. [27:03] I actually don't. Maybe the models don't [27:05] even need to get better. They just need [27:06] better tools to recognize when they're [27:08] doing things wrong or bigger context [27:09] windows to keep track of what they're [27:11] doing right. I don't know. But then we [27:13] have the distribution illusion. There's [27:15] a flip side. With the barrier to entry [27:17] gone, the noise level has reached an [27:19] all-time high. My feeds are currently [27:21] flooded with AI entrepreneurs claiming 5 [27:23] figure monthly recurring revenue numbers [27:25] for apps they built in an afternoon. [27:27] Most of these are [ __ ] and fail [27:28] super super fast. Even just today, I was [27:31] looking for ways to manage all of my [27:33] vibe coding stuff in parallel. And I [27:36] have been sent three options that seem [27:38] to have just appeared all at once. We [27:40] have autoclaude which lets you have a [27:42] cananban board for managing all your cla [27:44] code instances. Vibe canban which is [27:46] similar with open codeex [27:49] and all the other solutions too. And [27:51] automaker by webdev cody good friend in [27:54] other awesome YouTube channel worth [27:55] watching. He's ahead of us on a lot of [27:57] these things. He's almost perpetually 6 [27:59] months to a year ahead. He built this [28:01] with similar goals. These are all open [28:03] source projects that do roughly the same [28:05] thing that seem to have just appeared in [28:07] the past week or two. And this is going [28:09] to keep happening as more and more [28:11] people spin these out and distribution [28:13] is going to matter more and more. How [28:15] fast you can write code and how good you [28:16] can write code matters less and how far [28:18] you can distribute that code, how [28:20] relevant the thing is and feels and how [28:23] well you can communicate that to the [28:24] world matters more than ever. Also, good [28:26] to see you in chat, Cody. Hope you're [28:27] doing well. Seriously, go give Cody a [28:29] follow on YouTube if you haven't. If you [28:31] haven't subscribed to me, subscribe to [28:32] him first, then hit the sub button for [28:33] me. But he's so far ahead of this [ __ ] [28:36] But anyways, turns out the author [28:38] agrees. These claims are highly suspect. [28:40] When you see a creator with no existing [28:41] distribution and no clear moat claiming [28:43] 10K MR on a weekend project is usually a [28:45] play for engagement rather than a [28:47] reflection of business reality. Some of [28:49] these stories are probably true, but in [28:50] most cases, they aren't actually [28:52] blueprints for technical innovation. [28:53] They're marketing case studies. These [28:55] individuals succeed because they have [28:57] mastered the art of capturing attention [28:58] in a crowded landscape, not because they [29:00] have an AI co-pilot. Yep. These other [29:02] skills matter more and more. Again, I [29:04] just filmed this video and it's crazy [29:06] how relevant a lot of my points are now. [29:08] But the idea of capability being the [29:11] thing that matters for engineers just [29:12] isn't true anymore cuz AI has leveled [29:14] all of our capability up. What's [29:16] happening is people are realizing the [29:18] other parts matter more than they [29:20] thought before. If you don't have the [29:22] ability to be clear in what should be [29:24] built to delegate across these agents to [29:26] orchestrate the whole thing and then [29:28] explain to the world why it matters does [29:30] not matter how much code you can [29:31] generate. Previously, we would hold [29:33] these engineers up high because their [29:35] contribution charts were nuts, but [29:37] nothing they were doing was useful. If [29:38] you can't communicate the value of the [29:40] things you're doing and be very clear [29:42] and concise in why I should use your [29:43] thing, nothing else matters. And just [29:46] bumping your capability up a ton doesn't [29:48] solve any real problems. We've entered [29:49] an era where the ability to generate [29:51] code is no longer the bottleneck. The [29:53] real challenge has shifted to [29:54] distribution. Hi, good time to have a [29:56] YouTube channel, isn't it? By the way, [29:58] if you're building something really [29:59] cool, you raised money and you don't [30:00] know how to get it to people, my DMs are [30:03] open and you can get my email for [30:04] potential sponsorship stuff on my [30:06] YouTube channel very easily. YouTube [30:07] att3.gg. This is what I'm here for. More [30:10] importantly though, distinguishing the [30:12] genuine utility from the get-richqu [30:14] posturing that has become so prevalent [30:16] in the industry. I have done so much of [30:18] this for brands, like the majority of [30:20] the sponsors I bring on the channel, I [30:22] don't do an ad after they pay me, at [30:24] least not immediately. Most will [30:26] eventually do the ad, but I'll often [30:29] have to do three to six months of back [30:30] and forth with the brand, fixing their [30:32] onboarding, fixing their go to market, [30:34] helping them rebrand and structure the [30:36] pitch for their product. It takes a lot [30:39] of time to do that for some companies. [30:40] And it's crazy like almost half of the [30:43] brands I've worked with have through the [30:45] process of me refining the pitch rewrote [30:47] their whole homepage just to match a [30:49] better way of describing what they're [30:51] actually here for and why you should [30:53] care. The why you should care is a much [30:56] much more important question than ever [30:58] to answer because you have more [31:00] competition than ever. And if you have a [31:02] great idea that's hidden underneath your [31:05] inability to talk about it, somebody [31:07] like me can just come in, steal the [31:08] idea, vibe code alternative, communicate [31:11] it better, and put you out of business. [31:13] Being good at talking and describing why [31:14] your [ __ ] matters has never mattered [31:16] more. If a brand has me up to sponsor [31:18] and their product just isn't there or [31:20] their marketing just isn't good and I [31:22] don't know how to help them describe it, [31:24] it might be easier for me to just steal [31:26] the idea, go vibe code my own [31:27] alternative and sell that than it is for [31:29] me to teach the brand how to do [31:30] marketing. These people haven't stumbled [31:32] upon a secret shortcut. They've simply [31:34] found a way to execute their existing [31:35] advantage faster and they potentially [31:37] unlocked it in the first place if [31:38] learning to code was rightfully too big [31:40] an undertaking for a side project idea. [31:42] Here's where my hot takes are going to [31:43] come in. I don't think you could be [31:45] successful at selling software if you [31:48] aren't highly motivated. If your [31:51] motivation led to you becoming a great [31:52] programmer, awesome. If that motivation [31:55] is strong enough that it can now bring [31:57] you to learning how to communicate about [31:59] your ideas better and show people and [32:01] distribute the things you're building [32:03] better, awesome. But if coding was too [32:06] hard for you to learn, now you can code [32:08] for free. The rest is just as hard, if [32:11] not harder. explaining an idea concisely [32:14] took me as much time to learn as [32:16] JavaScript did. And if anything, I am [32:19] continuously learning with both, but I'm [32:21] learning more about communication and [32:23] clarity every day than I am about [32:24] [ __ ] JavaScript. And if you aren't [32:27] willing to sit there and learn those [32:28] hard things, you're not going to go [32:30] anywhere. If you learned how to code 10 [32:32] years ago, pushed through all that hard [32:34] stuff when you were motivated, and now [32:35] you've just been coasting for 10 years, [32:38] you're [ __ ] It's over. If you don't [32:40] have motivation, you're not going to go [32:42] anywhere. I felt this a lot because I'm [32:44] a content creator. I'm going to go down [32:46] a little bit of an anecdote here, but [32:48] it's one that's important to me. It's a [32:50] real interaction I had. We're going to [32:53] start this with a weird poll. You're in [32:55] a plane. Imagine you're flying [32:57] somewhere, passenger aircraft. The pilot [33:00] is suddenly incapacitated. They had a [33:02] heart attack. They fainted. Something [33:04] happened. Can you land the plane? Yes, [33:07] maybe or no. If you know how people [33:09] answer this, don't spoil in chat. I want [33:11] to see what you actually think. And you, [33:13] the viewer, too, think this in your [33:15] head. If you're on a Boeing 747 or some [33:18] [ __ ] pilot goes unconscious. Can you go [33:21] into the cockpit, assuming you have the [33:23] ability to go in, sit down, everything's [33:24] fine there? Can you land the plane? Less [33:27] than half of my audience is saying no. [33:30] Less than half. Here's the harsh [33:33] reality. If you're not already [33:34] certified, you're not going to land that [33:36] [ __ ] plane. They land themselves. No, [33:38] they [ __ ] don't. They do a lot of the [33:41] like specifics where like making sure [33:44] the right flap is down the right amount [33:46] based on your current velocity. It helps [33:47] with a ton of that. 99% of you won't [33:49] even get the [ __ ] radios working. [33:51] You're not going to land that goddamn [33:53] plane. The reason I asked this is [33:55] because most people assume they can do a [33:58] thing that is highly skilled if they had [34:01] the opportunity. Most people think they [34:03] could be a successful founder if only [34:05] they had enough followers on Twitter and [34:07] they knew how to code. Most people think [34:08] they'd be a great Google employee, but [34:10] learning to code is too hard. Most [34:12] people think they'd be a great YouTuber, [34:14] but editing video and OBS are too hard. [34:16] If only these tools were easier to use. [34:18] If only video editing was less [34:19] complicated, then everyone could be a [34:21] YouTuber. Cuz that's the hard part. Cuz [34:23] that's the first problem you ran into. [34:25] The radio thing even happens to an [34:27] extent here, too. If the airplane radios [34:29] were easier, everyone could land the [34:31] plane. No, you [ __ ] can't. Be [34:32] realistic here. 34 of men answer yes to [34:36] this question. Fun fact, the majority of [34:39] men think they can land the plane. I [34:42] bring this up because of a real [34:43] conversation I had would have been about [34:45] a year and a half, maybe two years ago, [34:49] where I was talking to a developer and [34:51] he said, basically, I'm looking to [34:54] diversify my income sources. I'm going [34:56] to pick up YouTube. any advice for me to [34:59] have a successful channel with as little [35:00] effort as possible? The way I raged, [35:04] I had multiple witnesses to the second [35:07] version of this conversation cuz he [35:08] followed up the next day, which is [35:09] really funny. I'm thankful I did cuz I [35:11] would have went [ __ ] insane [35:12] otherwise. Do you know what his [35:14] reasoning was for thinking he could do [35:16] this? Well, I kind of like cameras and [35:18] talking's pretty easy. I don't see why [35:20] it would be hard for me to be a [35:22] YouTuber. Seems like it's pretty easy [35:24] what you're doing, Theo. Yeah. So, where [35:27] this really fell apart was when I asked [35:29] him a quick question. What YouTube [35:31] channels do you watch? Do you know what [35:33] he answered to this? Honestly, I don't [35:35] watch YouTube very much. This [35:37] interaction has haunted me for 2 years. [35:40] Because this is how most people work. [35:41] This is how most people think. They [35:43] legitimately believe that whatever the [35:46] thing in front of them right now is [35:47] that's in the way is the only blocker. [35:49] And if they could just get that out of [35:51] the way, it'd be so easy. Like after [35:53] saying this, he didn't even let me start [35:56] to interrupt saying, "If you don't know [35:57] how YouTube works, this is probably [35:58] going to be hard." He as quickly says, [36:00] "I don't watch YouTube that much. What [36:02] editor should I start using?" Are you [36:04] joking? I just [36:08] Yeah, I don't know if you guys know this [36:11] about me. I watch a disgusting amount of [36:12] YouTube. When I'm not like at a [36:14] conference or in meetings all day, I'll [36:16] do six to eight hours of YouTube a day. [36:19] Like, straight up. I love the platform. [36:22] I love watching other creators. I watch [36:24] a shitload of YouTube. And I did that [36:26] for a decade and a half before I ever [36:28] thought to make a channel of my own. I [36:29] didn't even want to. My channel happened [36:31] accidentally because I was doing Twitter [36:34] spaces and wanted to show people in a [36:36] more visual way what my stack was. So, I [36:38] did a live stream and then reuploaded on [36:40] YouTube so I had something to link to. [36:41] And now I have this YouTube channel that [36:43] basically runs my life and my [36:45] businesses. This was not something I [36:46] chose to do. This is something I had to [36:49] do because I had specific other problems [36:50] I wanted to solve and all of those led [36:52] to me being here. None of the best [36:54] YouTubers chose to be a YouTuber. They [36:56] ended up here. Other things they wanted [36:58] brought them here. And this guy cared [37:00] too much about camera equipment and [37:02] video editing software to realize that [37:04] he didn't care about YouTube. It's just [37:06] insane to me. The reason I did the [37:08] airplane thing just now is because the [37:10] second time this guy had the [37:11] conversation with me, there was a camera [37:14] DP standing next to me. somebody who [37:16] came from the Hollywood world that [37:18] switched over to software dev who [37:20] overheard this whole conversation and [37:22] felt like he was going mad. As soon as [37:25] this person walked away, he pulled me [37:27] aside and was like, "What the [ __ ] Does [37:30] everybody just think that way?" Like, [37:32] how does somebody actually believe they [37:34] could just be a YouTuber when they don't [37:36] know anything about it? I asked at [37:37] first, "Do you think you could land an [37:38] airplane?" He's like, "Fuck no. Why [37:39] could I land an airplane? I did video [37:41] and now I do code." It's like, watch [37:43] this. And I went around the table and [37:45] asked every single person at the table, [37:47] "Do you think you could land a plane if [37:48] the pilot's incapacitated?" Every single [37:50] one said yes or maybe. Nobody else said [37:53] no. This is the delusion. It's kind of a [37:55] Dunning Krueger, but it's deeper than [37:57] that. Most people think that they would [37:59] be incredible at whatever thing they see [38:01] in front of them if only this random [38:03] thing directly in front of them wasn't a [38:05] little too hard to get over. Code [38:07] Bradley in chat here said, "As someone [38:09] who's been in marketing for 15 years, [38:10] everyone thinks they could be a good [38:12] marketer." Ready for a real honesty [38:14] moment from me? I didn't think I could [38:16] be. One of the first things I was [38:18] planning on hiring for for T3 tools, aka [38:21] ping, aka now T3 chat. I was planning on [38:23] hiring a marketer really early cuz I [38:25] didn't think I would ever be able to [38:27] build that skill. That and sales. Turns [38:29] out I'm okay at those things. Actually, [38:30] I would go as far as I'm pretty damn [38:32] good at those things. But I had to learn [38:34] those and scale up in them out of need. [38:36] I didn't go in thinking I could do it if [38:39] only my inbox was easier to manage. No, [38:42] I went in humbly expecting to suck at [38:44] the thing and slowly got good. So, all [38:47] of that was a tangent because I don't [38:49] necessarily agree that unlocking the [38:52] average person's ability to code is [38:54] going to push them past the next step. [38:56] If the friction of learning a video [38:58] editor or learning how to set up and use [39:00] OBS or figuring out what camera you [39:02] should use is enough to keep you from [39:04] being a creator, if I hand you solutions [39:06] to all of those problems, you're going [39:07] to be a [ __ ] creator still. If you're so [39:10] unmotivated that learning how to code [39:12] was too much friction for you to go do [39:13] the thing, you're going to be a [ __ ] [39:15] founder and marketer and business person [39:18] as well because there are just as many [39:20] hard friction points you'll hit. Many of [39:22] which are even harder when it comes to [39:24] marketing and distribution. You're just [39:26] you're not going to succeed there. If [39:28] you don't believe me here, then you [39:30] don't have a following yet. Go make a [39:31] Twitter account and get to 10,000 [39:33] followers. Hit me up when you're done. [39:34] There's a useful framing for this shift. [39:36] AI's effectively removed engineering [39:38] leverage as a primary differentiator. [39:40] Yes, this has been a weird one for me [39:42] because I have had a specific set of [39:43] edge skills that basically don't matter [39:46] anymore. The thing that made me a [39:48] valuable asset in my previous jobs was [39:50] that I could come in and take a project [39:52] that is way [ __ ] behind and get it [39:55] back on schedule without compromising on [39:57] quality or capability. I am really, [40:00] really good at taking a long road map, [40:02] figuring out what to cut and shift [40:05] around in order to make it actually [40:07] doable in a reasonable amount of time. [40:10] I've always been the ship fast guy, and [40:12] that doesn't matter anymore. I was a [40:15] very rare type of engineer before that [40:18] everyone can be now. Claude Code does [40:20] what I did at Twitch, faster, more [40:22] efficiently, and cheaper. And that's [40:23] wild to think about. That was a ton of [40:26] my leverage. I would just ship the [40:28] solution faster. If you can go prompted [40:30] in cloud code and get the solution out [40:32] just as fast, that doesn't matter [40:33] anymore. Thankfully, I've also leveled [40:36] up these other skills around marketing, [40:37] communication, distribution, [40:38] orchestration, all these other things [40:40] that matter even more. So, the fact that [40:42] I don't have a unique lever here anymore [40:44] barely even matters. But all of my [40:46] friends who worked this way too are [40:48] [ __ ] When any developer can use an [40:50] LLM to build and deploy a complex [40:52] feature in a fraction of the time it [40:53] used to take, the ability to write code [40:55] fast, especially is no longer the [40:57] competitive advantage it once was. It is [41:00] no longer enough to just be a builder. [41:02] Couldn't agree more. Instead, success [41:04] now hinges on factors that are much [41:06] harder to automate. Taste, timing, and [41:09] deep intuitive understanding of your [41:11] audience matters way more than ever. You [41:13] can generate a product in a weekend, but [41:15] that is worthless if you're building the [41:17] wrong thing or launching it to a room [41:19] full of people who aren't listening. [41:20] Yep. Or even better, an empty room, [41:22] which is what most of y'all do, and then [41:24] you complain that the algorithm is so [41:25] bad. If only the algorithm was better. [41:27] Everyone would know about my slop app. [41:30] Good luck with that. In this new [41:31] environment, the code has become the [41:33] easy part. The hard part remains exactly [41:34] where it's always been, finding a way to [41:36] get people to care. Another way of [41:38] framing this is that previously code was [41:41] hard enough that you needed a lot of [41:43] coders once you had someone in something [41:46] that was worth caring about. If it turns [41:48] out Twitch is worth caring about, it [41:50] takes a lot of engineers to build all [41:52] the pieces. So for every one person who [41:54] understands this and cares enough about [41:56] this to do all of the other parts, you [41:58] need a team of 10 to 20 engineers to do [42:01] the rest. Now that that part isn't as [42:03] important or at least it's not as [42:04] important in the same ways as it was and [42:06] is much easier to automate. The hard [42:08] part still exists, but if you're just an [42:11] edge, you just are the accessory to the [42:14] leaders who are actually getting the [42:15] thing out there. You're useless now to [42:18] an extent. And that sucks. And this is [42:20] where I think a lot of the insecurity is [42:22] coming from is that 20 to1 ratio of 20 [42:26] good engineers to one person who [42:28] understands the thing that they're [42:30] building. That ratio went from 20 to one [42:32] to like one here. So when I was the [42:35] other 19 engineers, I don't know. I'm [42:37] not trying to hire them. So who wins [42:39] here? First, you'll have domain experts [42:41] who are stuck with boring, repetitive [42:43] problems. Then there are internal teams [42:45] building throwaway tooling, the kind of [42:46] scripts and internal apps that need to [42:48] work immediately rather than look [42:50] perfect. There are whole billion dollar [42:52] companies that were built just around [42:53] this. My co-founder Mark, my CTO, was [42:56] working at Retool before he joined my [42:58] company. Retool was a way to build much [43:00] easier internal dashboards that access [43:03] data across all the different places [43:04] that your company might have data from. [43:07] So some internal support team that needs [43:09] better visualizations of how much usage [43:11] a user has on their account when they're [43:13] doing support, some random person on [43:15] that team that's not even an engineer [43:16] can whip up something in retool to [43:18] manage it. Now with vibe coding, all [43:20] these other things, the ability for a [43:22] company or even an individual to do the [43:24] same thing reduces the value of a tool [43:26] like retool. They got to a very very [43:29] high valuation very very fast because [43:31] preai everyone needed [ __ ] like this. [43:34] They were getting contracts with [43:35] everyone from like Philips and Pinterest [43:37] to stripe and Amazon which is a wild [43:39] range. But now barely matters. They are [43:42] trying desperately to catch up with all [43:44] these other AI alternatives that now [43:45] exist. That market is huge huge enough [43:48] for retool to become a multi-billion [43:49] dollar company. It's also addressed well [43:52] enough now for retool to be struggling [43:53] to survive. Power users also see a [43:56] massive gain here, particularly when [43:57] they are looking to replace brittle [43:59] manual workflows with something more [44:00] robust. Finally, it's a win for those [44:02] engineers who prioritize ownership of [44:04] the solutions over high gloss polish. [44:07] And yes, tools like Opus 4.5, Claude [44:10] Code, and Cursor are genuinely useful [44:12] for engineers. They are remarkably good [44:14] at removing boilerplate, implementing [44:15] features, and writing unit tests. One of [44:17] my favorite use cases lately, especially [44:19] since starting a new job, is generating [44:21] personalized documentation and [44:23] walkthroughs of features to get up to [44:25] speed on product code bases and how all [44:27] the nuances work. It's been extremely [44:29] helpful in getting up to speed. Yeah, [44:31] it's so nice having AI that can [44:33] understand a large codebase well enough [44:35] to give you useful insights. But here's [44:38] the reality. LMS are far from perfect at [44:40] writing code, even if it compiles first [44:42] time. Even with the high quality [44:44] prompting and clear rules, these models [44:45] will still make mistakes. Speaking as [44:47] someone who uses these tools every day, [44:48] you cannot simply trust the output [44:50] outright. You still have to review the [44:52] code as if it were a poll request from a [44:53] teammate. You have to read the logic, [44:55] check the assumptions, and often make [44:56] manual edits to get it right. I am [44:58] starting to drop this part. I'll just [45:00] tell the model what it did wrong, and it [45:01] will fix it. And I am suspicious that [45:03] the amount of this will go down more and [45:04] more, especially again to go back to my [45:06] chart earlier. If the problem size is [45:09] small enough, I'm not going to bother [45:10] reading that [ __ ] code. If the [45:12] problem of size is big enough and the [45:14] difficulty is big enough, I'll probably [45:15] take the time to read the code. But it [45:17] varies and how you think about these [45:19] things will vary a lot. After all, [45:21] you'll likely be sending this to a [45:22] teammate for review and maybe Code [45:24] Rabbit, I guess. Okay, to be clear, [45:25] tools like Code Rabbit, Grappile, all [45:27] these AI code reviews. Do those before [45:29] you send it to your teammate because [45:30] they will catch small annoying mistakes [45:32] that your teammate shouldn't be dealing [45:33] with. I know those companies sponsor me. [45:35] I don't care. They're super [ __ ] [45:37] useful. AI code review is a way to not [45:39] waste your team's time doing a code [45:41] review. Super useful. Your teammates [45:44] still should review the code, [45:45] absolutely, but they shouldn't be [45:47] reviewing it for small syntax mistakes. [45:48] They should be reviewing it for [45:49] understanding of the codebase for [45:51] reducing bus factor and making sure what [45:53] you're doing is aligned with the goal of [45:55] what needs to be done. AI isn't great at [45:57] that, but it'll catch all your stupid [45:58] [ __ ] syntax and weird one-off errors [46:00] much better than a human will. Don't [46:02] waste the people's time with that [ __ ] [46:03] This is a really good question. Is it [46:05] fair to make them review something you [46:06] didn't even write or bother to check? [46:08] Humans, no. AI, absolutely. Letting an [46:11] AI review code that an AI wrote is [46:13] awesome, and you should absolutely do [46:14] that. These tools help you move faster, [46:16] but they do not replace the need for a [46:18] critical eye or your years of [46:19] experience, and they do not understand [46:21] the overall problem space better than [46:23] you. The hype makes it look like we're [46:24] entering a golden era of SAS. We aren't. [46:27] We're entering an era of personal [46:29] software, tools you generate to solve a [46:31] problem, and then move on. With $20, a [46:33] few hours of spare time and a bit of [46:35] patience, almost anyone can ship a [46:36] functional app. We're entering the era [46:38] of personal software, where the gap [46:40] between an idea and a working product is [46:42] narrower than it's ever been. In this [46:43] new reality, engineering expertise [46:45] remains incredibly valuable, but the [46:47] nature of the role is shifting. [46:48] Relevance is not fading. Instead, it's [46:50] about leveraging these tools to build at [46:52] a higher level than was previously [46:54] possible. True expertise is now required [46:56] to steer these systems and provide the [46:58] technical oversight that LM lack. While [47:00] AI is undeniably good at writing code, [47:02] it remains poor at architecting, [47:04] maintainable, distributable, and [47:06] scalable systems. This is where [47:07] nontechnical leaders who think they can [47:09] fire their development teams are making [47:10] a significant mistake. Until we see the [47:12] arrival of an artificial intelligence [47:13] that renders this entire discussion [47:15] moot, believing that technical expertise [47:17] can be replaced by a prompt is a [47:18] strategic error. I fully agree here. [47:21] Building robust software still requires [47:22] a human who understands the underlying [47:24] principle of the craft. A different way [47:25] of framing this. Hard problems are still [47:28] hard and motivating yourself through [47:30] them is the key. A highly motivated vibe [47:33] coder that will take the time to figure [47:35] out why their things are breaking and [47:36] learn them will be way more valuable [47:38] than an experienced engineer who's kind [47:41] of checked out and is just not paying [47:43] attention to the code they're merging. [47:45] Motivation is going to be the key [47:46] differentiator. Do you care enough to [47:48] skill up in the areas you don't know? [47:50] Because if you're willing to sit there [47:52] and ask endless questions to the AI to [47:54] figure out where your knowledge gaps [47:55] are, figure out what might be going [47:57] wrong and try all these different [47:58] theories, the patience and diligence and [48:01] like resilience is going to matter more [48:03] than ever. And if you're already burnt [48:04] out, you're [ __ ] You're absolutely [48:06] [ __ ] If you can't find excitement in [48:09] what these tools enable, you just feel [48:11] frustration and tired, you're probably [48:14] not going to survive this transition. [48:15] You need to have the motivation to push [48:17] through. You don't just need the skills. [48:19] I would argue you could build the [48:21] technical expertise faster than ever [48:22] with enough motivation, but you can't [48:25] get that motivation by just having the [48:28] expertise. The bottom line is that while [48:30] the tools have changed, the fundamentals [48:31] of good engineering have not. While [48:32] barrier to entry may be gone, judgment, [48:34] taste, and responsibility are still the [48:36] job. Absolutely agree. This was a [48:39] fantastic article. I know I didn't agree [48:40] with all of it, but the framing was [48:42] incredible and the majority of it is [48:44] more than on point. I have a feeling [48:46] I'll be keeping a close eye on Chris and [48:48] the other things he does. Turns out he's [48:50] also a big Elixir and Live View fan. I [48:52] love Elixir, so hyped. In fact, as I [48:54] mentioned before, this whole time I have [48:56] been running this gigantic project in [48:58] the background, which looks like it [48:59] actually finished in 35 minutes and 50 [49:01] seconds. So, I'm going to go play with [49:02] that. I got nothing else to say here. [49:04] Stay motivated, keep building, keep [49:06] doing cool [ __ ]  ## 📺 Video ![](https://www.youtube.com/watch?v=28z6OjsNsUk) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: What happens now? The Shift from Expensive Code to Disposable Software ## 🧰 Action Inbox - [H1] Experiment with disposable software approach — try building one-off solutions instead of seeking SaaS #experimentation - [H2] Develop communication and distribution skills — focus on why software matters, not just how it works #career-development - [H3] Practice orchestration mindset — treat AI tools like team members to coordinate #ai-tools ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Chris Gregory's article](URL) - referenced inspiration for the discussion - [SpaceTime Database](https://spacetime.link/) - featured sponsor - [t3.gg](https://t3.gg) - Theo's website ## 📝 Summary - **What happened**: AI code generation tools (Claude Code, Cursor, OpenCode) have made writing code extremely cheap, shifting the software development paradigm from expensive, permanent solutions to disposable, single-use tools - **Why it matters**: This represents a fundamental change in how software is created and used - similar to when compilers abstracted away assembly code - where the barrier to creating software has collapsed but distribution and communication have become more critical - **Key stakeholders**: Software developers, founders, businesses using internal tools, content creators, and anyone building digital products - **Risks and tradeoffs**: While code generation is now trivial, most generated code runs zero to one times; engineering skills are shifting from coding ability to system orchestration and communication - **Bottom line**: Code became a commodity, but software value now depends entirely on solving real problems and effectively communicating that value to users ## 📖 Main Content The fundamental economics of software development have shifted. Where code was once expensive and carefully maintained, AI tools have made code generation so cheap that most code is now written once and discarded. This creates a new category of "disposable software" - tools built to solve immediate, specific problems rather than long-term platforms. The shift parallels historical transitions like the move from assembly to higher-level languages. Just as compilers abstracted away low-level details, AI tools are abstracting away the mechanics of coding itself. However, this doesn't eliminate the need for engineers - it transforms their role from code writers to system architects and orchestrators. The real bottleneck has moved from technical implementation to problem identification, communication, and distribution. Tools like Claude Code function more like "Excel for developers" - powerful utilities for immediate problem-solving rather than permanent infrastructure. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/28z6OjsNsUk?t=0) — [H1] The fundamental shift in code economics - Key idea: Code has historically been expensive, requiring large teams of well-paid engineers - Evidence: "Code has always been really expensive... That's why so many companies had to employ such a large number of expensive engineers" #### ⏱️ [02:30](https://youtu.be/28z6OjsNsUk?t=150) — [H2] Code abundance vs software scarcity paradox - Key idea: Code is now prolific but software has become more expensive than ever - Evidence: "Code is now prolific. There is more of it than ever. But software... has become as if not more expensive as a result" #### ⏱️ [04:15](https://youtu.be/28z6OjsNsUk?t=255) — [H1] Historical parallel to compiler revolution - Key idea: This shift mirrors the transition from assembly to high-level languages - Evidence: "This is similar to when compilers happened where all of a sudden code wasn't this really hard to reason about stuff" #### ⏱️ [07:00](https://youtu.be/28z6OjsNsUk?t=420) — [H2] The rise of disposable software - Key idea: Software no longer needs to be built for longevity - single-use tools are now viable - Evidence: "Programs that weren't worth writing before because the use case was too small and the effort was too high now are absolutely worth it" #### ⏱️ [12:45](https://youtu.be/28z6OjsNsUk?t=765) — [H1] Shift from execution to orchestration - Key idea: Senior developers excel with AI tools because they're used to orchestrating people - Evidence: "Claude code just feels like another person that you're orchestrating that is way more capable but way less good at planning" #### ⏱️ [18:30](https://youtu.be/28z6OjsNsUk?t=1110) — [H2] Most code runs zero to one times - Key idea: The average usage per line of code is plummeting due to disposable software - Evidence: "The vast majority of that code will be run zero to one times. The vast majority of it" #### ⏱️ [22:15](https://youtu.be/28z6OjsNsUk?t=1335) — [H3] Dynamic code generation per request - Key idea: Future endpoints might generate new code for each request rather than executing static binaries - Evidence: "The idea that a user can do a thing and the result isn't that an existing binary is executed... but maybe the endpoint generates new code specific to the shape of the payload" #### ⏱️ [28:00](https://youtu.be/28z6OjsNsUk?t=1680) — [H2] Lowered threshold for problem-solving - Key idea: The size of problems worth solving with code has dramatically decreased - Evidence: "The size of problem that's worth solving with code has gotten way way smaller" #### ⏱️ [33:45](https://youtu.be/28z6OjsNsUk?t=2025) — [H1] Excel for developers analogy - Key idea: AI coding tools are like Excel - flexible utilities for immediate problem-solving, not permanent foundations - Evidence: "Cloud code is Excel for devs, a powerful, flexible utility for solving immediate problems rather than Shopify for founders" #### ⏱️ [38:20](https://youtu.be/28z6OjsNsUk?t=2300) — [H2] The brittleness problem - Key idea: AI-generated solutions often break when they encounter real-world complexity - Evidence: "The subscription tracker you vibe coded breaks the moment a bank changes their CSV export formats" #### ⏱️ [42:10](https://youtu.be/28z6OjsNsUk?t=2530) — [H1] Distribution becomes the new bottleneck - Key idea: With code generation democratized, the ability to reach and communicate with users is the limiting factor - Evidence: "We've entered an era where the ability to generate code is no longer the bottleneck. The real challenge has shifted to distribution" #### ⏱️ [48:30](https://youtu.be/28z6OjsNsUk?t=2910) — [H2] The airplane landing delusion - Key idea: Most people overestimate their ability to succeed at complex tasks if given basic tools - Evidence: "34% of men answer yes to this question... the majority of men think they can land the plane" #### ⏱️ [55:15](https://youtu.be/28z6OjsNsUk?t=3315) — [H1] Motivation still required for success - Key idea: If learning to code was too difficult before, the remaining challenges of building successful software will be equally daunting - Evidence: "If coding was too hard for you to learn, now you can code for free. The rest is just as hard, if not harder" #### ⏱️ [58:45](https://youtu.be/28z6OjsNsUk?t=3525) — [H2] The 20:1 ratio collapse - Key idea: The ratio of engineers needed per product visionary has dramatically decreased - Evidence: "That ratio went from 20 to one to like one... So when I was the other 19 engineers, I don't know. I'm not trying to hire them" ## 📚 References - [Chris Gregory's article on code vs software costs](URL) - [SpaceTime Database](https://spacetime.link/) - [Rethinking Reactivity by Rich Harris](URL) - [Theo's YouTube channel](https://youtube.com/t3dotgg) ## 🗣️ Paraphrase - AI has made writing code extremely cheap, but this has paradoxically made good software more expensive because the real value lies in understanding what to build and communicating why it matters - We're moving from a world of permanent software platforms to disposable, single-use tools that solve immediate problems and are then discarded - The role of engineers is shifting from code writers to system orchestrators who manage complexity and communicate value, similar to how compilers shifted focus from assembly details to higher-level logic ## 📰 Newsletter 🚀 **The Great Code Commodity Shift is Here** AI tools like Claude Code have fundamentally changed the game - code generation is now virtually free, but that's created a fascinating paradox. While anyone can now build software in minutes, the real challenge has shifted to distribution and communication. **What This Means for WordPress Developers:** - Focus on understanding user problems deeply rather than just implementation details - Develop skills in system architecture and project orchestration - Master communication - explaining why your solution matters is now more valuable than how you built it The future belongs to developers who can bridge the gap between technical possibility and human need. Start experimenting with AI-assisted development, but invest equally in your ability to identify real problems and communicate solutions effectively. **Key Takeaway:** Code became a commodity. Problem-solving and communication became premium skills. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create content showing AI-assisted WordPress development workflows, measure engagement on disposable software concepts - Education: Design workshops on prompt engineering for WordPress-specific tasks, office hours for AI tool adoption - Developer experience: Document AI-friendly APIs, create scaffolding tools that work well with code generation - Developer marketing: Campaign around "WordPress + AI" positioning, content strategy for post-code world - Community management: Survey developers on AI adoption fears, moderate discussions on industry changes #### OSPO - Policy & Governance: Develop policies for AI-generated code contributions, licensing implications - License Compliance: Create scanning processes for AI-generated code, train on provenance tracking - Security Management: Establish vulnerability processes for rapidly-generated code, attestation frameworks - Software Inventory: SBOM strategy for disposable software, ownership tracking for ephemeral tools - Developer Support: AI tooling recommendations, consultation on orchestration approaches - Community Engagement: Fund AI accessibility tools, agreements with tool providers - Strategic Alignment: KPIs for AI adoption impact, OKRs around developer productivity shifts #### Community - Maintainers: Templates for AI-assisted project governance, roadmap support for tool integration - Contributors: Onboarding programs that include AI workflow training, first-issue programs with AI assistance - Sponsors: Transparent budgets for AI tooling costs, impact reports on productivity gains - Ecosystem: Cross-project coordination on AI tool standards, shared prompt libraries #### WordPress - Core: AI-assisted contribution workflows, issue triage automation, performance budget enforcement - Core Performance: AI-driven profiling analysis, automated optimization suggestions - Core AI: Integration guardrails for AI features, evaluation sets for WordPress-specific use cases - Core Program Team: Coordination tools for distributed AI-assisted work, retrospectives on tool adoption - Mobile: AI-assisted mobile app development workflows, automated testing approaches - Playground: AI-powered learning labs, reproducible environment generation - Community: AI-assisted meetup content generation, WordCamp talk suggestion systems - Training: AI-enhanced lesson plan creation, personalized learning path generation - Marketing: AI-assisted campaign development, automated social content creation - Support: AI-powered response suggestions, knowledge base enhancement automation - Design: AI-assisted UX audit tools, automated design token generation - Documentation: AI-enhanced content generation, automated gap analysis - Photos: AI-assisted content moderation, automated tagging systems - TV: AI-generated captions, automated content indexing - Polyglots: AI-assisted translation workflows, automated glossary consistency - Accessibility: AI-powered WCAG compliance checking, automated audit tooling - Meta: AI-enhanced .org roadmap planning, automated API reliability monitoring - CLI: AI-assisted command generation, automated scaffolding improvements - Hosting: AI-powered hosting optimization recommendations, automated performance monitoring - Tide: AI-enhanced code quality scoring, automated plugin improvement suggestions - Openverse: AI-assisted content moderation, automated metadata enhancement - Themes: AI-powered theme review assistance, automated mentoring content - Plugins: AI-enhanced security analysis, automated provenance verification #### The WPCC - Programs: AI-assisted fellowship matching, automated microgrant evaluation, productivity-based stipends - Projects: AI-enhanced governance templates, automated documentation generation - Funding: AI-assisted grant matching, automated milestone tracking, transparent ledger automation #### FAIR - Technical independence: AI-assisted metadata generation, automated provenance verification - Policies: AI-transparent funding decisions, automated anti-capture detection - Governance artifacts: AI-assisted charter generation, automated operator agreement compliance ## 🧪 Hypotheses - Organizations that invest in communication and distribution skills will outperform those focused solely on technical AI adoption - The average lifespan of software projects will decrease dramatically as disposable software becomes the norm - Engineers who develop orchestration mindsets will remain valuable while pure coders become commoditized - Distribution channels (social media, content creation, community building) will become more valuable than technical skills ### 📊 Methodology - Study design: Track productivity metrics before/after AI tool adoption across different developer skill levels - Data sources: GitHub commit patterns, project completion rates, developer survey data on time allocation - Experiments: A/B test projects with AI-assisted vs traditional development approaches, measure long-term maintenance costs ### ❓ Questions - Will the quality of software improve or degrade as the cost of creating it approaches zero? - How will software security evolve when most code is generated rather than carefully crafted? - What new business models emerge when code generation becomes a commodity? ### 🔮 Future Research - Long-term impact study on software quality and maintainability in the AI-assisted development era - Analysis of changing skill premiums in the software development job market - Investigation of new software distribution and discovery mechanisms for disposable software ### 💡 Implications - **Practice**: Daily development workflows must incorporate AI orchestration and communication skills alongside technical abilities - **Policy**: Organizations need new governance frameworks for AI-generated code quality and security - **Security**: Rapid code generation creates new attack vectors and requires automated security scanning approaches - **Education**: Computer science curricula should emphasize system design and communication over syntax and algorithms - **Funding**: Investment priorities should shift toward teams with strong distribution capabilities rather than just technical depth ### 🧠 Learning Styles Assessment Reading level estimate: 10-12 (College level, technical content with accessible explanations) #### 👀 Visual learners - Present: Charts and graphs showing productivity shifts, architectural diagrams - Improve: Timeline visualizations of the coding paradigm shift, infographics comparing traditional vs AI-assisted workflows #### 🔊 Aural learners - Present: Full video discussion format with detailed verbal explanations - Improve: Podcast version focusing on key concepts, audio summaries of main points #### 🗣️ Verbal learners - Present: Clear definitions, analogies (airplane landing, Excel for developers), extensive examples - Improve: Glossary of terms, more story-driven case studies #### 🧩 Kinesthetic learners - Present: --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=28z6OjsNsUk)* **[00:00]** Over the last few decades, code has always been really expensive. It's gone down some amount from when we were doing punch cards back in the day. But for the most part, code has been an expensive thing. That's why so many companies had to employ such a large number of expensive engineers. It's why we were all pressured to go to college to learn how to code so that we could make the margins work a little better for those companies. That's why we've heard of all these crazy salaries being taken home by these people throughout our entire lives for the most part. I still remember back in high school where I was pitched this concept of Google being the coolest **[00:30]** place in the world to work. And here we are today and everything is changing. Code is no longer this super expensive thing that we don't have a lot of. If anything, code is now prolific. There is more of it than ever. But software, the thing that we actually want the code to provide for us, has become as if not more expensive as a result. It is really weird to see this shift happening in real time. Yes, this is an AI thing, but it goes deeper than that. The software we use is fundamentally changing because the code underneath it is too. I'd go as **[01:01]** far as to say this is similar to when compilers happened where all of a sudden code wasn't this really hard to reason about stuff that was weird syntax managing memory. C made it so you could write code that was a much easier thing to understand as a human. And we stopped thinking about the assembly code over time. I think we're going in the same direction with software as well, where the software is the thing we care about, but the code underneath matters less and less. I just saw this article written by Chris and inspired me to go deep on this topic. It's a thing I've been thinking a lot about. The higher level of the **[01:32]** things we use matters more than ever, but the details are starting to matter less. This hurts me as a developer who cares a lot about software, but it also excites me as a person who cares about the experiences that they use every single day. Do you know what you should be using though? today's sponsor. Guys, it's 2026. Why are we still writing our databases like we're in the 90s? Why are we running a SQL database so far away from our own servers that we can't trust it to do fast stuff? How would we handle it if we wanted to do a real-time experience like people sharing cursors on the screen or a multiplayer game? Why **[02:03]** is our database such a limiting factor in all of these things? Well, the reason is that you haven't tried today's sponsor yet, SpaceTime. These guys are from the game industry. They know how to make things that are performant with insane amounts of throughput for small sets of users and big ones, too. They put a ton of time into building a database platform to run their MMO and realized it's useful outside of their game. And then they realized it's useful outside of gaming. And here we are today with them shipping a full TypeScript client as well as Rust and C#, by the way, so that you can write TypeScript code that will run on the same box that **[02:35]** the data is on. That just changes the dynamics of everything. We're talking about paradigms where a user can just have their cursor's location written to the database and everyone else can see it with sync, by the way, without having to do anything special at all. Things that you would normally never do because it will hose the database just don't matter with a model like this. Write your table definitions in Typescript, which is awesome. It gives you full stack type safety, too. As you guys know, I love that. You can then create reducer functions. And funny enough, the default language is Rust. Just click the TypeScript button, and you can see it's literally five lines of super simple Typescript. We have our table. We then **[03:07]** have our reducer where a user can now insert a new user with an ID and a name. You can even identify the sender to know who is the one who is hitting this thing because again these queries can face users directly. They can just query and mutate the data in the database and the code in the database are the same thing. So it all flies. They even have a React library that works fully with their O platform. Pretty cool thing to have for a database that's much more focused on the lower level stuff. But that's part of what makes FaceTime magical. They built these rocksolid super performant primitives so that you can build a scalable super performant application. **[03:38]** It's one of those products that unlocks things you could never have built before. And honestly, I'm so excited to go build with it myself. Check them out now at sidv.link/basetime. Huge shout out to Chris Gregory for letting me read this article and use it as a reference point for the stream and video. I'm super excited to dig in. This is a thing I've been thinking a lot about, and it's such a good way of framing it, too. The barrier to entry for building software has collapsed. The barrier to building something that matters hasn't moved an inch. Yep. Cloud Code and Opus 4.5 have poured fuel on the hype. LM tools existed before, but **[04:08]** they're better than ever now. So, a lot more people are paying attention. But we're not entering a golden age of SAS. We're entering an era of personal disposable software, where engineering shifts from writing code to shaping systems, and engineers are still required for exactly that reason. This disposable software piece in particular is something that's really exciting to me. Programs that weren't worth writing before because the use case was too small and the effort was too high now are absolutely worth it because building it is cheap. The thing that's expensive is figuring out what exactly you want **[04:39]** and specking it out. If you can write down a markdown file what exactly you want, you can get the code much easier now, which is super cool. The shift in modern development. Cloud code is taking over my feed right now. Open code more so mine, but I feel you for sure. What's interesting isn't just that devs are jumping on it. it's that builders and makers who previously relied on platforms like lovable or replet are migrating to it. I don't necessarily agree there. I think what's much more interesting is that senior and experienced developers are starting to embrace it too because they are both seeing the value of these disposable **[05:10]** pieces of software. And also they are so used to orchestrating people that claude code just feels like another person that you're orchestrating that is way more capable but way less good at planning and figuring out what it wants to do. Lovable and replet are still totally viable for shipping fast. But we're seeing a clear shift as people rediscover the inherent beauty of a CLI first workflow. When you move the interaction into the terminal, the abstraction layer thins out. You aren't just following a managed UI's happy path. You're the one in control. Eh, I feel like, especially now that I'm **[05:40]** hopping between the different CLI tools, I feel more restricted than ever. Even something as simple as typing in the interface sucks. option delete does something different between cla code and open code and it's so annoying. Just for an example quick, I'm gonna open up open code and claude code in a random directory. I'm going to type something. Then I'm going to do a new line, something else, another thing, and start typing one more thing. Watch what happens when I press option delete. It deletes the new line. It should only **[06:12]** delete to the last alpha numeric. So, if I do something like this, the option delete should stop at the end of the kebab casing. It doesn't always do that. And I'm command- zinging right now, and it doesn't bring it back. Whereas here, option delete keeps me on the new line like it should. It doesn't delete the new line. And if I command Z, oh no, Command Z also doesn't work here. That's annoying. Yeah, I hate all of this. I just want a real input box so badly. I know terminals better than most people. I have been a T-Mux person since I was **[06:44]** literally 14. Well, I was a GNU screen person because I'm old enough that I was a GNU screen person and now I'm a T-Ux person. I'm trying to wean myself off it and it's been really, really tough. That all said, when I'm writing things with multiple lines, which is very often with these tools, I hate using the terminal as my input. It's just bad. And a part of why it's weird in open code is they're using the alternative view mode in the terminal, which means they're not using the standard buffer. And the standard buffer is what gives you these standard behaviors. They have to reimplement all of those behaviors in **[07:15]** open code in order for it to behave well. That's also why their UI is so much better than cloud code because they're not just writing into the standard buffer. But it means that weird things I'm used to behaving certain ways in my terminal have to be manually re-implemented. And I don't feel in control as a result. I don't feel like I have this level of control of my instances the way I do in more traditional software. That said, I have been using the CLI things a lot more and they're cool as hell. I just don't necessarily agree with the point that the CLIs are giving you this level of **[07:45]** full control. This is the part I care a lot more about though. The collapse of the barrier to entry. What are people actually building with these tools? If you look around, the answer is almost everything. Even just sty shipping is absurd. Pete already had his hundred million dollar exit from a big company, so he doesn't have any traditional reason to care a whole lot about what can make money, but he isn't letting that slow him down. He's putting out more software than ever, and it's all entirely free and open source, and there's so much cool [ __ ] in here. **[08:15]** Claudebot's the one that's taking the world by storm. A personal favorite of mine is Codex Bar, which should be somewhere in here. Oh, it's number three there now. It used to be lower. Codex bar is how I keep track of my remaining rate limits across all of my different subscriptions for AI stuff. Super cool. The amount of [ __ ] Pete has shipped in just the last few months is absurd. And if you look at his GitHub contribution chart, it is actually hilarious. He has a screenshot of it cuz I think he broke it. Yeah, he's doing like 530 commits on **[08:46]** some days because he just spins things up and ships them. really now finally comes down to like how good are your ideas and how well can you describe them? As the author puts it here, the answer to what are people building? Almost everything. In fact, we've reached a point of saturation. On one hand, we're witnessing the true democratization of software creation. The barrier to entry has effectively collapsed. For the first time, non-devs aren't just consumers of software. They are the architects of their own tools. I still think we're not quite there yet. There are certain things that will help us get there. What I'm more interested **[09:17]** in is the really skilled developers like Pete and how much more they can ship by using their existing orchestration abilities and mindset and multiplying that using these AI tools. In the past, if you had a specific problem, you'd spend hours searching for a SAS product that solved 80% of it. Yep, been there so many times. Today, the workflow shifted. People are opening a CLI or a voice interface and simply describing what they need. We're seeing a surge in personal software, things like subscription trackers tailored to specific budget styles, Chrome extensions that solve very niche data **[09:47]** entry problems, fitness apps with an interface exactly how the specific user wants it. I've built all of these things and more in just the last few weeks. This is a massive shift. Software is becoming a personal utility that you generate rather than a commodity you buy. This is a thing I think a lot about. One of the craziest stats to think about and I there is no way to measure this sadly. How many times is the average line of code run when you are paid to write code in a real codebase at work? How much do we expect **[10:20]** that code to run? This is a weird thing to think about because it's not just importance. When I was at Twitch, I wrote some very important software that only needed to run once for a migration. I wrote some really important software that only runs a few dozen times a week because admins internally were using those pieces of software. I also wrote some things that really weren't too important that run literally thousands of times a minute because they are facing users and there are millions of those users. That all said, almost all **[10:51]** code that was being written was used at least a few times and the average piece of code, especially piece of code being written by a professional developer, was often run quite a bit. This is shifting. The number of lines of code that are being output in a given day has gone up exponentially because these tools make it so cheap to output code. And the vast majority of that code will be run zero to one times. The vast majority of it. It is going to bring down the average immensely. Doesn't matter that there's a bunch of code that is run millions of times a second if there are millions **[11:22]** more lines of code that are never run at all. And this idea that a given piece of code is being run way less is fascinating to me. Another way of thinking about it is given a specific endpoint, what code runs. Traditionally, when you hit an endpoint, there is specific code bound to that endpoint. There might be a switch statement or something that chooses which sub code, which functions run as a result of the shape of the request. But the actual payload, the binary that is executing when you hit that endpoint is relatively **[11:52]** static until you ship a new update. I think that's going to change too where the average request is going to result in code existing that might not have before it. And that's a crazy idea. The idea that a user can do a thing and the result isn't that an existing binary is executed to solve some problem, but maybe the endpoint generates new code specific to the shape of the payload. that something new is created upon the hitting of that endpoint. It's just a weird inversion of how software's worked **[12:24]** our entire lives. That is just it's a crazy thought to me. The closest thing we've had before is I could send like a payload of JavaScript text to an endpoint that it would execute it and send me a result. But the idea of an endpoint no longer meaning a onetoone binding with an existing piece of code, an existing binary, and instead being dynamic based on the shape of the request and the user is just it's [ __ ] with my brain a lot and I wanted to talk about it here because it is fundamentally different from how software has worked all of our lives. This idea that code is expensive enough **[12:56]** that a given endpoint should run the code that we put all this time and money into and that the average line of code that a person's being paid to write is valuable enough that we should be holding it strong and maintaining it for a long time. That's over. Now, this is a huge fundamental change in how software works that has been keeping I want to say it's keeping me up at night, but it's got me thinking in a very different way than I have historically. from SAS to scratch pads. This is another one of those things I feel a lot where historically I've been the guy who goes and tries out the new SAS, tries out the **[13:26]** new database tool, the new framework, all of those things. I'm not doing that anywhere near as much anymore. When I have an idea or I see something interesting, I hop into my cloud code directory on my computer. I just have this CC sandbox where I whenever I have an idea, I go screw with it and see what comes out of it. It's been really fun to play with. And instead of going to find a solution online to a problem that I have to go subscribe to and test out, I just stick around in cloud code and it works really well. In fact, I have it building a full linear clone in Elixir as an experiment in a Ralph loop in the **[13:58]** background that's been going for 21 minutes and is still going. Excited to see how that comes out. We're entering a new era of software development where the goal isn't always longevity. For years, the industry has been obsessed with building platforms and ecosystems. Absolutely agree. The tide is shifting now. It's towards something more ephemeral. We're moving from SAS to scratchpads. Yes, languages like Rust were built for the name to Rust. The point of Rust is that once you rewrite something in Rust, you don't have to worry about it anymore. Is it more maintainable? Yes. But it's also way **[14:29]** more reliable and robust. And when you write code properly in Rust, you don't have to worry about it collapsing the way other things do. Memory leaks, probably not going to happen. weird one-off runtime errors that you didn't catch in the code. Probably not a thing if you use all of the guards and the checkers and things within the Rust ecosystem properly. The Rust compiler makes it way less likely you make the types of mistakes that require software to be iterated on and replaced. That mattered a lot when software was expensive. Now that it's cheap, it's questionable if it matters at all. There **[14:59]** are certainly places where those things matter, like in your kernel for your system or in medical software or in embedded systems that you can't change the code for. But a random HTTP service in Rust, come on. A lot of this new software isn't meant to live forever. In fact, it's the opposite. People are increasingly building tools to solve single specific problems exactly once and then discarding them. I did this four times the last two days. This is so real. It's so cool realizing these weird problems you have. Like I was setting up a new Linux box, running a 5090 to do **[15:30]** some local inference stuff a few days ago. Well, yesterday I built it. and I was having a lot of annoying problems getting it configured on the network. So I spun up cloud code to go solve it and ended up writing a bunch of scripts to set it up itself because funny enough it didn't have pseudo access. So it wrote all of these scripts like thousand plus line scripts to configure the exact thing I wanted once so I could run one command have my machine set up and then throw away the code and never think about it again. That's wild. That is such a different way of doing things. I **[16:01]** never would have cared enough to do that type of thing before. This is software as a disposable utility designed for the immediate now rather than the distant later. What makes this viable today is a specific technical philosophy. CLI first interfaces, local data, and zero onboarding. When you remove the friction of signing up, configuring a database, or navigating a complex UI, the cost of creating a tool drops so low that temporary becomes a feature, not a bug. Yep. Like if you have to go learn a new language or framework or tool or ecosystem to try it out idea out or solve some small problem, you're just **[16:32]** not going to if it's not big enough. And the size of problem that's worth solving with code has gotten way way smaller. That's one of the coolest things. Everybody has this threshold in their head. Like if there are problems that are large but easy to solve, obviously you're going to try and solve them. If there are problems that are difficult to solve and not that big, you're obviously not going to try and solve them. Everybody has a line somewhere here. Some people literally just do it horizontally. I've seen this before where there's a certain type of person **[17:02]** that doesn't really care about how hard a problem is. They just care about how much it bothers them. And if it bothers them enough, they'll fix it no matter how difficult it is. Somebody like Lionus Torvalt is a good example here where the problem of source code management was annoying enough that he decided to fix it. the problem of not having access to Unix was annoying enough that he decided to fix it. He doesn't really think about how hard it is. He just thinks about how much it bothers him. There are also people who are the opposite that they only think about how difficult it is to solve. If a problem is easy, it doesn't really matter how big or small it is. They'll **[17:34]** just solve it anyways because it isn't too hard for them to do. Most people have a sliding scale more like this though. Where as the problem gets more difficult, the size of the problem has to increase accordingly where everything in this area here they are down to solve because the size of the problem is bigger than the difficulty. But everything in this section here is less likely to be solved because the problem is annoying or tedious and the size of it isn't very big. What's been fun for me is this area of problems that aren't very big but are hard enough that I **[18:05]** wouldn't bother with that's been eradicated. This whole section here is so fun to just vibe code it out. Like when you're trying to transcode a bunch of random old files or you're trying to find a picture of your dog or you're trying to reconfigure your Zish scripts to do something different on your machine. problems that maybe cost you a few minutes every couple weeks that just weren't worth dealing with before suddenly can be solved. And what's changing right now is the size of the **[18:35]** difficulty of the problems these tools can resolve is just growing constantly. Opus was arguably a shift where this line went from here to like here. It's hard to find the limit of what Opus can't do given the right tools, the right prompt, and the right set of evals that it can use throughout its development process. That's crazy. But this is also why we're getting more and more of these small one-off things and why people are using these tools in such cool ways to just solve a random problem they have. I know I'm doing this a ton. I've never written so much software that **[19:06]** I never bothered even putting in a git repo. It's crazy to think that the majority of the code I've written in the past month, well written, is not even in a git repo because I don't care because it's just there to do one thing once. I'm probably at like 50,000 lines of code that I've just thrown away after using it once in just the past couple weeks. It's crazy. As Chris says here, if it takes 5 minutes to spin up a custom solution for a one-off task, you don't need it to persist. You don't care if you need it again in the future. You just regenerate it the same way. Who cares? The contrast with the traditional SAS model is stark. SAS is inherently **[19:38]** built to optimize for retention, lock in, and expansion. It's a business model designed to keep you inside the ecosystem in growing your footprint. Bespoke tools, on the other hand, optimize for immediiacy and control. They don't care about your lifetime value as a customer. They only care about solving the task at hand. In many ways, this is a return to how spreadsheets were originally used. That is such a cool comparison. Spreadsheets are the start of so many incredible, revolutionary things in software. One of my favorite talks ever is Rethinking Reactivity by Rich Harris. I still go **[20:08]** back to this every year or so, just to let it break my brain again. And a huge part of the intro for this video is talking about spreadsheets and how powerful they were, even when software was still in really early days. And so much what we're talking about now does definitely remind me of the old spreadsheet era in a really cool nostalgic but also powerful way where spreadsheets made computers go from this thing that hardcore nerds could do like silly games with and like solve some complex math problems with into a useful **[20:40]** tool for day-to-day people. Managing the invoices for their business or keeping track of the schedule for their hair salon. Spreadsheets made it possible for anyone to do whatever they needed that involved numbers and timings on a computer without having to write software and know how code worked. You didn't open a spreadsheet to build a permanent multi-year database, use it as a scratch pad to reason through a problem, calculate a result, and move on. Yeah. In this new landscape, cloud code is Excel for devs, a powerful, flexible utility for solving immediate problems rather than Shopify for **[21:11]** founders, which is built to be a permanent foundation for a business. It's about getting the job done than letting the tool go. Absolutely agree here. This is one of the piece I think a lot of people are missing. If you happen to be one of those people working on problems that cloud code, codeex, cursor, open code, whatever struggles with even with the best models, I'd want to see more cuz I just haven't seen much there that isn't a prompting issue honestly. But even if you are one of those people in one of those spaces where it's hard to use these tools to solve real problems, there are people **[21:41]** there like Lionus Orvoltz, the creator of Linux. That doesn't mean these tools aren't useful to Lionus, though. In fact, he's even been contributing to code bases with them recently. Not the code that matters for the actual packages, but code for things like visualizing his weird audio extension thing that he's building. Code to confirm the work you're doing works or to test out a theory or to experiment visualize. All these types of things that used to be really annoying to do went from really annoying to trivial, especially in places that you might not **[22:12]** understand. Well, like if you're a web dev or even a kernel dev that doesn't know Python, well, using these Python libraries is now trivial. But in order to do that, you have to do this really important thing that a lot of devs seem to struggle with. Letting go. You have to be okay with the fact that majority of the code being written by you is going to be thrown out. Most of it won't even be run at all. Some of it will be run once and then thrown away after. It's a weird feeling, but once you get over it, life gets way better. But this is where the thesis of the article comes in. Generating software quickly is one **[22:43]** thing. Making it survive contact with the real world is a whole different thing. Code is cheap. Software is still expensive. Here's the reality of the current AI native era. Code's become cheap, but software remains incredibly expensive. LMS have effectively killed the cost of generating lines of code, but they haven't touched the cost of truly understanding a problem. We're seeing a flood of these apps that were built in a weekend, but most of these are just thin wrappers around basic CRUD operations and third party APIs. They look impressive in a Twitter demo, but they often crumble the moment they hit **[23:14]** the friction of the real world. I would say this depends a lot on what the role of the program is. Like we have vibecoded a bunch of things for my content channel. In particular, Ben is going hard on rebuilding all of our internal tooling for managing things like which sponsors are on which videos and how well are those videos performing. That is more than holding up to our real world test. Could that scale to thousands of users? Maybe not. But it is a piece of software that is resilient that is on the cloud that we are using every day without issue. So there's a **[23:46]** balance here again of like how many users, how deep are the problems those users are experiencing, how much variety is there between the users and how does the software we write scale against that. But problems that are really specific to you that don't need to have these other considerations can be more than real world ready. But it depends on what world you're talking about. The cost of software isn't the initial writing. It's the maintenance, the edge cases, the mounting UX debt, the complexities of data ownership. These fast solutions are very brittle. The **[24:16]** subscription tracker you vibe coded breaks the moment a bank changes their CSV export formats. The Chrome extension dies the second a target website's DOM shifts. The fitness app becomes unusable as soon as a user needs robust offline support or reliable data sync. For the latter, use Convex. It helps a lot. On that note though actually I think a lot of these problems can be solved by better tools to fix these things. Like the CSV format change could be a in between tool that will reformat the CSV using AI or detect when the format **[24:47]** changes and adjust accordingly. Like the these inputs and outputs being more dynamic is a thing I expect to see in the future where if an error rate is detected on this input or output that it can adjust the code accordingly automatically. that I could absolutely see happening and being really really cool. Or things like offline support and sync, those come down to the primitives you're using to build the data layer. And if those primitives evolve enough that they work right out of the box, these problems are solved just by using the right tools. And more and more, I **[25:17]** think that's going to start happening. Chris has been seeing lots of doomsaying on Hacker News, Reddit, and Twitter about the end of engineering. This misses the point entirely. We aren't witnessing the end of the profession. We're entering a new era of it. I agree here. I don't know what this will look like long term though. Like how many engineers do we need for this? What are their data days like? Everybody asks me what I think software dev will be like in 2030. I don't know what it'll be like in March. But I know it will be different because it's very different now than it was 3 months ago. And if you haven't felt any differences, then you haven't tried these things enough. The **[25:48]** value of an engineer shifting away from the how of syntax and towards the what and why of systems. Real engineering lies in the abstractions and the architecture as well as the communications and the orchestration across all of it. Like who is working on what, when will it be done, what do we expect from this. All of that is a a skill that leaders have that traditional programmers don't. And leveling up there is super important. I just filmed a video all about that about why senior devs are liking these tools more. It's all about knowing how to structure a system that lasts, understanding why a **[26:19]** specific rate limiting strategy is necessary, knowing how to manage a distributed cache, and knowing exactly when not to store environment variables. Man, environment variables are possibly like the single biggest problem a lot of these tools have. That and authentication, authorization, and all of the layers around it makes all of this more annoying than it should be. I'm hopeful that we'll see leaps and bounds type solutions that make this stuff way better in the near future. We're not there yet. A often feels powerful because it hides the complexity. But as an engineer, your job is to manage that complexity, not ignore **[26:50]** it. The tools have changed, but the fundamental requirement for engineering rigor has never been higher. I don't know if this will change or not. I've been thinking about this a lot. Like if the models get twice as good again, will that rigor matter as much? I don't know. I actually don't. Maybe the models don't even need to get better. They just need better tools to recognize when they're doing things wrong or bigger context windows to keep track of what they're doing right. I don't know. But then we have the distribution illusion. There's a flip side. With the barrier to entry gone, the noise level has reached an all-time high. My feeds are currently **[27:21]** flooded with AI entrepreneurs claiming 5 figure monthly recurring revenue numbers for apps they built in an afternoon. Most of these are [ __ ] and fail super super fast. Even just today, I was looking for ways to manage all of my vibe coding stuff in parallel. And I have been sent three options that seem to have just appeared all at once. We have autoclaude which lets you have a cananban board for managing all your cla code instances. Vibe canban which is similar with open codeex and all the other solutions too. And **[27:51]** automaker by webdev cody good friend in other awesome YouTube channel worth watching. He's ahead of us on a lot of these things. He's almost perpetually 6 months to a year ahead. He built this with similar goals. These are all open source projects that do roughly the same thing that seem to have just appeared in the past week or two. And this is going to keep happening as more and more people spin these out and distribution is going to matter more and more. How fast you can write code and how good you can write code matters less and how far you can distribute that code, how relevant the thing is and feels and how **[28:23]** well you can communicate that to the world matters more than ever. Also, good to see you in chat, Cody. Hope you're doing well. Seriously, go give Cody a follow on YouTube if you haven't. If you haven't subscribed to me, subscribe to him first, then hit the sub button for me. But he's so far ahead of this [ __ ] But anyways, turns out the author agrees. These claims are highly suspect. When you see a creator with no existing distribution and no clear moat claiming 10K MR on a weekend project is usually a play for engagement rather than a reflection of business reality. Some of these stories are probably true, but in most cases, they aren't actually blueprints for technical innovation. **[28:53]** They're marketing case studies. These individuals succeed because they have mastered the art of capturing attention in a crowded landscape, not because they have an AI co-pilot. Yep. These other skills matter more and more. Again, I just filmed this video and it's crazy how relevant a lot of my points are now. But the idea of capability being the thing that matters for engineers just isn't true anymore cuz AI has leveled all of our capability up. What's happening is people are realizing the other parts matter more than they thought before. If you don't have the ability to be clear in what should be **[29:24]** built to delegate across these agents to orchestrate the whole thing and then explain to the world why it matters does not matter how much code you can generate. Previously, we would hold these engineers up high because their contribution charts were nuts, but nothing they were doing was useful. If you can't communicate the value of the things you're doing and be very clear and concise in why I should use your thing, nothing else matters. And just bumping your capability up a ton doesn't solve any real problems. We've entered an era where the ability to generate code is no longer the bottleneck. The real challenge has shifted to **[29:54]** distribution. Hi, good time to have a YouTube channel, isn't it? By the way, if you're building something really cool, you raised money and you don't know how to get it to people, my DMs are open and you can get my email for potential sponsorship stuff on my YouTube channel very easily. YouTube att3.gg. This is what I'm here for. More importantly though, distinguishing the genuine utility from the get-richqu posturing that has become so prevalent in the industry. I have done so much of this for brands, like the majority of the sponsors I bring on the channel, I don't do an ad after they pay me, at **[30:24]** least not immediately. Most will eventually do the ad, but I'll often have to do three to six months of back and forth with the brand, fixing their onboarding, fixing their go to market, helping them rebrand and structure the pitch for their product. It takes a lot of time to do that for some companies. And it's crazy like almost half of the brands I've worked with have through the process of me refining the pitch rewrote their whole homepage just to match a better way of describing what they're actually here for and why you should care. The why you should care is a much **[30:56]** much more important question than ever to answer because you have more competition than ever. And if you have a great idea that's hidden underneath your inability to talk about it, somebody like me can just come in, steal the idea, vibe code alternative, communicate it better, and put you out of business. Being good at talking and describing why your [ __ ] matters has never mattered more. If a brand has me up to sponsor and their product just isn't there or their marketing just isn't good and I don't know how to help them describe it, it might be easier for me to just steal the idea, go vibe code my own **[31:27]** alternative and sell that than it is for me to teach the brand how to do marketing. These people haven't stumbled upon a secret shortcut. They've simply found a way to execute their existing advantage faster and they potentially unlocked it in the first place if learning to code was rightfully too big an undertaking for a side project idea. Here's where my hot takes are going to come in. I don't think you could be successful at selling software if you aren't highly motivated. If your motivation led to you becoming a great programmer, awesome. If that motivation is strong enough that it can now bring you to learning how to communicate about **[31:59]** your ideas better and show people and distribute the things you're building better, awesome. But if coding was too hard for you to learn, now you can code for free. The rest is just as hard, if not harder. explaining an idea concisely took me as much time to learn as JavaScript did. And if anything, I am continuously learning with both, but I'm learning more about communication and clarity every day than I am about [ __ ] JavaScript. And if you aren't willing to sit there and learn those hard things, you're not going to go **[32:30]** anywhere. If you learned how to code 10 years ago, pushed through all that hard stuff when you were motivated, and now you've just been coasting for 10 years, you're [ __ ] It's over. If you don't have motivation, you're not going to go anywhere. I felt this a lot because I'm a content creator. I'm going to go down a little bit of an anecdote here, but it's one that's important to me. It's a real interaction I had. We're going to start this with a weird poll. You're in a plane. Imagine you're flying somewhere, passenger aircraft. The pilot **[33:00]** is suddenly incapacitated. They had a heart attack. They fainted. Something happened. Can you land the plane? Yes, maybe or no. If you know how people answer this, don't spoil in chat. I want to see what you actually think. And you, the viewer, too, think this in your head. If you're on a Boeing 747 or some [ __ ] pilot goes unconscious. Can you go into the cockpit, assuming you have the ability to go in, sit down, everything's fine there? Can you land the plane? Less than half of my audience is saying no. **[33:30]** Less than half. Here's the harsh reality. If you're not already certified, you're not going to land that [ __ ] plane. They land themselves. No, they [ __ ] don't. They do a lot of the like specifics where like making sure the right flap is down the right amount based on your current velocity. It helps with a ton of that. 99% of you won't even get the [ __ ] radios working. You're not going to land that goddamn plane. The reason I asked this is because most people assume they can do a thing that is highly skilled if they had **[34:01]** the opportunity. Most people think they could be a successful founder if only they had enough followers on Twitter and they knew how to code. Most people think they'd be a great Google employee, but learning to code is too hard. Most people think they'd be a great YouTuber, but editing video and OBS are too hard. If only these tools were easier to use. If only video editing was less complicated, then everyone could be a YouTuber. Cuz that's the hard part. Cuz that's the first problem you ran into. The radio thing even happens to an extent here, too. If the airplane radios were easier, everyone could land the plane. No, you [ __ ] can't. Be **[34:32]** realistic here. 34 of men answer yes to this question. Fun fact, the majority of men think they can land the plane. I bring this up because of a real conversation I had would have been about a year and a half, maybe two years ago, where I was talking to a developer and he said, basically, I'm looking to diversify my income sources. I'm going to pick up YouTube. any advice for me to have a successful channel with as little effort as possible? The way I raged, **[35:04]** I had multiple witnesses to the second version of this conversation cuz he followed up the next day, which is really funny. I'm thankful I did cuz I would have went [ __ ] insane otherwise. Do you know what his reasoning was for thinking he could do this? Well, I kind of like cameras and talking's pretty easy. I don't see why it would be hard for me to be a YouTuber. Seems like it's pretty easy what you're doing, Theo. Yeah. So, where this really fell apart was when I asked him a quick question. What YouTube channels do you watch? Do you know what he answered to this? Honestly, I don't **[35:35]** watch YouTube very much. This interaction has haunted me for 2 years. Because this is how most people work. This is how most people think. They legitimately believe that whatever the thing in front of them right now is that's in the way is the only blocker. And if they could just get that out of the way, it'd be so easy. Like after saying this, he didn't even let me start to interrupt saying, "If you don't know how YouTube works, this is probably going to be hard." He as quickly says, "I don't watch YouTube that much. What editor should I start using?" Are you joking? I just **[36:08]** Yeah, I don't know if you guys know this about me. I watch a disgusting amount of YouTube. When I'm not like at a conference or in meetings all day, I'll do six to eight hours of YouTube a day. Like, straight up. I love the platform. I love watching other creators. I watch a shitload of YouTube. And I did that for a decade and a half before I ever thought to make a channel of my own. I didn't even want to. My channel happened accidentally because I was doing Twitter spaces and wanted to show people in a more visual way what my stack was. So, I did a live stream and then reuploaded on **[36:40]** YouTube so I had something to link to. And now I have this YouTube channel that basically runs my life and my businesses. This was not something I chose to do. This is something I had to do because I had specific other problems I wanted to solve and all of those led to me being here. None of the best YouTubers chose to be a YouTuber. They ended up here. Other things they wanted brought them here. And this guy cared too much about camera equipment and video editing software to realize that he didn't care about YouTube. It's just insane to me. The reason I did the airplane thing just now is because the **[37:10]** second time this guy had the conversation with me, there was a camera DP standing next to me. somebody who came from the Hollywood world that switched over to software dev who overheard this whole conversation and felt like he was going mad. As soon as this person walked away, he pulled me aside and was like, "What the [ __ ] Does everybody just think that way?" Like, how does somebody actually believe they could just be a YouTuber when they don't know anything about it? I asked at first, "Do you think you could land an airplane?" He's like, "Fuck no. Why could I land an airplane? I did video **[37:41]** and now I do code." It's like, watch this. And I went around the table and asked every single person at the table, "Do you think you could land a plane if the pilot's incapacitated?" Every single one said yes or maybe. Nobody else said no. This is the delusion. It's kind of a Dunning Krueger, but it's deeper than that. Most people think that they would be incredible at whatever thing they see in front of them if only this random thing directly in front of them wasn't a little too hard to get over. Code Bradley in chat here said, "As someone who's been in marketing for 15 years, everyone thinks they could be a good **[38:12]** marketer." Ready for a real honesty moment from me? I didn't think I could be. One of the first things I was planning on hiring for for T3 tools, aka ping, aka now T3 chat. I was planning on hiring a marketer really early cuz I didn't think I would ever be able to build that skill. That and sales. Turns out I'm okay at those things. Actually, I would go as far as I'm pretty damn good at those things. But I had to learn those and scale up in them out of need. I didn't go in thinking I could do it if only my inbox was easier to manage. No, **[38:42]** I went in humbly expecting to suck at the thing and slowly got good. So, all of that was a tangent because I don't necessarily agree that unlocking the average person's ability to code is going to push them past the next step. If the friction of learning a video editor or learning how to set up and use OBS or figuring out what camera you should use is enough to keep you from being a creator, if I hand you solutions to all of those problems, you're going to be a [ __ ] creator still. If you're so unmotivated that learning how to code was too much friction for you to go do **[39:13]** the thing, you're going to be a [ __ ] founder and marketer and business person as well because there are just as many hard friction points you'll hit. Many of which are even harder when it comes to marketing and distribution. You're just you're not going to succeed there. If you don't believe me here, then you don't have a following yet. Go make a Twitter account and get to 10,000 followers. Hit me up when you're done. There's a useful framing for this shift. AI's effectively removed engineering leverage as a primary differentiator. Yes, this has been a weird one for me because I have had a specific set of **[39:43]** edge skills that basically don't matter anymore. The thing that made me a valuable asset in my previous jobs was that I could come in and take a project that is way [ __ ] behind and get it back on schedule without compromising on quality or capability. I am really, really good at taking a long road map, figuring out what to cut and shift around in order to make it actually doable in a reasonable amount of time. I've always been the ship fast guy, and that doesn't matter anymore. I was a **[40:15]** very rare type of engineer before that everyone can be now. Claude Code does what I did at Twitch, faster, more efficiently, and cheaper. And that's wild to think about. That was a ton of my leverage. I would just ship the solution faster. If you can go prompted in cloud code and get the solution out just as fast, that doesn't matter anymore. Thankfully, I've also leveled up these other skills around marketing, communication, distribution, orchestration, all these other things that matter even more. So, the fact that I don't have a unique lever here anymore barely even matters. But all of my **[40:46]** friends who worked this way too are [ __ ] When any developer can use an LLM to build and deploy a complex feature in a fraction of the time it used to take, the ability to write code fast, especially is no longer the competitive advantage it once was. It is no longer enough to just be a builder. Couldn't agree more. Instead, success now hinges on factors that are much harder to automate. Taste, timing, and deep intuitive understanding of your audience matters way more than ever. You can generate a product in a weekend, but that is worthless if you're building the **[41:17]** wrong thing or launching it to a room full of people who aren't listening. Yep. Or even better, an empty room, which is what most of y'all do, and then you complain that the algorithm is so bad. If only the algorithm was better. Everyone would know about my slop app. Good luck with that. In this new environment, the code has become the easy part. The hard part remains exactly where it's always been, finding a way to get people to care. Another way of framing this is that previously code was hard enough that you needed a lot of coders once you had someone in something that was worth caring about. If it turns **[41:48]** out Twitch is worth caring about, it takes a lot of engineers to build all the pieces. So for every one person who understands this and cares enough about this to do all of the other parts, you need a team of 10 to 20 engineers to do the rest. Now that that part isn't as important or at least it's not as important in the same ways as it was and is much easier to automate. The hard part still exists, but if you're just an edge, you just are the accessory to the leaders who are actually getting the thing out there. You're useless now to an extent. And that sucks. And this is **[42:20]** where I think a lot of the insecurity is coming from is that 20 to1 ratio of 20 good engineers to one person who understands the thing that they're building. That ratio went from 20 to one to like one here. So when I was the other 19 engineers, I don't know. I'm not trying to hire them. So who wins here? First, you'll have domain experts who are stuck with boring, repetitive problems. Then there are internal teams building throwaway tooling, the kind of scripts and internal apps that need to work immediately rather than look perfect. There are whole billion dollar **[42:52]** companies that were built just around this. My co-founder Mark, my CTO, was working at Retool before he joined my company. Retool was a way to build much easier internal dashboards that access data across all the different places that your company might have data from. So some internal support team that needs better visualizations of how much usage a user has on their account when they're doing support, some random person on that team that's not even an engineer can whip up something in retool to manage it. Now with vibe coding, all these other things, the ability for a **[43:22]** company or even an individual to do the same thing reduces the value of a tool like retool. They got to a very very high valuation very very fast because preai everyone needed [ __ ] like this. They were getting contracts with everyone from like Philips and Pinterest to stripe and Amazon which is a wild range. But now barely matters. They are trying desperately to catch up with all these other AI alternatives that now exist. That market is huge huge enough for retool to become a multi-billion dollar company. It's also addressed well enough now for retool to be struggling **[43:53]** to survive. Power users also see a massive gain here, particularly when they are looking to replace brittle manual workflows with something more robust. Finally, it's a win for those engineers who prioritize ownership of the solutions over high gloss polish. And yes, tools like Opus 4.5, Claude Code, and Cursor are genuinely useful for engineers. They are remarkably good at removing boilerplate, implementing features, and writing unit tests. One of my favorite use cases lately, especially since starting a new job, is generating personalized documentation and walkthroughs of features to get up to **[44:25]** speed on product code bases and how all the nuances work. It's been extremely helpful in getting up to speed. Yeah, it's so nice having AI that can understand a large codebase well enough to give you useful insights. But here's the reality. LMS are far from perfect at writing code, even if it compiles first time. Even with the high quality prompting and clear rules, these models will still make mistakes. Speaking as someone who uses these tools every day, you cannot simply trust the output outright. You still have to review the code as if it were a poll request from a teammate. You have to read the logic, **[44:55]** check the assumptions, and often make manual edits to get it right. I am starting to drop this part. I'll just tell the model what it did wrong, and it will fix it. And I am suspicious that the amount of this will go down more and more, especially again to go back to my chart earlier. If the problem size is small enough, I'm not going to bother reading that [ __ ] code. If the problem of size is big enough and the difficulty is big enough, I'll probably take the time to read the code. But it varies and how you think about these things will vary a lot. After all, you'll likely be sending this to a teammate for review and maybe Code Rabbit, I guess. Okay, to be clear, **[45:25]** tools like Code Rabbit, Grappile, all these AI code reviews. Do those before you send it to your teammate because they will catch small annoying mistakes that your teammate shouldn't be dealing with. I know those companies sponsor me. I don't care. They're super [ __ ] useful. AI code review is a way to not waste your team's time doing a code review. Super useful. Your teammates still should review the code, absolutely, but they shouldn't be reviewing it for small syntax mistakes. They should be reviewing it for understanding of the codebase for reducing bus factor and making sure what you're doing is aligned with the goal of what needs to be done. AI isn't great at **[45:57]** that, but it'll catch all your stupid [ __ ] syntax and weird one-off errors much better than a human will. Don't waste the people's time with that [ __ ] This is a really good question. Is it fair to make them review something you didn't even write or bother to check? Humans, no. AI, absolutely. Letting an AI review code that an AI wrote is awesome, and you should absolutely do that. These tools help you move faster, but they do not replace the need for a critical eye or your years of experience, and they do not understand the overall problem space better than you. The hype makes it look like we're entering a golden era of SAS. We aren't. **[46:27]** We're entering an era of personal software, tools you generate to solve a problem, and then move on. With $20, a few hours of spare time and a bit of patience, almost anyone can ship a functional app. We're entering the era of personal software, where the gap between an idea and a working product is narrower than it's ever been. In this new reality, engineering expertise remains incredibly valuable, but the nature of the role is shifting. Relevance is not fading. Instead, it's about leveraging these tools to build at a higher level than was previously possible. True expertise is now required to steer these systems and provide the **[46:58]** technical oversight that LM lack. While AI is undeniably good at writing code, it remains poor at architecting, maintainable, distributable, and scalable systems. This is where nontechnical leaders who think they can fire their development teams are making a significant mistake. Until we see the arrival of an artificial intelligence that renders this entire discussion moot, believing that technical expertise can be replaced by a prompt is a strategic error. I fully agree here. Building robust software still requires a human who understands the underlying principle of the craft. A different way of framing this. Hard problems are still **[47:28]** hard and motivating yourself through them is the key. A highly motivated vibe coder that will take the time to figure out why their things are breaking and learn them will be way more valuable than an experienced engineer who's kind of checked out and is just not paying attention to the code they're merging. Motivation is going to be the key differentiator. Do you care enough to skill up in the areas you don't know? Because if you're willing to sit there and ask endless questions to the AI to figure out where your knowledge gaps are, figure out what might be going wrong and try all these different theories, the patience and diligence and **[48:01]** like resilience is going to matter more than ever. And if you're already burnt out, you're [ __ ] You're absolutely [ __ ] If you can't find excitement in what these tools enable, you just feel frustration and tired, you're probably not going to survive this transition. You need to have the motivation to push through. You don't just need the skills. I would argue you could build the technical expertise faster than ever with enough motivation, but you can't get that motivation by just having the expertise. The bottom line is that while the tools have changed, the fundamentals **[48:31]** of good engineering have not. While barrier to entry may be gone, judgment, taste, and responsibility are still the job. Absolutely agree. This was a fantastic article. I know I didn't agree with all of it, but the framing was incredible and the majority of it is more than on point. I have a feeling I'll be keeping a close eye on Chris and the other things he does. Turns out he's also a big Elixir and Live View fan. I love Elixir, so hyped. In fact, as I mentioned before, this whole time I have been running this gigantic project in the background, which looks like it actually finished in 35 minutes and 50 **[49:01]** seconds. So, I'm going to go play with that. I got nothing else to say here. Stay motivated, keep building, keep doing cool [ __ ]