TL;DR

  • Writing software is more than producing syntax.
  • But code was never “irrelevant” either.
  • The industry is currently redefining engineering value in real time.
  • That shift is social and economic before being technical.

Once Upon a Time, There Was a New Buzzword

I’ve always been fascinated by trends.

You suddenly develop a deep and very personal desire. A jacket. A bicycle. A pair of shoes. It feels original, almost intimate. Yours and yours alone. Then, a few days later, you see someone in the street wearing the exact same thing. A few weeks later, half the people around you seem to have independently become the same kind of “free spirit” you thought you were.

The workplace is no stranger to these waves of collective revelation. If anything, it is where they work best. Add hierarchy to the usual social and cultural pressures, and trends stop being trends altogether. They become doctrine.

That is how millions of managers end up quoting the exact same book to describe their management philosophy. And, unsurprisingly, in an era fascinated once again with “masculine energy” and command-post leadership, the book is often written by an ex-military officer.

But that is not the subject here.

Recently, I kept hearing a sentence that genuinely puzzled me:

“The value of programmers has never been in the code.”

I cannot remember who said it first around me. What I can remember is how quickly it became a collectively validated truth. A manager said it. Then a colleague. Then a CxO. A few days later, every tech blog seemed to have reached the same revelation simultaneously.

The idea, in essence, is this: programmers are not valuable because they know programming languages, or because they can produce code a machine understands. Their real value supposedly lies elsewhere. In “problem solving”.

And that is where things become interesting.

Corporate Limbo Masterclass

The sentence is a masterclass in corporate rhetoric.

First, it leans on another deeply established cliché of the software industry: the idea that developers are fundamentally “problem solvers”. Every day, we are supposedly facing a new and complex puzzle standing between the company and success. We are not coders. We are strategists. Engineers. Architects of solutions.

This belief has become so widespread that it now serves as justification for another one.

If coding becomes partially automated, then coding was never the valuable part to begin with.

Convenient.

The problem is not that software development involves solving problems. Of course it does. The problem is that the phrase has become so broad that it has lost almost all meaning.

Most developers are not designing Mars rovers or distributed systems at NASA scale. A massive portion of the industry builds CRUD applications, internal dashboards, marketplace platforms, booking flows, showcase websites, marketing tools and e-commerce systems.

That work matters. Some of it matters a lot. But calling every Rails admin panel or React landing page a feat of elite “problem solving” starts sounding less like description and more like mythology.

At some point, “solving problems” becomes so vague that cooking eggs qualifies as solving my breakfast problem.

And yet the slogan survives because it performs two functions simultaneously.

First, it reassures developers frightened by AI.

Second, and more importantly, it quietly redefines where professional value is supposed to reside precisely at the moment code generation itself becomes easier and cheaper.

That shift is not purely technical. It is social and economic.

Because historically, coding skill absolutely did have market value.

The industry spent decades gatekeeping it, mythologizing it, overpaying it and building prestige around it. Entire cultures emerged around mastery of languages, frameworks, algorithms and systems.

And now, suddenly:

“Actually, the code never mattered.”

Really?

If developers’ economic value had truly never been tied to coding itself, I doubt the industry would have spent so much time treating programmers simultaneously as expensive divas and indispensable specialists.

Programming Languages Are Not Human Languages

Part of the confusion comes from people underestimating what programming languages actually are.

A computer language is not a human one.

Human conversation is tolerant. Approximate. Redundant. You can speak broken French with a terrible accent and still receive encouragement because your interlocutor understands intention, context and ambiguity. Humans compensate for mistakes naturally.

Computers do not.

Programming languages require a radically different form of precision. They force you into explicitness. Into formal structures. Into a mode of thinking where ambiguity is not charming but catastrophic.

Some languages have tried to become more readable and expressive. Ruby is probably one of the best-known examples.

Ruby developers often describe the language as “elegant” because it allows code that almost resembles natural language:

Account.where(first_name: "Bill").active.registered_last_month

And yes, this looks readable.

But only within a very specific context.

A Ruby developer understands that this code is probably part of an ActiveRecord query chain. They understand what a scope is. They infer conventions. They mentally reconstruct missing layers of abstraction.

In reality, this line only appears “natural” because years of accumulated conventions have compressed its complexity.

More importantly: reading such code is not the same thing as being able to write it.

active and registered_last_month are not magical words built into Ruby itself. Someone had to design those abstractions. Someone had to model the domain. Someone had to decide what “active” means, what “registered” means, how time is handled, what happens with edge cases, database performance, composability and future maintenance.

The visible line of code is merely the surface residue of a much larger cognitive process.

And this is the part that current AI discourse often flattens.

No serious engineer believes software development is merely about typing syntax. A CRUD application generated in ten minutes was never the essence of the craft.

But reducing programming to generic “problem solving” is equally dishonest, because it erases the technical and cognitive specificity of software construction itself.

Writing software involves abstraction design, systems thinking, temporal reasoning, constraint management, debugging mental models and anticipating future change. The code is not separate from those operations. It is their crystallization.

Wrap Up

Writing software is not equivalent to typing syntax.

But neither is code some disposable byproduct that never truly mattered.

The current discourse around AI is attempting to redefine where engineering value supposedly resides. And maybe some of that reframing is necessary. Maybe some of it is even correct.

But we should at least acknowledge what is happening.

Because saying “The value of programmers has never been in the code” is not a neutral observation.

It is a cultural adaptation mechanism from an industry trying to renegotiate its own mythology in real time.