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

I came across a post from an old colleague, questioning whether intelligence and knowledge still define who we are, now that AI can produce answers faster than we can formulate questions.

The idea itself isn’t new, but something about it stayed with me. Not because of the technology, but because of what it exposes when familiar markers of value stop being rare.

At that point, the discussion shifts. It stops being about machines and becomes a question of where human value actually sits.

This is not a story about AI replacing humans. Rather, it is about value moving away from knowledge and towards something less comfortable.

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.

Show me an architecture no one questions, 
and I’ll show you a system no one understands.

A few years back, I walked into a post-mortem where the architecture was being blamed for everything from latency spikes to the office coffee machine malfunctioning.
The architect? Well, he was calm. Unbothered. Certain.

“It’s not the design,” he said.
“The team just didn’t implement it properly.”

There it was: the dead giveaway. He wasn’t doubting the design. He was defending it like gospel.

Right then, I knew.
The most dangerous architect isn’t the one who lacks answers.
It’s the one who never asks questions.

If you’re an architect or becoming one, doubt isn’t your enemy. 
It’s your sharpest tool.

Consulting rule #1: Smile, nod, and translate chaos into meaning.  
Rule #2: Don’t let your sarcasm show.  
Rule #3: Break Rule #2 when appropriate.  

Trying to be client-friendly while carrying a sarcasm habit is like juggling flaming swords in a library: impressive if it works, disastrous if it doesn’t.

This is my daily dilemma: I’m in a customer-facing role, but my personality leans dry, cynical, and borderline allergic to buzzwords. I can steer through three political minefields per call and blueprint clarity from chaos, yet it still leaks out like House M.D.’s smirk when calling out bullshit.

A few years ago, I took a week off. First vacation in months. On day two, I got six Slack messages, three “urgent” calls, and by Wednesday, the team had spun up a new feature that killed the application’s performance like a toddler on an espresso overdose: fast, chaotic, and entirely unsupervised.

That’s when it hit me: I hadn’t built a system, I’d built a babysitting job.

errorless (adj)

Free from error, accurate, correct.
Being complete of its kind and without defect or blemish.

I stumbled lately onto a strange feeling: many of the architectures I review are overcomplicated, fragmented, full of flows jumping here and there.
And what makes it worse? The costs of development, the deployment, the running, the operations — just to keep the system alive — are astronomical.

I’ve been wondering how to celebrate this milestone. Because yeah… today marks exactly 20 years since I hit “publish” on my very first blog post — April 18th, 2005.

That post? Honestly… it was bad. A clumsy “hi”, a confused tone, and zero clue about where I was heading. It was a start.

But hey… here we are. Twenty years later.
Still blogging. Still writing — even if what that means has changed a lot over time. I guess it’s time for a little reflection.