The AI debate is arguing about the wrong thing

2026-08-18T11:30:00.000Z

AI wars, taking place in a galaxy not so far, far away.

I’ve read an increasing number of polarising posts regarding the use of AI in software systems. A kind of “AI wars” if you like.

On one side, the arguments tend to be along the lines of:

• If you don’t write the code, you won’t understand the system.
• If you don’t write the code, you won’t learn.
• AI-generated code creates technical debt faster than we can address it.
• Engineers just become code reviewers.
• Junior engineers lose the opportunity to develop key skills.
• Eventually nobody understands how the system really works.

Therefore serious engineers shouldn’t rely on AI.

On the other side, the argument tends to be that AI is simply another engineering tool:

• Engineers have always used tools.
• Nobody writes all the code from the ground up.
• We already rely on ‘black box’ software, OSs, libraries, stacks and so on.
• AI removes large amounts of the ‘grind’ or mechanical work.
• Engineers can focus on what matters, architecture, requirements and key decisions.

Refusing to use AI is effectively refusing a productivity multiplier. As a result the people resisting the use of AI are simply being nostalgic or afraid of change.

I think both camps are right to some extent, but to my mind:

AI doesn’t necessarily make engineers less capable. Using it without understanding what it’s doing does.

I think each side is arguing about the wrong thing. The most important point is:

We can delegate the work. We can’t delegate the responsibility, not even to AI.

If an AI writes 80% of the code, it doesn’t necessarily mean the engineer understands less. It might, but that will depend on how the tool was used. The real decider isn’t who typed the code. It’s whether the engineer understands the system enough to make decisions about it and, importantly, take responsibility for the consequences.

Equally, a developer can spend three weeks painstakingly writing thousands of lines of code and still have a terrible mental model of the architecture. And, in my experience, there’s often no architecture to speak of, just code.

Using AI doesn’t just mean generating code, it can also be used as a thinking aid. Another engineer could use it to help them think about:

• What the system should do
• Where the boundaries belong
• What assumptions are being made
• How failure should behave
• How the pieces interact
• How the system will be tested
• Whether the implementation actually makes sense

And then use AI to generate the individual parts of the system they’ve decided are necessary. IMO, this engineer will probably have a better understanding of the system, despite personally typing less code.

So, the important question isn’t who wrote the code. It’s

Who understands the system well enough to take responsibility for it.

As an aside, I think there’s another interesting angle emerging as a result of AI which makes the distinction between coding and engineering more visible. For as long as I’ve been doing this, the terms “software engineer” and “programmer” have been used almost interchangeably, much to my irritation.

To my mind, they aren’t the same. If a machine can produce code cheaply, then the value of simply coding decreases. What becomes more valuable then is:

• Knowing what should and shouldn’t be built
• Understanding the architecture and how it all fits together
• Understanding the system’s failure modes
• Deciding which approaches are “good enough”
• Being able to explain how it all works

And then, most importantly, taking responsibility when it doesn’t.

With that in mind, maybe AI isn’t a threat to software engineering. Maybe it’s just forcing us to decide what it really means?