Your Developers Aren't Underperforming. They're Undertrained.
Your AI coding spend isn't underdelivering because the tools are bad. The day you handed your developers an agent, you promoted them from writing code to managing it — and forgot to tell them. It's a different job and most of them are hitting the same four failure modes.
Photo Credit: Rob Grzywinski
Anthropic's analysis of 400,000 Claude Code sessions found that the gap between novice and expert users wasn't coding background — it was domain expertise. The more precisely someone could frame what they needed, the more work the agent did. Novices averaged 5 Claude actions per prompt. Experts averaged 12, with output more than five times longer. The tool doesn't replace judgment. It multiplies it. Which means the question isn't whether your developers are using the tool. It's whether they have the judgment the tool is waiting to multiply.The slowdown you're seeing isn't necessarily the tools failing. It's the transition.
Name the Job They Actually Got
An individual contributor — IC — does the work directly. They write the code, lay out the page, run the numbers. The role is defined by what comes out of their own hands. A manager is responsible for the work of other people. Their output is mostly other people's hands.Most companies treat the path between the two as a single ladder: get good enough at doing the work and eventually you climb into the job of getting others to do it. As the engineering leader Diego Ballona puts it, the journey from junior to senior is a continuum; the journey from contributor to manager is a different job.What you're asking your developers to do when you hand them an agent is architect-level thinking: writing a crisp spec that constrains the solution space without over-prescribing the implementation, reviewing for coherence rather than correctness, setting context so precisely that the work that comes back is shaped by the problem, not just the prompt. These are the skills that distinguish a senior engineer from a principal, and a principal from a staff. You're now asking for them from people who may never have needed them before — and reading the gap as a productivity problem when it's a role transition.The difference shows up in what makes each of them feel like they had a good Tuesday. The contributor knows. She shipped the thing. The tests passed. The customer noticed. The reward arrives the same week, sometimes the same hour.The manager's Tuesday is harder to read. Nothing came out of their hands. Somebody else shipped, somebody else got the email from the customer, and what they did, in any visible sense, was sit in meetings and ask questions. They have to learn, usually painfully, that their good Tuesday is somebody else's good Tuesday — and that the proof of their work is not what shipped today but the slow, mostly invisible fact that the people around them are getting better at shipping. The reward arrives in months. Sometimes at a different company entirely, when an old report lands a job she grew into without quite knowing who to thank.Their good Tuesday is somebody else's good Tuesday.
This rewiring is not small. A contributor's nervous system has been trained, often for a decade, to crave a particular kind of feedback: the green check, the closed ticket, the note from the customer. A manager's nervous system has to learn to feed on something quieter. Most of the failure modes below are not character flaws. They are the sound of someone reaching, under pressure, for the only reward they've ever learned how to feel.The job of the people training them is to make sure that reach lands somewhere new.
The Four Failure Modes
Four places people get stuck, in roughly the order they show up. Nobody moves through them in sequence and nobody finishes — but each one is worth knowing before it arrives.Failure Mode 1: Still Doing the Work
The first place people get stuck is the most obvious one, which is perhaps why it's so easy to miss in the moment. The newly-leveraged contributor keeps doing the work themselves.It almost never looks like vanity. It looks like helpfulness. Something falls behind, or somebody is stuck, or the deadline is Friday and it's already Thursday afternoon, and the developer — fast, competent, with the whole system in their head — rolls up their sleeves and gets it done. The team is grateful. The developer feels, briefly, like themselves again. Then the same thing happens the next week, and the week after that, and somewhere in the third month, when the team has come to expect rescue and the developer has stopped sleeping, somebody on a Zoom call uses the word "bandwidth" and everybody nods.Marcel Weekes, who runs engineering at Figma, calls this the "new manager death spiral," which is melodramatic but accurate. The team is effectively without a manager — its manager is doing contributor work — and the contributor work isn't being done as well as it used to be, because the person doing it is also, in the margins, trying to manage. Two jobs, badly.The lesson isn't abstinence. Sometimes pitching in is the right call, and a manager who refuses to ever touch the work becomes a different kind of problem. The lesson is to notice the urge. The pull tends to show up at predictable moments — when something's late, when someone is struggling, when the manager is tired — and the work of the first few months is learning to feel that pull as a signal rather than a command.The replacement behavior: At the moment you feel the pull to fix it yourself, write down what you would have done instead. Not to share — just to make the urge visible. Most people who make this transition well will tell you, in retrospect, that they spent the better part of a year learning to recognize their own tells. The journal is how you learn your tells faster.Failure Mode 2: Handing Off Badly
Once the developer has, mostly, stopped doing the work themselves, the second failure mode arrives almost immediately — because now the work has to be given to someone else. This sounds straightforward and is not.The pattern goes like this: having finally decided to delegate, they over-specify the how and under-specify the why. They write three paragraphs about which approach to take and one sentence about what the customer actually needs. The person on the receiving end does, faithfully, what they were told. The result comes back not quite right. The developer concludes, privately, that delegation doesn't work, and goes back to doing it themselves. The death spiral resumes, wearing a different costume."Build this in three steps, using these tools" gives the person doing the work nowhere to be smart. "Customers need to sign up by email in under thirty seconds, and here are the three edge cases that have bitten us before" gives them a problem they can solve. The first instructs. The second invites.This is where the AI analogy earns its keep. Anyone who's watched somebody get a useless answer out of a coding assistant knows the diagnosis is almost never that the tool is broken. It's that the person typed two vague sentences and hit enter. That same person, asked to write the same instructions for a contractor, would have written a paragraph. The clarity you don't spend at the front, you spend at the back, with interest. This is true whether what's on the other end of the handoff is a junior developer or a coding agent.The replacement behavior: Before you write a handoff — to a person or an agent — write one sentence that completes this: "The person receiving this should be able to make a good decision about X without asking me, because I've told them Y." If you can't complete it, you're not ready to hand off yet.Failure Mode 3: Checking Without Smothering
Now the work is happening somewhere outside the developer's hands. They have to verify it without becoming the bottleneck themselves. There are two ways this typically goes wrong and they are exact opposites.The first is abdication. They handed it off, didn't look at it for two weeks, and now it's the day before the demo and what came back isn't what they wanted. There is no time to fix it. The developer apologizes, fixes it themselves overnight, and resolves to be more involved next time.The second is hovering, which is what "more involved next time" usually turns into. The developer is in every message, every status update, every half-finished draft, asking how it's going. The work suffers, because constant interruption damages all work, and the person doing it feels watched — which is a quiet way of being told they aren't trusted.The replacement behavior: At the moment of handoff, agree on two checkpoints. One in the middle, where the work is shown and course-correction is still cheap. One at the end, with a clear definition of done. Between those two, nothing. The developer does not ask how it's going. They have already arranged a moment at which they will find out.The first few times, the in-between silence is excruciating. The excruciating silence is the skill arriving.Failure Mode 4: Forgetting to Grow the System
The fourth failure mode is the one most often skipped, because by the time someone has navigated the first three they feel like they're managing — and in some sense they are. But the job isn't only to get this week's work done. It's to make next week's work easier than this week's was. Otherwise the team doesn't compound; it just runs harder in place.This shows up in two ways. The first is feedback. New managers, especially those who came up technical, are fluent in one kind of feedback and rusty on every other. They can tell you precisely what's wrong with the architecture of an interface. They cannot, or do not, tell you that the way you handled the conversation with the partner team last week made the partner team a little less likely to trust you next time. Marcel Weekes puts it plainly: we are never as direct as we think we are.The replacement behavior for feedback: Say, out loud: "I have some feedback for you." Then give the feedback. This sounds stilted the first three times and then stops sounding stilted. A startling number of people leave their performance reviews unsure whether they were given any.The second is institutional memory. Teams that compound have a habit of writing down what they learn. The form barely matters: a runbook, a wiki page, a pinned note in a channel, a paragraph at the end of a retrospective. The point is that the lesson, once learned, lives somewhere outside one person's head — so that when that person leaves, the lesson doesn't leave with them. Teams that don't do this relearn the same lessons every quarter and call the resulting exhaustion culture.The replacement behavior for memory: At the end of every significant piece of work — shipped feature, resolved incident, completed sprint — write one paragraph that begins: "Next time we do something like this, we should know..." If that paragraph already exists somewhere, link to it and update it. If it doesn't, you just wrote the first draft of your team's institutional memory.
A Note on Who, or What, Is on the Other End
The four failure modes above describe a single underlying job: leading work that someone else does. What that job feels like, day to day, depends a great deal on who — or what — is on the receiving end of the handoff.When the other end is a person, the manager is dealing with somebody who has a mood, a career, a place in the social order of the team. Feedback lands differently depending on the day. Trust accrues slowly and bleeds out fast. The challenges here are mostly interpersonal: listening better than feels natural, being more direct than feels polite, holding a longer timescale than feels efficient.When the other end is a coding agent — or any tool that produces a draft rather than executes a command — the manager is dealing with something that has no memory between sessions unless you give it one, no judgment about scope unless you set it, and a habit of producing something plausible-looking that is subtly wrong. The challenges here are mostly structural: being precise about what's wanted, building checks that catch quiet errors, writing things down so the same lesson doesn't have to be relearned tomorrow.Neither is harder than the other. They are differently shaped. A person carries memory and judgment but also history, fatigue, and the politics of the team. A tool carries none of those, which sounds easier until you've spent an afternoon explaining the same constraint to it for the fourth time. Both demand management. Neither rewards the old instinct to just fix it yourself.Most teams will, increasingly, have both. The four failure modes don't change. What's on the other end of the handoff does.
The Work That's Left
If you're the leader reading this, the practical part of your job is shorter than the article that led up to it. Name the promotion out loud. Find each newly-leveraged contributor on your team and say, in whatever words feel honest, that the work they're doing now looks more like managing a small team than doing it themselves — and that this is a different job, one you can help them learn. Most of the strain is coming from the unnamed-ness of it. Naming it does a surprising amount of the work.After that, mostly, make their getting-better possible. Pair them with someone half a step ahead so they don't have to make every mistake themselves for the first time. Stop measuring them on the throughput you used to measure them on, or they'll keep optimizing for it and keep drowning. Protect an hour somewhere in their week that isn't allowed to become ship time, because the rewiring we've been describing happens in that hour or it doesn't happen at all.And then be patient. The reward function we're asking them to swap is the one you swapped years ago, and you've probably forgotten how long it took. Months, usually. Sometimes longer. Some of the people you train into this will discover they love it. Some will try it and decide, knowingly this time, to go back to the work that comes out of their own hands — and they'll be better contributors for having seen the other side. Both are fine. What isn't fine is leaving them in the gap, with the leverage of a team and the title of a contributor, alone.That's the gap you can close. That's the work that's yours.
The great AI divide isn't about technology — it's about two clashing definitions of intelligence and who has already lived through a profession being automated away.30 June 2026
We bought artificial intelligence and have been using it like artificial efficiency. The real work isn't prompt engineering — it's onboarding something smart and unfinished, the way good managers always have.15 June 2026