AI Coding: Are We Fighting a Battle We've Already Lost?

I keep reading posts from people arguing that AI still can't do software development as well as a human developer.

Many of these posts claim that AI-generated code is insecure. Yet AI has also demonstrated its ability to uncover vulnerabilities that have remained undetected for over a decade.

So perhaps it's time to rethink what we actually mean by secure code.

Anyone who has worked in cybersecurity for nearly two decades, as I have, knows that security has never been an absolute guarantee. It's about managing risk and reducing the probability of a successful attack.

Systems are more likely to be targeted when they are widely adopted and provide access to valuable information: credit card details, banking credentials, passwords, and so on.

The principle is relatively simple: when an attacker's resources exceed a defender's ability to protect a system, compromise becomes increasingly likely.

We've even seen supposedly isolated, air-gapped systems compromised through infected USB devices, as demonstrated by Stuxnet. Imagine the challenges today, when almost every device needs to be connected to the Internet.

But that's not really the point. It's just the background to my argument.

So, what's the real point?

Twenty years ago, developers were still writing a significant amount of low-level code. In certain applications, parts of the software were even written in assembly language to squeeze out every bit of performance.

With the adoption of object-oriented programming, the goal shifted towards organising code into larger, reusable components, improving efficiency, maintainability, and readability.

Back then, I remember asking myself a simple question:

Will there ever be a function like db() that gives us access to an entire relational database without having to deal with all the underlying complexity?

Time has shown us just how much abstraction is possible.

Now, why did developers start adopting ready-made frameworks instead of building every single application component from scratch?

Simple: time, resources, costs, and time to market.

These were, and still are, the key factors in deciding how to build new software.

Remember when a custom-built enterprise application was already outdated by the time it was finally released?

That's exactly the problem I'm talking about.

And now we have AI.

Today, whenever we discuss vibe coding or AI-generated software, the same argument keeps coming up:

"You still need experienced developers to review and validate the code AI produces."

And here's where I see a paradox.

When developers use MySQL or complex frameworks and platforms such as Firebase, do they personally inspect and verify every line of their underlying source code?

Of course not.

It would be absurd even to consider doing so.

So why do we apply a completely different standard to AI-generated code?

Some might argue that AI is still relatively new, and that current models haven't yet reached the level of reasoning, expertise, and reliability of an experienced human developer.

Fair enough.

But then perhaps we're asking the wrong question.

The real question isn't whether AI can write better, more efficient, and more secure code than an expert developer today.

It's whether it will be able to do so tomorrow.

And more importantly: how far away is that tomorrow?

That brings me to another question.

Does it still make sense to invest enormous amounts of time maintaining deep technical expertise in a particular technology when there are dozens, if not hundreds, of alternatives on the market?

No human being can master all of them.

AI, however, can already work across a breadth of technologies that no individual developer could realistically keep up with.

So does it make sense to keep competing on a battlefield where we may have already lost the advantage?

Perhaps we need to start thinking differently.

If AI is already becoming exceptionally capable at writing code, perhaps — and I emphasise perhaps — its real limitations now lie elsewhere, particularly in software architecture, system design, and strategic decision-making.

And if that's the case, shouldn't we start repositioning our skills accordingly?

Maybe the next evolution of a senior software engineer isn't simply becoming a better programmer.

Maybe it's becoming an "AI Director": someone who defines the architecture, sets the direction, makes the critical decisions, and orchestrates AI to turn ideas into working systems.

Not competing with AI at writing code, but directing it.

I'd genuinely like to hear your thoughts.

Are we still preparing developers for the world we've known, or should we already be preparing them for the world that's coming?

Let me know what you think in the comments.