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.

In a few years, everything will be vibe-coded. That’s the prophecy.

Yeah, sure.

For now, we just need to ride it out. It’s the age of slapping AI labels on everything, inflated job titles packed with AI-flavoured bullshit, and vibe-coding sold as the next revolution.

Managers are getting starry-eyed at the thought they no longer need those weirdos with beards and shorts, sipping coffee, avoiding eye contact, and smelling a bit odd.

Only those of us old enough to have lived through the pre-DevOps world can truly appreciate just how revolutionary the idea really was. I remember those long, dreaded release planning meetings before a Big Bang production deployment. People from alien departments—who hadn’t spoken to each other all year—would suddenly be packed into a room to plan what sounded like a bank heist:

“You come in at midnight and shut down system X. At 1:15am John will install system Y. At 2am Jane will update the config and deploy the hotfix. At 3am Tom will bring system X back online…”

People often ask how to apply the engineering principles I talk about.

My answer — “it depends” — isn’t a cop-out. It’s a recognition that teams and contexts vary. But across high-performing teams I’ve led, some patterns consistently work (yes, in the real world; yes, in large orgs; yes, in regulated industries).

Here’s what that looks like:

Be a real team.

Not just engineers. A cross-functional group: engineering, UX, product, QA, domain experts — collaborating daily. We need some process, but the real value comes from interactions. Colocation is optional. Real-time collaboration is not. The best teams I’ve worked with mobbed for 4–6 hours a day. If not that, then rotating pairs. If not rotating pairs, then just pairs. Solo work? Only for trivial, isolated tasks.

The Forest and Desert metaphor is a compelling way to highlight the communication gap between software teams in different working conditions, but it risks slipping into absolutism and evangelism.

I don’t like it.

It sets up a dichotomy where the Forest is seen as the enlightened, flourishing state of software development (agile, tested, customer-focused) while the Desert is a place of dysfunction, scarcity, and struggle. This framing is seductive, but ultimately incomplete and potentially harmful.

I made a huge mistake early in my career. I thought I was going to get fired. My manager just said, ‘Just learn from it.’

I saw this quote from a junior engineer reflecting on their early experience, and while it sounds enlightened and kind on the surface, it’s actually not the right stance.

A better response would have been: “Let’s all learn from this. How do we fix the environment so that an engineer—especially someone new—was in a position to make that mistake in the first place?”