From Babysitting to Orchestrating, and Why the Gap Is a Skills Gap
The abstract for this talk lands a phrase I keep coming back to: stop babysitting your AI and start orchestrating it. I want to take that further, because the gap between those two modes is not a confidence gap or a tooling gap. It is a skills gap. And the developers who close it are not the ones with the best models. They are the ones who have learned a small set of moves and made them habitual.
I spent the first year of my serious Claude Code usage in supervision mode. I gave it tasks, read every diff, approved every command, corrected every drift. The output was good. My throughput was capped at the speed of my attention, which is to say, capped at one task at a time. The moment I started learning the orchestration moves, my output changed shape. Not because the model got better. Because I stopped being the bottleneck in my own workflow.
Three things to take away
- The cost of supervising a capable model goes up, not down. If you keep watching every diff, the model finishes in three minutes and your review takes ten.
- The single biggest payoff is verification the agent can run on its own. Tests, type checks, linters, visual checks. Build them first, prompt second.
- The move from one agent to three is a different skill than running one well. Parallelism rewards structure, not enthusiasm.
The math against babysitting
There is a simple piece of math that explains why supervision mode breaks at scale. Suppose the agent takes T minutes to do a task. You take R minutes to review the work. If R is less than T, the agent is your bottleneck and watching makes sense. If R is greater than T, you are the bottleneck.
In 2024, R was almost always less than T. The model was slow, the agent loops were brittle, and you needed to catch mistakes early. So you watched. That was the right call.
In 2026, the math has flipped for most tasks I care about. The model finishes faster than I can read what it did. If I keep reviewing line by line, I am paying for the model's speed with my own throughput. The fix is not to read faster. The fix is to stop reading every diff in the first place.
The way you stop reading every diff is to make the agent prove its own work. The agent ran the tests. The agent ran the linter. The agent took a screenshot and the screenshot looks right. The agent ran the integration and got the expected response. Each of those proofs replaces a piece of your review. When the proofs are stacked deep enough, your review becomes a spot check instead of a full read.
That investment is what moves you from babysitting to orchestrating. It is unglamorous. It is also the only way the math works.
The setup matters more than the prompt
The other failure mode I see in babysitting-mode developers is overinvesting in prompts and underinvesting in the surrounding setup. They tune a prompt for an hour. They run the prompt. They get an okay result. They tune again. They are optimizing the wrong layer.
What actually determines whether an agent succeeds is the environment around the prompt. The CLAUDE.md that tells it what the project is. The hooks that fire when it makes changes. The skills it can invoke. The MCP servers it can call. The permission boundaries that keep it from breaking things. The verification commands it runs before declaring done.
Once that environment is right, the prompt can be short. "Add a feature that does X" lands cleanly because everything around the prompt is doing its job. When the environment is wrong, no prompt is good enough, because every prompt has to compensate for a missing piece of the setup.
The first time I rebuilt a project's CLAUDE.md from scratch and added three hooks, my prompts got shorter and my success rate doubled. That was not a prompting lesson. That was a setup lesson. The prompt is the last thing you tune, not the first.
Verification, then review
If I had to name the one move that closes the babysitting gap fastest, it is this: build the verification before you build the workflow.
When I start a project now, the first thing I do is make sure the test suite runs cleanly. The second is to make sure the linter and type checker run cleanly. The third is to write a script that runs all of those together and reports back in a way the agent can read. Only then do I start using Claude on the project.
The reason is that the agent only earns autonomy when it can prove its own work. Without proof, every output is a question. With proof, every output is a claim with evidence. I review claims with evidence very differently than I review questions. I trust the claim until something looks off, and I spend my attention on the parts where the proof is missing.
Most projects I inherit do not have this. The tests are flaky. The linter is configured but never run. There is no integration smoke test. So every agent run is a question, and the developer answers the question by reviewing the diff. That is the babysitting trap. The fix is to build the proof layer before you scale the agent usage.
Recovery patterns are the moves that matter
The other gap between supervision and orchestration is how you handle failure.
In supervision mode, you fix the failure yourself. The agent went wrong, you take over, you correct the code, you continue. That works, but it teaches the agent nothing, and it makes you the recovery mechanism for the project forever.
In orchestration mode, you treat the failure as a signal. Why did the agent fail here? Was the prompt wrong? Was the context missing? Was the verification too lax? Was the permission boundary too tight? Each failure should produce a small change in the setup, not a manual fix to the code.
The pattern I use is "roll back, learn, retry." When the agent goes off the rails, I do not edit the diff to save the work. I revert. I look at what was missing. I add it, either as a clearer hook, a better CLAUDE.md instruction, a tighter scope on the prompt, or a new verification command. Then I re-run.
That sounds slow. In practice it is faster, because each rollback teaches the setup something, and the setup compounds. After a few weeks, the failures are different failures. The old ones do not come back, because the setup learned them.
Parallelism is a different skill
Once you can run one agent reliably, the next question is whether you can run three at once. The answer is yes, but parallelism is a different skill than autonomy. You can be great at running one agent and bad at running three.
The constraint is coordination. Three agents on the same codebase will trip over each other. Three agents on three branches will produce three sets of changes that need to be merged. Three agents on three sub-tasks of the same feature will produce inconsistent assumptions about the shared parts.
The patterns that work for parallelism are about isolation. Worktrees so each agent has its own filesystem. Scoped tasks so the work does not overlap. Clear merge points so the integration is explicit. A coordinator session that does not write code itself but tracks what the others are doing.
I run two or three Claude Code sessions in parallel on most days now. It took me a few months to stop losing track of which session was doing what. The fix was to keep a simple text file open with the status of each session, and to make each session write a brief note to that file when it finished. Once the coordination was external to my head, parallelism stopped being chaos and started being throughput.
The mental model shift
The biggest change is the mental model. Babysitting treats the agent as an extension of your hands. You are still the one doing the work. The agent just types faster.
Orchestration treats the agent as an extension of your team. You are still the one accountable for the work, but you are not the one doing every step. You delegate, you set expectations, you check the output the way you would check a colleague's output. Some things you let through. Some things you push back on. None of them are your direct work.
That shift changes how you measure your own day. In babysitting mode, productivity is "how much code did I produce." In orchestration mode, productivity is "how many things shipped, regardless of who typed them." The second metric scales. The first one does not.
What to do this week
Pick the last five tasks you did with Claude Code. For each one, ask: did I supervise this or did I orchestrate it? If you supervised, why? Was it because the task required your judgment, or because your setup did not give you the proofs you needed to trust the agent?
The first answer is fine. The second answer is the work. Find the task type you supervise most often, identify the proof that would let you stop, and build it. That is the move.
The model is already capable. The gap is your setup. Close the setup gap and you stop being the bottleneck.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: Stop Babysitting Your Agents at Code with Claude London 2026. https://youtu.be/wI0ptqCSL0I