Your Attention Is the Bottleneck, Not Your Agents — Zack Proser, WorkOS transcript

Hey everyone. Uh I'm Zach. I work at WorkOS. Thanks for coming. Uh WorkOS is um provides drop-in APIs that allow you to take your software and go upmarket and sell larger deals to enterprises. Uh but what I'm going to talk about now is um sort of the way that I'm finding to try and maintain balance with all the insane new tools that we're getting every day. So, show of hands if anyone is uh AI coding with agents lately and feels a little bit like this and yeah, despite, you know, getting more done than ever before, like you're completely fried at the end of the day, right?

And like adrenaline dumping constantly. So, this has been my experience and I've noticed that some of the worst of it is like the context switching was always super expensive for me and now it's it's worse than ever before, right? So, I think a lot of us are feeling this way. Um like the the tools are are like insanely powerful and our skills are more in demand than ever before and yet we're like exhausted by 11:00 a.m.

So, I'll I'll make this concrete with a recent story. I was working I'm on the Applied AI team at WorkOS. I was building a Slack bot that kind of democratized uniform blogging for everybody so that anybody that even if they've never written a blog post before can come into a Slack channel, make a simple request and get a uniform blog post that does everything the correct way, right? And there was a bug that one of my colleagues reported that said, "Hey, we need to use sentence case and the sentence case uh pass right now is mangling some of our acronyms like skim and SSO." So, normally I'd be living in that kind of window hell that I just showed you.

And um instead this time I made a very minor change that ended up being super impactful. So, I gave Claude Code, which is my current like preferred aperture for working, the ability to read and write to Slack as well. And it already had my linear ticket access. And so, I told it, "You need to fix this and then you also need to verify your own work and don't stop until you've done that. And so roughly this is what it looked like if my terminal's on the left, you know, I ran Claude and I said fix the sentence case enforcer, it's mangling acronyms.

And so it went and did that and because it had an MCP connection to Slack, it it fired it into this blog post channel. And then the blog bot that it's working on, you know, it's sitting in that code base on my in my working directory, picked it up and ran all the way through and got to the step that was relevant. And then Claude verified the access and the the outcome and then said, okay, now I have I definitively fixed this bug.

So when I came back to it, I came back to a completed loop that was had been fixed and I didn't have to tell it, hey this part's still broken. So that felt incredible and I and I think that that's an important part of what we're going to all build into our toolkit and we already are. But it also scared me because I realized that there's like there's there's nothing there's no ceiling to this, right? So the tools are nuclear now and our nervous system is still relatively ancient and so the thing that I'm thinking about recently is is how do I find my own kind of developer balance in this this world, right?

So why not just stack that same process, why not use that harness and just fix 150 bugs every day at work? Well, you know, the agents can kind of do that especially if you give them enough context, if you give them the right verification criteria, if you give them the tools to verify their own work. But at the end of the day, like I can't actually sit on top of all of that and make sure that the quality is there. And also show up the next day for like another 8-hour work session and not be completely destroyed.

So what I think I'm finding and I think a lot of other folks I've been talking to you recently are finding is that the agents are not the bottleneck now and I think that's going to increasingly be the case, but we are. So agents can scale infinitely especially now that they're made available as of last night via cloud API. You can give them verification criteria and the tools that they need in order to match that criteria, but our attention is still, you know, in meatspace, if you will, and it still degrades under load.

It's It's still the hard constraint, essentially. Uh and this is something that's not just me and not just you, everyone that just raised their hand at the beginning of this talk feeling it. Um as Simon Willison said recently, like last week, that he fires up four parallel agents and he's wiped out by 11:00 a.m. And so, he suggests that all of us finding our own individual uh balance and and sort of our personal limits is now something that we all need to do on our own.

I'm definitely seeing this also on the Applied AI team. So, uh here's a couple of tips and tricks or things that I've used like recently and found success with, and so, I'll share them. Some of them, I'm sure you've already seen. Um so, we essentially need to bring the human developer into balance with this new way of working because now that we have these like hyper-charged tools, it's faster than ever to burn yourself out, especially if you just scale linearly in terms of your what you're taking on and at work and what you're you're outputting.

And so, see um the way that I'm sort of breaking it down in my mind is that agents are going to do better in terms of infinitely scaling, uh looping infinitely until they have uh reached the criteria you've given them. Um but we still have judgment, taste, knowing that something is actually solved, knowing that the the criterion is actually met in in uh in terms of human needs and business needs. And so, this is kind of an early breakdown of the stack that I'm seeing.

