What Two Years of Agentic Coding Did to My Org Chart

Anthropic shipped Claude Sonnet 4.5 on September 29. The launch post reports a 30-hour autonomous coding run on one of their benchmarks. Two weeks later they shipped Haiku 4.5 and openly framed the multi-agent shape as a product:

Sonnet 4.5 can break down a complex problem into multi-step plans, then orchestrate a team of multiple Haiku 4.5s to complete subtasks in parallel.

That is the frontier lab telling you, in marketing copy, that the org-chart shape they assume their customers are building is one lead agent dispatching a fleet of sub-agents. The "engineering manager with reports" model is now an architectural pattern Anthropic sells.

I wrote in June 2024 that engineers were becoming agent managers. Sixteen months later, some of that thesis held up cleanly. Some of it I had wrong. The actual shape my org has been pushed into is not quite what I described, and the difference is worth being honest about.

What held up

The core claim that AI flattens the output curve and forces a rethink of the engineering pyramid has held up. The teams I see shipping faster are the teams where every engineer is competently using coding agents as the default workflow, not a sometimes tool. The "AI-assisted is the default, not optional" line from the June 2024 post is the one I would still write the same way. Sixteen months of data later, it is more true, not less. LeadDev's AI Impact Report, based on 883 engineering leaders surveyed in May and June, finds 38% saying AI tools have already reduced senior-to-junior mentoring. The teams that didn't adapt to AI-default workflows are the ones falling behind on velocity in ways that show up in their delivery numbers.

The other claim that held up is that the work of an experienced engineer is decisively not writing code anymore. The judgment, taste, and system-design work I described as "what seniors actually do" was the right list of skills. If anything, I was too conservative. Reviewing AI-produced output at velocity is a senior skill, and the gap between juniors and seniors on that specific dimension is much larger than the gap was on writing code in 2023.

What I got wrong

The framing I have to revise is the "one engineer can manage five agents in a day" line. Sixteen months later, that number is wrong in both directions, depending on the engineer and the work.

For senior engineers on well-scoped tasks with strong eval coverage, the number is much higher than five. Gergely Orosz's writeup of how the Claude Code team at Anthropic is built, published September 23, is the cleanest public data point we have:

Anthropic saw a 67% increase in PR throughput as their team size doubled, thanks to Claude Code.

Read that carefully. PR throughput up 67% while headcount doubled. The throughput-per-engineer number on its own went slightly down, which sounds like Brooks's Law. It isn't. The shape of what the engineers are doing changed. Less typing, more orchestrating. The team produces more total work with less per-engineer code. That is what happens when the eval rig is good, the agent is competent, and the engineers are senior. Five agents per engineer was a fine number for June 2024. The right number for late 2025, on a strong team, looks more like ten to fifteen sub-agents per orchestrator.

For mid and junior engineers, the number is sometimes lower than five and sometimes zero. The judgment to keep five agents productively scoped, evaluating their output critically, intervening when they drift, is not yet a developed skill in less experienced engineers. The right number for a junior engineer working without a senior watching is one. Maybe two. Past that, the failure modes compound and nobody catches them.

This bifurcation is the part I did not see clearly in June 2024. The "engineers are becoming agent managers" thesis treated all engineers as if they had the same coefficient of agent-leverage. They don't. The senior coefficient went up. The junior coefficient is still close to one.

What this did to hiring

The hiring data is the part of this that is no longer subtle. Meri Williams, CTO of Pleo, told LeadDev in September: "The work that AI can do is similar to what an entry-level engineer can do." That is a CTO on the record. The LeadDev AI Impact Report from August has the numbers that back it up:

54% of respondents expect hiring of junior engineers to decrease over the longer term.

Sara Ali's piece asks the load-bearing question: if AI is doing what juniors used to do, where do the seniors of 2030 come from?

I have run hiring loops twice in the last year. Both times the criteria were different from what I would have screened for in mid-2024. The shift is consistent:

Junior level. I am screening less for "can implement a feature given a spec" and more for "can read AI-generated code critically and tell me what's wrong with it." Reviewing is now an entry-level skill. Implementation, alone, is no longer interesting. We hire fewer juniors than we did, and the ones we do hire have a stronger reviewing instinct than the implementation-strong juniors we hired in 2022.

Mid level. I am screening for the agent-management skill specifically: can you scope a problem to a level an agent can execute, set the eval criteria, review the output, course-correct without rewriting the agent's whole plan? This is a distinct skill from "writes good code," and many engineers who were strong mid-levels in 2023 turn out to be slow at it.

