Check out my previous post on this topic. It sets the stage for the problems addressed by my current workflow. To summarize, over the past 9 months, I scaled my workflow by:
Increasing the number of parallel agents running at any given time.
Switching from AeroSpace virtual screens to Herdr to see all agents on one screen.
Using mobile (Tailscale, Herdr, Moshi) to keep my agents working around the clock.
Hitting the Wall
But this wasn’t enough. It created a new problem: I couldn’t keep up with my agents.
I no longer remembered what any particular agent in my Herdr session was doing. Which one was responsible for this PR? Which one is blocked? What feature was this again? I started coping by just scanning through all the agents over and over again, telling them to remind me what they were doing. I was back to inefficiency, and, moreover, my brain was melting.
It was clear that even with Herdr, Moshi, and multiple agent sessions, I had hit peak productivity. To get more done, I needed to change something fundamental.
The short list of problems:
No longer able to keep track of individual agent sessions.
Too much manual work in getting code merged (reviews, CI failures, etc.).
Flatlining productivity - not able to scale to getting more work done.
All time in the day was spent managing agents; no free time to think or do other aspects of the job (marketing and sales).
Agents are amazing, but I had never felt so scatterbrained. A lot of posts on social media describe how agents kill flow for software engineers. I think that’s true in the traditional sense, but it is possible to get into flow around things not related to code. But at a certain point, the chaos of just managing all these little virtual bots erodes even that.
All my time and attention was being spent on agents. So, how did I get my time back? I reframed the problem. Instead of optimizing for maximizing agent productivity, I changed the optimization function to be minimizing human attention.
A New Prioritization Function
Back when I worked in Big Tech, we’d use the prioritization framework below for figuring out what to build. For every potential feature/project, we’d label it with potential impact and cost (you do this in a very quick, pseudo-scientific way). We’d then focus on building the stuff that was high impact, low cost and go from there.
Teams would brainstorm, look at customer feedback, look at data, and generate a list of ideas (the backlog). Then, the EM, PM, and TL would go through the list and do "t-shirt" sizing (low, medium, high) - they'd label each item with an estimated cost and estimated impact. The prioritization framework above sorts the backlog based on these t-shirt sizes.
Here's the question: when the cost of building things basically goes to zero (and yes, you can argue that tokens aren't free, but go with me here), what is the new prioritization framework?
So this is how I think about prioritization with agents. Instead of the prioritization orienting around features or things to build, the prioritization framework must orient around the new scarce resource: my attention.
This is how I work now. In a world where I can build anything, I need to be super intentional with my attention. Given a particular item of work, I think about how much attention it needs and then choose the right tool for the job.
The diagram above calls out this idea of the loop. I mean this in the abstract sense - a software development lifecycle process - with observable points. When a human is the loop, you are managing the SDLC yourself. When you have a human around the loop, you are monitoring those observable points of the SDLC yourself. When an agent is around the loop, you've built a harness or some type of adversarial review system to monitor the points of the SDLC. And finally, you can of course just ask the agent to do it all (there is no SDLC - it's just the agent).
I like this framework because it flips the focus on how to optimize workflows - you go from optimizing how you build to what you pay attention to.
Three Workflows
I use three different agentic workflows depending on the attention/impact matrix.
Claude Code with subagents is the top-right corner: high impact, high attention. Since Opus 5.5 came out, Claude Code has become my go-to lab-owned harness. It's a great model AND its support for subagents is killer. I start a session with Claude, and then just vomit work at it and tell it to use subagents to fan out the work - it can put up multiple PRs. Note that I use this approach for other cells when needed; I'm not a framework purist. Claude and subagents are great when you dogfood since you can just say "fix this with a subagent" over and over again and just get all the fixes.
The factory covers most of the framework. Putting aside memes around software factories, my factory puts the software delivery lifecycle on rails. It maintains points I can check in (planning, code review), and I can choose to use those or just approve plans/merge (fully automated). It automates a bunch of stuff I was wasting time on - polling PRs, fixing CI issues, unblocking agents, fixing bugs that would come up when working on a new feature, and so on. The factory makes it easy for me to automate building and releasing full features (task epics), and I can choose how much attention to pay.
A /goal loop, ultracode, or custom harness is my go-to when I want to just one-shot a new app, tool, or experiment. When a project is not in the critical path, and I intentionally want to use a model's intelligence instead of my own, I use these techniques to try to one-shot it so I can stay focused on more critical work. For example, to port our 314,000-line TypeScript CLI to Rust, I built a custom harness, rustify: it walks the import graph, tells agents what to port next, hands them a self-contained brief, and fails CI if the port falls behind the TypeScript. Sometimes I'll degrade this way of working into shotgun prompting.
The Results
I track my PRs per week to understand how my velocity changes as I tweak my workflow (given how I work, each PR typically represents one task and ranges from 600 to 1,200 LOC). I opened 7,142 PRs this year: about 50 a week in January, around 200 when I hit the wall in August, and 300–520 a week since the Factory.
Now, PR count is not a perfect metric. And I moved away from trying to maximize velocity a month or two ago. Instead, I try to minimize where I need to spend my human attention. I think focusing on human attention as the metric to minimize is far more interesting and can lead to many more creative insights around work, what agents are good vs bad at, and where to spend my scarce attention resource.