The idea that machines can be programmed without detailed coding is not new. “Application Development Without Programmers” by James Martin came out in 1981 (44 years ago!), exploring 4GL programming languages.

Today, people are either excited or weary about using natural language as a programming language for AI agents. But specification languages have existed for a long time. All the current debate about how to construct prompts reminds me of controlled natural languages (CNLs), researched for decades.

We’re not facing disruption, we’re witnessing evolution.

The history of human-computer interaction tells a fascinating story. We began with human “computers” doing calculations by hand, then moved to room-sized machines with tape reels and punch cards. We graduated to CPUs and machine language, then created high-level programming languages that could translate our symbolic logic into instructions machines could understand.

Today, we’re realising a decades-old dream: communicating with machines in natural language. Though let’s be honest, COBOL and SQL were pretty successful attempts at this too!

I keep hearing people (often experts) say things like, “the system clearly wasn’t tested thoroughly” whenever they discuss some (in)famous incident.

Testing a system thoroughly sounds fine in theory, but what does it actually mean? Especially after development, knowing when testing is “enough” is a tricky question, and incidents will still happen.

As W. Edwards Deming famously said, “Quality inspection is too late.” By the time we inspect, the system is already built, and the cost of fixing issues is far higher.

Start with systems, not people Reward early visibility

I loved the talk “Postmortems Without Blame: Running Real, Transformative Incident Reviews” by Agata Skorupka at DevOpsDays London.

It linked beautifully with so much of the literature that shapes how we think about work.

Amy Edmondson’s research on psychological safety (“Right Kind of Wrong”) reminds us that people won’t surface problems early if the culture punishes vulnerability.

L. David Marquet’s “Turn the Ship Around!” shows how intent-based leadership creates conditions where responsibility is distributed, not concentrated, which makes early signals stronger.

Developers often complain about the risks of merge conflicts with long-lived branches, but the “solutions” they propose usually miss the real point. The most common one is to keep merging main (or, even worse, develop) into the branch.

That’s often accompanied by the vaguest advice of all: “Keep communicating with others to know what they’re working on.”

The first is a non-solution. Merging the main trunk of development into branches regularly doesn’t help when changes stay isolated on those branches for long periods. Other developers’ work won’t land in main quickly enough to reveal integration issues in time.

Conversation around AI has flipped. We’ve gone from AI hype to anti-AI hype in record time. The narrative now is less about what AI can do, and more about mocking those who dare to experiment with it. It’s an odd place to be.

I too have been critical of the blind rush to jump on the AI bandwagon. Adopting any new technology without experimenting deeply, without examining the evidence, is careless. But here’s the problem: most of what we hear against AI today isn’t careful analysis either. It’s the equivalent of hairdresser’s chatter.