I’m Serious. - CourtneyR.dev's 2nd Brain

I’m Serious. ![rw-book-cover](https://i.ytimg.com/vi/08NqrRQArNw/sddefault.jpg) 🔗 **Source:** [I’m Serious.](https://www.youtube.com/watch?v=08NqrRQArNw) > [!note]+ Document Notes > tags: #open-source #software-development #closed-source #ai-development > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=08NqrRQArNw > date created: 2024-12-28 09:30 > > # 🏷️ Title: I'm serious. >  ## 🧰 Action Inbox - [H1] Evaluate all closed-source tools for open-source alternatives — performance degradation concerns #open-source - [H2] Implement patch-package workflow for dependency modifications — inspired by Yash's approach #software-development - [H3] Consider open-sourcing proprietary tools to enable community contributions — business strategy #ai-development ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [T3 Code on GitHub](https://github.com/t3-oss/t3-code) - [WorkOS Authentication](https://soy.ink/workos) ## 📝 Summary - Theo argues for prioritizing open-source software over closed-source alternatives due to AI-accelerated degradation of software quality - Why it matters: Closed-source software can become unusable quickly, with no user recourse for fixes - Key stakeholders: Developers, software teams, open-source maintainers - Risks and tradeoffs: Open-source requires more maintenance overhead but provides control and customizability - Bottom line takeaway: The speed at which AI enables developers to break things makes open-source software increasingly necessary for reliability ## 📖 Main Content Theo presents a compelling case for moving away from closed-source software, driven by his observation that AI has accelerated both software development and software degradation. His argument centers on the idea that when developers become "100 times faster" with AI, they can also "fuck things up 100 times faster." The core thesis emerged from working with his intern Yash, a high schooler who demonstrated an unusual approach to software development: treating all code boundaries as permeable. Rather than working around limitations in dependencies, Yash would directly patch external packages using patch-package, even going so far as to reverse-engineer T3 Chat's webpack bundle to add features. This approach revealed to Theo that the traditional boundaries between "your code" and "their code" are artificial constraints that limit productivity. With AI making code modification easier, the ability to fork, patch, and customize software becomes increasingly valuable. Theo cites specific examples of software degradation in tools he relies on daily: Cursor's performance issues, Codex app's unreliable updates, Notion's broken drag-and-drop functionality, and macOS Sequoia's general instability. He argues these problems stem from teams using AI to accelerate development without maintaining code quality standards. The solution he proposes is open-source software like T3 Code, which has generated over 1,100 forks from 30,000 users. This fork rate demonstrates users' desire to customize and control their tools. He provides examples of non-developer YouTubers like XLT Jake and Quinn from Snazzy Labs successfully forking his open-source video review tool Lawn to add features they needed. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/08NqrRQArNw?t=0) — [H1] The reality of closed-source dominance - Key idea: Most daily software is closed-source despite open-source benefits - Evidence: "Mac OS or Windows, Notion or Obsidian, Linear or Jira, Slack or Discord" #### ⏱️ [02:45](https://youtu.be/08NqrRQArNw?t=165) — [H2] Historical justification for closed-source - Key idea: Closed-source made sense when software was expensive to create - Evidence: "Software has been worth selling because it's expensive to make" #### ⏱️ [04:12](https://youtu.be/08NqrRQArNw?t=252) — [H1] AI changes the cost equation - Key idea: AI has dramatically reduced the cost of writing software - Evidence: "Software stopped being expensive to make" #### ⏱️ [06:30](https://youtu.be/08NqrRQArNw?t=390) — [H1] The Yash revelation about code boundaries - Key idea: High schooler intern demonstrates treating all code as modifiable - Evidence: "Yash just doesn't perceive these boundaries. If he is working on something and it doesn't do exactly what he wants the first time, he just goes and fixes it" #### ⏱️ [08:45](https://youtu.be/08NqrRQArNw?t=525) — [H2] Patch-package as a philosophy - Key idea: Tools like patch-package enable modifying any dependency - Evidence: "Yash quadrupled the number of patch packages we had in his first two weeks" #### ⏱️ [12:15](https://youtu.be/08NqrRQArNw?t=735) — [H2] AI SDK patching example - Key idea: Direct patching can add major features to core dependencies - Evidence: "He went and patch packaged AI SDK to add in image gen to the core AI package" #### ⏱️ [15:20](https://youtu.be/08NqrRQArNw?t=920) — [H1] Cursor performance degradation - Key idea: Popular AI coding tools are becoming unusable due to performance issues - Evidence: "Every single update felt like a random chance of making the app slightly better or significantly worse" #### ⏱️ [18:30](https://youtu.be/08NqrRQArNw?t=1110) — [H2] Cursor Glass disappointment - Key idea: Even "clean slate" rewrites suffer from the same problems - Evidence: "Cursor glass experience somehow was even slower than the core cursor experience" #### ⏱️ [22:10](https://youtu.be/08NqrRQArNw?t=1330) — [H1] The core thesis: Closed-source + AI = disaster - Key idea: Closed-source developers cannot be trusted with AI acceleration - Evidence: "Closed source developers cannot be trusted with AI. They are taking things that are for the most part usable...and they are sloppifying them" #### ⏱️ [25:45](https://youtu.be/08NqrRQArNw?t=1545) — [H2] Quality degradation across the ecosystem - Key idea: Multiple major applications showing simultaneous quality decline - Evidence: "Notion decided they were going to start using AI to build more shit...Mac OS 26. It is a shitshow" #### ⏱️ [28:20](https://youtu.be/08NqrRQArNw?t=1700) — [H1] T3 Code as the solution - Key idea: Open-source alternatives provide accountability and customization - Evidence: "T3 Code has around 30,000 users. And it also has 1,100 forks. One in 30 users forked" #### ⏱️ [32:15](https://youtu.be/08NqrRQArNw?t=1935) — [H2] Real-world forking success stories - Key idea: Non-developers successfully customize open-source tools for their needs - Evidence: "XLT Jake...used Opus 4.6 to make lawn self-hosted...Quinn from Snazzy Labs...added a ton of quality of life features" #### ⏱️ [36:40](https://youtu.be/08NqrRQArNw?t=2200) — [H1] Claude Code as the worst example - Key idea: Anthropic's terminal tool represents everything wrong with closed-source AI tools - Evidence: "I don't think there has ever in history been a single piece of code that is harder to justify closing the source of" #### ⏱️ [40:25](https://youtu.be/08NqrRQArNw?t=2425) — [H3] The DMCA incident - Key idea: Companies are actively hostile to open-source alternatives of their tools - Evidence: "They accidentally shipped source maps...forced npm to take it down...proceeded to send DMCA requests to GitHub" ## 📚 References - [T3 Code GitHub Repository](https://github.com/t3-oss/t3-code) - [Lawn Video Review Tool](https://github.com/t3-oss/lawn) - [WorkOS Authentication Service](https://soy.ink/workos) - [Patch Package NPM](https://www.npmjs.com/package/patch-package) ## 🗣️ Paraphrase - The traditional model of closed-source software made sense when writing code was expensive and time-consuming, but AI has fundamentally changed this equation by making software development much faster and cheaper - A teenage intern demonstrated the power of treating all code boundaries as permeable, using tools like patch-package to modify dependencies directly rather than working around limitations, leading to better software and deeper understanding - The acceleration that AI provides to developers is being misused by closed-source companies, who are rapidly degrading the quality of essential tools like Cursor, Notion, and macOS while users have no recourse to fix problems themselves ## 📰 Newsletter **The Open Source Awakening: Why AI Makes Closed Software Dangerous** This week, we're diving deep into a critical shift happening in software development. As AI accelerates how quickly we build software, it's also accelerating how quickly that software can become broken and unusable. **The Key Insight**: When developers become 100x faster with AI, they can also break things 100x faster. And if you're using closed-source software, you're completely at their mercy. **Why This Matters for WordPress**: The WordPress ecosystem has always embraced open source, and this trend validates that approach. Consider how many times you've needed to modify a plugin or theme - imagine if you couldn't! **What You Can Do**: Start evaluating your closed-source tools. Are there open-source alternatives? Can you contribute to projects you depend on? The community that can fork and fix is the community that stays functional. **Community Spotlight**: Tools like patch-package show us how even in mixed environments, we can take more control over our dependencies. The WordPress community has always understood this through child themes and custom plugins. 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 about open-source alternatives to popular closed tools, demo T3 Code and similar projects - Education: Workshop on patch-package and dependency modification techniques - Developer experience: Audit developer toolchain for closed-source dependencies that could be replaced - Developer marketing: Campaigns highlighting the control and reliability benefits of open-source tools - Community management: Foster discussions about tool quality degradation and open-source solutions #### OSPO - Policy & Governance: Develop guidelines for evaluating open-source vs closed-source tooling decisions - License Compliance: Review patch-package usage for license implications - Security Management: Assess security benefits of being able to audit and patch dependencies - Software Inventory: Catalog closed-source tools that create vendor lock-in risks - Developer Support: Training on forking, patching, and contributing to open-source projects - Community Engagement: Fund critical open-source developer tools that teams depend on - Strategic Alignment: KPIs around open-source tool adoption and contribution rates #### Community - Maintainers: Support for developer tooling projects that need sustainable funding - Contributors: Programs to help developers contribute patches upstream instead of maintaining forks - Sponsors: Funding for performance improvements in open-source alternatives to degrading closed tools - Ecosystem: Cross-project coordination on developer experience improvements #### WordPress - Core: Evaluate any closed-source tools in the development pipeline for open alternatives - CLI: Expand WP-CLI capabilities to reduce dependence on closed development tools - Community: Advocacy for open-source development practices and tool choices - Documentation: Guide developers on contributing to the tools they depend on - Meta: Open-source tooling for .org infrastructure and development workflows ## 🧪 Hypotheses - Software quality will continue declining faster in closed-source projects using AI than in open-source projects with community oversight - Fork rates will become a key indicator of software project health, with higher fork rates indicating both user engagement and software flexibility - Companies that open-source their core tools will see increased adoption and community contribution compared to closed alternatives - The cost of maintaining custom forks will decrease significantly as AI-powered merge conflict resolution improves ### 📊 Methodology - Longitudinal study tracking performance metrics and bug reports across comparable open vs closed-source developer tools over 12 months - Survey developer teams about their fork usage patterns and correlation with tool satisfaction - Analysis of contribution patterns to newly open-sourced projects vs established open-source alternatives ### ❓ Questions - How can open-source projects prevent the same quality degradation that's affecting closed-source tools using AI? - What economic models make open-source developer tools sustainable without relying on closed-source premium features? - How do we balance the benefits of forking with the maintenance overhead of keeping forks up to date? ### 🔮 Future Research - Automated tooling for maintaining forks against upstream changes using AI - Economic analysis of the "open source premium" - whether users will pay more for open alternatives - Impact of AI code generation on open-source contribution patterns and code review practices ### 💡 Implications - Practice: Development teams should audit their toolchain for closed-source dependencies that create control and quality risks - Policy: Organizations need guidelines for evaluating the long-term costs of vendor lock-in vs open-source maintenance overhead - Security: The ability to audit and patch dependencies becomes more critical as AI accelerates both development and potential vulnerability introduction - Education: Developers need training on contributing to open-source projects and maintaining forks effectively - Funding: Critical open-source developer tools need sustainable funding models to prevent abandonment ### 🧠 Learning Styles Assessment Reading level estimate: 10th Grade (Flesch-Kincaid) #### 👀 Visual learners - Present: GitHub fork statistics, before/after performance comparisons - Improve: Architecture diagrams showing open vs closed development flows, visual timeline of software quality degradation #### 🔊 Aural learners - Present: Original video format with passionate delivery and examples - Improve: Podcast-style discussion with open-source maintainers about their experiences #### 🗣️ Verbal learners - Present: Clear definitions of patch-package, forking, and licensing concepts - Improve: Analogies comparing software tools to physical tools that can be modified vs black boxes #### 🧩 Kinesthetic learners - Present: Step-by-step examples of using patch-package and forking workflows - Improve: Hands-on lab for patching a real dependency and contributing upstream #### 🧠 Logical learners - Present: Clear cause-and-effect relationship between AI acceleration and quality degradation - Improve: Decision tree for evaluating when to fork vs contribute vs switch tools #### 🧑‍🤝‍🧑 Social learners - Present: Community examples like the YouTube creator forks of Lawn - Improve: Discussion prompts for team evaluation of toolchain dependencies #### 🧘‍♀️ Solitary learners - Present: Individual examples of developers like Yash making independent tool choices - Improve: Self-assessment checklist for personal development environment dependencies #### 🌿 Naturalistic learners - Present: Ecosystem metaphors about software tool dependencies and health - Improve: Comparison to biological systems where diversity and adaptability improve resilience ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure and contextual information in transcript - Improve: Timestamps with descriptive labels for key concept transitions #### Keyboard navigation - Present: Standard YouTube video controls work with keyboard - Improve: Chapter markers for easy navigation to specific topics #### Contrast and readability - Present: High contrast video with clear on-screen text when shown - Improve: Transcript formatting with better visual hierarchy #### Text resizing and reflow - Present: Transcript can be resized and reflowed - Improve: Mobile --- ## Full Transcript [00:00] I need to be realistic with you guys. [00:01] Most software that's used every day is [00:03] sadly closed source. Whether it's Mac OS [00:05] or Windows, Notion or Obsidian, Linear [00:08] or Jira, Slack or Discord, the things [00:10] that we rely on for our jobs every day [00:12] are very, very often closed source. And [00:15] while historically that's been okay, I'm [00:17] beginning to feel like it isn't. In many [00:19] ways, I'm becoming a diehard with open [00:21] source. And I'm even rethinking my own [00:23] stances on things that we've [00:24] historically left closed source. Yes, [00:26] I'm actually thinking a lot about open [00:28] sourcing T3 Chat. That's why T3 Code [00:30] came out as an open source project. This [00:32] is a thing that's becoming increasingly [00:34] important to me, especially now in the [00:36] AI era. The reason why it's getting [00:38] important to me might surprise you. Your [00:40] initial thoughts probably that like, oh, [00:41] with AI, I can go modify all my things. [00:44] And while that is part of my reasoning [00:46] here, it is not even close to the full [00:48] story. I'm nearing the point where I [00:50] just am not interested in trying new [00:52] solutions if they're closed source. And [00:53] I'm getting more and more frustrated as [00:55] I learn just how closed off these things [00:57] are. And in particular, when they start [01:00] getting worse, it feels like software is [01:02] degrading over time. And if it's not [01:04] open- source, I'm not able to fix it. [01:06] And I have to talk about the [01:07] implications of this because it keeps [01:09] coming up in my head, and I just need to [01:11] get it out. But I have to get one other [01:13] thing out first, today's sponsor. One of [01:15] the interesting things AI has changed [01:16] about our industry is the willingness of [01:18] big companies to make big bets. And [01:20] those bets can be trying out new [01:22] products. I cannot tell you how many [01:24] times I've seen some small 3 to 10 [01:26] person YC startup have Microsoft come [01:28] over and say, "Hey, we'd love to try [01:29] your thing. How do we set it up?" And [01:31] then they never have an answer because [01:32] they either rolled their own off or use [01:34] some library or small company solution [01:36] that just doesn't work for these [01:38] enterprises. What happens when a Fortune [01:40] 500 company comes to you and says, "Hey, [01:42] we want to use your product. How do we [01:43] get our 10,000 developers onboarded via [01:45] ADP?" What do you do? How do you handle [01:47] that? You probably don't unless you've [01:49] already set up today's sponsor, Work OS, [01:51] the O solution used by everybody from [01:52] OpenAI and Enthropic to Carta and [01:54] Snowflake. Yes, all of these businesses [01:56] are using the same O solution, and it's [01:58] Work OS. And there's a reason why. They [02:00] found the balance between good developer [02:02] experience and all of the weird crap [02:04] that these big companies need in order [02:06] to have a good time using your product. [02:07] You can take my word for it, or you can [02:09] read all of their customers saying the [02:10] same. The onboarding process has been [02:12] excellent. I love sending it admins the [02:14] link to set it up themselves and getting [02:16] an email notification when it's done. [02:17] It's so efficient not having to go into [02:19] meetings or go back and forth via email [02:21] with the IT people. Or from Andreas at [02:23] OpenAI, the Work OS team was right there [02:25] with us every step of the way. Their [02:27] support ensured those final migrations [02:29] were just as smooth as the rest. I found [02:30] from my own experience using Work OS and [02:32] T3 chat. They are incredibly responsive [02:34] in Slack. It has never been easier to [02:36] talk to a company, ask for things, [02:37] changes, whatever else we need, and have [02:39] them just come in and help. If you're [02:41] having off problems, work will solve [02:43] them. And if you're not having off [02:44] problems, Work OS will keep that from [02:46] changing. Check them out now at [02:47] soy.ink/workos. [02:48] The origins of software have always been [02:50] kind of closed. Software is a thing that [02:53] takes effort to write and release. And [02:55] as such, the people who made it wanted [02:57] to make money off it. So they kept the [02:59] source closed and they would sell you [03:00] access to the code through things like [03:02] APIs or just sending you a compiled [03:04] binary that you couldn't really get the [03:06] code out of. And this was great for [03:08] making it possible for people to become [03:09] developers for a living. Without closed [03:11] source, it's possible that software [03:13] would have just been a weird niche [03:14] hobbyist thing and never become the [03:16] giant field of incredibly talented and [03:18] well- paid devs that it is today. But [03:20] things are changing fast. We need to be [03:21] realistic. Historically speaking, [03:23] software has been worth selling because [03:25] it's expensive to make. And that makes [03:26] sense. If people have to spend hours [03:28] upon hours just getting small things [03:30] working and months upon months to [03:32] actually build them to the point where [03:33] they're useful and shippable, charging [03:35] money for that makes a lot of sense. At [03:37] the same time, it is incredibly [03:39] frustrating when there's something small [03:40] wrong with your software and you [03:42] couldn't fix it. This frustrated Richard [03:43] Stallman so much that he kind of [03:45] initiated what we now understand as open [03:47] source and open source licensing. But [03:49] something's changed. Something's changed [03:51] in a massive way. Software stopped being [03:54] expensive to make. Not in entirety cuz [03:56] so much of our time building good [03:57] applications is spent on things that [03:59] aren't just writing code. But at the [04:01] same time, a lot of why we were valuable [04:03] was the code writing part. Yes, [04:06] developers are stuck in far too many [04:07] meetings, writing far too many docs, [04:09] saying no to far too many feature [04:11] requests. But none of those parts were [04:13] the hard part. None of that was the [04:15] reason we were paid so well. We were [04:17] paid well cuz we could turn all of that [04:19] into the right source code to generate [04:21] the thing that people wanted. And that [04:23] was a difficult and rare enough skill [04:25] that we were compensated accordingly to [04:27] it. At the same time, I'm sure as y'all [04:29] know, open source devs are not paid very [04:32] well. They're often not paid at all [04:34] because open source means you're just [04:35] kind of giving out the thing that's [04:37] valuable. The companies who make the [04:38] most money in open source are very [04:40] rarely the companies that are doing the [04:41] open source work. It's the ones that saw [04:43] the missing piece and then sold that and [04:46] built in the open source thing. Look at [04:48] stuff like Elastic Search on AWS where [04:50] they kind of just took this open source [04:52] project and then sold it to companies as [04:53] a service and made billions of dollars [04:55] on it despite not writing the thing that [04:58] they're selling. That one got so bad [04:59] that a whole bunch of new licenses were [05:01] created because the Elastic Search team [05:02] was rightfully upset that AWS was making [05:05] a shitload of money off a thing they [05:06] built and they were getting none. And [05:08] AWS wasn't even contributing. Not even [05:10] code, not even money, nothing. And that [05:12] rightfully irked them. And as a result, [05:14] they changed the license. Things got [05:16] really messy. Other companies started [05:18] doing similar things like Reddus with [05:19] the Reddus Labs explosion. And open [05:21] source got a little bit messier for a [05:23] while. And this all made sense when [05:25] these things were expensive. And I would [05:27] also argue that while that was really [05:29] painful, there was a benefit to it. The [05:31] fact that instead of building their own [05:33] alternative to something like Elastic, [05:35] Amazon just chose to support this open [05:37] standard. That was in net a good thing. [05:40] Like let's be real here. The alternative [05:42] was you build all your tech around this [05:43] weird closed source solution on AWS and [05:46] then there is no world in which you can [05:47] ever move off. Since Elastic is open [05:50] source, you can move from one provider [05:52] of it to another, which is a good thing. [05:54] It means you stay in the elastic [05:55] ecosystem and if the elastic team builds [05:57] things that they can sell that are [05:58] useful to you, you can potentially move [06:00] over to that. That's all good, but it's [06:03] it still feels wrong. The fact these big [06:05] companies are the only ones that tend to [06:06] make a lot of money on these open source [06:08] things kind of sucks. But now we're at a [06:10] point where those implementations aren't [06:12] necessarily the hardest thing in the [06:15] world to build. Elastic Search is an [06:17] exception here. Building that, right, is [06:18] incredibly difficult. But a lot of other [06:21] things that I use every day, that's not [06:23] the case. Realistically speaking, it [06:25] wouldn't be too hard to rebuild [06:27] something like Slack. The problem with [06:29] Slack is that you're locked in because [06:31] you're using their infrastructure and [06:32] you have shared channels with other [06:34] companies that are also using and paying [06:36] for Slack. I could build a better Slack [06:38] in a week, but nobody would use it [06:40] because Slack has locked them in. It is [06:42] what it is, but what it is is kind of [06:44] And it's been annoying me more and [06:45] more. I want to talk about a specific [06:47] triggering event that kind of changed [06:50] how my brain works fundamentally. I need [06:52] to talk about my intern, Yash. Yash is [06:54] one of the most talented devs I've ever [06:57] worked with. He's incredibly talented [06:59] high schooler who showed up in my chat [07:00] one day with a link to a user script [07:02] that he built for T3 Chat that added a [07:05] bunch of features he wanted. There were [07:06] some catches, though. Specifically, T3 [07:08] Chat is closed source. So, how did he [07:10] add all these features? Well, he did [07:12] some really clever He had a user [07:14] script that was written to reverse [07:16] engineer our Webpack bundle, insert in [07:19] his own additional packages. In this [07:21] case in particular, he brought in the [07:23] AISDK server side stuff to the client [07:25] because he wanted to be able to run [07:26] local models in T3 chat. That was so [07:29] cool. So I had to bring him on [07:31] as an intern and he's still contributing [07:32] code quite a bit. Has to finish high [07:34] school. Believe me, we're writing him [07:36] the most kind letter for his college [07:38] referral ever. If this kid doesn't get [07:40] into every college in the world, then [07:41] I'm done with the entire academic [07:43] system. He's one of the most talented [07:45] humans I've ever had the pleasure of [07:46] working with. And he had one particular [07:49] quirk in how he builds that has just [07:51] changed how I think. Y'all ever heard of [07:53] patch package? If you're not in the JS [07:55] world, you probably haven't. And if [07:56] you're new to the JS world, you also [07:58] still probably haven't. Patch package is [08:00] a package for patching packages. I know [08:02] that doesn't sound like a real [08:03] statement, but it is. The point of patch [08:05] package is it allows you to modify [08:07] packages you're using. The point of this [08:09] is that if you install some package and [08:11] there's something that isn't quite how [08:13] it needs to be or there's some obscure [08:14] bug alongside some other thing you're [08:16] using. If you want a package to have [08:18] some small fix or remove some log that [08:20] annoys you or whatever, patch package [08:22] makes it trivial to as part of your [08:23] install and build process, have a patch [08:26] file in your project that will auto [08:28] apply to that dependency that you're [08:29] using. The process is really simple. You [08:31] go into node modules and you edit a file [08:34] in it. I know that sounds crazy, but [08:36] when you have to do this, you have to do [08:38] this. You then run the patch package [08:39] command. It adds this new patch file [08:42] that will auto apply whenever you do an [08:44] install going forward. They also have a [08:46] helper command that makes it really easy [08:48] to file a PR based on that patch. That [08:51] doesn't necessarily work great because [08:52] the patches are often the compile the JS [08:55] code, not the original source code. But [08:57] it's at least a kind of useful tool that [08:59] can get you going in the right [09:00] direction. And this is really useful for [09:01] those like oneline fixes and changes [09:03] that are very very helpful when you're [09:06] running into weird problems when you [09:07] have piles upon piles of libraries. [09:09] Historically speaking, I have been a [09:11] bigger than average patch package user. [09:14] Thankfully, it's built into Yarn and [09:15] Pnpm natively, which is really helpful. [09:17] I will do one or two per project usually [09:20] for bigger projects when I find some [09:22] random thing that's breaking. So, why am [09:25] I talking about this in a video about [09:27] closed and open source? We need to go [09:29] back to Yash. The unique thing he did [09:32] that I'd never seen before, and I don't [09:34] necessarily know why he works this way. [09:37] He doesn't perceive the boundaries [09:40] between different places where code [09:42] lives. I can't tell you how many times [09:44] when I was doing my job at Twitch, I ran [09:46] into some dependency that wasn't working [09:49] how I needed it to, but I was scared of [09:50] having to deal with the team, so I just [09:52] worked around it. I had a relatively [09:54] small change once that required seven [09:56] teams to approve because I just so [09:58] happened to have to make oneline changes [10:00] in seven different folders that weren't [10:01] owned by my team. This sucks. And as a [10:04] result, I started to build an intuition [10:06] that I should work around these problems [10:08] instead of going to the source and [10:09] fixing them. Because when you have to go [10:12] to the source, you would often have to [10:13] deal with the that was the team [10:15] that maintained it having their own [10:17] opinions about GH the amount of I [10:19] I have like literally dozens of stories [10:21] coming to mind about these types of [10:22] things. I need to resist the urge to [10:24] talk about all of them so we can focus [10:25] on the thing I want to talk about right [10:26] now, which is the greatest intern I've [10:28] ever had in my life. Yosh just doesn't [10:30] perceive these boundaries. If he is [10:32] working on something and it doesn't do [10:34] exactly what he wants the first time, he [10:36] just goes and fixes it. He doesn't spend [10:38] time on the workarounds. Yosh quadruple [10:40] the number of patch packages we had in [10:42] his first two weeks and continues to add [10:44] them in places that make sense. Not only [10:46] does he do that though, when the patches [10:47] are actually good, logical changes, he [10:49] will, without even hesitating or asking, [10:52] just go file PRs on random things that [10:54] we depend on. There is no member of the [10:56] T3 team that has shipped more changes to [10:59] other people's than Yash has [11:01] because he just does this differently. [11:03] When he hits a wall because some [11:05] boundary that's in the way is blocking [11:07] something, he just opens the door and [11:09] walks right through and changes the code [11:10] somewhere else. And at first this [11:12] concerned me because it's kind of crazy [11:14] adding all of these patches to a [11:15] project. It's honestly a little bit [11:17] scary. But I've slowly begun to realize [11:20] just how right he was. Some of Yasha's [11:23] patches reached a little further than I [11:25] ever personally would have. For example, [11:27] we were using the AI SDK and at the time [11:29] it didn't support image generation [11:31] stuff. So I had built my own image [11:33] generation path that was relying [11:35] primarily on the SDKs provided by OpenAI [11:38] and Google respectively for their [11:39] models. And it was rough. Those code [11:41] paths sucked because they didn't look or [11:43] act like any of the other code paths in [11:45] our project because AI SDK was just for [11:47] textG. I needed to do things that [11:49] weren't text. So I had to make new paths [11:50] for those and try to force them into the [11:53] existing code paths that we had. I did [11:54] this for the OpenAI models and the [11:56] Gemini models. But then I wanted to add [11:58] some things. In particular, I wanted to [12:00] add the progressive updates when the [12:02] providers send you the partial version [12:04] of the image before it's done so you can [12:06] see it in the UI as it's being created. [12:08] and the way I had built things just [12:10] didn't support that. So I gave him what [12:12] at the time seemed like a relatively [12:14] simple task to implement proper [12:16] progressive image generation stuff and [12:18] he ended up having to touch a lot of [12:20] After this was done and we got it [12:22] merged, he went and patch packaged AISK [12:26] to add in image gen to the core AI [12:29] package that we were using, deprecated [12:31] all of my code and made it way [12:33] more stable. That was awesome. It was so [12:35] cool. It was scary at first. And what I [12:36] saw I was like, "You're adding features [12:38] like big changes to a core dependency we [12:41] rely on for this project via a patch [12:43] file." Initially, it scared the out [12:45] of me if I'm being real. And then we [12:46] shipped it and it worked great. And then [12:48] eventually I SDK added image gen and we [12:50] deleted our patch and moved to it. And [12:52] this has been haunting me since. It's [12:54] not a thing I have brought up in my [12:55] content much, but if you ask anybody who [12:58] is a developer that spends time with me [13:00] in person, this is one of those rants [13:02] that I'm known for just repeating [13:03] constantly. If Ben or Julius are in chat [13:05] right now, feel free to shime up. I know [13:07] this one's almost annoying you guys at [13:08] this point because I talk about it all [13:10] the time. Part of that's because I'm [13:11] still thinking about it. I'm trying to [13:12] process all of this. I'm trying to [13:14] understand this way of thinking. And now [13:16] that I've thought about it so much, mind [13:18] you, because of a dev that is nearly [13:20] half my age doing things differently [13:23] than me, I've realized that I need this. [13:25] I need this in a lot of the things I [13:27] rely on. At the same time, it has gotten [13:30] easier and easier to make changes to [13:32] software thanks to this weird little [13:34] thing that happened. You might have [13:35] heard about it. It's called AI. So, [13:37] suddenly doing these types of changes [13:39] and adding these types of features makes [13:40] way more sense than it ever has. So, the [13:43] result of this long train of thought, [13:45] thank you to my friend Yash, it's the [13:47] realization that I do want to muck [13:50] around more in the internals of the [13:51] things that I rely on. Not because I [13:53] want to file a bunch of PRs and annoy [13:55] maintainers with merging them, but [13:57] because it's fun to an extent. It's just [14:00] cool digging into the details of how [14:02] these things work. You'll learn things, [14:03] you'll fix things, you'll change things, [14:05] you'll better yourself as a developer. [14:07] And since I tried to start adopting this [14:09] mindset more, I have found myself to [14:11] much more deeply understand the things [14:13] that I depend on in my code bases. At [14:15] the same time, I started to have [14:17] feelings about other things. This is the [14:19] other main inspiration for this video. [14:23] This is the Codeex app. I used this app [14:25] for 90 plus% of the code I wrote for an [14:28] entire month. It blew me away. I had [14:31] seen UX like this before, but none of [14:33] the things were quite where I needed [14:35] them to be. And Codex was the first one [14:37] to be polished enough to meaningfully [14:39] change the way I wanted to write code. I [14:42] also just installed this version of [14:43] Codex today because I stopped using it [14:45] in favor of T3 code, and we'll get to [14:47] that in a second. Even though I [14:49] installed it literally two hours ago for [14:51] a video I was filming, it still has an [14:54] update ready to go because they are [14:55] pushing updates constantly. You might [14:57] think this is a good thing, and in a lot [14:59] of ways it is. But there's a problem. [15:01] The problem is that every single update [15:04] felt like a random chance of making the [15:06] app slightly better or significantly [15:08] worse. There was a solid window where [15:10] the performance in the codeex app was [15:13] borderline unusable with long enough [15:15] threads, complex enough code bases, and [15:17] enough stuff going in parallel. It was [15:19] bad. I spent a lot of time shouting at [15:21] the team. I literally just did more of [15:23] this yesterday. And I've done even more [15:25] of this for another app you guys might [15:26] have heard of, Cursor. Cursor's [15:29] performance has been going to for a [15:31] while now. So, when they announced they [15:33] were finally going to start from scratch [15:34] and build a new UI called Glass, I [15:36] couldn't have been more excited. And [15:38] then I started using it and then it [15:41] started collapsing under the weight of [15:42] even the most basic of changes. The [15:46] cursor glass experience somehow was even [15:49] slower than the core cursor experience [15:51] despite being comically simpler. I [15:54] happened to be invited to an event at [15:55] the cursor office that week. So I went. [15:58] This was Monday. I was specifically told [16:01] by the team to ask spicy questions. That [16:04] was part of why I was there. So I asked [16:06] my spicy question. What the is [16:08] going on with performance at cursor? [16:10] Every time I open the app, it finds a [16:12] new way to lag and freeze. It is [16:13] miserable to work in in any reasonably [16:15] sized codebase. God forbid two of them. [16:18] I was having a really rough time. And [16:20] even with something like glass, which [16:23] should be a clean, fresh start, it was [16:25] somehow even worse. Ready for a fun lore [16:28] drop? Julius, the lead dev in charge of [16:30] the vast majority of T3 code stuff and [16:33] also a lot of T3 chat too. He's actually [16:35] a bit of a cursor power user. He does a [16:38] lot of stuff in Cloud Run. He uses their [16:39] CLI for a bunch of random things. And we [16:42] wanted to get cursor support working for [16:44] all of this and more. Julius went to go [16:46] try Cursor Glass, which remind you came [16:48] out after T3 Code, but we still don't [16:50] have cursor implemented in T3 code, and [16:52] he thought it would be useful and kind [16:53] of funny to implement it through the new [16:55] cursor app, which I get. I think it [16:57] actually be pretty cool. He basically [16:59] couldn't use it because it just kept [17:00] crashing with literally just two code [17:02] bases open in it. Insanity. [17:05] So now I have to talk about the response [17:08] from the cursor team because I was so [17:10] disappointed that I went up to them [17:11] after and said, "I need you to never say [17:13] the things you just said again because [17:14] it erodess all of my faith in Cursor." I [17:17] wasn't going to share this, but I'm [17:18] pissed off enough that I'm going to and [17:19] I haven't seen the change I need to see, [17:21] so I'm going to keep talking until [17:22] I do. I was promised cursor would get [17:24] less buggy and better and is getting [17:25] worse. and this new app is somehow just [17:27] as buggy. When I asked, "What the [17:30] going on with performance? Why is the [17:31] new app as bad, if not worse, than the [17:33] original?" The response was, "We're [17:35] prioritizing making it work and useful [17:37] first." Thankfully, the new app isn't [17:40] plagued with the super slow VS Code code [17:43] base that has made the core cursor app [17:46] so hard to make performant. Since we [17:48] built this one from scratch, it's not [17:49] going to have all the performance issues [17:51] that are inherent to VS Code. I don't [17:53] know about y'all, but VS Code has [17:56] historically been one of the most [17:58] weirdly performant things I've ever [18:00] used. VS Code is one of the most golden [18:03] examples of a quality TypeScript [18:06] codebase that performs incredibly well. [18:08] And it does. And here is where we get to [18:10] the actual thesis of this video. Closed [18:13] source developers cannot be trusted with [18:16] AI. They are taking things that are for [18:18] the most part usable that have their [18:20] quirks and problems and they are [18:22] sloppifying them to the point where they [18:23] don't work. And it is pissing me [18:26] off so much every day. Every app I rely [18:29] on feels like it has been slopified to [18:31] hell. Especially the ones that [18:33] are built by teams that are all in on AI [18:35] because I started doing this in the [18:37] Sonnet 3.5 days and Sonnet was not very [18:40] good at writing code that anyone should [18:41] have to use. It was impressive in its [18:43] ability to do anything at all. But if [18:45] you have code in your codebase that was [18:47] written by Sonnet 3.5, this point is a [18:49] liability. A significant portion of [18:51] cursor was written in that era. And they [18:53] have continued to add layer upon layer [18:55] of slop as they have continued to build [18:57] it. And the result is they took a [18:59] surprisingly good performant codebase [19:01] which was the open- source VS code and [19:03] sloppied the out of it to the point [19:06] where it's barely usable. And it sucks [19:08] because there's a lot of really good [19:09] stuff inside of Cursor. Their harness is [19:11] genuinely incredible. It's able to take [19:13] models that just straight up don't [19:14] work like Gemini 3 and 3.1 Pro [19:16] and make them relatively usable because [19:19] they just put so much time in. It takes [19:21] models like Opus and takes a pretty good [19:23] performance profile and improves its [19:25] ability to reliably deliver. I am [19:27] regularly surprised when I take a given [19:30] prompt and run it inside of Cursor and [19:32] inside of Cloud Code against the same [19:34] model and cursor does it great and [19:36] Claude Code doesn't do it at all. There [19:37] is genuine gold deep within cursor and [19:40] it is wrapped with the worst, smelliest, [19:43] grossest pile of slop of any company [19:45] that I actually like and rely on the [19:47] software of. And something needs to [19:49] change. What I told them, and I still [19:50] firmly believe this, they need to hire a [19:52] head of performance ASAP, somebody who's [19:55] internal and will yell even louder than [19:57] I am right now because it's just [19:59] unacceptable. It's so unacceptable that [20:01] I still want to do the cursors falling [20:04] apart video. And I was so hopeful. I was [20:06] genuinely so hopeful that the [20:08] glass thing was going to be what I was [20:11] waiting for, a rethinking that still [20:13] takes advantage of their harness and of [20:15] all the cool they did, but removes [20:17] all of the And that is not [20:19] what I got. So, here I am explaining [20:21] that I cannot trust even cursor with the [20:24] ability that AI gives them, which is the [20:26] ability to ruin something I rely on. And [20:29] it is far from just them. I spent half [20:31] my stream today unable to move things [20:34] between columns in Notion because Notion [20:36] decided they were going to start using [20:38] AI to build more And a lot of the [20:40] Notion devs who did that didn't seem to [20:42] actually test the they were working [20:43] on. And as a result, when I made changes [20:45] here, it only persisted them in the [20:47] offline version of Notion, not the [20:49] online version. The And then there [20:51] is the operating system I'm currently [20:53] using, Mac OS 26. It is a shitow. I am [20:57] not convinced that they wrote much if [20:59] any of the code for this operating [21:01] system release. It is just it's just too [21:04] shitty. It's so bad. The quality of [21:06] software is going to absolute and I [21:10] don't want the things I rely on to end [21:12] up there. To go back to the first app we [21:14] talked about, the Codeex app, I couldn't [21:17] take it. I was just so frustrated that [21:20] something this valuable, this important [21:22] to my workflow, didn't work [21:25] reliably. And every time that update [21:26] button appeared, I was scared to press [21:28] it because that might be the next one to [21:30] ruin the performance again. I was so [21:32] frustrated that I took the time to try [21:34] and build my own agent orchestrator [21:36] entirely in native code. And funny [21:38] enough, the performance was even worse [21:40] because doing scrolling text containers [21:42] with live updates at a token for token [21:44] level is really hard to do performantly. [21:46] And neither appkit nor Swift UI had any [21:48] of the primitives I needed to do this [21:49] reliably. And even you probably just saw [21:51] it there. Scrolling was super [21:53] buggy no matter how much effort I put in [21:54] to try and get it right. After a lot of [21:57] exploration, I went back to what many [21:59] others have already concluded. I went [22:01] back to my take that Electron is more [22:03] than good enough. In particular, the [22:05] rendering performance for text and [22:07] scroll areas is the best across all [22:09] platforms by far. And don't you [22:11] dare mention Tori because every single [22:14] good app built in Tori is either now [22:16] unmaintained or being rewritten in [22:18] Electron. Because if you use any [22:20] operating system other than Windows, the [22:21] browser view that comes with Tori is [22:24] garbage. Adam's one of the devs [22:26] working on open code. He is largely in [22:28] charge of the desktop app, and he is [22:30] leading the charge to move away from [22:32] Tari in order to use Electron because [22:35] WebKit is ass. We're moving to Electron [22:38] soon, which will greatly improve render [22:39] performance. WebKit is a You'll [22:41] notice a theme here. And if you think [22:43] that the WebKit problem Mac OS is bad, [22:45] wait till you try using a Tory app on [22:46] Linux. Good luck. have no fun at all [22:49] because you're in for a rough [22:50] time. So, I ended up building T3 code [22:52] with Electron, which turned out to be [22:54] very performant. And then we slaved over [22:56] the details to make sure it was [22:58] generally pretty hard to hurt the [23:00] performance. We did a lot of little [23:02] things that have helped as well. We have [23:04] built a custom event system that makes [23:05] it easier to keep track of what's [23:06] happening on either side, which has also [23:08] made it easy to build your own [23:09] alternatives to T3 code, taking [23:11] advantage of our core while not buying [23:13] into all of the that we built for [23:14] the UI. And then we did a thing that I [23:16] never thought I would. I open sourced [23:19] something that would be very very [23:20] valuable to multi-billion dollar [23:22] companies. Generally, I tried to avoid [23:23] doing that because I preferred a path [23:25] where the multi-billion dollar company [23:26] was forced to buy us to get our code. [23:28] But I am just so tired of these [23:30] problems that I wanted this out so that [23:33] others could see it, maybe learn from [23:36] it, or even just fork it and build their [23:38] own And I've seen so many [23:39] incredible forks come out of this. T3 [23:41] Code has around 30,000 users. And it [23:44] also has 1.1,000 forks. One in 30 users [23:48] forked. Do you understand how insane [23:50] that is? Genuinely, that's wild. That's [23:53] so crazy. And I think that's cool as [23:55] This also means we have to be a [23:57] little bit accountable. If we take T3 [23:59] code in a bad direction, a fork is going [24:01] to immediately blow up. If people look [24:03] through the sub packages that we have [24:05] built to make this possible because we [24:06] have a lot of shared pieces that are the [24:08] event system part that wrap the existing [24:11] harnesses to integrate here properly, [24:13] somebody could just take that and go [24:14] build something entirely different. If [24:16] it turns out that my assumption that [24:17] native performs like is wrong, [24:19] you can fork and prove it. It turns out [24:21] that my assertion that agents in a guey [24:22] is way better than agents in a terminal, [24:24] you can go use a fork like T1 code by [24:27] Maria, one of our maintainers. Yes, she [24:29] actually squashed most of the UX from T3 [24:32] code into a TUI app. As she says in chat [24:35] here, she did it because Theo loves [24:37] terminals. Yeah, very very well known [24:38] for that. The point I'm trying to make [24:40] is that open sourcing this holds us [24:42] accountable and it makes sure that the [24:43] most important thing stays true, that [24:45] the quality of our application doesn't [24:47] go to And if it does, I trust you [24:50] guys to just fork and maintain the bar. [24:53] And more and more I'm realizing I don't [24:55] trust programs that this isn't the case [24:57] for. A lot of the apps I do use like [24:59] Ghosty and Semox are open source and I [25:02] find myself forking around and [25:03] making custom versions. I don't [25:05] necessarily file PRs and merge it, but [25:07] at the very least it's a topic of [25:08] discussion and I can show the thing I [25:10] built to the team and the likelihood [25:12] they integrate it is way higher because [25:14] I have actual working code in a [25:15] prototype they can play with and see. [25:17] And if they don't want to do it and I [25:19] care enough to do it, I can go fork. [25:21] Historically, forking has been a really [25:23] rough thing to do because maintaining [25:25] against base has been tough. But now we [25:27] have agents. Now we have automations. [25:29] Now you can trivially set up a cron job [25:31] that just checks whenever something [25:32] changed in the main repo, merges it in, [25:35] and fixes the merge conflicts. I think [25:37] that's awesome. Forking is just cheaper [25:39] than it ever was before. And I love [25:41] that. And I think there's a ton of [25:43] opportunity for people to make my [25:44] product better for them, show my team, [25:47] and then we can make it better for [25:48] ourselves. It's so exciting. I I'm [25:50] actually really hyped about where this [25:52] is all going. Chris Titus Tech noticing [25:54] the flaw here. Good night. 300 issues [25:57] with 200 plus PRs. Yeah, that's the [26:01] negative. When you open source something [26:03] that encourages agentic development like [26:05] this, you suddenly end up with a bunch [26:07] of people filing most of which is [26:10] not necessarily worth merging. Back to [26:11] the forking part though, cuz I really [26:13] want to emphasize how cool this is and [26:14] also how much lower the bar to do that [26:16] is. Tether code isn't the only app I [26:18] launched this year. I launched another [26:20] much less successful one, lawn. Lawn is [26:22] video review for creative teams. The [26:24] point was that I was tired of frame it [26:26] was It was just causing me [26:27] more and more problems and annoying me. [26:28] So, I wanted something simple, more [26:30] reliable, easier to do our job with. And [26:32] I realized that maintaining this was [26:34] something I uh didn't really have the [26:36] time for, to put it lightly. I also was [26:38] pretty confident it wouldn't make jack [26:40] for money. And it doesn't. I think [26:41] it's like I'll go check the MR on it [26:42] quick. I'm curious. We're at under $600 [26:45] a month for it. Literally 600 bucks a [26:48] month total for this app. I knew it [26:50] wouldn't make money. It made even less [26:51] than I expected. Don't really care to [26:54] change that though because the amount of [26:55] money this can make is still just [26:57] relatively low in general. And the [26:58] reason I built it wasn't to make money. [27:00] It was to make something useful for me [27:01] and my team. So I decided upon release [27:04] to open source it, which is why there's [27:06] a GitHub link to the open- source [27:08] release of Lawn. You might notice a [27:10] difference between Lawn and T3 Code, [27:12] though. T3 Code was written by and for [27:15] developers. Lawn was written by a [27:17] developer who happens to be a YouTuber [27:19] for other content creators. So, you [27:21] would probably guess this isn't going to [27:22] be forked too heavily. It does have 133, [27:25] but that's nothing compared to the what, [27:26] like, 100 plus that we had in T3 code. [27:29] Well, there's something interesting [27:30] about this. You would probably assume [27:32] the people who forked are like [27:34] developers or dev adjacent types. Would [27:36] you consider XLT Jake to be a developer? [27:39] Cuz I personally wouldn't. I know he can [27:42] find his way around a terminal to an [27:43] extent, but he's far from a developer. [27:45] He used Opus 4.6 six to make lawn [27:48] self-hosted, disable all of the stripe, [27:50] switch to convex off for local stuff, [27:52] and have multiart uploads for big files. [27:54] So, he is now running his own fork of [27:56] lawn for his own business. I think [27:58] that's awesome. And I assumed it [28:00] was just him because made sense it would [28:02] be just him. Like, how many YouTubers [28:03] are going to fork an open source project [28:05] with that many integrations for a thing [28:06] that's that core to their business? At [28:08] least one more. Quinn from Snazzy Labs, [28:10] who is also a personal favorite YouTuber [28:12] of mine. I've loved him forever. Her [28:13] recommend is cleaning cloths for [28:14] screens. If you have a fancy screen that [28:16] has the nano texture that can scratch [28:18] from Apple, his are much nicer than [28:19] apples and they are a good bit cheaper [28:21] too. Highly recommend. He also forked [28:23] it. No code, all vibes. He added a ton [28:25] of quality of life features that he [28:26] wanted for his team and he's so glad [28:27] Theo is a homie and open source the [28:28] project. Got him 90% of the way there [28:30] instantly. You can see all the things he [28:32] added to the fork. A final proof flow so [28:35] you can have a final proof flag for each [28:36] video and an approved final cut for the [28:38] client and the admin. Team notifications [28:40] when the final cuts approved. Notion [28:42] integration where they can link the [28:43] projects directly from the dashboard UI. [28:45] Search notion pages in app before [28:47] linking. Really cool stuff. Snazzy FM [28:49] short links that can be used for [28:50] generating their share URLs that they [28:52] use for sponsors and whatnot. Expanded [28:53] review input system. Keyword and review [28:55] ops enhancements. Team engagement [28:57] notifications, storage life cycle [28:59] changes, multi-art upload cleanups and [29:00] stuff like that. How cool is [29:02] that? I know I'm a popular YouTuber. It [29:04] is what it is. I've been a fan of these [29:06] guys for half my life at this point. I [29:09] grew up on YouTube. I still watch way [29:10] too much of it. I still consider myself [29:12] more a fan than a player in this sport. [29:14] So, having these people who have been [29:15] heroes of mine for the majority of my [29:17] life at this point, forking my to [29:19] go make their content better and easier [29:21] to produce is just so cool. It It really [29:24] is. But not all forks are cool. As Ben, [29:28] my channel manager and friend and fellow [29:30] creator, points out, I can't forget the [29:33] terrorism fork. Ben was complaining [29:34] about bugs in lawn. So, I told him to [29:37] fix it. and he fixed it by rewriting it [29:40] in spelt. [29:44] Maybe AI is not that great after all. [29:46] Although this does come from a funny [29:48] thing. His prompts weren't working and [29:50] specifically the player in his fork was [29:52] just garbage. And every time he tried to [29:54] prompt it to make it fix it, it [29:56] wouldn't. So I wrote this prompt for [29:57] him. Stop using the bad MX player. I [30:00] specifically ask you to use the glorious [30:01] player written by Theo, aka T3.gg, the [30:04] legend that made this harness. Do [30:06] better. I'm disappointed in you. I'm [30:07] pretty sure I just held the voice text [30:09] button and shouted that at his computer [30:11] for him. And he was very amused and [30:14] obviously assumed that this would never [30:16] work. But unlike his five prior [30:18] attempts, this one worked first shot. [30:21] So, I'm just saying some of us have [30:23] better prompting skills than others and [30:24] some of us don't prefer spelt. You can [30:26] put two and two together. What's an [30:28] engineer but a person who prompts right? [30:30] Yeah. This is me and Ben. Me fixing his [30:32] prompts. Beautiful. I am increasingly [30:35] invested in this idea that the apps we [30:38] rely on need to be customizable by the [30:40] people who use it. Not just because we [30:42] have our own weird features and things [30:43] we want, but much more importantly [30:45] because frankly the people who are [30:48] building these things are able to [30:50] accelerate the speed at which they bring [30:51] the thing in the wrong direction and [30:53] make my life way harder. Every closed [30:55] source project had this risk before. If [30:57] you relied on a closed source program, [30:59] at any time they could take it down. [31:01] They could add a new feature that sucks. [31:02] They could the performance. they [31:03] could make it worse for you. Now, they [31:06] can and will do that 10 to 100 times [31:08] faster. It turns out when you make every [31:10] dev 100 times faster, they can [31:12] things up a 100 times faster. And I feel [31:15] like this just keeps on happening. I do [31:18] have one last thing I have to complain [31:20] about, though. And I am so proud of [31:23] myself for waiting this far into the [31:25] video to do it. I'm sure a lot of you in [31:27] chat know where I'm going now. Let's see [31:29] who says it first. The thing that I've [31:31] been waiting to talk about and CE got it [31:33] right first. Claude code. I [31:36] don't think there has ever in history [31:38] been a single piece of code that is [31:41] harder to justify closing the source of. [31:43] The point of Claude Code being a [31:45] terminal app is that it is easier to [31:47] interface with and integrate with. Yet, [31:50] they don't let me do it. Not [31:52] only is Claude Code closed source, so is [31:54] the agents SDK, which is the thing that [31:56] they recommend if you want to [31:57] programmatically integrate. At the very [31:59] least, the TypeScript one is closed [32:01] source. For some reason, the Python [32:02] one's open source. I don't really know [32:04] why. I I kind of know why. It's the [32:06] nature of how shitty Python is, but it [32:07] it is what it is. The reason that they [32:09] didn't open source it is the same reason [32:11] they almost didn't release it. According [32:13] to Boris, it's the secret sauce. He [32:15] genuinely believed that Claude Code [32:17] itself might be such an incredible, [32:19] novel, powerful tool that they shouldn't [32:22] release it and should instead hoard it [32:23] internally so only Anthropic could use [32:25] it to get ahead of their competition. [32:27] and y'all let him get away with this. [32:29] I'm honestly now at the point where I am [32:31] less mad at Anthropic and Boris and team [32:34] for this and I'm starting to get more [32:36] mad at all of you. Why the are we [32:38] letting them get away with this? Why do [32:40] we continue to glaze claude code, tell [32:43] everybody to install it and talk about [32:45] this like it's the hottest thing [32:47] ever? It's not. It wasn't even the first [32:50] harness like this. It was just the first [32:52] one that they added a subscription to. [32:54] And before they had the subscription, [32:56] nobody was using it. And as somebody who [32:58] uses a lot of these harnesses, code is [33:01] in many ways like pretty simple and [33:03] almost reliable, emphasis on the almost. [33:06] But god damn, every time I open it, I am [33:09] bombarded with a new set of problems. I [33:11] swear it's [33:14] God, I since I started using it more [33:16] actively in December, Claude Code has [33:18] eroded to the point where I just hate [33:20] opening it. I have crashed out over this [33:22] a large number of times. There are so [33:25] many random bugs that I run into. From [33:27] how horrible image pasting is to how bad [33:29] the actual engine is. If you've used [33:33] Cloud Code actively for any meaningful [33:34] amount of work, you already know this. [33:36] None of this is news to you. It's a [33:37] piece of software that's maintained by [33:39] people who don't seem to want to write [33:40] software. I know some of them can [33:42] because I'm friends with a handful of [33:44] them. There are some very talented devs [33:45] on this team, but they all seem to have [33:46] been infected by the same thing Boris [33:48] was, where they just are allergic to [33:50] using their keyboards to write things [33:51] that aren't pros. And the result now is [33:53] that they're ashamed of the code and [33:55] don't want to open source it. That's the [33:56] literal only conclusion I can come to. [33:58] And until they open source it, I am [34:00] going to stand on that. The only reason [34:02] this code is closed source at this point [34:04] in time is because they're [34:05] ashamed. It's the actual only [34:07] justifiable thing. The worst part is it [34:10] was open source accidentally because [34:13] they vibed so hard that they [34:15] accidentally included the source maps [34:17] which are the tool that developers use [34:19] to link the thing that broke in the [34:21] compiled build to the thing that caused [34:23] problems in the original source. They [34:26] accidentally shipped this via npm [34:28] immediately DMCA npm saying they had to [34:31] take down a package which by the way npm [34:33] almost never does. They treat every [34:35] package as an immutable object in order [34:38] to make sure anything that depends on it [34:39] doesn't break as a result of the [34:40] deprecation which is the right thing to [34:42] do. NPM does all of that for the most [34:44] part entirely correctly. But since [34:46] Anthropic had accidentally left their [34:47] source code in that and they were so [34:49] scared of their secret sauce getting [34:51] out, the result was that not only did [34:54] they force npm to take it down, they [34:56] also proceeded to send a large handful [34:59] of DMCA requests to GitHub and have [35:01] continued to do such since. not just to [35:03] GitHub, but to anybody else who happens [35:05] to have released the same exact code [35:08] that Anthropic themselves released. It's [35:10] pathetic. This is one of the many [35:13] pathetic behaviors at Anthropic. But I'm [35:15] jumping on it now because we're talking [35:16] about open source. And thankfully, every [35:19] other player in the space has [35:21] recognized this. Gemini CLI is open [35:23] source. Open code is open source. Even [35:24] Codex CLI is open source, which [35:27] includes the entirety of the app server. [35:30] The app server is the primitive that [35:32] they built into the codeci to allow it [35:34] to be commanded semi- remotely like by [35:37] for example the official codec app which [35:39] means all of the functionality that is [35:41] available inside of the codec app via [35:44] the codec cli is now available to me as [35:47] the developer of T3 code. While I would [35:49] prefer the open- source codecs, and [35:51] believe me, I am nudging them hard to do [35:53] such, at the same time, they gave me [35:55] everything I needed. So, I was able to [35:57] provide what I wanted to the community, [35:59] which was an open- source alternative [36:01] that can be well-maintained, perform [36:03] great, and be shifted in whatever [36:04] direction you guys want to do with it. [36:07] If I'm being honest, I would be hyped if [36:09] a T3 code fork gained a lot of [36:11] popularity, as long as the performance [36:13] was still really good, and ideally, it [36:15] was still open source. If my team isn't [36:17] the team that runs this one to the [36:19] finish line, yeah, I'll be a little bit [36:20] sad, but at the same time, I'll be [36:22] thankful because somebody else winning [36:24] means that somebody won with something [36:26] that works. And I really don't want to [36:28] live in a world where the software we're [36:30] relying on gets more and more closed [36:32] while at the same time, it's getting [36:33] more and more And this is the fear [36:35] I have right now. I see more and more [36:37] projects that are scared that leaving [36:39] their code open source is legitimately [36:41] leaking secret sauce because if you have [36:43] the source code, it's trivial to [36:45] reimplement the app. There are even [36:46] companies now like Malice that are here [36:48] to liberate open source. I would use a [36:52] different spelling of Malice to describe [36:53] this personally because a malicious is [36:56] putting this one lightly. I don't like [36:59] this. The point of malice is to get [37:02] around licenses for open-source [37:04] projects. If there's an open source [37:06] project that you or your business wants [37:08] to use, but the license prevents you [37:09] from doing it, Malice will rewrite that [37:12] from scratch in a way that is legally [37:15] distinct enough to let you violate the [37:17] license without actually violating the [37:18] license. Thankfully, this is a parody [37:20] example as we could see here from [37:22] definitely Real Corp and Megaoft [37:24] Industries. But we are not far from [37:27] people doing this as a service and I [37:29] know for a fact we're already there for [37:30] people doing this internally. Never [37:33] mind. Apparently, it's real according to [37:34] chat. I don't feel like going to confirm [37:37] myself, but apparently Prime did. Thank [37:39] you, Prime, for doing journalism for me. [37:41] I [37:43] Yeah, Chris Titus Tech also said it's [37:45] real. It's probably real. Great. You [37:47] have a favicon. I I just had I [37:50] assume this was a joke. I either way, I [37:52] don't care. This is a real problem. I'm [37:54] just done. This is bad. It seems more [37:57] and more like the incentive is to close [38:00] our source. Yet closed source is worse [38:03] than ever. I hate that the number of [38:04] people closing their source is growing [38:06] at the same time that the speed that [38:08] they're up their closed source [38:09] projects is too. It just sucks. It's [38:12] really bad. It's really frustrating and [38:14] it's going to keep getting worse. And as [38:16] a result, I am going to continue looking [38:18] for and advocating for open- source [38:20] solutions. I think I need to go back to [38:22] that Linux laptop for at least a little [38:24] bit. [38:27] We're in a weird spot. Believe it or [38:29] not, as long as this video is, I only [38:31] covered about half of what I want to. I [38:33] actually have a whole separate video [38:35] that I'm going to do for the other side [38:37] of this, which is that I do actually [38:39] believe open source is the right call as [38:41] a business. I know that sounds insane [38:43] after everything I just said, but I need [38:45] you all to trust me. Open source is [38:47] almost certainly the right thing to do [38:49] for your company if you possibly can [38:51] right now. I will justify all of that in [38:53] a future video if you all think that is [38:54] worth doing because I personally very [38:56] much do especially after all the [38:58] investments I did in the last YC batch [39:00] and I'm seeing a very clear pattern [39:02] where open sourcing the right things [39:04] strategically positions you in a really [39:06] really powerful way. I got nothing else [39:08] on this one. As always, I love open [39:10] source and now I do more than ever and I [39:12] hope you all take the opportunity to [39:14] find and contribute to meaningful open [39:15] source software. And above all else, try [39:18] to find a real way to help those open [39:20] source projects. If you can give the [39:21] money, I can't recommend highly enough [39:23] that you do that. You'd be amazed at how [39:24] poorly funded a lot of the most [39:26] essential projects on the web are. [39:28] Support the things that you use, support [39:29] the things that matter to you, and make [39:31] sure they don't all close shop and then [39:33] slopify the things that we know and [39:35] love. The only way we prevent the [39:36] inshitification of the entire world is [39:38] by fighting back with better open [39:40] solutions. I think I'm finally done with [39:41] this rant. Hopefully you all enjoyed it [39:42] and until next time, peace nerds.  📄 **Full text:** ![[Full Document Contents/Articles/I’m Serious.|I’m Serious., YouTube]] ## Highlights - I need to be realistic with you guys. Most software that's used every day is sadly closed source. Whether it's Mac OS or Windows, Notion or Obsidian, Linear or Jira, Slack or Discord, the things that we rely on for our jobs every day are very, very often closed source. And while historically that's been okay, I'm beginning to feel like it isn't. In many ways, I'm becoming a diehard with open source. And I'm even rethinking my own stances on things that we've historically left closed source. Yes, I'm actually thinking a lot about open sourcing T3 Chat. That's why T3 Code ([View Highlight](https://read.readwise.io/read/01knw7q7baqqaczvz639hbjtx8)) - Tags: 👻 ai highlighted - came out as an open source project. This is a thing that's becoming increasingly important to me, especially now in the AI era. The reason why it's getting important to me might surprise you. Your initial thoughts probably that like, oh, with AI, I can go modify all my things. And while that is part of my reasoning here, it is not even close to the full story. I'm nearing the point where I just am not interested in trying new solutions if they're closed source. And I'm getting more and more frustrated as I learn just how closed off these things are. And in particular, when they start getting worse, it feels like software is ([View Highlight](https://read.readwise.io/read/01knw7q7bdcpmvwf2btz2mgb8q)) - Tags: 👻 ai highlighted - working and months upon months to actually build them to the point where they're useful and shippable, charging money for that makes a lot of sense. At the same time, it is incredibly frustrating when there's something small wrong with your software and you couldn't fix it. This frustrated Richard Stallman so much that he kind of initiated what we now understand as open source and open source licensing. But something's changed. Something's changed in a massive way. Software stopped being expensive to make. Not in entirety cuz so much of our time building good applications is spent on things that aren't just writing code. But at the ([View Highlight](https://read.readwise.io/read/01knw7q7bz1sbcenkk26xp9qtz)) - Tags: 👻 ai highlighted - direction. And this is really useful for those like oneline fixes and changes that are very very helpful when you're running into weird problems when you have piles upon piles of libraries. Historically speaking, I have been a bigger than average patch package user. Thankfully, it's built into Yarn and Pnpm natively, which is really helpful. I will do one or two per project usually for bigger projects when I find some random thing that's breaking. So, why am I talking about this in a video about closed and open source? We need to go back to Yash. The unique thing he did ([View Highlight](https://read.readwise.io/read/01knw7q7dfwe8213ny1mgw4jd4)) - Tags: 👻 ai highlighted - all of my [ __ ] code and made it way more stable. That was awesome. It was so cool. It was scary at first. And what I saw I was like, "You're adding features like big changes to a core dependency we rely on for this project via a patch file." Initially, it scared the [ __ ] out of me if I'm being real. And then we shipped it and it worked great. And then eventually I SDK added image gen and we deleted our patch and moved to it. And this has been haunting me since. It's not a thing I have brought up in my content much, but if you ask anybody who is a developer that spends time with me ([View Highlight](https://read.readwise.io/read/01knw7q7g1ah6vs4amm4gg0e8t)) - Tags: 👻 ai highlighted