So, the first I'm calling signal layers for lack of a better word, and I'll I'll develop that a little bit in a second. Uh the second is voice-first flows. I've been doing voice-first coding now for about a year and a half, and it's been life-changing. Um and then remote control, which is becoming more and more recent uh more applicable, and I think we're going to start seeing it everywhere. Right now, it's sort of a Claude code-specific thing.

And then the system improving itself. So, um changing just minimal things about the way that you work and the way that you store your own message history, even, can enable incredibly powerful passes now that you have agents that can rip through all of that um material in seconds and find patterns for you on a loop without you even needing to remember to do it. So, let's take a quick look at what each of these uh what I mean by this.

So, calling back to the the bug that I showed you that I fixed and had Claude do it. Um my problem is that if I were to go and go comb through Slack myself, uh it's like 80% guaranteed that I'm going to get distracted by some other thread. I'm going to find something else or somebody's going to have a new ask for me and that's going to kind of pull me off task. And so, instead I had Claude code um be able to read my Slack and do it on a loop so that it can see are there at mentions, are there DMs, are there actually like high priority asks that need to be actioned?

Meanwhile, it's all all always had access to my linear via MCP and so it can deduplicate asks and find the real tickets. And this is just enough of a sort of facade for me to allow me to continue to focus and maintain my attention on the things that are the key for me to be able to do as the human developer. Uh and I think that there's a ton of tools that are coming out that we're all seeing here, too, that are going to make this kind of like um just a bespoke experience wherever you want to work.

Um but it's sort of about managing the now extra insane levels of traffic and pings and and noise that we're all going to deal with. The second is just voice-first flows, like another um just nudge if you haven't tried this yet. Uh highly recommend it. I'm a person that love to type. I've grown up typing since I was 3 years old. I think at my best I was hitting 90 words per minute in a weird non-standard way with my uh giant sausage fingers.

But now with uh voice-first tools, um it's significantly faster. I regularly hit like 184 words per minute on a on a given day. And what that enables is not just speaking into one thing quickly and and having it done, you know, faster, it enables kind of parallel workflows, right? So, imagine if at the top, I'm a developer who's speaking across three different cursor windows or into codex and then also into Claude across multiple tabs.

And because it's 184 words per minute, they're now often running while a traditional developer is still typing in their first prompt. Um and I think that if you consider, you know, that that small things grow quickly, right? In in terms of software, what how does this compound over the course of a year, two, three years of working? Um and this has been really key for me because uh as I get more and more comfortable with voice flows, it also enables what I'm going to show next, which is spending less and less time at your actual desk while still getting work done.

The next is remote control. Right now, this is kind of um a Claude code specific thing, but I expect that's going to rapidly change. So, before we go look at exactly what that means in the Claude ecosystem, um we'll just talk touch on the shower principle. I'm sure everyone has heard about this before. The basic idea is that there's two modes of thinking. If you're hardcore focused in your IDE and you're typing and you're searching for symbols, you're likely in focus mode.

You likely have a very clear blueprint in your mind of what you're trying to build and how you want to do it. And that focus is excellent for getting something over the line and building something exactly the way you want. But it's um also ideal for having blind spots and missing what you need to uh creative solutions to things and and increasing your inhibitions. Um but paradoxically, when you get up and walk away and you start playing with your dog or or walking your kids to the park or taking a shower, you uh it's like there's a flash of insight and you get the full-form solution.

And the the thesis of the the shower principle is that basically your subconscious is always churning on these hard problems. And so, as soon as you walk away and kind of open the aperture and lower your inhibitions, diffuse mode allows you to see, you know, more creative solutions quickly. And the key thing I want to stress here is that we've always had this and there's been, you know, hundreds of books written about it and we've all talked about it for decades, but it used to mean that diffuse mode and walking away from your desk meant stopping work.

And that is no longer the case, especially with things like remote control. So, what remote control means in the Let's just take the Cloud Code Ecosystem example. If I'm starting a Cloud Code session, I pass the remote control flag, or I run remote control, or I have in my config enable remote control, then I can start at my desk. It's running on my dev machine. It has access to, you know, the file system, etc. But then as soon as I uh pull up Cloud on my phone on a different network, CDMA, off the Wi-Fi from my house, like, you know, miles away in the trail, I can still see that session, and I can still talk to it and send messages and poke it.

