A friend messaged me lately: Where do you see IT going? Any new patterns in the post-AI era?

My answer started with two recent jobs, both from my own desk. The first was one afternoon, when I asked an agent to build me a small UI that exports data from my workout tracker and from my Fitbit Air through the Google Health API, and merges it into a training agent I’d built. It works, and it will never need to survive me.

For the second, around the same time, I spent a week updating one outdated JavaScript library in an emergency medical dispatch system (the kind that follows an ambulance from the first call to the hospital doors, with the patient’s status reported along the way). It was already running. An agent helped me debug it and swap the library, and the rest of the week went on reading, tracing, testing, and asking what would break and who would notice first.

Same tools on both, but completely different jobs.

I owned one car on this list. A Renault Twingo, 2006, first generation, Gris Boréal. Initiale Paris, all the premium. I treated it well and it served me well during my single days when I moved to France. Then I got married, we had a first child, then a second. My wife kept driving it for a long period, because it was hers by then. Eventually two children in a Twingo becomes something you manage rather than something that works. We chose something bigger. The Twingo didn’t fail us. We outgrew it.

The rest of this list I’ve only ever wanted. Carried in my head since I was a kid. What they share: a shape you can sketch from memory, and a reason to exist beyond getting from one place to another. They’re mostly from before 2000. That’s not nostalgia. Post-2000, aerodynamic optimisation and safety regulation converged the industry onto a single optimal form. The physics made them better cars but made them harder to tell apart.

The engagement started with a decommission notice on a system nobody had fully mapped.

The system processed a significant chunk of daily financial data. A risk management platform, wired deep into a legacy mainframe that was still very much alive, and very much a black box. Outside that mainframe sat a single overbloated component doing the work of several, holding the integration layer together through years of accumulated dependencies nobody had ever fully mapped.

There are meetings where everyone in the room knows the truth and nobody says it.

I’d been through the existing codebase. The designs were rough; the code behind them was worse, not catastrophically wrong, just badly built, in the way that happens when a team has been too busy to be honest with itself, and too stubborn to revisit the amateur choices it had made along the way.
I’d written it up. They’d seen my assessment and recommendations, but a new deck was better.

The meeting opened with a presentation: architecture diagrams, process flows, the kind of thing that takes real effort.

I didn’t say much.

The manager called me in.
I already knew.
I’d known for weeks, in the way you know something before you’re willing to say it out loud.
The conversation was ten minutes.
The decision had already been made, by both of us, long before that.

AI doesn’t threaten intelligence.
It exposes how little judgement most systems have.

A few months back, I sat in a review where a junior engineer presented an architecture proposal. Clean diagrams, well-structured document, confident annotations. The first questions were answered fluently. Then we pushed into the edge cases: what happens when this service changes, how does it behave under unexpected load, why this particular approach over the alternatives?

“I’d need to check.”

Three times in the same conversation. The work looked senior-grade. The reasoning wasn’t there. When I asked what had informed specific choices, the honest answer eventually came: “Claude suggested it and it seemed right.”

I didn’t blame them. But I kept thinking about what had actually happened in that room.

Quality is subjective.  
Architecture is judgemental. 
So how on earth do we measure it?

Every architecture review, every design workshop, every committee meeting eventually hits the same wall. Someone asks: “But is this actually good?”

We pretend the answer lives in metrics. Response times. Availability. Coupling scores. Maturity models. Dashboards filled with comforting colours. We convince ourselves that if the numbers are green, the architecture is good.

That is the uncomfortable reality: half the time, those numbers are illusions. They tell part of the story.

I’ve witnessed perfectly green dashboards collapse the moment real business pressure appeared.

“The difference between good and bad architecture is the time you spend on it.”
– David Chipperfield

There is a specific kind of architect that worries me.
Not the junior one learning the ropes. Not the experienced one who double checks the consequences.
I mean the architect who is absolutely convinced they are right, and talks incessantly to prove it.

I was in the war room at 2 AM, staring to the aftermath of what was supposed to be our next evolutionary leap.

We pushed the final piece of our cloud migration at midnight.
By 12:07 AM, 60% of our customers couldn’t log in.
By 12:15 AM, the rollback plan failed because the servers it was meant to restore to didn’t even exist anymore.

Despite the thorough migration plan, the old system was gone … extinct in a single night, and our “evolved” architecture had nowhere to run.
We didn’t anticipate the blind spots, and the post-mortem read like a crime scene report where we were both the victim and the suspect.

That’s when I realised Darwin’s theory applied to software too: Software behaves like living organisms.

“True friends are never apart, maybe in distance but never in heart.”
— Helen Keller

Friendships don’t always end with fights. Sometimes they just fade, without drama, without closure. One day they’re there. The next, they are just names in your phone.