The agent can produce code faster than you can review it. That’s the bottleneck now, not the keyboard, not the compiler. You.
Before agents, the constraint was how fast you could write code. Now it’s how fast you can review it. The agent ships. You approve. And the agent is faster than you. You’re not the producer anymore. You’re the reviewer. And that changes everything about how you should spend your time.
Orchestration is review
If agents are the service layer (available, fast, ready to write code on demand) then you’re the orchestration layer. You schedule the work, set the direction, define the tasks. And what does an orchestration layer actually do? It routes, it prioritises, and it checks outputs. That’s review.
You set the direction. The agent does the work. You review the code, the approach, the intent. You’re a manager now. Not of people, of agents. Your job isn’t to write the code. It’s to set the direction and make sure what ships is correct.
Your bottleneck is not how fast you can produce. It’s how fast you can judge.
The second-order problem
Here’s what nobody talks about: managing has overhead too.
The agent can write code faster than you can track what it’s doing. It opens PRs, hits blockers, waits on dependencies. You are now the dependency the agent is waiting for. It’s only possible to “always have an agent running” or “always be burning tokens” if you can keep up.
There’s a cognitive load to keeping up with everything: context switches, code reviews, PR statuses, rebases, deployment config that needs updating after rollouts. This load compounds quickly when you’re trying to keep multiple things moving.
Use the agent as your chief of staff
The answer to cognitive overhead is the same as the answer to everything else: the agent.
But this time the agent isn’t doing more work, it’s tracking work. Externalise your brain to the agent. Give it every task, every PR link, every blocker. Let it tell you what’s on fire and what can wait.
You scaled your output with AI. Scale your management the same way.
There are two levels of tracking work. There’s the level that’s useful to your team: Jira tickets, Linear issues, the stuff that maps to sprints and roadmaps. And then there’s the level that’s only useful to you: every PR that needs a rebase, every review comment to address, every CI failure blocking a merge. You’re not going to write Jira tickets for those. But they still eat your attention.
That’s what the agent tracks. Not the team backlog. Your backlog. The stuff that’s too granular for any project management tool but too numerous to hold in your head.
Let the agent track what’s todo, done, and blocked. You don’t need a new tool or a new app. Markdown files and a chat interface. Keep the system boring.
Give it the tooling to check your PRs with the gh CLI. Let it query which PRs are passing CI, what need a rebase, who’s requested changes.
Don’t waste your brain CPU cycles on the grunt work of orchestration, offload that to the agent.
Practical tips
- Build a
/what-nextskill that prompts the agent to check in on all your work (especially PRs) and tell you what to do next. - Give the agent a sense of priority when you hand it a task. The output of
/what-nextwill be better for it. - The agent has no concept of time, so its instructions need to include using the
dateCLI to get the current date and time. - Tell the agent to always print GitHub URLs when it mentions tasks or PRs, so you’re not wasting time hunting them down.
Direction, review, priority
That’s the job now. You’re not writing the code. You’re deciding what gets built, reviewing whether it was built right, and deciding what matters next.
The agent can handle the rest, including the overhead of knowing what “the rest” even is.