Some of the strongest engineers I know won’t work with coding agents, at least not at the level I’d expect. A bit of Cursor yes, some Claude -- but it’s an add-on, not fundamental harness loop engineering. Just as likely, they are uncomfortable with it because they have never had to practice the skill it takes.
They see the problem quickly. They know the part of the codebase that needs to change, the shortcut that will fail in production, and the test that will catch it. Then they give an agent two sentences, watch it head in the wrong direction, and take the keyboard back. Ten minutes later the change is done.
Their conclusion is reasonable: I can do this better myself.
For that one task, they may be right. But they have skipped a different piece of engineering. They moved from idea to code. Agentic development inserts a middle layer:
idea -> communication -> outcome
That middle layer is delegation. It means deciding which context another actor needs, which decisions belong to them, what cannot change, how the result will be evaluated, and when the work needs to come back. A manager has to do this with people. Coding agents have made it an individual-contributor skill too.
We teach engineers how to solve problems. We teach design, decomposition, testing, and code review. We spend far less time teaching them how to make their understanding usable by somebody else.
I think that explains a meaningful share of the gap between engineers who get substantial output from agents and engineers who find them irritating. The evidence does not prove delegation skill is the sole cause. It does show that expertise can make instruction more abstract, that experienced developers do not get an automatic productivity gain from AI, and that successful agent use depends heavily on problem framing and evaluation.
TL;DR
Solving a problem yourself and specifying it for another capable actor are different forms of work. Agentic development makes engineers practice the second one.
Experts can be poor instructors because their knowledge has become compressed. A Stanford study found experts gave more abstract, less concrete instructions than beginners.
In roughly 400,000 Claude Code sessions, people made about 70% of planning decisions while Claude made about 80% of execution decisions. The human job did not disappear. It moved toward intent and evaluation.
Useful delegation defines the outcome, relevant context, decision authority, evidence of success, and a return path. It leaves implementation room inside those boundaries.
Engineering organizations should teach and assess delegation alongside system design, testing, and code review.
Strong Engineers Short-Circuit the Middle
Expertise is compression.
A senior engineer does not consciously replay every step required to diagnose a stale cache, unwind a dependency cycle, or recognize that an innocent schema change will break an old consumer. Years of experience have turned those steps into pattern recognition. That is part of what makes the engineer fast.
It can also make the engineer a poor source of instructions.
In a 2001 Journal of Applied Psychology study, Pamela Hinds, Michael Patterson, and Jeffrey Pfeffer asked experts and beginners to give novices instructions for an electronic circuit-wiring task. The experts used more abstract and advanced statements, with fewer concrete statements. Novices taught by beginners performed better on the same task and reported fewer problems with the instructions.
The expert instructions had a different advantage. Novices taught by experts transferred what they learned more successfully to another task in the same domain. Abstraction was useful, but it was pitched at the wrong level for immediate execution.
That is a close description of many failed agent sessions. The engineer supplies the concept because the missing steps no longer feel like steps. The agent supplies its own version of those missing steps. Then the engineer calls the output stupid.
Sometimes it is. Coding agents make bad decisions, miss local conventions, and produce code that passes a narrow test while violating the system around it. But “the agent should know that” often means “I knew that and failed to communicate it.”
The distinction gets lost because explaining the work feels like overhead to somebody who can already do it. Delegation is slower than execution until the delegated system starts producing more than one person’s hands can.
Seniority Does Not Produce an Automatic AI Gain
A strong counterweight to AI productivity anecdotes remains METR’s randomized study of early-2025 coding tools. Sixteen experienced open-source developers completed 246 tasks in repositories where they averaged five years of prior experience. When AI tools were allowed, completion time increased by 19%.
The developers expected a 24% speedup before the work. Afterward, they still estimated that AI had made them 20% faster.
This is a historical result, not a verdict on current models. The study mostly used Cursor with Claude 3.5 and 3.7 Sonnet. METR later changed its follow-up design after more developers declined to participate because they did not want to work without AI, which introduced selection bias. The researchers also warn against treating their original participants as representative of software development as a whole.
Still, the result closes off one comforting assumption: being good at a codebase does not make somebody good at directing an agent through it. The participants knew their systems. They had substantial AI experience. They could choose whether to use the tools. And in that setting, the tools cost them time while feeling faster.
METR did not test my delegation thesis. It measured the gap I am trying to explain.
Agentic Development Splits Planning From Execution
Anthropic’s June 2026 study of roughly 400,000 Claude Code sessions offers a clearer picture of the work split. Its classifiers attributed about 70% of planning decisions to the person and about 80% of execution decisions to Claude.
Planning included what to do, which approach to take, and what counts as done. Execution included which files to change, what code to write, and which commands to run.
This is delegation in software form. The person retains the problem and the acceptance decision. The agent gets a bounded decision space inside it.
Anthropic also found that novice-rated prompts led to around five agent actions and 600 words of output, while expert-rated prompts led to about 12 actions and 3,200 words. Sessions rated intermediate or above reached Anthropic’s strict verified-success measure 28% to 33% of the time, compared with 15% for novice-rated sessions. When sessions ran into trouble, expert-rated users recovered more often.
There is a circularity in those numbers. Anthropic’s expertise classifier partly looked at how precisely a person framed directions, what they asked Claude to verify, and whether they corrected the model. Those are delegation behaviors. The study shows that the behaviors travel with longer agent runs and higher measured success, but it cannot tell us how much each behavior caused the result.
The occupational result is still suggestive. In code-producing sessions, management occupations finished slightly above software occupations on the strict verified-success measure, though Anthropic says managers may be more likely to state explicitly that they got what they wanted. A skill learned by directing people may transfer to directing software agents.
Small qualitative studies point the same way. In a 2026 mixed-methods study of senior and junior engineers, Dana Feng, Bhada Yun, and April Yi Wang found that senior engineers maintained control through detailed delegation. They scoped changes, supplied context, delegated smaller units, asked for minimal reviewable diffs, and refined the work through feedback. The junior engineers moved between over-reliance and cautious avoidance.
Ten juniors and ten seniors are not a population. But the described behavior will be familiar to anybody who has watched one person steer an agent while another person alternates between accepting everything and taking the work back.
From Hub to System
An engineering leader recently described his problem to me as being “too much in the hub.” Teams waited for him to make decisions. Work crossed his desk because he knew the history, the risks, and how the parts fit together. His competence had become part of the system architecture.
So he started moving ownership outward. One leader took a product area. Another took day-to-day operational work. The change was not a pile of redistributed tickets. Each person received a decision space and a return path.
Senior individual contributors create the same topology when every difficult change routes through them. Doing the work faster reinforces it. Soon the engineer is both the source of expertise and the queue in front of it.
Coding agents make that topology visible because they are always available to receive work. If nothing can move without the engineer touching the implementation, availability was not the constraint. The system had no interface for the engineer’s judgment.
Delegation builds that interface. A useful handoff answers five questions:
Decision Question Outcome What observable state should exist when the work is done? Context Which system facts and prior decisions affect the work? Authority What may the delegate decide or change without asking? Evidence Which tests, traces, screenshots, or artifacts establish success? Return path When should the delegate stop, ask, or escalate?
This applies to a person, an agent, or a group of agents. The amount of detail changes. The information contract does not.
Delegate Outcomes, Not Motions
“Implement this endpoint” delegates motion. The instruction names an activity and leaves the purpose, production bar, ownership boundary, and failure conditions unstated.
An outcome-level delegation describes the state the system must reach. It supplies the constraints that protect surrounding systems and says how to determine whether the result is acceptable. The delegate still chooses the implementation inside that space.
OpenAI’s Codex harness-engineering case study includes two good examples: service startup must finish in under 800 milliseconds, and no span in four named user journeys may exceed two seconds. Those are outcomes an agent can test. The repository exposes the application, logs, metrics, architecture rules, and remediation instructions required to pursue them.
The team did not achieve that by writing longer chat messages. It made the environment carry repeatable context. Plans became versioned artifacts. Architecture constraints became linters and structural tests. The agent could inspect the same evidence used to judge its work.
That team reported around one million lines across code, infrastructure, tooling, and documentation, with roughly 1,500 pull requests opened and merged over five months by three engineers directing Codex. OpenAI estimates the product took one-tenth the hand-written time. The more durable lesson is in their account of the slow start: progress was poor while the environment was underspecified.
I have seen the same pattern in my own work. Trusty Tools, the Rust-based multi-agent system I have been building since May 19, reached 3,200 commits and 3,426 closed GitHub issues by September 3. The current checkout contains roughly 1.46 million lines across code, documentation, and configuration formats.
Those are activity metrics. They do not prove the software is good. They do prove I was not typing every change myself.
The work moved when I stopped treating the agent as autocomplete and started treating the repository as an operating environment. Instructions became code-adjacent. Review rules became executable. Agents received narrow authority and had to return evidence. Failures fed changes back into the system instead of becoming one-off corrections in a chat window.
Delegation Has a Cost
Good delegation takes time. That is a feature, not a bug. It is why strong engineers resist it.
Vincent Schmalbach’s June 2026 pilot study on software delegation contracts compared ordinary issue-style prompts with explicit contracts covering the task, authority, returned work package, and acceptance context. Across 64 runs on ten small TypeScript tasks, every run passed the hidden acceptance tests. The contracts did not improve correctness because the tasks were already easy for the agents.
They improved reviewability. Evidence sufficiency improved in 22 of 30 paired comparisons and worsened in none. Reviewers saw more changed-file lists, known limitations, residual risks, and checklists. The contracts also used 13% more agent tokens and took 38% more wall-clock time.
That is a good trade only when reviewability is worth the cost. On a tiny task you will do once, it may not be. On repeated work, risky work, or work distributed across several actors, a reusable contract can pay for itself because the next handoff starts with an interface instead of another explanation.
Delegation also fails when it becomes abandonment. Giving somebody an outcome does not transfer away responsibility for the problem framing, the quality bar, or integration with the larger system. Autonomy needs a boundary and a feedback loop.
In one leadership model from my notes, exploratory work happened in a sandbox against broad targets. Useful results returned to an owner who could productionize them. The exploration was allowed to fail. The production handoff was not.
That distinction matters with agents. “Go figure it out” can be appropriate when the blast radius is small and the work is exploratory. It is negligence when the agent can change production state and nobody has defined how it returns evidence.
Teach the Skill
Delegation should appear in engineering development before somebody becomes a manager.
Code review already gives us the right setting. Ask an engineer to write the issue another engineer could implement without a private briefing. Ask what the assignee can decide, which constraints are real, which test would change the author’s mind, and when the work should come back. Then evaluate the handoff alongside the patch. Architecture exercises can do the same. A candidate should be able to design a subsystem and divide it into owned outcomes with interfaces between them.
Senior promotion rubrics should look for expertise that travels: working agreements, executable checks, useful documentation, and teams that can make decisions without routing every question back through the expert.
Engineering education is beginning to move this way. After two 2026 roundtables with roughly 30 to 40 academic and industry participants each, Sungmin Kang, Baishakhi Ray, and Abhik Roychoudhury argued that future engineers should learn to translate intent into machine-checkable specifications and evaluate whether those specifications capture the intended result. They also put agent orchestration and verification into the proposed curriculum.
I would call the umbrella skill delegation.
The engineer who can do everything is not necessarily the engineer who can create the most throughput. Agentic development rewards the engineer who can make judgment portable without pretending judgment has disappeared.
We will still need people who can solve the hard problem themselves. They are the ones most able to recognize a wrong abstraction, an unsafe shortcut, or a test that proves less than it claims. But if all of that understanding remains inside one person’s implementation process, it can guide only one stream of work.
The goal isn’t to do less engineering. It’s to move more of the engineering into a form that other capable actors can use.
Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.
Related reading:
What Is Harness Engineering? (And Do You Need to Learn It?). Why the system around the model determines how much useful work it can do
AI Power Ranking. Tool comparisons and benchmarks for AI practitioners
LinkedIn Newsletter. Strategic AI insights for CTOs and engineering leaders
I really like your phrase “Expertise that travels”. It is a really useful way of framing a core component of senior expertise.
Your article really struck a chord in me. In my coaching work with experts, delegation comes up often.
Early in an expert's career, much of their credibility comes from what they can solve. The danger is that being the person who can solve the hardest problems becomes part of their identity. They become the firefighter everyone calls. And they get good at it. And fast.
But eventually that can become a personal and professinal constraint.
In my work with experts across multiple fields, such as engineering, I frequently discuss one measure of senior expertise: "What can happen because of your expertise when you're NOT in the room?"
I think I like "Expertise that travels" better.
Delegation is a capability that everyone struggles with when they first become responsible for other people's work or development. It is not unique to experts. First-time supervisors struggle with it too. But people with deep subject matter expertise definitely struggle more because of all the reasons you share in your article.
I work to set goals for experts who need to delegate more:
- Can other people make better decisions because of you?
- Can they challenge their own assumptions they couldn't previously see?
- Can they solve problems without escalating to you?
- Can you make others less dependent on you?
AI makes this much more visible because suddenly experts have another “actor” to whom they need to transfer intent, context, and judgment. And that actor often doesn't ask hard questions or challenge the expert. It doesn't say "I don't know enough" before it starts the task.