Agentic Coding Has A HUGE Problem - CourtneyR.dev's 2nd Brain

Agentic Coding Has A HUGE Problem 🔗 **Source:** [Agentic Coding Has A HUGE Problem](https://www.youtube.com/watch?v=YVq28OTPCKw) > [!note]+ Document Notes > tags: [developer-workflow, agentic-coding, developer-experience] > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=YVq28OTPCKw > date created: 2024-12-19 14:30 > > # 🏷️ Title: Agentic Coding Has A HUGE Problem >  ## 🧰 Action Inbox - [H1] Evaluate current multi-project development workflow — assess window management pain points #workflow - [H2] Test localhost port/cookie collision issues — document OAuth redirect problems #debugging - [H3] Explore desktop/workspace management solutions — before scaling agentic development #productivity ## 🧭 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 - [Sentry Agent Dashboard](https://soyv.link/entry) - [Codex UI](https://codex.com) ## 📝 Summary - Developer workflow breaks down when scaling from single to multiple parallel projects using agentic coding tools - Traditional single-project mental model (terminal/editor/browser) fails with multiple long-running AI tasks - Key technical issues: localhost port conflicts, OAuth redirects, shared app storage across ports - Current solutions (tmux, Docker, in-browser IDEs) don't address core window management and context switching problems - Background agents gain popularity partly due to local development workflow pain rather than inherent superiority ## 📖 Main Content Theo explores a critical UX problem with modern agentic coding: while AI tools enable parallel development across multiple projects, our traditional development environment wasn't designed for this workflow. The core issue stems from splitting project context across separate applications (terminal, editor, browser) that worked fine for single projects but becomes chaotic with multiple parallel workflows. Technical problems include localhost treating all ports as the same host (breaking OAuth and cookies), port collisions, and difficulty tracking which terminal/browser tab corresponds to which project. Traditional solutions like tmux, Docker, or in-browser IDEs address symptoms but not the fundamental context management problem. The video argues that background/cloud agents are popular partly because they avoid these local workflow issues, though they may reduce code quality through less hands-on interaction. Theo calls for experimentation with new development environment paradigms rather than incremental fixes to existing tooling. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/YVq28OTPCKw?t=0) — [H1] Unprecedented building velocity with AI - Key idea: AI enables building multiple projects simultaneously across various domains - Evidence: "I don't think I've ever been building as much as I am right now" #### ⏱️ [02:15](https://youtu.be/YVq28OTPCKw?t=135) — [H2] Sentry agent observability sponsor segment - Key idea: Agent debugging requires specialized observability tools for arbitrary tool calls - Evidence: "48 errors, two LM calls, one tool call, and 29K tokens generated" #### ⏱️ [04:30](https://youtu.be/YVq28OTPCKw?t=270) — [H1] Traditional single-project workflow paradigm - Key idea: Mental model of terminal/editor/browser worked when contained under one project - Evidence: "Your terminal, your editor and your browser are all part of your mental model for managing this one project" #### ⏱️ [06:45](https://youtu.be/YVq28OTPCKw?t=405) — [H2] Multi-project workflow breakdown demonstration - Key idea: Window management becomes chaotic when scaling beyond single project - Evidence: Demonstrates tabs, windows, desktop switching creating navigation confusion #### ⏱️ [09:20](https://youtu.be/YVq28OTPCKw?t=560) — [H3] macOS workspace switching failures - Key idea: Built-in workspace management has fundamental UX flaws for development - Evidence: Shows flickering between windows, wrong focus targets, slow navigation #### ⏱️ [11:10](https://youtu.be/YVq28OTPCKw?t=670) — [H1] Long-running agent tasks enable parallelism - Key idea: Hour-plus build times make single-project focus inefficient - Evidence: "I often have a job running with codecs that takes one to two hours" #### ⏱️ [13:25](https://youtu.be/YVq28OTPCKw?t=805) — [H2] Terminal context loss problems - Key idea: No visual indication of current project context in most terminal setups - Evidence: "Where am I? Where in the world am I right now? What project am I inside of" #### ⏱️ [15:40](https://youtu.be/YVq28OTPCKw?t=940) — [H1] Localhost technical limitations - Key idea: Localhost app storage shared across all ports breaks multi-project development - Evidence: "local hosts app storage data in the browser is shared across all ports" #### ⏱️ [17:15](https://youtu.be/YVq28OTPCKw?t=1035) — [H2] OAuth redirect port collision issues - Key idea: OAuth configurations break when projects use different ports than expected - Evidence: "if you set up your O to redirect to either localhost 3000...and now you have localhost 3000 in 12" #### ⏱️ [18:30](https://youtu.be/YVq28OTPCKw?t=1110) — [H3] Real workflow interruption scenario - Key idea: Notification sounds from wrong context create constant workflow disruption - Evidence: Describes ding notification scenario requiring hunt across terminal tabs and browsers #### ⏱️ [20:45](https://youtu.be/YVq28OTPCKw?t=1245) — [H2] Why common solutions don't work - Key idea: Tmux, Docker, built-in terminals don't address core context management issues - Evidence: "T-Mux is recommended to me a lot...I've been using GNU screen since before most T-Mux fans were born" #### ⏱️ [23:20](https://youtu.be/YVq28OTPCKw?t=1400) — [H1] Background agents as workflow workaround - Key idea: Cloud/background agent popularity stems from local development pain rather than superiority - Evidence: "a lot of the hype around these features is because of how hard it is to do that type of parallel work locally" #### ⏱️ [25:50](https://youtu.be/YVq28OTPCKw?t=1550) — [H1] Call for experimentation rather than single solution - Key idea: Need diverse approaches to development environment design - Evidence: "There is no single correct solution. We need lots of them" #### ⏱️ [26:40](https://youtu.be/YVq28OTPCKw?t=1600) — [H2] Linux solution teaser - Key idea: Found potential solution in Linux environment (future video topic) - Evidence: "there's a good chance that the next time you see me...I might be using something that looks very, very different" ## 📚 References - [Sentry Agent Dashboard](https://soyv.link/entry) - [Original blog post - 1.2M views](https://example.com) - [Codex UI](https://codex.com) ## 🗣️ Paraphrase - Modern AI coding tools enable unprecedented parallel development but expose fundamental flaws in traditional development environments designed for single-project workflows - The core problem is context management across separate applications (terminal/editor/browser) when juggling multiple long-running AI tasks simultaneously - Technical issues like localhost port conflicts and OAuth redirects compound the workflow management problems, making popular solutions like background agents attractive for the wrong reasons - The solution requires rethinking development environment paradigms rather than incremental improvements to existing tooling ## 📰 Newsletter **The Hidden UX Crisis in AI Development** As agentic coding tools enable developers to work on multiple projects simultaneously, we're discovering that our development environments weren't designed for this parallel workflow. Theo's latest exploration reveals how traditional terminal/editor/browser setups break down when scaling beyond single projects. **Key Technical Challenges:** - Localhost treating all ports as one host (breaking OAuth and cookies) - Port collisions requiring constant manual management - Context switching chaos across multiple terminal tabs and browser windows - No visual indicators for current project context **Why This Matters:** Popular solutions like background agents and cloud environments may be gaining traction not because they're superior, but because they avoid these local development pain points. However, this could reduce code quality through less hands-on interaction. **The Path Forward:** Rather than Band-Aid solutions, we need fundamental rethinking of development environment design. The industry needs diverse experimentation with new paradigms that treat multi-project parallel development as a first-class workflow. Resources: [Sentry Agent Observability](https://soyv.link/entry), [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/) ## ✅ Action Items #### DevRel - Developer experience: Document multi-project development workflow patterns, best practices guides - Education: Workshop on managing parallel development environments, context switching strategies - Developer marketing: Survey developer workflow pain points, agentic tool adoption barriers - Community management: Forum discussions on development environment setups, tool recommendations #### OSPO - Developer Support: Training on container orchestration alternatives, workspace management tools - Strategic Alignment: KPIs for developer productivity in multi-project environments #### Community - Contributors: Onboarding documentation for managing multiple WordPress project workflows - Ecosystem: Cross-project coordination tools, standardized development environment configs #### WordPress - Core: Performance impact of multiple local WordPress instances, port management - CLI: Commands for project workspace management, context switching helpers - Meta: .org development environment standardization, contributor workflow optimization - Documentation: DevHub guides for parallel development, local environment best practices ## 🧪 Hypotheses - Background agent adoption correlates more with local workflow pain than actual productivity benefits - Localhost technical limitations (shared storage, OAuth) significantly impact developer productivity in multi-project scenarios - Traditional window management paradigms become exponentially more problematic with each additional concurrent project - Visual context indicators in development tools would significantly reduce cognitive overhead in multi-project workflows ### 📊 Methodology - Telemetry analysis comparing single vs multi-project development session patterns - A/B testing of different workspace management approaches with developer productivity metrics - Survey correlation between background agent usage and reported local development workflow issues ### ❓ Questions - How do different operating systems handle multi-project development workflow management? - What metrics best capture the productivity impact of context switching in development environments? - Can standardized development container configs mitigate localhost technical limitations? ### 🔮 Future Research - Comparative analysis of development environment paradigms across different programming ecosystems - Investigation of Linux-based solutions for development workflow management - Exploration of browser-native development environment isolation techniques ### 💡 Implications - Practice: Multi-project development requires fundamental workflow architecture changes, not incremental tool improvements - Policy: Development environment standards may need updating for agentic coding era - Education: Developer onboarding should include parallel workflow management training - Funding: Investment in development environment UX research could yield significant productivity gains ### 🧠 Learning Styles Assessment Reading level estimate: 8th grade #### 👀 Visual learners - Present: Window management demonstrations, screen recordings of workflow problems - Improve: Architecture diagrams of different workspace management approaches #### 🔊 Aural learners - Present: Video format with narrated explanations - Improve: Podcast version focusing on workflow strategy discussions #### 🗣️ Verbal learners - Present: Clear explanations of technical concepts, analogies for workflow problems - Improve: Glossary of development environment terminology #### 🧩 Kinesthetic learners - Present: Hands-on demonstration of workflow problems - Improve: Step-by-step guides for testing different workspace management solutions #### 🧠 Logical learners - Present: Structured problem analysis, cause-and-effect relationships - Improve: Decision tree for choosing workspace management strategies #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion prompts, shared experience validation - Improve: Developer workflow study groups, collaborative solution testing #### 🧘‍♀️ Solitary learners - Present: Individual workflow assessment opportunities - Improve: Self-evaluation checklist for development environment optimization #### 🌿 Naturalistic learners - Present: Ecosystem thinking about development environment interactions - Improve: Holistic workflow optimization approaches ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive content - Improve: Alt text for workflow demonstration screenshots #### Keyboard navigation - Present: Standard video player controls - Improve: Keyboard shortcuts for workflow tools mentioned #### Contrast and readability - Present: High contrast video content - Improve: Text transcript with proper formatting #### Media and captions - Present: Auto-generated captions available - Improve: Professional captions with technical terminology accuracy ### 🌍 DEIB Assessment #### Cultural breadth - Present: Universal developer workflow challenges - Improve: Examples from different development cultures, tool preferences #### Inclusive language - Present: Technical focus without exclusionary terms - Improve: Acknowledgment of different accessibility needs in development environments #### Neurodiversity support - Present: Recognition of ADHD-friendly workflow patterns - Improve: Multiple cognitive approach strategies for workflow management #### Representation - Present: Single perspective from experienced developer - Improve: Diverse developer workflow experiences and solutions ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from single-project to multi-project workflow breakdown - Inductive strength: Generalizes from personal experience to broader developer community issues - Causal reasoning: Identifies technical root causes behind workflow problems - Analogical strength: Effective comparison between traditional and parallel development paradigms #### Fallacies - Anecdotal evidence: Heavy reliance on personal experience, though validated by community response - False dilemma: May oversimplify solution space by dismissing traditional tools too quickly #### Tone of voice - Overall tone: Frustrated but constructive, technical expertise combined with practical urgency ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on accusers - Reverse victim/offender: No victim/offender dynamics - Emotional cues and rhetoric: Genuine frustration with technical limitations, call for collaborative solutions ## 🎯 Conclusion The rise of agentic coding tools has exposed a fundamental mismatch between our development environments and modern parallel workflows. While AI enables unprecedented building velocity across multiple projects, our terminal/editor/browser paradigm breaks down under the complexity of context switching and technical limitations like localhost port conflicts. The popularity of background agents may reflect local workflow pain rather than inherent superiority, potentially at the cost of code quality. Rather than Band-Aid solutions, the industry needs diverse experimentation with development environment paradigms designed for multi-project parallelism as a first-class workflow. The path forward requires acknowledging that incremental improvements won't solve architectural mismatches, and investing in fundamental rethinking of how developers interact with their tools in the agentic coding era. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Agentic tools enable unprecedented parallel development > [!quote] [Agentic Coding Has A HUGE Problem](https://www.youtube.com/watch?v=YVq28OTPCKw) by [[Theo - t3․gg]] via [[YouTube]]. Published 2024. Accessed 2024-12-19. > "I don't think I've ever been building as much as I am right now." Context: Demonstrates how AI coding assistants remove traditional bottlenecks allowing multiple concurrent projects. [view highlight --- ## Full Transcript [00:00] I don't think I've ever been building as [00:01] much as I am right now. Obviously, AI [00:03] has been helping a lot, especially [00:04] because I have like four other jobs. [00:06] Yes, YouTube is one of them. Running my [00:07] company is one of them. Managing all of [00:09] the other companies I work with is one [00:10] of them. And I do a lot. So, it's [00:12] surprising I can build it all, much less [00:14] how much I've been building. And this [00:16] has been super fun. I don't think I've [00:18] ever enjoyed building software as much [00:19] as I do now. These agentic tools make it [00:22] so easy to do lots of things at once at [00:24] scale and build things that I never [00:26] would have imagined. I have lawn, which [00:28] is my new video review tool meant to [00:29] replace frames so we can get Adobe out [00:31] of our lives. I have Shu, which is a new [00:32] way to do O across your projects because [00:34] having a lot of O setups across things [00:36] is annoying. This isn't meant to be the [00:38] greatest O library ever. It's meant to [00:39] unblock you so you can get back to work [00:41] by just having a simple Google sign-in [00:43] button. I have T3 Canvas, which is my [00:44] new image editing tool that I'm actually [00:46] hoping to merge a lot of into T3 chat [00:47] eventually. But more importantly, it's [00:49] something I use every day for everything [00:50] from icons for the projects I'm building [00:52] to concepts for thumbnails that I'm [00:54] working on. It's really useful. And then [00:56] this one that will take a bit before I [00:58] can share more, the FS2 CLI. This is my [01:00] attempt at doing file syncing on a lower [01:03] level. And yes, this whole project is [01:05] written in Rust. I also have two Swift [01:07] projects I'm working on. I've been [01:09] contributing to a ton of stuff. I've [01:10] just been building and touching more [01:12] [ __ ] than ever. So, what's the problem [01:14] then? Why are you watching a video that [01:16] is meant to be about the issues that I'm [01:18] having with this? Clearly, it's working, [01:20] right? No. In fact, the problems I'm [01:23] having were so great that I took the [01:25] time to sit down and write an article to [01:28] complain about it. I've been thinking a [01:29] lot about these UX problems, and [01:31] apparently others have too, which is why [01:32] this post got 1.2 million views and [01:35] everybody from Microsoft execs to vibe [01:37] coders reacting to it. I have a lot to [01:39] say about these UX problems. I've been [01:40] thinking about them a ton, and I might [01:42] actually have some solutions in mind as [01:44] well. Do you know what doesn't have any [01:46] of these problems, though? Today's [01:47] sponsor. You've already heard about [01:48] today's sponsor, Sentry, but you might [01:50] not have heard about the features I'm [01:51] here to talk about because I hadn't [01:52] until I talked to the team. The new [01:54] Sentry agent dashboard is unbelievable. [01:56] I really wish I had the setup for T3 [01:58] chat. I'm probably going to go do it [01:59] when I'm done filming cuz it's so [02:01] genuinely useful. If you're building [02:03] with agents, you know that things don't [02:04] always go right. Maybe when you write [02:06] code, you know what the error cases are [02:09] and you can easily trace where the error [02:11] came from. But when an agent can call [02:13] arbitrary tools in an arbitrary order [02:14] with arbitrary failure rates, good luck [02:17] debugging that. Imagine if you could [02:19] just see into those agent runs with five [02:21] lines of code. Kind of sounds [02:23] unbelievable. And I struggled to believe [02:25] it until I saw it here. It's so cool. [02:27] This project is a bunch of agents that [02:29] are running with the observability [02:30] through hotel on. But we can click any [02:32] one of them and see what it looks like. [02:34] So here is a request that had 48 errors, [02:37] two LM calls, one tool call, and 29K [02:40] tokens generated. You can even see how [02:42] much it cost. And if we click on it, we [02:44] get so much useful information from a [02:46] real trace. So this one was wrapping [02:48] claude code. Yes, you can wrap claude [02:51] code with this and see all the tool [02:52] calls it makes on a request. Here you [02:54] can see over time which tool calls [02:56] happened, how long they took, what [02:58] happened as a response to that, all of [03:00] the agents and sub aents that were [03:02] invoked as part of this request. This is [03:05] so useful. You can see how many tool [03:07] calls happen a day, broken down by which [03:08] tools are being used, how many tokens [03:10] are being used by various models, how [03:12] many LM calls are happening for each of [03:14] those models, error rates, and all of [03:16] these things that are really annoying to [03:18] find and figure out. Take it from [03:20] somebody who's been trying to debug [03:21] weird search tool call loops for a [03:23] minute now. This stuff is so useful. All [03:26] you have to do is set up the init call [03:27] and turn on experimental telemetry [03:29] wherever you're calling one of the [03:30] generate functions in the AI SDK. They [03:32] have this for a bunch of other [03:34] languages, tools, and SDKs as well. This [03:36] is what we use and like I'm probably [03:39] going to go set this up now. Don't wait [03:40] till things go wrong. You'll want these [03:42] traces when they do. Get them now at [03:44] soyv.link/entry. [03:46] The UX problem with aentic development. [03:49] In order to understand this problem, I [03:51] think we have to go back in time, a [03:53] really, really long ways back two months [03:56] ago because this shit's been changing [03:58] fast. This is what my setup would look [04:00] like most of the time that I was [04:02] working. For most of the time I've been [04:04] writing code, I would have my terminal [04:05] open with my dev server and some tab [04:08] open for git. I would have my IDE open [04:10] with a workspace setup for the thing [04:11] that I'm working on. And I have my [04:13] browser open with one tab in localhost [04:15] and one tab in GitHub. So here is a [04:18] rough idea of what my setup used to look [04:20] like. I had my terminal where I have my [04:22] dev server here and I have this empty [04:24] one that's for git stuff generally. So [04:26] like TIG to see my git history, all the [04:28] usual stuff. Then I have my browser [04:31] which has the dev environment and [04:32] usually I have GitHub up for the same [04:34] thing. Here's the GitHub repo for the [04:36] same project. And then I have my editor [04:38] where I'm actually writing code. In this [04:39] case, I'm writing all my code in [04:40] markdown files. But this is roughly what [04:42] my setup would look like the majority of [04:44] the time I was developing. And honestly, [04:46] it's not too bad. If I do the three [04:48] figures up, you can see here are the [04:49] surfaces that are split across this [04:52] piece of work. When I'm working on this [04:53] project, I have one editor, one browser, [04:55] one terminal with two tabs. All fine and [04:58] sensical. None of this is that bad right [05:00] now. But what happens if I'm working on [05:02] two things at once? Okay, let's try it. [05:05] Maybe we do another set of tabs in here. [05:08] Okay, but which one am I in at any given [05:10] time? That's annoying. I'm a big T-m [05:13] guy, so I used to set up T-Maces for the [05:15] different projects. But then if I wanted [05:17] two different things, like maybe I want [05:18] to break this Git terminal or this dev [05:20] terminal out to full screen. Does that [05:22] get a new tab? Maybe tabs aren't the [05:24] right way to do this. Maybe I break this [05:25] up into different windows for each [05:27] project. Maybe this one will be for T3 [05:29] chat and this window will be for long. [05:32] Okay, what about the browser though? Do [05:34] we make new browser windows for the [05:35] different projects or do I make [05:36] different tabs? How do I get to the [05:38] right GitHub tab? How do I manage the [05:40] back and forth between all of this? And [05:41] then when I have two different projects [05:43] in my editor, how do I know I'm in the [05:45] right one? I've seen everything from [05:46] people color coding their VS Code and [05:48] cursor instances to doing crazy stuff [05:51] with their workspaces on their computer. [05:53] And I'm here to tell you none of that [05:54] works. Here's a fun thing. Let's just [05:56] try moving things to a new desktop. [05:58] Here's desktop 3. I'll move this [06:00] terminal over. We'll manually open up VS [06:03] Code here with the code command. Now I [06:06] have those two. Let's do the browser. [06:08] Command tab to heal. Oh, it just moved [06:10] me to the wrong place. I'll go back over [06:12] command N. Now it's making a terminal. [06:15] How do I get a new browser here? Great [06:17] question. You have to go down to your [06:19] doc, which I never use. Rightclick, [06:22] new window. [06:23] Cool. Kind of works. What's even more [06:26] fun is if you do this and you go to a [06:27] tab where something else was open. So [06:29] I'm going to command tab to Helium from [06:31] workspace 3 where there is no browser in [06:33] workspace 3 and it switches to workspace [06:35] 2 and switches back to this focus. And [06:37] even funnier, and I can't replicate it [06:38] now, sometimes when I do this, it will [06:41] go to the other window and it will [06:42] flicker between two different windows [06:44] back and forth a few times before it [06:46] settles. On top of that, the actual [06:49] navigation here is so slow. The [06:51] three-finger scroll to switch between [06:53] things is awful. Oh, did you see the [06:54] flicker there where it switched from [06:55] Helium back to the terminal just when I [06:57] switched workspaces? [07:04] Oh, I did it again there where I [07:05] switched to lawn here. So, I'm going to [07:07] command tab to Helium. Right now, before [07:09] I do that, desktop one is a terminal. [07:11] Desktop 2 is a browser. Desktop 3 only [07:13] has terminal and editor. So, terminal 3, [07:15] command tabbing to Helium. And we did [07:18] this, right? Watch when I go back to [07:19] one. Are you kidding me? It's it's not [07:23] just like little annoyances. These [07:25] things make this unusable. Let's break [07:27] this down a bit more from first [07:28] principles. When your work was split [07:31] across apps before it was okay because [07:34] your mental model was effectively [07:36] everything here is contained under this [07:38] project. Your terminal, your editor and [07:41] your browser are all part of your mental [07:43] model for managing this one project. But [07:46] since a lot of these models are slow and [07:48] it's possible to run tasks that take [07:50] over an hour now easily. I often have a [07:52] job running with codecs that takes one [07:54] to two hours just cuz I have some idea [07:55] and I wanted to go test it out. That [07:57] means doing just one thing at a time [07:58] sucks because you're just sitting there [08:00] scrolling Twitter as you wait for the [08:01] build to finish. And by build, I don't [08:03] mean literally running the build. I mean [08:05] doing all of the building through the [08:06] agents. So you end up spinning up other [08:09] spaces. Maybe you have three different [08:10] branches or work trees for one project. [08:12] Or maybe you're just working on [08:13] different projects at the same time. [08:15] That does not work great now though. [08:17] Remember previously we had multiple [08:19] apps, multiple tabs and everything, but [08:20] it was in our head as all of those were [08:22] grouped under the project. But what [08:24] happens when you have more than one [08:25] project and now you have to split those [08:27] projects across different apps? Are you [08:29] going to make different windows for [08:30] everything? How are you going to manage [08:31] the different ones? What if terminal for [08:33] project B dings when project one's [08:36] browser is open? How do you get to the [08:38] right spot when you are dealing with all [08:41] of these things running in parallel? I'm [08:43] already seeing the push back in chat. [08:44] Things like, what about the context of [08:46] switching models? What about alt tab on [08:48] Mac OS the custom one? None of that ends [08:51] up mattering that much, especially the [08:53] context shifting thing. When you are [08:56] good at scoping your work and writing [08:58] down exactly what you have in mind, it's [09:00] not that hard to switch between because [09:01] otherwise you're just sitting there [09:02] staring at it for 20 minutes to 2 hours. [09:05] This is definitely an ADHD [09:06] characteristic that this works well for [09:08] me, but it does. I really like having [09:10] two or three projects going with long [09:12] running tasks that I can swap between [09:14] and see what's happening. But when you [09:16] have to split that context across apps, [09:18] it gets much more annoying. My dream [09:21] would be a very simple set of desktops [09:24] that have their own logical consistent [09:26] behaviors such that I could easily go [09:28] between the three and have them set up [09:30] perfectly. In my dream world, each of [09:32] these would be a different remote [09:34] computer that I'm controlling from here. [09:36] Sadly, just fixing window management [09:38] isn't enough, though. Because as bad as [09:40] this part is, and yeah, sure, window [09:42] management will help, the horrible split [09:44] of our projects across our apps, which [09:47] hurts so much right now. The fact that [09:49] our terminal or ID and browser are [09:50] separate is painful. And as I said, [09:53] there's a lot of sub problems. How do [09:54] you choose how you split your terminal [09:56] up? Do you use tabs or windows? Do you [09:58] use T-Mox? What do you do about that? [10:00] How do you know which terminal window [10:02] you're in right now? A lot of these [10:03] tools don't show you where you are when [10:05] you're running something like cloud [10:07] code. Like here, where am I? Where in [10:11] the world am I right now? What project [10:13] am I inside of with this terminal? No [10:15] way of knowing. I can go set up a custom [10:17] status bar to tell me where I am here. [10:19] But I shouldn't have to [ __ ] do that. [10:21] It's obnoxious. And when you're looking [10:23] at a higher level between different [10:24] browsers, knowing which one has the [10:26] right GitHub repo is the most annoying [10:28] thing in the world. The more you do this [10:30] type of work, the more you start to feel [10:31] these pain points, especially with stuff [10:34] like port collision, O and cookie [10:36] collision, all of those types of things. [10:38] Fun fact that I didn't know until [10:40] recently. Did you know that local hosts [10:42] app storage data in the browser is [10:43] shared across all ports? So, if you have [10:46] three things running on three different [10:47] ports and they all edit the same [10:49] cookies, they're all now very broken. [10:52] What? I did not believe this until I [10:55] experimented with it myself. But yes, [10:57] local host is one host. Thankfully, [11:00] chat's making me feel less insane for [11:02] saying this because I had no idea at [11:04] all. Ports don't count as different [11:05] hosts, which means multiple things under [11:07] local host all get grouped together, [11:09] which breaks a ton of [ __ ] And that's [11:11] not even counting the fact that if you [11:13] use a port that's different from what [11:14] your project's built for, things like [11:15] your off redirection are probably going [11:17] to break. Because if you set up your O [11:19] to redirect to either localhost 3000 or [11:21] your prod domain and now you have [11:23] localhost 3000 in 12 because you're [11:25] working on three things in parallel. [11:28] Good luck. It's broken now. And there's [11:30] just so many of these things constantly. [11:32] I have been running into this stuff [11:34] every day. I've been working with these [11:36] tools and they're getting more and more [11:38] frustrating every day. In my little [11:40] essay thing, I wrote an example of like [11:42] a real world story that I have [11:45] experienced that I'm sure lots of others [11:46] have too. Ding. You hear a notification [11:49] sound from a Cloud Code workflow [11:50] finishing. Which terminal tab was it? I [11:53] hop around my terminal windows and tabs [11:54] for a bit. Finally, I can find it. It [11:56] was project B. Okay. Now, which browser [11:59] was that? Oh, it got assigned to [12:01] localhost 3001. Now, my O redirects are [12:04] broken. I can't even sign into it. Which [12:05] terminal tab is using 3000? Okay. It was [12:07] project A. I'll kill it. Where's the tab [12:09] for project B's dev server so I can [12:11] rerun it with the right port? Ding. [12:13] Another workflow just finished. It [12:15] briefly grabs your attention just long [12:17] enough to lose track of whatever it was [12:20] that you were just doing. I run into [12:22] this multiple times a day right now. [12:24] Feel like I'm going mad. I am sure at [12:26] least half of you are thinking of simple [12:28] solutions to this that are like, "Oh, [12:29] it's so easy. Just do X, Y, or Z. Just [12:33] use Tail Scale or move to Linux or all [12:35] these things." No. Just no. T-Mux is one [12:40] that's recommended to me a lot, which is [12:41] really funny because I've been using GNU [12:43] screen since before most T-Mux fans were [12:45] born. I've been using it since I was 12 [12:47] and now I am old. Multipplexing your [12:49] terminal is an awesome thing and I [12:51] really, really like it. I used T-Mox as [12:53] my default terminal setup for the last 8 [12:55] years and I only didn't set it up on [12:57] this MacBook to see how I would feel [13:00] living without it. And the answer is not [13:02] much better, not much worse. What about [13:03] agent orchestration GUIs? As you guys [13:06] know, I absolutely love the Codeex UI, [13:09] not the Codeex CLI. It's fine, but I've [13:11] been building a ton of stuff here. And [13:13] you can see I am still doing that. I [13:15] love this UI. I like it a lot. The fact [13:18] that I have one app that lets me work [13:19] between different projects for the [13:21] generation side is great. But I still [13:23] end up in the terminal for running the [13:25] dev servers because the built-in [13:26] terminal in this app is just garbage. I [13:28] didn't even mention in the video cuz [13:29] it's so bad and I don't like built-in [13:30] terminals. And the diff view, as cool as [13:33] it is, does not give me enough detail to [13:34] ship confidently. So, I still like to [13:36] open my editor here and there. And of [13:38] course, the browser problem. I still [13:39] have to deal with the browser and all of [13:41] the weird things around port collisions, [13:42] redirects, all that and more. So, while [13:44] I love this app, it does not solve these [13:46] problems. If anything, I feel them more [13:48] now because solving the terminal side [13:50] here, like making this part go away [13:54] makes me feel like I can do more. And [13:56] because I feel like I can do more, I [13:58] start to do more. And then the problems [13:59] with these two get way worse really [14:02] fast. Without codecs, I feel pretty hard [14:04] limited to two things at a time, but [14:07] with codeex, I can do like four or five, [14:09] but now these problems get way worse. [14:11] How about an IDE with a built-in [14:13] browser? This is honestly some of the [14:15] closest I've seen. Something like cursor [14:17] with a built-in terminal, built-in Git [14:19] workflows, and a built-in browser can [14:22] get pretty damn far here. But I still [14:24] need GitHub because I need to see what's [14:26] going on in the project. Other PRs need [14:28] to review stuff like that. And as good [14:30] as the VS Code extension is, I use that [14:31] more for doing the detailed review than [14:34] for seeing what's going on. And then [14:36] stuff like off and off redirects and [14:38] trying to get your one password off [14:40] working properly inside of the cursor [14:42] browser in app. If you haven't tried it, [14:44] you don't know the pain. It's awful. And [14:46] then god damn it, like I had to try and [14:48] get pass keys working in the inapp [14:50] browser and I almost went mad. And then [14:52] there's people who sincerely recommend [14:54] Docker. And I would sincerely recommend [14:56] they get their heads checked out because [14:58] as cool as Docker is, it solves none of [15:00] this at all. Good question. Why would I [15:02] need pass keys in dev? Because in dev, [15:04] I'm still signing in with my Google [15:06] account and my Google account is set up [15:07] via a pass key. Could I set up an [15:09] entirely different dev environment for [15:11] all of my projects to make it friendly [15:12] to the specific text editor and built-in [15:14] browser that it has? Yeah, but I don't [15:16] want to do that. I don't want to have to [15:17] go to all of my like 17 projects and [15:20] rebuild how they think about the core [15:22] basics like off just so that I can use [15:25] them in an inapp browser. That sounds [15:27] insane to me. And here's my hottest [15:29] take. Background agents. I think a big [15:32] portion of why we are so hyped on [15:33] background agents in the idea of like [15:35] sending a Slack message to kick off a [15:37] job or having like inapp and cursor and [15:39] codecs, the cloud button that will kick [15:42] it off into the cloud in the background. [15:44] I legitimately think a lot of the hype [15:45] around these features is because of how [15:48] hard it is to do that type of parallel [15:49] work locally. It does help with where [15:52] the code is running and to an extent [15:54] linking the GitHub part, but I honestly [15:55] feel the way it does that is by just [15:57] taking stuff from these other two [15:59] categories and moving them into the [16:01] browser as well. I don't think moving [16:03] the editor experience or the terminal [16:04] experience into the browser necessarily [16:06] solves these things. If anything, what [16:08] I've seen is that these cloud and [16:10] background agent solutions just end up [16:12] being a source of a bunch of PRs that [16:14] don't get touched because no one is [16:15] going to look at this again after they [16:17] run it. But when I'm running locally, [16:18] I'm actually going to play with the [16:19] code. I'm going to test how it works. [16:20] I'm going to be more thorough and [16:22] detailed when it's on my machine my way. [16:25] That might change in the future as these [16:26] background tools get better. But I feel [16:28] like the background agent stuff is [16:30] getting most of its popularity because [16:31] of how bad these problems are and at the [16:33] same time is only solving the like [16:35] terminal aspect of it, none of the rest. [16:38] So, I know what you're thinking now. [16:40] Okay, Theo, you must have some genius [16:42] great solution to this problem, right? [16:46] As I said at the bottom of my post, I'm [16:48] not writing this to announce something [16:49] or to sound smart. I really, really just [16:52] want this fixed. I almost started to [16:54] build an operating system to do just [16:56] this. I need to be realistic though. [16:58] Can't do this one. I don't have the [16:59] skills, mental bandwidth to figure this [17:02] out. I wrote this in hopes that I can [17:04] inspire others to solve this problem. [17:05] There is no single correct solution. We [17:07] need lots of them. Experiment. It's [17:09] never been easier to test out theories, [17:11] build new workflows, feel this pain, try [17:14] to fix it, fail, try again, keep trying. [17:16] We need to figure this out. We need to [17:18] change how we use computers. [17:22] I have a lot of feelings about this one, [17:24] but since I wrote this, something very [17:26] interesting happened, and I will [17:28] emphasize this is not for this video, [17:31] but you should keep an eye out for [17:33] another video in the very near future. I [17:35] got one shot by Neri in Linux. I don't [17:38] want to spoil this whole video cuz it's [17:40] going to be a long and detailed one, but [17:42] there's a good chance that the next time [17:43] you see me in a video like this, I might [17:45] be using something [17:47] that looks very, very different. I [17:50] haven't been this excited about how I [17:51] use a computer for a very long time. And [17:54] it's kind of insane that the exact [17:56] problem I described has a UI that fits [17:59] it perfectly. And of course, it's far [18:01] from perfect. Most of these problems [18:03] still apply, but man, I am so excited to [18:05] show you guys what I've been doing on [18:07] Linux. So, yeah, crazy. You clicked on a [18:09] video here for learning about AI stuff, [18:11] and the answer might be Linux. And I [18:14] can't wait to share more. But for now, I [18:16] don't want you distracted by my [18:17] solution. I want you all to think about [18:20] your own. Build more. Build more in [18:22] parallel. Run into these problems, feel [18:24] them, experience them, then and only [18:27] then start exploring how you can solve [18:30] them yourself. I've built a lot of [18:31] pieces to try and make these things [18:33] better myself. But I'm much more excited [18:34] to see what all of you guys cook, how [18:36] you think about them, and whether or not [18:38] you even agree with the problems that [18:39] I'm perceiving here. There's no reason [18:41] we should only have one or two options [18:42] like we do with operating systems. The [18:44] world of the tools we use and the user [18:46] experiences we have when building this [18:48] way should be wide and diverse and [18:50] exciting. And I am so hyped to see where [18:52] this all goes. So go build, go play, go [18:55] find your own solutions, and let us all [18:57] know how it goes. I can't wait to see [18:59] what you build. Until next time, peace [19:01] nerds.