AI Isn’t the First Time We ‘Stopped Understanding the Code'

I’ve been hearing a lot of criticism about AI-generated code lately, and the more I listen to it, the more it sounds… familiar.

The common thread is that people don’t really understand the code anymore. That AI is doing the heavy lifting. That we’re creating engineers who can ship things without truly knowing what’s happening under the hood. And there’s this underlying concern that something foundational is being lost.

But we’ve been here before.

About 20–25 years ago, when I was first getting into the industry, I remember my senior engineers saying the same things about Java and C#. They came from C and C++, and to them, it felt like the compiler was doing all the real work. Memory management was abstracted away, guardrails were everywhere, and the question was simple—if you’re not working at that level, are you really engineering?

And yet, those languages didn’t kill engineering. They expanded it.

We didn’t lose rigor, we moved it. Less time on low-level mechanics, more on architecture, systems, and scale. The work didn’t disappear, it shifted up a layer—and it enabled a lot more software to be built.

And over time, the tooling got better. Compilers improved. Runtimes got faster. Early concerns faded as the ecosystem matured.

That’s what this moment with AI feels like—just happening faster.

Yes, the tool is doing more. Yes, people can generate code faster than they can fully reason about it line by line. And yes, that introduces risk. But it’s the same tradeoff we’ve always made with abstraction. The difference is AI tooling will evolve quickly, and a lot of today’s concerns will likely be engineered away.

At the same time, deep engineering understanding still matters. There’s a reason systems like Unreal Engine are still built in C++. When performance, memory control, and real-time constraints matter, abstraction only gets you so far. Someone still needs to understand what’s happening underneath when things break or need to scale.

Abstraction doesn’t remove complexity. It relocates it.

Most developers will live above that line, building faster with AI. But there will always be a need for engineers below it—shaping systems and solving the problems the abstraction can’t.

So when I hear that AI is doing too much of the work, it feels like we might just be measuring the wrong work.

We’re not watching the erosion of engineering. We’re watching another shift in where it happens.

#AI #SoftwareEngineering #DeveloperExperience #Programming #TechLeadership #AIinTech #Coding #Engineering #Innovation

Previous
Previous

If AI Writes the Code, Why Are We Paying to Review It?

Next
Next

Why AI Is Making Waterfall-Style Requirements Attractive Again