If you're using agentic coding tools on real projects, your next hire probably shouldn't be another engineer.
The chain of reasoning starts somewhere unexpected, and it ends at a job title nobody is currently posting for.
Start with what you actually control
The way this works now: break a project into small pieces, hand them to sub-agents, merge the results.
Reliability engineering tells you what happens next. The more sub-agents you add, the lower the probability the merged result is correct. It also drops with the reliability of each individual agent.
So as you launch more sub-agents, the only thing you genuinely control is the probability that each one does its job properly.
There are exactly two ways to raise that.
Better models. Less prone to hallucinating, more likely to follow instruction. Expensive, and largely out of your hands.
Better testing. Every sub-agent is verified as it finishes, which means the whole thing rests on test coverage.
One of those you can buy. The other you have to staff, and that is where this gets interesting.
What a sub-agent actually is
Drop the word agent for a second, because it smuggles in assumptions.
A sub-agent is a junior developer. Each one gets a small piece of work that can be unit tested on its own, and that does not require knowledge about anything else.
That last clause is the whole design constraint, and it's the one people skip.
If the piece needs context from four other pieces, you cannot test it standalone, you cannot clear the context between runs, and you cannot tell whether it failed because it was wrong or because it was misinformed. The work has to be sliced so each slice is genuinely self-contained.
Managing a fleet of sub-agents is managing a team of juniors who share no memory.
The skill that job needs is slicing work, not writing code.
Now notice what producing those slices actually is. PRDs. Stories. Product backlog items. Small pieces, each independently testable, each with a definition of done.
That is a product owner's job description. It has been for twenty years.
Follow the second lever down
Better coverage means more scenarios. You can work with the AI to generate scenarios and write test plans against them, and the model is genuinely good at that part.
But it cannot originate them.
The model doesn't know which edge cases matter in your business, which failure would be embarrassing versus catastrophic, or what a correct outcome looks like to the person who used to do this job by hand.
Ask a model to enumerate what a login could encounter and it will give you wrong username, wrong password, password too short, too long. Good list. It will not tell you that in your business a password reset during an active session corrupts a downstream record, because that fact lives in somebody's head and has never been written down.
So the scenarios are only as good as the domain knowledge behind them. And there is a stronger version of this that changes the sequencing.
Write the tests first, because they are code
If the tests are deterministic, they are code. If they are code, you can write them before the work exists.
Set up the test first, run it, and you have coverage as a fact instead of a hope. The agent then has an unambiguous target: make this pass. Not "follow these acceptance criteria," which is a request. Make this specific check go green, which is a gate.
That inverts who is on the critical path. The bottleneck is no longer generation. It's whoever can say what correct looks like precisely enough to encode it before a line is written.
Generation capacity is not your constraint any more.
Knowing what correct means is.
Which is why the hiring is off
"Everyone's hiring AI engineers" is usually hiring for the wrong bottleneck.
Not because engineers aren't needed. Somebody has to build the gates, the validators, the event infrastructure, and none of that writes itself. But generation stopped being scarce and judgment about the domain did not.
If you're staffing a team to ship with agents, the question is not who writes the most code. It's who can decompose a problem into pieces that are independently verifiable, and then say precisely enough what each one must do that a deterministic check can prove it.
Some engineers are excellent at that. Most job postings do not screen for it.
What this costs you
Both moves have a bill attached, and it lands on people who were not expecting it.
The product owner becomes the bottleneck. You removed a generation constraint and installed a judgment constraint. Fifty sub-agents need fifty sets of acceptance criteria, and those come out of one person's head at human speed. That does not fan out, right? You just moved the queue.
Enumerating failure is a different skill from defining value. Most product owners are trained to describe what good looks like. Writing scenarios that break a login is closer to QA analysis, and the market prices that separately. Expect to train for it or hire for it.
Slicing for independence fights natural decomposition. The way a feature divides cleanly for a human team is not the way it divides for agents with no shared memory. You will over-slice, hit pieces that genuinely cannot be made self-contained, and have to hand those back to a person.
Test-first costs you upfront when the design is still moving. Encoding correctness before a line exists is exactly wrong during exploration, where you do not yet know what correct is. This works on well-specified work and fights you on discovery.
Domain knowledge that lives in one head is a single point of failure. Making it explicit is the actual value here, and it is also the thing that person may have no incentive to do quickly.
When you actually do need the engineer. If you have no gates, no validators, and no event infrastructure, a product owner writing perfect acceptance criteria has nothing to enforce them with. Judgment is the bottleneck only after somebody built the thing that acts on it.
What to do tomorrow
Look at who writes your acceptance criteria. If it's an engineer guessing at domain edge cases, you've found your reliability ceiling.
Take one work item and ask whether it can be unit tested with no knowledge of any other item. If not, it isn't sliced yet.
Before the next AI hire, ask what the actual bottleneck is. More output, or knowing whether the output is right?
The 90-second version. Everyone's Hiring AI Engineers. They're Hiring the Wrong Person.
Everything above stands on its own.
Chris