«Why Not Just Use AI Instead of Hiring Engineers?» The Honest Answer
I hear the question on sales calls now, asked without embarrassment, which is new: «Why would I pay for senior engineers when the AI writes the code?»
It deserves a straight answer, and I'm oddly well placed to give one. I run a company that deploys senior engineers, so you know my incentive — but every squad we place works AI-first, our own tooling is built on agents, and I've spent months of my own nights inside agentic loops. If AI could genuinely replace my engineers, my margins would have noticed before my blog did. They've noticed something else instead, and one experiment from last year captures it better than any argument I could build.
The concession first: AI replaces real work, today
Anyone who answers this question with pure reassurance is selling you something. So the concession up front: a real slice of what junior engineers used to be hired for is gone, and it isn't coming back. Boilerplate, CRUD scaffolding, first-draft functions, test skeletons, one-shot migration scripts — the writing of routine code is now a commodity, and the market has already repriced it. SignalFire's talent data shows new graduates fell to 7% of Big Tech hires in 2024 — down by more than half from pre-pandemic levels — while demand for experienced engineers kept rising. The 2025 DORA report puts AI adoption at 90% of nearly 5,000 developers surveyed, with over 80% reporting productivity gains.
If the question were «can AI write code?», the answer would be yes and this would be a short post. The question you're actually asking is «can AI replace the people I was going to hire?» — and there the best data we have says something stranger.
The experiment: 19% slower, convinced they were 20% faster
In mid-2025, METR ran a randomized controlled trial — 16 experienced open-source developers, 246 real tasks in mature codebases they knew well. Developers allowed to use AI tools took 19% longer to complete their tasks. Asked afterwards, the same developers estimated AI had made them 20% faster.
Fair caveats, because this number gets abused in both directions: 16 developers is small, the repos were mature codebases with high quality bars, the tools were early-2025 models, and METR itself now flags the result as historical. I don't cite it to claim AI slows engineers down — in greenfield work, with current models, I've watched the opposite. I cite it for the gap between the two numbers, because a 39-point spread between measured and perceived speed is not a tooling problem. Perceived velocity and shipped outcomes are different quantities, and it takes engineering judgment to know which one you're looking at. That judgment is the thing you were hoping to skip hiring for.
DORA's own data carries the same tension inside it: 90% adoption, and yet 30% of the same developers report little or no trust in AI-generated code. Ninety percent usage with thirty percent trust isn't a contradiction — it's a job description. Someone has to be the trust layer.
I've watched this gap up close, and it always has the same shape: an agent refactors a service, the diff reads clean, the review closes feeling twenty minutes richer — and days later someone traces a subtle regression to a renamed config key three files away from anything the review touched. That half-day of tracing wipes out roughly fifteen «twenty minutes richer» moments. The refactor felt fast because the slow part moved downstream, where nobody was measuring. Multiply that by a team and a quarter, and you have the METR spread wearing production clothes.
What you're hiring is the harness, not the typing
The model is the commodity; the harness around it is the moat. Concretely, the work that remains when code generation costs nothing:
- Deciding what not to build — the model will happily generate either branch; choosing costs judgment.
- Verification — reviews, tests and evals that catch the confident-but-wrong 30%, cheaply and before production does it expensively.
- Architecture — the boundaries, contracts and failure modes that determine whether ten thousand generated lines compound into a system or into debt.
- Guardrails and permissions — the sandboxing, rate limits and rollback paths that let you give an agent real access without giving it your incident budget.
- Ownership at 3 a.m. — when production breaks, a model can help debug, but accountability doesn't run on inference.
We measured where the money goes in our read of the reactive-work data: AI commoditized the writing of code and made everything around it more valuable, not less. The engineers worth hiring in 2026 are the ones who operate that surrounding layer — which is why our vetting tests judgment on live architecture with AI on the table, not syntax from memory, and passes 3% of candidates.
The uncomfortable number on my side of the argument
One more stat, because it cuts against me and you should have it: that SignalFire figure — new grads at 7% of Big Tech hires — is an industry eating its seed corn. Senior judgment is trained, and the training ground was exactly the routine work AI just absorbed. If every company hires only seniors for a decade, the 2035 senior market is today's junior market that never got hired. I don't have a clean answer; nobody does yet. What I can tell you is what we do about it operationally: our squads pair AI-fluent seniors with the client's own earlier-career engineers precisely so the judgment transfers somewhere — because the alternative is renting judgment forever from a shrinking pool.
We've seen this movie before
Every wave of abstraction triggered the same question. Compilers were supposed to shrink programming teams; frameworks were supposed to end custom development; cloud was supposed to delete the ops role. Each time, the routine layer collapsed and demand moved up the stack to people who could wield the new abstraction — the engineer came back with a bigger surface to own, not a smaller one. The death of software keeps being announced, and the backlog keeps growing. AI is the largest of these waves, and the pattern is holding: fewer people hired to type, more hired to decide, verify and operate.
What I'd do with this quarter's budget
If I were sitting on your side of the call, four moves:
- Don't hire for code volume. Any role whose output is measured in lines or tickets is a role AI has already repriced. Write the job around judgment: architecture, review, evals, incident ownership.
- Hire fewer, more senior, AI-fluent. One senior engineer running agents well now covers what a pod used to — but only if they're genuinely AI-ready: fluent in prompting, tooling and in distrusting output for the right reasons.
- Budget for the trust layer. Put explicit time into evals, review discipline and guardrails. The METR gap is what an org looks like when perceived speed goes unaudited.
- Run the experiment on your own repo. Measure task completion, not vibes, for one sprint with and without heavy AI assistance. Whatever the result, you'll know which quantity your team has been reporting to you.
The answer, in one line
So: why not just use AI instead of hiring engineers? Because the question assumes the code was the product. It never was. The product is a system that works, keeps working, and can be trusted with your customers — and AI has made the code cheap while making that trust more expensive to produce. Use the AI. Hire the judgment that makes its output true.
If the judgment is the part you're missing, that's the exact profile we place: senior, AI-first engineers, matched in 72 hours.