Senior level. I am screening for architecture, taste, and the IA work I argued earlier this year is the actual moat. Strong seniors today own the interface between the codebase and the agents that work on it. They write the specs, they design the tool schemas, they own the eval suite, they decide what gets agent-built and what gets human-built. The senior IC role is now more concentrated and more valuable, exactly as you'd expect once implementation got cheap.

I have not widened my manager span of control on paper. The org chart still says one-to-six or one-to-eight. What changed is that my ICs each carry more leverage, so the team is producing more output without the manager-to-IC ratio shifting. Engineering leaders I have talked to describe the same shape: not "we have one manager per fifteen people" but "we have one manager per six people, who each direct three to five agents on top."

Ben Thompson framed the macro version of this in July: agents are replacements, not copilots, and the per-capita output of an engineering org now reflects the agents, not just the engineers.

The agent-management skill is its own thing

The June 2024 post compared agent management to managing direct reports. That analogy was wrong in the specifics, even though it was right in spirit. Managing agents is closer to reviewing and steering, with very little of the coaching and zero of the career-development work that real management is.

Sixteen months into running teams where every engineer is doing this every day, the skill looks like four sub-skills, in order of how much I see strong agent-managers being good at them:

Scoping work to an agent-executable unit. This is the skill no one sees you doing and the one that matters most. Knowing what to hand an agent (a focused refactor with clear acceptance criteria) versus what to keep for yourself (a design decision that requires reading three systems) is judgment that compounds. Engineers who hand the agent the wrong unit of work spend their day in rework. Engineers who hand it the right unit spend their day shipping.

Reading agent output at velocity. A senior engineer can review a clean AI-generated 400-line diff and tell you whether it is correct in under five minutes. A junior can't. This skill is what scales the per-engineer throughput.

Intervening without losing the plot. When an agent goes off track, the right move is rarely to rewrite the plan from scratch. It is to give the agent the single piece of context it was missing. Engineers who micromanage the agent or restart constantly lose all the leverage. Engineers who minimally course-correct keep moving.

Knowing when to stop the agent and write the code yourself. Sometimes the right answer is no agent. Senior engineers know this. The ones who don't end up burning an afternoon trying to convince an agent to do a 20-minute task.

These are skills. They develop with practice. They are not the same skills that made someone a strong engineer in 2022. The implication for career ladders is that the rubrics need updating, and most haven't been.

A Q4 punch list for engineering leaders

If you are running engineering and the last sixteen months have not visibly changed how your org operates, you are behind the data:

Update your career rubrics. "Code throughput" is no longer a signal at any level. The signal is what the engineer produces with one orchestrator on top of three to ten agents. Your performance rubric should describe that work, not the work of writing code by hand.

Decide what you are doing about junior hiring. The 54% who expect junior hiring to decrease are not all wrong, but "we hire fewer juniors" is a strategy that breaks your senior pipeline in five years. The teams I see being thoughtful are hiring fewer juniors but investing harder in the ones they hire, pairing them aggressively with seniors on agent review, and treating the first two years as deliberate apprenticeship in reviewing AI output. The teams that just cut junior hiring will pay for it in 2030.

Make the agent-management skill an explicit ladder rung. Don't promote a strong agent-manager because they "ship a lot." Promote them for the skill they actually have. And don't punish a strong engineer who is bad at agent management for being slow; pair them with someone who isn't and figure out which work each is good at.

Audit your manager span. Probably do not widen it yet. Your reports each have more leverage now, and the temptation is to absorb that into wider span. The thing that scales now is the leverage, not the span. Keeping the span narrow and letting the leverage grow is the move I have settled on after trying both.

Connect this to your review process. The review bottleneck I wrote about in April has gotten worse, not better, since Sonnet 4.5 shipped. If you have not invested in AI-assisted review tooling and the structural changes around it (smaller PRs as a contract, review-as-IC-work for staff+), the agent throughput is going to break your review queue this quarter.

Where I land

The June 2024 post said engineers were becoming agent managers and that the org chart was going to change. Sixteen months later, both halves are true, but the change is sharper and more uneven than I described. Senior IC roles concentrated. Mid-level engineering bifurcated by agent-management skill. Junior hiring contracted measurably. Manager spans mostly didn't widen; the leverage per IC did.

If you wrote a career ladder in 2022, throw it out. The work has changed. The titles haven't caught up yet. The teams that build the new ladder first are the teams that retain the engineers who are actually doing the new work.

Everyone else is paying senior salaries for the old job description.

The pyramid I described in June 2024 is gone. What replaced it is not flatter. It is more concentrated at the top, sparser in the middle, and the bottom is going to be carefully apprenticed instead of mass-hired. That is the shape I have on my org chart today and the shape I see on every healthy engineering org I have talked to this year.