The debate about agentic software engineering is currently framed as a binary.
- Agents will replace every single software engineer, software engineering is dead as a discipline.
- Agents can never replace a human engineer, all code we write is unique and special.
The reality of the situation is that they're both right.
Okay, not quite. There is a lot nuance to this so let's go through it bit by bit. The first thing to identify here is that this isn't actually one problem, it's two in a trenchcoat. Unpicking this will provide the answer to our question about how both can be true at the same time.
They're the same picture
Before we get into it too much, it's worth us talking about what LLM's and AI's fundamentally are, which is pattern recognition machines. Given enough information, even without context, computers with enough gas can extract, and therefore extrapolate those patterns in useful ways.
- Enough fraud information, we can find features that predict fraud
- Enough medical information, we can identify signs of cancer
- Enough Instagram reels watched, we can identify what will keep you watching
This is true of language models too as well, it's the same mechanism fundamentally it's just dressed up as a fancier magic trick. The clue is in the name Generative Pre-trained Transformer, given a string of tokens a model has been trained to predict what the next in the sequence is, the mechanism is complex enough yes by using things like self-attention to weight which tokens in the sequence are most relevant to each other, decoder architecture for the transformer, but ultimately it's all pattern recognition on existing data.
Why is this so important?
Because it explains the place of novel work, models can only recombine patterns from data they've already seen.
It's the economy, stupid.
Software engineering has always contained two broadly different categories of work:
- The hard, complex stuff. The kind where the problem itself isn't fully understood yet, where the architecture matters, where the wrong decision compounds for years.
- The work that is mostly an exercise in typing. Add a button to a webpage. Wire up this form to that endpoint. Change this label.
The second category has been subject to assembly-line thinking for decades because it scales like an assembly line. Put more people in, get more output out. Agile planners love it.
The people arguing that agentic delivery can never replace engineers are thinking about the first category. They're right. The people arguing it already has are thinking about the second. They're also right. The question isn't whether agentic delivery is as good as a qualified engineer. It isn't. The question is whether it's cheap enough to be a viable replacement in domains where quality is of less importance. That's a much more interesting question, and a much more honest one.
I saw a post recently (I forget where) that argued AI has mostly accelerated the gap between good and bad engineers. I think that's right, but the mechanism is worth being precise about. The problem isn't that the easy parts get faster. The problem is that typing was always the easiest part, even before LLMs. If you weren't thinking carefully about what you were building, you could always just write it anyway - it would be wrong, but it would exist. What LLMs do is make that faster and more convincing. Software is thoughts, not words. The words are just how the thoughts get recorded. Remove the thinking step and you don't get software, you get the shape of software. More output, more noise, no additional value. The gap between good and bad engineers widens not because good engineers get faster, but because bad ones now generate more with less friction and more confidence.
There's a related shift worth naming here. We talk a lot about moving away from deterministic engineering towards a probabilistic approach, as if those two things are close together on a spectrum. They aren't. "Likely improbable" and "mathematically impossible" sound similar. They are not. Deterministic guarantees meant you could say with confidence that a given failure mode could not happen. Probabilistic systems ask you to accept that things work well most of the time. That's a reasonable trade in the right context. In the wrong context, it's how you end up defending a production incident caused by a failure mode you'd considered acceptable to ignore. The domain where "usually works" is good enough is roughly the same domain where agentic delivery makes economic sense. Outside it, you need something more rigorous.
I attended a talk in Manchester recently about a consultancy running experimental fully agentic software delivery teams. The domains where it worked were small website fixes and a pipeline that took handoff specs from a UX team in Figma and shipped the changes. Both of those are interesting to see working. Both are also exactly the assembly-line category - well-defined inputs, clear output, low stakes if something needs a correction. The novelty was real. The scope was honest about what it was.
So where does that leave the first category - the hard stuff?
My current pattern is this. I approach with the problem. I give as much context as I can about the problem and my reasoning. I explicitly tell the LLM not to write anything for me, and I ask it to ask me probing questions instead. It works. Token count is low. I'm making real decisions about what gets built and why. I'm also using it the way I used to use Google - checking whether a specific option exists, asking for a source, verifying rather than generating.
For the complicated work, an LLM used this way is just a better rubber duck. It pushes back. It asks the question you hadn't thought to ask. It doesn't write your code for you, which is exactly the point.
The two camps in the agentic debate are both correct. They've just never agreed on which problem they're discussing.
