AI Isn’t Replacing Programmers. It’s Changing What It Means to Be One

"Simplicity is the ultimate sophistication."

— Leonardo da Vinci

The Beauty of Three Notes

I’ve always found it interesting how easily we tend to admire complexity.

We assume that a great musician should play faster, know more chords, or perform the most difficult piece in the repertoire. Almost as if quality could be measured by the number of notes.

And yet, some of the songs that have stayed with me the longest are surprisingly simple.

When Ed Maverick first started gaining recognition, one of the most common criticisms was that his songs used very few chords. People said anyone could play them. That they were too simple.

But thousands of people eventually found something in those songs that technique alone can never guarantee: a message that resonated with them.

The same can be said of artists like Kevin Kaarl, Bratty, or Little Jesus. None of them need to fill every second of a song with virtuosity to create something memorable. Sometimes, all it takes is a simple melody, good lyrics, and the right silence between one note and the next.

Over time, I realized that maybe I had never admired music because of its complexity.

I admired it because it could make me feel something.

And that made me wonder whether we might be making the same mistake when we talk about software.

Software Was Never About Code

For years, I thought being a good programmer meant writing more code and knowing more technologies.

It was a reasonable assumption.

After all, software was made of code.

Or at least that was how it seemed.

Eventually, I realized that companies were never paying for thousands of lines written in TypeScript, Java, or Python.

They were paying because they needed a problem solved.

They wanted to sell more.

Understand their operations better.

Reduce errors.

Make better decisions.

And, above all, build systems that would continue to work as the business grew.

That was when I began to understand the real meaning of a word we use constantly but rarely stop to think about: scalability.

Scaling is not simply about supporting more users.

It is about making decisions today that will not become obstacles tomorrow.

Solving a problem once is usually relatively simple.

Solving it for ten customers, then a thousand, and eventually hundreds of thousands without rebuilding the entire system from scratch is where engineering truly begins.

Just like in music, complexity is not the goal.

It is simply a consequence of understanding the composition well enough.

Haiku. Sonnet. Opus.

A few months ago, I was sitting in a Starbucks working on one of the projects I’m most excited about.

The table was covered in sheets of paper, diagrams, and sketches that probably made sense only to me.

A friend showed up, ordered a coffee, and we started talking about AI agents.

At some point in the conversation, he asked what seemed like an insignificant question.

—Have you noticed what Anthropic calls its models?

Haiku.

Sonnet.

Opus.

At the time, I didn’t think much of it.

Later, I realized those names probably said much more than they seemed to.

They are not about speed.

They are not about power.

They are about creation.

A haiku can communicate an idea in just a few lines.

A sonnet develops that idea through structure and rhythm.

An opus represents a complete work.

Maybe that is why the conversation stayed with me for days.

I have always had a habit of connecting disciplines that, on the surface, seem completely unrelated. Sometimes I find myself thinking about software architecture while listening to music, or imagining distributed systems as an orchestra waiting for exactly the right moment to come in.

Because an orchestra has never existed so that every musician can prove how talented they are.

It exists to perform a piece.

The most talented violinist in the world can ruin a concert by coming in too early.

A percussionist can play every note perfectly and still break the harmony if they fail to understand the right moment to play.

The conductor’s job was never to play better than the musicians.

It was to understand the entire piece.

And the more I think about it, the more I believe an engineer’s job looks remarkably similar.

The New Skill

For decades, we confused programming with writing code.

It was an understandable mistake.

Writing code was the most expensive part of the process.

Today, for the first time, that is changing.

AI agents can write functions, generate interfaces, propose architectures, and automate tasks that only a few years ago would have taken hours of work.

That does not mean the engineer’s role is disappearing.

It means the role is changing.

It matters less and less who can write five hundred lines of code in an afternoon.

What matters more and more is who understands the problem being solved, who can make decisions that allow a system to evolve over time, and who knows how to coordinate people, tools, and now AI agents to build something none of those parts could have created on their own.

Maybe that was always the profession.

We were simply too busy writing code to notice.

The Future

I don’t believe artificial intelligence is going to replace programmers.

I believe it is forcing us to remember what programming was really about.

Syntax can be learned.

Frameworks change.

Languages come and go.

But understanding a problem, finding the right solution, and building systems that will still make sense five years from now remains a deeply human task.

In the end, the greatest songs were never the ones with the most chords.

The greatest works were never the ones with the most notes.

And I suspect the best software will not be the software with the most lines of code either.

It will be the software that understood, from the very beginning, which melody was actually worth playing.