A principal engineer asked me a question in an interview this week. He said that with Claude and Copilot, one to three senior engineers can now run a codebase that used to need a whole team of juniors and mid-levels under them. Did I agree?
I did. I still do. But I think he stopped one step short of the real answer. What that senior now needs is a peer, not a junior.
The short version
The engineering team did not shrink. It changed shape. AI ate the junior tier first, because junior work is supervised execution, and that is exactly what coding agents do well. What it did not do is give the remaining senior a peer. So the senior running a product on AI is faster than ever and more alone than ever. The gap is not cheap hands anymore. The gap is a second set of senior judgment.
That is the whole argument. The rest of this post is why it is true, and what it means if you are the senior in that chair.
Why the junior tier went first
Think about what a junior engineer actually does on a team. They take a well-scoped ticket, write the code, get it reviewed, and learn from the corrections. This is the same apprentice-to-master path the centuries-old apprenticeship model has always run on. The senior holds the context, makes the calls, and supervises. That division of labor is centuries old in every craft. The apprentice executes, the master decides.
Coding agents slot into the apprentice slot almost perfectly. I give Claude a clear brief, it scaffolds the module, writes the tests, drafts the docs, and runs the mechanical refactor across two hundred files without getting bored. I review it the same way I would review a junior. The difference is it never sleeps, never context-switches, and turns the work around in minutes. This is not a toy demo either. I have written before about running agentic AI in PHP as production architecture, not a prototype.
So if your only reason to hire a junior was “I need more hands to execute work I have already figured out,” that reason is mostly gone. The principal engineer was right about that.
What did not move
Here is the part that gets missed. The agent took the execution. It did not take the ownership.
I run a US referral-marketing SaaS as fractional CTO. I have run it since its launch in 2016. Over eighteen months I took its architecture scorecard from 4.5 to 8.0, shipped a Preact migration, killed a third of the jQuery, moved the whole build to Vite, and stood up the first phase of distributed tracing. One engineer, multi-engineer pace. The leverage is real and I do not want to undersell it.
But every one of those decisions was mine. Whether to rip out the MySQL triggers and move to PHP events. Whether to stay on the custom framework or rewrite on Laravel. Whether a migration was safe to run on production this week or needed another pass. The agent executed brilliantly once I decided. It could not decide. More importantly, it could not tell me when my premise was wrong before I spent two weeks building on it.
That is the thing a peer does that an agent cannot. A peer pressure-tests the call before the work starts. A peer catches the wrong assumption. A peer carries half the weight at 2am when production is down and the decision is judgment, not code. AI scales execution. It does not scale ownership, and it does not scale judgment.
So the team has a new shape
The old shape was one senior on top, a few juniors underneath, lots of hands and one head.
The new shape is one senior plus a fleet of agents. Plenty of hands. Still one head. And that one head is now the single point of failure for every architecture call, every trade-off, every “is this premise even right” moment in the entire product.
That is not a staffing win you celebrate. That is a risk you have to name. The faster you ship alone, the more decisions ride on one person with no one to check them.
Why that senior needs a peer, not a junior
Not a junior. You already replaced that with a tool that is faster and cheaper.
You need a peer. Someone who has run a real product on AI leverage and knows where it lies to you. Someone who can take half the architecture load, not half the typing. Someone you can hand a hard call to and trust the pushback, because they think the way you think and they have the scars to prove it.
That is a different hire than the org chart used to have. It is not a body to manage. It is a second head to share the weight with.
Frequently asked questions
Does AI replace junior engineers? For pure execution work, mostly yes. Coding agents handle scoped tickets, scaffolding, mechanical refactors, test writing, and documentation at a speed and cost no junior can match. The apprentice slot is the slot AI fills first.
Can one senior engineer run a whole product with AI? Yes, on execution. I have done it for years on a live SaaS. What one senior plus AI cannot do is provide a second source of senior judgment. The output scales. The decision-making does not.
If AI handles the work, why hire anyone at all? Because AI scales execution, not ownership. You still need someone responsible for the hard calls, the trade-offs, and the moments where the premise itself might be wrong. That is peer-level judgment, and an agent cannot hold it.
What is the right next hire for a solo senior running on AI? A peer, not a junior. Someone who has shipped real work on AI leverage and can carry half the architecture and decision load, rather than someone you have to scope and supervise.
The takeaway
AI did not make the team smaller. It made it shallower. One head, many hands. If you are the head, the smartest thing you can add is not another pair of hands. It is a second head.
If you are running your product alone on AI right now, I am too. That is the chair I sit in every day. If you want a peer to share the weight of the hard calls, not a junior to manage, let us talk.
