"Agentic Engineering" Hype Meets Delivery Reality

In June 2026 a paper went up on arXiv with a title that doesn't believe in hedging: "The End of Software Engineering: How AI Agents Are Transforming Software Engineering." Its argument, in short, is that AI agents – language models doing the reasoning, orchestrated to act rather than just suggest – will take over a large share of the work software engineers do today.

The same month, in the same corner of the internet, a piece in BigDATAwire described the actual experience of teams using AI to write code and called it a paradox: code generation got faster while delivery got harder.

Read those two back to back and you've got the whole strategic problem of this moment in one sitting. One says the profession is ending. The other says the teams living it can't reliably ship faster than they did before. Both were published in the same thirty days. Both are, in their own way, true.

The mistake leaders are about to make is picking one.

A preprint is a hypothesis, not a roadmap

Let me be clear about what the arXiv paper is and isn't. It's a preprint – a researcher's argument, posted for discussion, not peer-reviewed, not validated, not a measurement of anything that happened. That doesn't make it wrong. Preprints are often where the real thinking shows up first. But it's a claim about the future written in the confident present tense, and we have a long, embarrassing history of treating those as if they were already the case.

"The end of software engineering" is not a new headline. We've retired this profession before. No-code was going to do it. Offshore was going to do it. The last few framework revolutions were each going to do it. Engineering kept being a job because the part that's hard about it was never the typing – it was deciding what to build, understanding what breaks, and being the human accountable when it does.

So when someone hands you a future-tense claim – agents will replace your engineers – the strategist's job is to notice that it's being used to justify present-tense decisions. Cut the team now. Freeze hiring now. Mandate agents now. Those are bets on the vision, made with this quarter's money, and the vision hasn't shipped yet.

What the ground truth actually says

Here's what we can observe rather than project. Teams are adopting these tools fast. Code is getting generated fast. And delivery – the rate at which working software actually reaches customers and stays working – is, by the honest accounts, not improving the way the demos promised. Faster at the keyboard, no faster out the door, sometimes slower once you count the review and the rework and the things that broke downstream.

I've built software with agentic tools myself this year. I'm a product manager, not an engineer, and they genuinely let me do things I couldn't have done alone. So I'm not standing here to tell you the agents are fake. They're capable, and getting more so. I'm telling you something duller and more useful: capability at generating code is not the same as capability at shipping reliable software, and the gap between those two is exactly where the agentic-engineering story is currently weakest.

An agent can write the code. It cannot yet own the consequences of the code being wrong. The reasoning has gotten remarkable. The accountability hasn't moved an inch, because accountability isn't a capability you can train into a model – it's a thing a person carries.

Holding both at once

So what do you actually do, sitting between a paper announcing the end of your discipline and a release calendar that says delivery got harder?

You separate the timelines. The trajectory is real and worth tracking – agents are getting better at engineering work, and a leader who ignores that is choosing to be surprised later. The present is also real – right now, on your team, the tools are not reliably improving delivery, and decisions that assume they are will cost you. You can believe the direction and distrust the timeline at the same time. That's not fence-sitting. That's just reading two true things accurately.

In practice that means you keep experimenting with agentic tools seriously, because the direction is worth being early on. And you refuse to make irreversible org decisions – headcount, structure, commitments to customers – on the strength of a future that's still a preprint. You let the delivery numbers, not the manifesto, tell you when the capability has actually arrived. When agents genuinely start moving cycle time and change-failure rate on real work, you'll see it in the measurements before you see it in a headline. Until then, the headline is a weather forecast, not a window.

The line that doesn't move

Every wave of "this ends software engineering" has quietly relocated the work rather than deleting it. The boring parts get automated, the bar for what counts as skilled goes up, and the human ends up doing more judgment and less typing than before. There's no reason to assume agents are different in kind rather than degree. The generation gets cheaper. The deciding, and the owning, stay where they've always been.

So read the paper. Take the direction seriously. Then go look at your own delivery numbers, because that's where you'll find out what's real on your team versus what's real in a title. The future-tense version is loud right now. The present-tense version is the one you're accountable for.

If you're trying to tell the trajectory from the hype on your own engineering org – and make adoption calls that survive contact with your release calendar – that's the kind of read I do at Fieldway. matthew@fieldway.org.