$ cat posts/software-engineering-as-a-technology.md
Software engineering as a technology
“Software engineering: not just process but technology.” That’s how Bertrand Meyer predicted in 2010 what programming would look like a decade later.
Fifteen years on, that prediction resonates with an irony Meyer probably didn’t anticipate. You know how it goes: better not to make predictions, or, if we want to be safe, follow Alan Kay’s advice: rather than predict it, invent it.
The original vision
In that presentation, Meyer talked about transforming software engineering from a set of practices and methodologies into a technology in its own right. His vision included integrated verification, ubiquitous web interfaces, pervasive concurrency.
The central idea was that the discipline would mature into something predictable, reliable, industrialized. Like civil engineering or manufacturing: repeatable processes, guaranteed results, measurable quality.
Meyer wasn’t talking about artisans or art. He was talking about technology.
The irony of the present
Today, in 2025, software engineering has indeed become a technology. Just not the way Meyer imagined.
Claude Code, Cursor and other tools have turned the act of programming into something closer to operating a machine than practicing a craft. As I wrote in my last post, the Jacquard looms of the 21st century have arrived.
The verification Meyer championed, an obsessive pursuit of formal correctness, has been replaced by the “seems to work” of vibe coding. Concurrency is almost everywhere, but hidden inside frameworks few people really understand. Web interfaces are commonplace, but generated by LLMs that produce code nobody will review line by line.
More sizzle than steak
Meyer himself has had to confront this reality. In a recent paper on using LLMs to fix bugs, his team discovered something revealing: there is “more sizzle than steak” in the promises of AI.

Their findings are brutal in their honesty:
- LLMs generate solutions that look correct but fail under rigorous verification
- “A successful test doesn’t mean anything” when we’re talking about real correctness
- They identified seven different “personalities” of LLM use, from the credulous to the skeptical
Meyer still believes in formal verification. He uses AutoProof and Eiffel contracts to validate the fixes proposed by GPT-4. He’s like a Swiss watchmaker insisting on handcrafted precision while the world buys Apple Watches.
Maybe the problem is that LLMs don’t have enough Eiffel code in their training data. How much is Eiffel even used in industry? But our hero isn’t deterred by that small inconvenience.
At least the author admits that, statistically speaking, this study may not be relevant.
The technology we got
Software engineering did become a technology, but not in the sense Meyer imagined. It isn’t a technology of rigorous processes and formal verification. It’s a technology of mass generation and approximate validation.
And here lies the big difference between an academic’s vision and the reality of the market. Meyer dreamed of cathedrals; we got factories. He imagined artisans elevated to engineers; we got operators running machines they don’t understand.
And here’s the interesting part: both visions are technology. It’s just that one is the technology of precision and the other is the technology of productivity.
The real technological shift
When Meyer talked about software engineering as a technology, he was thinking of tools that would amplify the human capacity for formal reasoning. Tools that would make verification “something routine”, natural and built in.
What we got were tools that replace reasoning with statistical approximation. That turn programming into a dialogue with a black box. That transform debugging into an AI-assisted process of trial and error.
It’s not that Meyer was wrong. It’s that the market chose to automate what it already knew.
The paradox of the fulfilled prediction
Meyer was right about one thing: software engineering became a technology, or at least partially. But, applying the old trick of prophecies that come true, what we have to do is transform its original meaning.
Verification is integrated, but it’s verification by empirical testing, not formal. Concurrency is everywhere, but handled by abstractions that hide its complexity. Web interfaces are ubiquitous, generated automatically by LLMs.
It’s as if we had taken every item on his list and implemented it with an asterisk:
- Integrated verification*
- Pervasive concurrency*
- Universal web interfaces*
- Engineering as a technology*
*But not the way we expected
The future of the technology
Perhaps the most important lesson is that technology doesn’t evolve according to the wishes of technologists. It evolves according to market pressures, human limitations, and the path of least resistance.
Meyer wanted to elevate programming. The market wanted to popularize it (out of pure greed: more hands were needed, and the few available were expensive). Meyer sought correctness. The market sought speed. Meyer imagined engineers. The market needed operators.
And so software engineering became a technology. Not the technology of formal verification and mathematical correctness, but the technology of mass generation and good-enough validation.
Like the weavers of the 19th century facing the Jacquard looms, we find ourselves at a moment of transition. We can insist that real software is formally verified, that real engineers understand every line. Or we can accept that technology has taken a different road.
A road where “more sizzle than steak” isn’t a bug. It’s a feature.
What do you make of this transformation? Do you think Meyer was right deep down, even if the implementation turned out different? Or are we witnessing something completely unlike what anyone could have imagined? Subscribe to my newsletter (in Spanish) to continue this conversation.
Comments
comments powered by Disqus