The Backstory
Before I started using coding agents, I wrote enough of each project by hand that I could explain almost any part of it. I knew where every feature started, which services it crossed, and which constraint had led to an odd-looking design decision. I spent hours and hours inside the codebase, so I carried the entire mental model around in my head.
Coding agents changed the amount of work I could take on. On a normal day, I now have around five agents running across a few projects and machines. I’ve even had upwards of ten going in parallel at once. My local coding-agent histories give you an idea of the scale: 2,804 sessions over eight weeks. That includes 747 top-level sessions and 2,057 delegated sessions for exploration, implementation, and review.
I hit the constraint when those agents needed me at the same time. One wanted to know if it should add a database migration. Another had two reasonable API designs and needed me to pick one. A third had finished its work and wanted a review. None of those questions took long to answer, but I had to remember the repository, the original request, the choices we had made, and the part of the system we were trying not to break before I could answer any of them. Don’t even get me started on how painful navigating long history can be in agentic cli sessions.
After doing this for a while, I noticed that re-entering some projects required more reconstruction than it should have. I knew the architecture, but too many implementation details were staying inside individual agent sessions. The agents could produce plenty of code, but I needed that context to decide where the code belonged and whether we should write it in the first place.
The Human Context Window
Despite how much we talk about the context window of agents, more recently I’ve noticed that the agents are able to handle long context windows quite well, and without many issues. The real constraint is now my own context window.
Say I am reviewing an authentication change when an agent from another project asks about a failed deployment. To answer it, I have to put the authentication work down and load how the other project deploys, what that agent changed, and whether the failure is expected. Once I answer, I have to reconstruct the authentication context before I can continue the review.
Do that fifty times in an hour and the day feels different from an hour spent writing code. I was using more energy to remember what I had been doing than to solve the problem in front of me. After a few long days, I had less attention available for the design problems that require a view of the whole system. Unfortunately, those are also the most demanding and attention-heavy areas.
High-Touch, Then Low-Touch
To remedy this, I’ve started treating agent orchestration as an engineering problem.
I now split my time with an agent into a high-touch phase and a low-touch phase.
During the high-touch phase, I stay with the agent while it reads the repository and works out a plan. We settle the scope, talk through the design, and decide which parts of the system it should leave alone. I want to know which files it expects to change and how it plans to prove that the change works. If the task could go in two different directions, I make that choice while I have the project loaded in my head. If there’s any critical experiments to validate the overall approach, we run those “spikes” immediately.
I stay in that phase until the agent has asked the questions that could change its approach. At the end, both of us should be able to explain the task and what the next hour or two will look like.
Once we agree on the plan, I leave the agent to implement it, run the checks, and handle the small reversible choices on its own. I move to another project and give that agent the same attention.
The amount of time is less important than keeping all of the context together. During one twenty-minute planning session, I load the project once. With ten two-minute questions, I may have to load it ten times while I am trying to think about something else.
The first half of the graph is what my day looks like when every agent gets to ask a question as soon as it has one. The small cuts are those quick checks that only take a minute but pull me into another project. The agents spend a surprising amount of time waiting for me to come back and give them the next answer.
In the second half, I plan each ticket in one block and let the agents run at the same time. I come back when a ticket is ready for review. If an agent gets stuck, like the deploy-preview agent in the example, it can wait until I finish my current block. I then load that project, unblock it, and let it continue. With fewer interruptions, I have enough room to keep six agents moving instead of struggling with four.
Batch the Questions
This only works if the agents know how to ask me for input. I added the following instruction to my shared AGENTS.md (I personally prefer taking a personal, conversational tone in these files):
One huge issue that I deal with due to this is context switching, so try to frontload your questions and any input that you need from me, or, if you can’t frontload it, try to group it all together and prepare everything at once for me. That’ll help me stay on track and well informed on what you’re working on.
I ask the agent to inspect the code before it sends me that batch. Getting five questions at once does not help when the repository answers three of them. I want the agent to investigate, narrow the problem down, and bring me the decisions that need my judgment.
For each decision, I want the options, what they affect, and the agent’s recommendation. That gives me enough information to answer while the project is in my head and keeps me from repeating the investigation that the agent has already done.
There are obvious exceptions. If the agent is about to delete data, expand the scope, expose a secret, or make an architectural decision we never discussed, it should stop and ask. The only choices that I let it handle are those that are small and reversible.
I have also become comfortable with an idle agent. I used to see an unanswered question as wasted capacity, so I would interrupt whatever I was doing to keep every agent moving. That was a critical mistake. Now, I would rather leave one agent waiting for twenty minutes than spend the rest of the afternoon trying to remember what I was doing.
Returning Through the Diff
When an agent tells me it has finished, I may have spent the last hour inside another repository. I need a quick way back into the project before I can review its work.
Most of the time, I meet that work through a diff or a pull request description. I ask the agent for a short mental model of the change, the files it touched, the checks it ran, and anything risky or untested. I read that first, then check its claims against the diff.
I do not want a diary of every command the agent ran. That makes me sort through the whole implementation to find the few decisions I care about. Tell me what changed, why it changed, and where I should pay attention.
Why This Works Better
By working this way, I maintain a stronger mental model of every active project. When an agent returns with a diff, I already know which boundaries it should have respected, which files I expect to see, and how it should have tested the change. I can spend the review on whether the result fits the system instead of reconstructing the task.
With the project in my head, I catch decisions that look reasonable inside one ticket but create problems around it. If an agent proposes a new persistence layer, I can check whether an existing boundary already owns that state. If provider-specific behavior leaks into a shared abstraction, I can move it back into the adapter before the pattern spreads.
On long workdays, that difference compounds. When I group my time with each agent, I preserve my attention for the design and review work that needs human judgment instead of spending it on repeated context reloads.
I do not expect to remember every line an agent writes. I do want to understand why each part of the system exists, which constraints shaped it, and where I should look when it breaks. I build that understanding while I plan with the agent and check it again when I review the diff.
Conclusion
Over the past 6 months, I’ve worked much faster with coding agents, but it took me a while to notice what I was giving up for that speed. I had given every agent permission to interrupt me as soon as it hit a question.
Now I give each agent my full attention while we decide what to build and how to build it. Questions come back in batches, and finished work comes back with a mental model, a diff, and the results of the checks it ran. If an agent has to wait until I can load its project again, that is completely fine.
The agents write more of the implementation than I do. I keep the architecture, constraints, and decisions in view so I can make sure all of that code belongs there, and makes sense to me.
I always love improving this workflow as well, so if you’re reading this and see any clear ways to take the next step, I would love an email!
Happy Coding!
-Nicholas