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

Hey everyone, uh, I'm Zack. 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 gonna 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, uh, 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 AM. 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 SCIM 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, uh, the, the outcome and then said, "Okay, now I have, uh, definitively fixed this bug."

So when I came back to it, I came back to, um, a c-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, uh, an important part of what we're going to all build into our toolkit, and we already are.

Um, but it also scared me because I realized that there's, like, there's n-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 d-balance in this, this world, right?

So why not just stack that same, uh, process? Why not use that harness and just fix 150 bugs every day at work? Uh, well, you know, the agents can kinda do that, especially if you give them enough context, if you give them the right, uh, 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 eight-hour work session and not be completely destroyed. So what I think I'm finding, and I think a, a lot of other folks I've been talking to recently are finding, is that, uh, 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. Um, 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 meat space, 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 AM. 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 l, uh, 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 gonna 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 fir-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, m-more applicable, and I think we're gonna 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 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 gonna get distracted by some other thread.

I'm gonna find something else, or somebody's gonna have a new ask for me, and that's gonna 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 @ mentions, are there DMs, are there actually, like, high priority asks that need to be actioned.

Meanwhile, it's al- al- 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 gonna make this kind of like, um, just a bespoke experience wherever you wanna work. Um, but it's sort of about managing the now extra insane levels of traffic and pinging and, and noise that we're all gonna 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 loved to type. I've grown up typing since I was three 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 off and 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 d- how does this compound over the course of a year or 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 gonna 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 broo- blueprint in your mind of what you're trying to build and how you wanna 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, 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, 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 wanna 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 Claude Code ecosystem example. If I'm starting a Claude Code session and I pass the Remote Control flag or I run Remote Control or I have in my config enable Rem- 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, et cetera. But then as soon as I, uh, pull up Claude 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 gonna 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, uh, getting your agents churning, making sure work is proceeding the way that you want, and then leaving the desk, reducing your RSI and the n- 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 Claude 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 gonna 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 gonna 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. Uh, 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, uh, the Claude Code that you must verify your own work with the browser, click through it, and sh- ensure that you haven't broken login, for example. Um, three is closer to like constitutional AI in the, in the way that, um, 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, uh, 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 q- queue up, fire those all into Codex, start working on the features you really care about in, um, in an IDE perhaps, or in Claude Code.

And then essentially you walk away, uh, after getting them kinda 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, uh, fire messages back to them, and you can start reviewing the PRs as they come through on your phone.

And now a- again, because agents are, are-- we haven't quite found the LLM wall, like with Opus 4.6 it's quite reasonable to leave a natural language comment on a PR in GitHub Mobile, @Claude or @, you know, Cursor Agent or @Vercelbot and say, "This needs to change." And most of the time it's gonna 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, 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, a key learning that I've 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, the week, um, Monday feels amazing.

I can rip through a ton of work. Tuesday feels the same. Now I got a bunch of random ass 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 JSONL 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, or 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 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 s- 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.

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, um, reliable manner. Uh, last thing I'll just share for, um, for giggles. Uh, I love, um, my Oura Ring, and one of the first things I did was connect it via MCP.

There's a, a couple of GitHub projects that en- 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 gonna tackle the first part of this, and we're not gonna do the rest of it, and you're gonna do it tomorrow."

And I tell him, "To 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 kinda do this mindlessly, the default path is going to be burnout, but now burnout turbo, like super fast and easier than ever, uh, enabled by LLMs, right? Um, whereas the intentional path is a little bit more like how do I preserve myself, 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 signal layer. It can be as simple, uh, as just plugging in Slack or Linear or 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 eat a 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, um, also doing deep work and-- or at least, like, you know, I learned to program by doing a lot of deep work, getting into, running into issues-

Yep

... and, um, and big-- overcoming those hurdles.

Totally.

Um, it sort of-- And, and I'm also super on board with this new flow of working, but it sort of almost felt like I-

It's been a skill deficit and, like, it's ma-made it harder to learn. So have you found a balance for that where, uh, yet you can still push forward in, I don't know, skill, but, um, while getting benefits of, 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, um, 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 LLMs and AI to go deeper faster and to s- 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 and you have confidence in them, then it's okay to ki- if you've shipped a ton of Ruby apps, it might be okay to start shipping Ruby apps faster with LLMs and Claude.

Um-

Yeah. So, like, only delegate code you're qualified to review or what is-

I, I would. If I w- 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, a-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 st- I still think there's a super bright future for that. So yeah. Great question.

Thanks.

Yep.

Yeah. 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. 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 it at it before. Uh, the question is, how do you ha-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 it at it, but the other thing you can do is use hooks so that the end of every coding session you can say, "Save the key bits that we talked about, and especially highlight where we struggled or where we spent 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.

But are you using AI or just something deterministic?

Uh, well, it would 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.

Yeah. But how do you determine which other bits to save?

Uh, you could just tell it in the prompt, basically. You could say, like, "Look specifically for things that-

It would be an AI prompt?

Yeah, yeah. It would be an AI prompt to say, like, you're specifically look- 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 nighttime, 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 OpenClau. Um, so I do that with, uh, cron jobs, and I have, like, some, uh, doing some content for me. Um, then I wake up in the morning, kind of review it and freak out and scream at it, and then eventually merge, like, a, 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 gonna end up s-settling on is gonna be linear tickets for everything, subtasks for bugs and for feature requests, and then marking tickets with a tag that says agent ready, and then having a loop that's literally going every fifteen minutes, all day long and all night long, churning through personal and, uh, Earmuff's company work too.

Hi. Um, do you let your agent, um, 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 s- agents 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 s- do a lot of work just in, like, OpenAI's advanced voice mode. That's one of my favorite things about that, ChatGPT, and it's one of the only reasons I would use ChatGPT over Claude. And I'll go for a walk for two 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."

Yeah. That's stuck at four point one, right? This GPT four point one or something.

Uh, I think it's-- I, 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... Uh, and there's also the voice space is moving so quickly that even last night I found one that, that-- There'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 OpenClau 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.

Thank you.

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 way the application work or effector, it, it feels like it grinds all of that to a halt, and I'm not able to parallelize anymore-

Yeah

... 'cause I need my focus. Are, are you able to work on that sort of, like, more chunky task yourself?

Yeah. I think, uh, I think that's a great question. I think everyone's struggling with that. The question is, th- you know, these flows work really, really well for discrete bite-sized tasks, and I, I agree with that. And then how do you do bigger, chunkier ones that are like, it's gonna touch the entire stack. It's gonna-- You know, an entire new feature for, like, a distributed cloud system.

Um, where my mind goes for that is, is git worktrees, first of all, so 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, that makes the verification gates and the unit tests, 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 as we go. Um, I think that's gonna keep evolving, though, and I, I imagine that as models get better, there's gonna be more and more complete harnesses to make that more reliable. Yeah. That's a great question.

All right. Thank you so much.