And that's incredibly powerful because I get my best ideas and all the solutions as soon as I've walked away from the desk. And so, what this enables now is uh and what I'm going to propose that enables is um starting your day in focus mode, getting everything loaded up that you need to do that's super important, and then um getting your agents turning, making sure work is proceeding the way that you want, and then leaving the desk, reducing your RSI and the number of like physical injuries you're getting from sitting in the same position all day, and going and taking a walk, but still being super productive.

And I have done a ton of experiments with this, and I even filmed a 32-minute film last year like proving that you can do this and review PRs from your phone in the woods. Um so, I'm I'm not just blowing sunshine. Like, it's it's possible. Um and the really nice thing about it is that when you talk to that session through your phone, uh that's the session on Cloud Code is still running on your machine, still has access to do whatever it needs.

If you have some genius idea of like this is the design that's going to nail it, then you just fire that back. You don't have to remember to do it when you get back to your desk. You're going to come back to it having already been applied. So, of course, in order to do this, I I often say that speed requires safety, and so there's levels of doing this and having verification. And And now with new tools coming online like not only Chrome use, but also computer use for agents, um this is going to get more sophisticated.

The gate one is like the minimal lint and build and unit test, right? Let the agents with hooks um every single time verify their own work at the code level to make sure nothing's broken. You know, gate two is when you tell the Claude code that you must verify your own work with the browser, click through it, and ensure that you haven't broken login, for example. Um three is closer to like constitutional AI in the in the way that Anthropic kind of conceives of it, where they're talking about there's a constitution of what you must do, and another agent will kind of come and verify that you did that correctly, otherwise give you feedback that you need to action.

Um and so taking all this together, how does this actually change a working software developer's day? Uh so like I said before, I propose like a deep focus session in the beginning of the day. You might go through all the backlog tasks in GitHub, the software development life cycle chores that you need to queue up, fire those all into Codex, start working on the features you really care about in an IDE, perhaps, or in Claude Code.

And then essentially you walk away after getting them kind of going on their the work tracks that you've identified for that day, because you have access to them on your phone. So even when you're out wandering around on on the edge or on LTE, you can fire messages back to them, and you can start reviewing the PRs as they come through on your phone. And now, again, because agents are we haven't quite found the LLM wall, like with Opus 4.6 is quite reasonable to leave a natural language comment on a PR in GitHub mobile at Claude or at, you know, cursor agent or at Vercelbot, and say this needs to change, and most of the time it's going to get it right.

Um and so this kind of enables this complete loop, where you're actually spending less and less time away from your desk, uh less and less time at your desk, you're spending less and less time injuring yourself, your wrists, your hands, um and you're getting oxygen when you're getting better ideas when you're out walking around, but you're still in the loop, and you're still directing work forward and making progress.

So, um I'll just quickly show that a key learning that I found in in doing this kind of as an experiment is that uh if you just use the tools on your own, like in the beginning of the of the week, um Mondays feels amazing. I can rip through a ton of work. Tuesday feels the same. Now I got a bunch of random asks in the middle of the week that kind of threw me off course and and then by Friday I'm completely wasted and I don't remember what the hell I did and uh I know that work shipped, but it's all disorganized.

Uh as my uh illustrious colleague who's with us here, Nick, reminded me, all of Claude Code's conversations are saved locally in JSON L files. And what that enables you to do um is to start working smarter and have a scheduled pass where your agent goes back and reviews your own conversations with it at the end of every week, at the end of every day if you want, and say, "Look for the patterns where you had to do a significant amount of spending thinking tokens to get something right or you and I had to go back and forth and eliminate ambiguity in order to get a task done correctly and figure out the skills that are missing.

What's the delta for if you had these tools, this MCP server, or these skills? How could we tighten that loop so that it doesn't happen next week?" And then this is a way in which just by working regularly with your own tools, your entire system or your entire harness can start to get smarter. Um there is a built-in skill in Claude Code now to not only build its own skills, but evaluate skills, improve skills, and take natural language prompt and just create bespoke skills that you need.

Um so highly recommend doing that and then tightening that loop so that you can still get your work done, still deliver what you need to at work, but spend less and less time at your desk. And so what that starts to look like is you're working, you're still paying attention through your main preferred aperture, whatever it is, maybe it's Zed, maybe it's Cursor, maybe it's Claude Code in the terminal, but the patterns are being built up because you're not trashing all of the context that you're building up while working.

