There seem to be two dominant opinions about AI and programming. One says AI is mostly useless because it writes horrible code and fixing its mistakes takes longer than writing the code yourself. The other says that AI-generated code is so good that it will eventually make programmers obsolete.

I think both arguments focus on the wrong thing because they focus on who writes the code.

We never wrote all the code

I've never considered that the ability to recall syntax and typing code from memory to be particularly important to my job. I use documentation. I search the internet. I copy examples from Stack Overflow. I read blog posts. I look at code written by colleagues.

In a modern software system, this is almost unavoidable anyway. A typical application might involve TypeScript, Python or Go, YAML, Dockerfiles, SQL, configuration files, CI pipelines and a dozen other technologies. Nobody has every detail of all of them memorized.

So if copying a useful piece of code from Stack Overflow has always been acceptable, why would asking a machine to produce that code be fundamentally different?

Ownership was never about authorship

There's another reason I don't find the "AI writes the code" argument particularly convincing: We have always worked on systems we didn't write.

You inherit a service from another team. Someone who left the company wrote half of it. Three people contributed to the part you're responsible for, and you don't even remember who wrote which function. Yet after working with the system for long enough, you start to think of it as yours. Why?

Not because you wrote every line. Because you understand it.

You know what it does. You know why it behaves the way it does. You know where its boundaries are, what its dependencies are, and what happens when something goes wrong.

That's what ownership actually feels like.

The dangerous thing to outsource

This is where I think AI-assisted programming gets interesting. The problem isn't that the machine writes the code, the problem is that it's very easy to let it take over the thinking as well.

There's a huge difference between saying "I understand what needs to happen; write this for me" and saying "make this work" and then accepting whatever comes back.

In the first case, you've delegated typing, while in the second you've delegated understanding. And those are not remotely equivalent.

Debugging is where it becomes obvious

Writing code is surprisingly easy to outsource. Debugging is much harder to outsource without giving up something important.

When you debug a system yourself, you're forced to construct a model of it. You have an expected outcome. Something different happened. So you work backwards: what should have happened? What would have needed to happen to produce the observed result? Where in the chain did reality diverge from your expectations?

After enough of these exercises, you develop something incredibly valuable: an intuition for how systems behave.

I've worked with developers who didn't have this skill. When something broke, they changed things at random. They simply shot in the dark until eventually something worked, but they had no idea why. That's not debugging.

AI makes it remarkably easy to fall into exactly this pattern. Give the machine the error, let it propose a fix, try the fix, report the next error, repeat until the tests pass. You can produce working software without ever developing a useful mental model of the software you're producing.

The illusion of competence

This is what worries me more than AI replacing programmers. AI can create the illusion that you understand a system because it can make the system work for you. You ask a question and get an answer. You encounter an error and get a patch. The patch doesn't work, so you provide the new error and get another patch. Eventually the machine finds something that works.

From the outside, this looks like competence. But if you don't understand why the solution works, you're not actually becoming more capable. You're becoming dependent on the machine to maintain the illusion.

And the consequences become particularly serious when something happens that the machine can't solve, or you just run out of tokens. At that point you need the mental model you never built.

This matters even more for juniors

For experienced developers, there's at least a large reservoir of knowledge built from years of working through problems the hard way, but for someone starting today that experience may never accumulate in the same way.

If every frustrating debugging session can be handed to an AI, there's little incentive to spend four hours figuring out why a system behaves the way it does. And those four hours are not wasted time. They're where the mental model comes from.

You don't learn systems by successfully changing them, you will be able to successfully change them once you are able to explain why they fail.

Don't outsource the understanding

I don't think the answer is to stop using AI, quite the opposite. Use it aggressively. Let it write the boilerplate. Let it remind you of syntax. Let it explore an unfamiliar library. Let it implement the tedious parts.

But keep the important part for yourself.

You should understand the problem. You should decide what the system should do. You should make the architectural decisions. You should be able to explain how the pieces fit together and why they were designed that way.

Let the AI write the code, not design the solutions.

The developer becomes more architectural

If writing code becomes cheap and accessible to everyone, then writing code stops being much of a differentiator. The developers who stand out will be the ones who understand systems.

Architecture. Integration. Distributed systems. Observability. Failure modes. Boundaries. Trade-offs. The things that exist around the code rather than inside it.

In that sense, AI may actually push developers toward a more architectural role.

The best developers won't be the ones who refuse to let the machine write their code. They'll be the ones who use the machine to understand their systems better, while remaining firmly in control of the decisions.

I made a video version of this discussion if you'd rather watch it: Beyond recall: The role of the Software Engineer in the age of AI.

Thanks for reading.