AI Coding Agents Rewired Engineering Roles. Here's Who Absorbed the Cost.

The loudest engineering argument of the last month was not about which model writes better code. It was about who is left to check it.
Across Hacker News, Reddit, and a run of YouTube post-mortems, the same story kept surfacing: teams adopted coding agents, shipped noticeably faster for a quarter, then found the bottleneck had not disappeared. It had moved. It landed on the small number of people senior enough to tell good output from confident nonsense.
The comment that summed up the month
In one of the bigger threads on agent adoption, a reply with a few hundred upvotes made the point better than any analyst report:
Six months later, oops, we hired too many and now we have to do layoffs again.
Adopt agents. Watch output per engineer jump. Conclude the jump is permanent. Adjust headcount to match. Then discover the second-order costs arrived a quarter late, wearing different names: rework, incident volume, review backlog, a codebase nobody quite understands.

The velocity was real. The durability was not.
What agents are actually good at
Coding agents are genuinely strong on boilerplate, glue code, test scaffolding, a first pass at a CRUD endpoint, mechanical refactors, and turning a well-specified ticket into a plausible diff. On that slice they are fast, cheap, and better than most people expect.
They are weak wherever the specification is the hard part, wherever the work needs a mental model of a system they cannot see, and wherever being confidently wrong is expensive. They will produce a 400-line diff that compiles, passes the tests it wrote for itself, and does the wrong thing, with no signal that anything is off. The first half is why adoption is not optional. The second is why it is not free.
Tier one: the junior squeeze
The slice agents handle well is, almost exactly, the slice junior developers used to be given.
Nobody handed a junior the concurrency bug or the migration on the payments table. They got the well-specified ticket. They shipped it, someone reviewed it, and they learned what "good" looked like by having it corrected fifty times. That loop is the apprenticeship, and it ran on the same tasks an agent now completes in ninety seconds.
| The old loop | What it produced | Where it went |
|---|---|---|
| Junior takes a scoped ticket | Working code, slowly | Agent does it in minutes |
| Senior reviews the diff | Judgment transferred | Senior reviews agent output instead |
| Junior repeats for two years | A mid-level engineer | No longer happens by default |
| Mid-level grows into review | The next senior | Pipeline runs dry in ~3 years |
The honest framing is not "agents replaced juniors." It is that agents replaced the training set. The role still has value; the default path into it was switched off, and nobody switched on a replacement.
Tier two: seniors became reviewers
Meanwhile the senior job changed shape without anyone renegotiating it.
Catching a wrong-but-plausible 400-line diff requires knowing the system, knowing the business rules, and having been burned before. As agent output scaled, that verification load landed on the people who already had the most context, which is the same people who were supposed to be doing the hard design work.

So throughput on an agent-heavy team is capped by senior review hours, not generation speed. Teams that added agents without adding review capacity did not get faster. They got a larger queue of unreviewed work, a longer path to production, and senior engineers doing less of what they were hired for.
There is a morale dimension too. "Senior engineer" and "full-time reviewer of machine output" are different jobs. Teams that never said that out loud tend to find out through resignations.
Tier three: is "AI engineer" a real role?
Strip the marketing and the role is mostly this: someone good at specification, evaluation, and integration, applied to probabilistic components instead of deterministic ones. Writing the spec precisely enough that output can be judged, building the harness that judges it, and knowing what to do when it is right 94% of the time. Those are not new skills, which is why the jump is easiest for engineers who were already good at the boring parts.
The practical read: do not hire for the title. Hire for specification and evaluation ability, and let the title follow.
Five things that actually work
1. Hire juniors for review, not just output. Put them in the review seat early, paired with a senior, on agent-generated diffs. It is the fastest judgment-building exercise available, and judgment is now the scarce skill.
2. Make the agent explain itself. Require the prompt, the reasoning, and the alternatives considered in the PR description. A diff you cannot interrogate is a liability regardless of who wrote it.
3. Budget review capacity explicitly. If agent output doubles and review hours do not, you have bought a queue.
4. Measure defect escape rate, not lines shipped. Velocity metrics are exactly the ones agents inflate. If you cannot see whether quality moved, you are making budget decisions on a number that means nothing.
5. Keep one system nobody automates. Every team needs a codebase where humans hold the full mental model. It is your insurance for the day an agent confidently rewrites something load-bearing.
Are AI coding agents replacing junior developers?
What is the real bottleneck when a team adopts coding agents?
Is "AI engineer" a genuinely different role from software engineer?
How should we measure whether agent adoption is working?
The short version
Cutting junior hiring is real savings and it lands on this year's budget, which is why it keeps happening. The cost lands in year three, when the seniors absorbing all the review have moved on and there is nobody behind them.
Agents did not remove work from software engineering. They moved it from writing to verifying, and verifying was always the expensive part. That is not an argument against agents, which are a genuine gain teams cannot afford to ignore. It is an argument against pricing that gain as though the expensive half had disappeared. Teams that staff for verification come out ahead; teams that read one quarter of velocity numbers as permanent will hire twice and lay off twice.