And so you're treating all of those sessions as gold, which they are because a single pass with Opus 4.6 can reveal a ton of skills that if we had this next week, I can do this way more efficiently, way more quickly, in a way more reliable manner. Uh last thing I'll just share for um for giggles. Uh I love uh my Oura Ring, and one of the first things I did was connect it via MCP. There's a couple of GitHub projects that enable you to do that.

And then I gave it to Claude. And so, uh when I'm arguing with Claude about a project, there there are times he will literally come back and say, uh "You didn't sleep last night, and so we're going to tackle the first part of this, and we're not going to do the rest of it, and you're going to do it tomorrow." And then I tell him, "The hell with you, you're a machine, do what I want." And I just do it anyway, but at least I thought about taking a break.

Um And so, uh this this is kind of a fun thing, too, but I I do think there is something to this as well, uh where you start to actually look at your work holistically, not not just in terms of the conversations you're having with which colleagues, um your tickets, and everything, the skills that you have, but then also the condition of your body, what times are you able to focus the best, how much sleep are you getting.

Um and I think this is super important because if we just kind of do this mindlessly, the default path is going to be burnout, but now burnout turbo, like super fast and easier than ever, enabled by LLMs, right? Um whereas the intentional path is a little bit more like, how do I preserve myself and still do my best work, and direct uh agents to do the minutiae for me while I'm still responsible for the quality and the review, and and actually shipping.

Um so, uh if you find any of this interesting, I would recommend try uh building one single layer. It can be as simple uh as just plugging in Slack or Linear, whatever you find to be the highest um cost context switch for you into your preferred pane of glass that you're working with. Add some verification gates you don't have for Chrome for for uh uh Claude code, it's as simple as passing {dash} {dash} Chrome now and giving it access to its own browser.

And then with the margin that you get back, use that to go to either picnic in the park alone, right? Or go on a walk, or, you know, play with your dog, or whatever the case may be. So, yeah, the tool The tools are nuclear now. Um our nervous systems are still ancient. And so, what I'm thinking about these days is trying to find some developer balance. Hope that was helpful. THANK YOU SO MUCH. ANY QUESTIONS? YES. YEAH, so I guess I'm somewhat early in my career.

Uh-huh. And that means skill development is also very important. >> Yep. And uh also doing deep work Well, at least like, you know, I learned to program by doing a lot of deep work. Getting into running into issues. Yep. And uh big overcoming those hurdles. Totally. Um it's sort of And and I'm also super on board with this new flow of working, but it's sort of almost felt like a uh it's been a skill deficit for me. Like, it's made made it harder to learn.

So, have you found a balance for that work? Yeah, you can still push forward and at that skill level, but um while getting benefits of this approach. Yeah, excellent question. So, to repeat in case it's not recorded, um the question is basically if I'm early in my career, uh this is all like skill advancement, but then how do I actually do the hard skill development? And it's my fear is almost that this could kind of take it away from me, right?

And how do I manage that or maintain it? The way I think about that is the best piece of advice I saw for that was basically, don't use AI to do something that you don't know how to do already. Um so, I'm shipping like TypeScript systems and Rag systems and and doing AWS deployments because I used to do that the hard way for many many years. And so, like, I have that battle um those battle scars and like scar tissue of doing it.

And I can immediately catch Claude, for example, and and say like, no, that's insane. We're not doing that, um the second it says something that's a hallucination or is not a good idea, because I've spent that time building that up. I think you should absolutely still do that. I think you should go deep on those things and I think it's even possible with LLM's and AI to go deeper, faster, and to even say like test me, where do I where am I missing this and like my mental model here is still murky.

So, highly recommend doing that. Like build some of those skills, still code some stuff by hand, figure out what's painful about it. But then once you start to develop those skills you have confidence in them, then it's okay to kind of you ship a ton of Ruby apps, it might be okay to start shipping Ruby apps faster with LLM's and Claude. You also said only delegate code if you want to write your own work. I I would. If I would if my focus is kind of like skilling up and making sure that I'm on a solid foundation, yeah, I would recommend that.

Um and I would also say don't get discouraged because in the past when I was coming up and learning like I didn't know the names of the things that I didn't know, so I couldn't ask, you know? And now you can kind of ask and go faster and deeper on it. It's almost like if you're more honest with yourself about I don't know this, you can go faster. And I still I still think there's a super bright future for that. So, yeah.

