Agentic Coding Has a HUGE Problem  I don't think I've ever been building asmuch as I am right now. Obviously, AIhas been helping a lot, especiallybecause I have four other jobs.Yes, YouTube is one of them. Running mycompany is one of them. Managing all ofthe other companies I work with is oneof them. And I do a lot. So, it'ssurprising I can build it all, much lesshow much I've been building. And thishas been super fun. I don't think I'veever enjoyed building software as muchas I do now. These agentic tools make itso easy to do lots of things at once atscale and build things that I neverwould have imagined. I have Lawn, which is my new video review tool meant toreplace Frames so we can get Adobe outof our lives. I have Shu, which is a newway to do O across your projects becausehaving a lot of O setups across thingsis annoying. This isn't meant to be thegreatest O library ever. It's meant tounblock you so you can get back to workby just having a simple Google sign-inbutton. I have T3 Canvas, which is mynew image editing tool that I'm actuallyhoping to merge a lot of into T3 Chateventually. But more importantly, it'ssomething I use every day for everything. From icons for the projects I'm buildingto concepts for thumbnails that I'mworking on. It's really useful. And thenthis one, which will take a bit before Ican share more about: the FS2 CLI. This is myattempt at doing file syncing on a lowerlevel. And yes, this whole project iswritten in Rust. I also have two Swiftprojects I'm working on. I've beencontributing to a ton of stuff. I'vejust been building and touching morethan ever. So, what's the problemthen? Why are you watching a video thatis meant to be about the issues that I'mhaving with this? Clearly, it's working,right? No. In fact, the problems I'm having were so great that I took thetime to sit down and write an article tocomplain about it. I've been thinking alot about these UX problems, andapparently others have too, which is whythis post got 1.2 million views andeverybody from Microsoft execs to vibecoders reacting to it. I have a lot tosay about these UX problems. I've beenthinking about them a ton, and I mightactually have some solutions in mind aswell. Do you know what doesn't have anyof these problems, though? Today'ssponsor. Today's sponsor, Sentry, mightbe features you haven't heard aboutuntil now. The newSentry agent dashboard is unbelievable.I really wish I had the setup for T3chat. I'm probably going to do itwhen I'm done filming because it's sogenuinely useful. If you're buildingwith agents, you know that things don'talways go right. When you writecode, you typically know the error casesand can easily trace where the errorcame from. However, when an agent can callarbitrary tools in an arbitrary orderwith arbitrary failure rates, good luckdebugging that. Imagine if you couldjust see into those agent runs with fivelines of code. It soundsunbelievable. I struggled to believeit until I saw it here. It's so cool. This project consists of a bunch of agentsrunning with observabilitythrough hotel on. We can click anyone of them and see what it looks like.Here is a request that had 48 errors,two LM calls, one tool call, and 29Ktokens generated. You can even see howmuch it cost. If we click on it, weget so much useful information from it. Real trace. So, this one was wrappingClaude code. Yes, you can wrap Claudecode with this and see all the toolcalls it makes on a request. Here youcan see over time which tool callshappened, how long they took, and whathappened as a response to that, all ofthe agents and sub-agents that wereinvoked as part of this request. This isso useful. You can see how many toolcalls happen a day, broken down by whichtools are being used, how many tokensare being used by various models, howmany LM calls are happening for each ofthose models, error rates, and all ofthese things that are really annoying to find and figure out. Take it fromsomebody who's been trying to debugweird search tool call loops for aminute now. This stuff is so useful. Allyou have to do is set up the init calland turn on experimental telemetrywherever you're calling one of thegenerate functions in the AI SDK. Theyhave this for a bunch of otherlanguages, tools, and SDKs as well. Thisis what we use, and like I'm probablygoing to go set this up now. Don't waittill things go wrong. You'll want thesetraces when they do. Get them now atsoyv.link/entry. The UX problem with agentic development.In order to understand this problem, Ithink we have to go back in time,a really, really long way back, two monthsago, because things have been changingfast. This is what my setup would looklike most of the time that I wasworking. For most of the time I've beenwriting code, I would have my terminalopen with my development server and some tabopen for Git. I would have my IDE openwith a workspace setup for the projectI was working on. I also had mybrowser open with one tab on localhostand one tab on GitHub. So here is a rough idea of what my setup used to looklike. I had my terminal with mydevelopment server and this emptyone for Git generally. I would useTIG to see my Git history, along withall the usual functions. Then I had my browserwhich had the development environment andusually GitHub open for the sameproject. Here's the GitHub repo for thesame project. And then I had my editorwhere I was actually writing code. In thiscase, I was writing all my code inMarkdown files. This is roughly whatmy setup would look like the majority of the time. The time I was developing, and honestly,it's not too bad. If I do the threefigures up, you can see here are thesurfaces that are split across thispiece of work. When I'm working on thisproject, I have one editor, one browser,one terminal with two tabs. All fine andsensical. None of this is that bad rightnow. But what happens if I'm working ontwo things at once? Okay, let's try it.Maybe we do another set of tabs in here. Okay, but which one am I in at any giventime? That's annoying. I'm a big T-mguy, so I used to set up T-Maces for thedifferent projects. But then if I wantedtwo different things, like maybe I wantto break this Git terminal or this devterminal out to full screen. Does thatget a new tab? Maybe tabs aren't theright way to do this. Maybe I break thisup into different windows for eachproject. Maybe this one will be for T3chat and this window will be for long.Okay, what about the browser though? Dowe make new browser windows for thedifferent projects or do I makedifferent tabs? How do I get to theright GitHub tab? How do I manage theback and forth between all of this? Andthen when I have two different projects. In my editor, how do I know I'm in theright one? I've seen everything frompeople color coding their VS Code andcursor instances to doing crazy stuffwith their workspaces on their computer.And I'm here to tell you none of thatworks. Here's a fun thing. Let's justtry moving things to a new desktop.Here's desktop 3. I'll move thisterminal over. We'll manually open up VSCode here with the code command. Now Ihave those two. Let's do the browser.Command tab to Helium. Oh, it just movedme to the wrong place. I'll go back overCommand N. Now it's making a terminal.How do I get a new browser here? Greatquestion. You have to go down to yourdock, which I never use. Right-click,new window.Cool. Kind of works. What's even morefun is if you do this and you go to atab where something else was open. SoI'm going to Command tab to Helium fromworkspace 3 where there is no browser inworkspace 3, and it switches to workspace2 and switches back to this focus. And even funnier, and I can't replicate itnow, sometimes when I do this, it willgo to the other window and it willflicker between two different windows. Back and forth a few times before itsettles. On top of that, the actualnavigation here is so slow. Thethree-finger scroll to switch betweenthings is awful. Oh, did you see theflicker there where it switched fromHelium back to the terminal just when Iswitched workspaces? Oh, I did it againthere where I switched to lawn. So, I'm going tocommand tab to Helium. Right now, beforeI do that, desktop one is a terminal. Desktop 2 is a browser. Desktop 3 onlyhas terminal and editor. So, terminal 3,command tabbing to Helium. And we didthis, right? Watch when I go back toone. Are you kidding me? It's notjust little annoyances. Thesethings make this unusable. Let's breakthis down a bit more from firstprinciples. When your work was splitacross apps before, it was okay becauseyour mental model was effectivelythat everything here is contained under thisproject. Your terminal, your editor, andyour browser are all part of your mentalmodel for managing this one project. Butsince a lot of these models are slow,it's possible to run tasks that takeover an hour now easily. Job running with codecs takes oneto two hours just because I have some ideaand I wanted to test it out. Thatmeans doing just one thing at a timesucks because you're just sitting therescrolling Twitter as you wait for thebuild to finish. And by build, I don'tmean literally running the build. I meandoing all of the building through theagents. So you end up spinning up otherspaces. Maybe you have three differentbranches or work trees for one project. Or maybe you're just working ondifferent projects at the same time.That does not work great now though.Remember previously we had multipleapps, multiple tabs and everything, butit was in our heads as all of those weregrouped under the project. But whathappens when you have more than oneproject and now you have to split thoseprojects across different apps? Are yougoing to make different windows foreverything? How are you going to managethe different ones? What if terminal forproject B dings when project one'sbrowser is open? How do you get to theright spot when you are dealing with allof these things running in parallel? I'malready seeing the push back in chat. Things like, what about the context ofswitching models? What about Alt+Tab onMac OS, the custom one? None of that endsup mattering that much, especially thecontext-shifting thing. When you aregood at scoping your work and writingdown exactly what you have in mind, it'snot that hard to switch between becauseotherwise you're just sitting therestaring at it for 20 minutes to 2 hours. This is definitely an ADHDcharacteristic that this works well forme, but it does. I really like havingtwo or three projects going with longrunning tasks that I can swap betweenand see what's happening. But when youhave to split that context across apps,it gets much more annoying. My dream would be a very simple set of desktopsthat have their own logical, consistentbehaviors such that I could easily gobetween the three and have them set upperfectly. In my dream world, each ofthese would be a different remotecomputer that I'm controlling from here. Sadly, just fixing window managementisn't enough, though. Because as bad asthis part is, and yeah, sure, windowmanagement will help, the horrible splitof our projects across our apps, whichIt hurts so much right now. The fact thatour terminal or ID and browser areseparate is painful. And as I said,there are a lot of subproblems. How doyou choose how you split your terminalup? Do you use tabs or windows? Do youuse Tmux? What do you do about that? How do you know which terminal windowyou're in right now? A lot of thesetools don't show you where you are whenyou're running something like cloudcode. Like here, where am I? Where inthe world am I right now? What projectam I inside of with this terminal? Noway of knowing. I can go set up a customstatus bar to tell me where I am here.But I shouldn't have to do that.It's obnoxious. And when you're lookingat a higher level between differentbrowsers, knowing which one has theright GitHub repo is the most annoyingthing in the world. The more you do thistype of work, the more you start to feelthese pain points, especially with stufflike port collision, and cookiecollision— all of those types of things.Fun fact that I didn't know untilrecently: Did you know that local hostsapp storage data in the browser isshared across all ports? Three things running on three differentports all edit the samecookies, and they're all very broken.What? I did not believe this until Iexperimented with it myself. But yes,localhost is one host. Thankfully,chat's making me feel less insane forsaying this because I had no idea atall. Ports don't count as differenthosts, which means multiple things underlocalhost all get grouped together,which breaks a ton of things. And that'snot even counting the fact that if youuse a port that's different from whatyour project's built for, things likeyour OAuth redirection are probably goingto break. Because if you set up your OAuthto redirect to either localhost 3000 oryour prod domain, and now you havelocalhost 3000 and 12 because you'reworking on three things in parallel,good luck. It's broken now. And there arejust so many of these issues constantly. I have been running into this stuffevery day. I've been working with thesetools and they're getting more and morefrustrating every day. In my littleessay, I wrote an example of a real worldstory that I have experienced that I'm sure lots of othersI have too. Ding. You hear a notificationsound from a Cloud Code workflowfinishing. Which terminal tab was it? Ihop around my terminal windows and tabsfor a bit. Finally, I can find it. Itwas project B. Okay. Now, which browserwas that? Oh, it got assigned tolocalhost 3001. Now, my O redirects arebroken. I can't even sign into it. Whichterminal tab is using 3000? Okay. It wasproject A. I'll kill it. Where's the tabfor project B's dev server so I canrerun it with the right port? Ding. Another workflow just finished. Itbriefly grabs your attention just longenough to lose track of whatever it wasthat you were just doing. I run intothis multiple times a day right now.I feel like I'm going mad. I am sure atleast half of you are thinking of simplesolutions to this that are like, "Oh,it's so easy. Just do X, Y, or Z. Justuse Tail Scale or move to Linux or allthese things." No. Just no. T-Mux is onethat's recommended to me a lot, which isreally funny because I've been using GNUscreen since before most T-Mux fans wereborn. I've been using it since I was 12and now I am old. Multiplexing yourterminal is an awesome thing. I really like it. I used T-Mox asmy default terminal setup for the last 8years, and I only didn't set it up onthis MacBook to see how I would feelliving without it. And the answer is notmuch better or worse. What aboutagent orchestration GUIs? As you guysknow, I absolutely love the Codeex UI,not the Codeex CLI. It's fine, but I'vebeen building a ton of stuff here. Andyou can see I am still doing that. Ilove this UI; I like it a lot. The factthat I have one app that lets me workbetween different projects for thegeneration side is great. But I stillend up in the terminal for running the dev servers because the built-interminal in this app is just garbage. Ididn't even mention it in the video becauseit's so bad, and I don't like built-interminals. The diff view, as cool asit is, does not give me enough detail toship confidently. So, I still like toopen my editor here and there. And ofcourse, the browser problem. I stillhave to deal with the browser and all ofthe weird things around port collisions,redirects, all that and more. So, whileI love this app, it does not solve theseproblems. Now, solving the terminal sidehere, like making this part go away,makes me feel like I can do more. Andbecause I feel like I can do more, Istart to do more. Then the problemswith these two get way worse reallyfast. Without codecs, I feel pretty hardlimited to two things at a time, butwith codecs, I can do four or five.But now these problems get way worse. How about an IDE with a built-inbrowser? This is honestly some of theclosest I've seen. Something like cursorwith a built-in terminal, built-in Gitworkflows, and a built-in browser canget pretty far here. But I stillneed GitHub because I need to see what'sgoing on in the project. Other PRs needto review stuff like that. And as goodas the VS Code extension is, I use thatmore for doing the detailed review thanfor seeing what's going on. Then stuff like off and off redirects andtrying to get your One Password offworking properly inside of the cursorbrowser in-app. If you haven't tried it,you don't know the pain. It's awful.Then, god damn it, like I had to try andget pass keys working in the in-appbrowser, and I almost went mad. There are people who sincerely recommendDocker, and I would sincerely recommendthey get their heads checked out because,as cool as Docker is, it solves none ofthis at all. Good question. Why would Ineed pass keys in development? Because in development,I'm still signing in with my Googleaccount, and my Google account is set upvia a pass key. Could I set up anentirely different development environment forall of my projects to make it friendlyto the specific text editor and built-inbrowser that it has? Yeah, but I don'twant to do that. I don't want to have togo to all of my 17 projects and rebuild how they think about the corebasics, like authentication, just so that I can usethem in an in-app browser. That soundsinsane to me. And here's my hottesttake: background agents. I think a bigportion of why we are so hyped onbackground agents and the idea of sending a Slack message to kick off ajob or having in-app and cursor andcodecs, the cloud button that will kickit off into the cloud in the background.I legitimately think a lot of the hypearound these features is because of howhard it is to do that type of parallelwork locally. The code is running and, to an extent,linking the GitHub part, but I honestlyfeel the way it does that is by justtaking stuff from these other twocategories and moving them into thebrowser as well. I don't think movingthe editor experience or the terminalexperience into the browser necessarilysolves these things. If anything, whatI've seen is that these cloud andbackground agent solutions just end upbeing a source of a bunch of PRs thatdon't get touched because no one isgoing to look at this again after theyrun it. But when I'm running locally,I'm actually going to play with thecode. I'm going to test how it works. I'm going to be more thorough anddetailed when it's on my machine, my way.That might change in the future as thesebackground tools get better. But I feellike the background agent stuff isgetting most of its popularity becauseof how bad these problems are, and at thesame time, is only solving the terminalaspect of it, none of the rest.So, I know what you're thinking now.Okay, Theo, you must have some geniusgreat solution to this problem, right?As I said at the bottom of my post, I'mI'm not writing this to announce somethingor to sound smart. I really justwant this fixed. I almost started tobuild an operating system to do justthis. I need to be realistic, though. I can't do this one. I don't have theskills or mental bandwidth to figure thisout. I wrote this in hopes of inspiringothers to solve this problem.There is no single correct solution; weneed lots of them. Let's experiment. It'snever been easier to test out theories,build new workflows, feel this pain, tryto fix it, fail, and try again. We need tofigure this out. We need tochange how we use computers. I have a lot of feelings about this one,but since I wrote this, something veryinteresting happened, and I want toemphasize this is not for this video.You should keep an eye out foranother video in the very near future. Igot one shot by Neri in Linux. I don'twant to spoil this whole video because it'sgoing to be a long and detailed one, butthere's a good chance that the next timeyou see me in a video like this, I mightbe using somethingthat looks very, very different. Ihaven't been this excited about how IUse a computer for a very long time. Andit's kind of insane that the exactproblem I described has a UI that fitsit perfectly. And of course, it's farfrom perfect. Most of these problemsstill apply, but man, I am so excited toshow you guys what I've been doing onLinux. So, yeah, crazy. You clicked on avideo here for learning about AI stuff,and the answer might be Linux. And Ican't wait to share more. But for now, I don't want you distracted by mysolution. I want you all to think aboutyour own. Build more. Build more inparallel. Run into these problems, feelthem, experience them, then and onlythen start exploring how you can solvethem yourself. I've built a lot ofpieces to try and make these thingsbetter myself. But I'm much more excitedto see what all of you guys cook, howyou think about them, and whether or notyou even agree with the problems thatI'm perceiving here. There's no reasonwe should only have one or two optionslike we do with operating systems. Theworld of the tools we use and the userexperiences we have when building thisway should be wide and diverse andexciting. And I am so hyped to see whereThis all goes. So go build, go play, gofind your own solutions, and let us allknow how it goes. I can't wait to seewhat you build. Until next time, peacenerds., Agentic Coding Has a HUGE Problem, YouTube, 01kh9rvntz98tw9f8ph6y8g3z6.