Will AI replace software engineers? No, and the data on how developers actually spend their time explains why: coding itself eats up somewhere between 9% and 61% of a developer's day depending on the study, the rest is requirements-gathering, review, and the accountability of actually shipping something that works. AI agents compress that coding slice. They don't touch the rest.

That's not a reason to hire the same way you did two years ago, though. What's actually changed isn't whether you need developers, it's what's worth screening for when you do. The candidates who look strongest on paper, the ones who ship the most visible code the fastest, aren't automatically the ones actually moving your product forward anymore.

What AI actually changes about the candidates you're evaluating

Google principal engineer Jaana Dogan, as reported by The Pragmatic Engineer, described giving Claude Code a description of a problem and watching it generate, in about an hour, what her team had spent a year building. That's a real, named, verifiable data point, not a vendor claim, and it's the actual shift worth paying attention to: the valuable skill is increasingly working fast and correctly in a codebase you don't already know cold, not having spent five years specializing in one language.

That reshapes what a strong candidate looks like. A developer who can describe a problem precisely enough for an agent to act on it, then verify the result, is doing the job that used to require deep, narrow expertise in your specific stack. Teams that used to insist on "a senior engineer with Go experience specifically" have less reason to hold that line. A competent generalist can use an agent to get productive in an unfamiliar codebase quickly, which is exactly the pattern The Pragmatic Engineer's reporting points to as well: startups hiring one generalist who works across the whole stack with an agent, instead of separate frontend and backend specialists.

This is the hiring-side version of the same shift already reshaping how the senior engineer role itself is changing and what actually breaks in a team's process once agents write a growing share of the implementation. A two-person team hiring its third engineer isn't choosing between "the React person" and "the backend person" anymore, it's evaluating whether this person can move across both with an agent's help, which is a genuinely different interview to run.

Does junior hiring change

Not in the way most of the AI-replaces-jobs framing assumes. One documented case makes the real risk clear: a team saw an eight-fold increase in lines of code shipped after adopting AI coding tools, but only a 30% increase in actual releases. Volume of code was never a reliable measure of a junior hire's real contribution, and it's an actively misleading one now that an agent can inflate it without any corresponding increase in what actually ships.

That doesn't mean junior hiring goes away. It means the scarce skill for a junior hire shifts. The old bar was "can write correct boilerplate." The new one is "can write a spec clear enough that an agent's output is worth trusting, and can actually verify it."

That's teachable from day one, arguably easier to teach than deep language mastery ever was. Screening on the old signal, raw code output or years with a specific framework, is now the weaker predictor of the two.

What a small team should actually screen for

For a 2-8 person team, three things matter more than they did before:

• Spec clarity. Can this person describe a problem precisely enough that someone else, or an agent, could act on it without guessing at intent? This is closer to a writing skill than a coding one, and it's rarely tested in a standard technical interview.
• Verification judgment. Given a chunk of AI-generated code, can they actually tell whether it's correct, not just whether it runs? A candidate who accepts agent output uncritically is a real liability now, in a way a slow-but-careful reviewer never was.
• Comfort moving across unfamiliar code. The Dogan example is the model here: speed and competence in a codebase you didn't write, not depth in one you did.

If the strongest candidate for that third hire happens to need relocation or work-authorization sponsorship to actually join, what qualifying for something like the EU Blue Card actually takes is worth checking before the offer goes out, not after a candidate has already turned down a competing offer while waiting on paperwork.

None of this replaces the scope-based framing that already applies at every level. The ceiling between senior and staff was never about raw skill, it was always about scope, and that logic holds just as well when evaluating a new hire's actual contribution against their raw code output.

The real answer to "will AI replace software engineers" is that it's already changed who looks like a strong hire, without changing whether you need to hire at all. A candidate who writes a lot of code fast is not automatically the stronger one anymore. The one who can specify precisely, verify honestly, and move confidently through code they didn't write is.