Great question. Yep. Yes, so you talked about getting Claude to look at your own chat history with all those JSONL files. I I I've tried stuff like that and like a problem I found is that like those JSONL files are not really meant for AI consumption. They get really long and there's a lot of junk in there. Do you just point Claude straight at it or do you have some kind of intermediary step where there's something that parses that into a more amenable format?

Yeah, that's a great question. I mean I have just pointed at it before. Uh the question is how do you handle Claude going back and reviewing, doing aggregate kind of analysis on JSONL files if they're super gross and not meant for AI consumption? Um I have had success just pointing at it, but the other thing you could do is use hooks so that at the end of every coding session you could say save the key bits that we talked about and especially highlight where we struggled or where we spend a lot of extra time and put them in a separate uh data store.

So, it could be Obsidian, could be a flat file of markdown for that week, could be just a simple archive, right? And then you run your your analysis at the end of the week on that. >> AI or just deterministic? Uh well, it It be it would be used like for example, I would do it with Claude Hooks and so it would be like at the end of each one of these sessions or when I say that this is done or we merge the PR, that would be the trigger. >> other bits to say Uh you could just tell it in the prompt basically.

You could say like look specifically for things that Yeah, yeah. It would be an AI prompt to say like you're specifically looking on the hunt for things that uh we could make more efficient in the future or or indications of struggle and churn. Yep. Do you also make uh make use of night time like a like a night shift for your for your agent? I do. I have ex- uh the question is do you make use of night shift for agent?

I've been experimenting with open claw. Um so I do that with uh cron jobs and I have like some doing some content for me um and then I wake up in the morning kind of review it and freak out and scream at it and then eventually merge like a small percentage of them. Um I'd like to get to the point where with like better systems and verification that's like churning through. I think the thing I'm going to end up settling on is going to be linear tickets for everything, subtasks for bugs and for feature requests and then marking tickets with a tag says agent ready and then having a loop that's literally going every 15 minutes all day long and all night long churning through personal and uh earmuffs company work, too.

Do you let your agent speak back to you or do you read it? If it's very verbose, what do you do because obviously reading is faster than than speaking. Yeah, great question. Uh the question is do you let your agent speak back to you in terms of voice um in terms of speed and everything? I actually do all of that. I I have if I'm working most of the time with Claude Code, I'm speaking to it and then it's writing back to me and I'm reading it.

Um but I do a lot of work just in like OpenAI's advanced voice mode. It's one of my favorite things about that ChatGPT. It's one of the only reasons I would use ChatGPT over Claude. And I'll go for a walk for 2 hours and I'll like brain dump and talk back and forth and sharpen an idea and then say at the end of that, "Okay, now make this a succinct transcript or architecture that I can paste." Uh I think it's I can talk to but even that is quite, you know, intelligent enough to have like a I've had you know, conversations of arguable quality with it before.

Um but I and there's also the voice space is moving so quickly that even last night I found one that that that it's an open source ghost pepper that's basically whisper flow. It's local only and doesn't use an API. I think there's like a tremendous amount of ability I I have open claw on Twilio. So at night I can ask for the call and as opposed to it reading to me and then I can talk to it and say this is what I want you to do tomorrow.

Um yeah, I find I find general voice is super efficient. Yeah. Yep. Yes, sir. Uh do you do every kind of work with that? So I I've had similar workflows and I found it works really nicely when you're doing like small bugs or UI fixes and stuff like that and I can, you know, do many things in parallel. But then when I have a more chunky feature, you know, something that needs to touch the back end database, front end, that changes like the whole application work or factor, it it feels like it grinds all of that to a point where then I'm not able to parallelize anymore cuz then it might focus.

Are you able to work on that sort of like more chunky task yourself? Yeah, I think I think it's a great question. I think everyone's struggling with that. The question is you know, these flows work really really well for discrete bite-size tasks and I I agree with that. And then how do you do bigger chunkier ones that are like it's going to touch the entire stack. It's going to, you know, an entire new feature for like a distributed cloud system.

Um where my mind goes for that is is get work trees first of all so that the agents can run in truly in parallel without stepping on each other's work. And then agent teams um with really clearly defined prompts. And then again, it makes the verification gates and the unit tests and um even more important. And then kind of, you know, continuous integration getting to the point where I'm constantly testing the application.

They're constantly building against a spec. I'm flowing back my insults and rage and, you know, into the system and then it's like fixing it and as we go. Um I think that's going to keep evolving though and I I imagine that as models get better, there's going to be more and more complete harnesses to make that more reliable. Yeah, that's a great question. All right, thank you so much.