Whatever Works Is Not Whatever Is Right

There's a video that did the rounds on my feed last month. A cat, confident, efficient, visibly pleased with itself, washing dinner plates in the toilet bowl. Every plate spotless. Every plate going straight back onto the dinner table.

The dishes came out clean. That is not the point.

I have been watching a version of that cat in almost every product review, sprint demo and board update of the last two years. The AI era has made it very, very easy to produce things that work. It has done nothing to make it easier to produce things that are right. And the gap between the two is where companies quietly die.

Whatever works is not the same as whatever is right. It is right's better-dressed impostor.

Let me show you the three places I keep finding the cat.

1. Vibe coding: "it ran" is not evidence

The build passes. The demo runs. The founder is thrilled. And when I ask the simplest question in engineering, why does this work?, the room goes quiet.

Nobody is lying. They don't know. The model wrote it, the tests (which the model also wrote) went green, and the deadline was Thursday. This is what people now call vibe coding, and I want to be careful here, because I'm not against it. I run AI-native companies. Our engineers use these tools all day. The speed is real.

But code you cannot explain is a plate washed in the toilet. Clean today. Unexplainable the morning it breaks, and it will break at 2 a.m. on the day of the biggest demo, because that is the only schedule shortcuts keep.

"It ran" is not evidence. It is luck with good posture.

What I ask teams to do instead is boring and it works: every written by AI change gets a human owner who can narrate it, line by line, to a colleague who wasn't there. Not "review", narrate. If no one can tell the story of the code, the code isn't done. It's just quiet.

2. Product building: the metric moved, the meeting ended early

Numbers went up. Everyone relaxed. Nobody asked which number moved it.

A discount moved it. A pop-up moved it. A one-time push notification moved it. The dashboard updated the same day. Churn takes a quarter to arrive, and it never sends a calendar invite.

I've sat in enough growth reviews, my own included, to know how seductive this is. You built something, the line went up, and the human brain files that as proof. But growth that works before it is right is only damage on a delay. You've borrowed next quarter's retention to pay for this quarter's slide.

A metric without a mechanism is a rumour. Before you celebrate a number, you should be able to say, in one sentence, what caused it and whether that cause is repeatable without a coupon. If the sentence has the word "probably" in it, you don't have a result. You have a lead.

3. Team building: the single point of failure wearing a team T-shirt

It shipped on time. Everyone clapped. Somebody ordered biryani.

Then, three weeks later, you find out one engineer quietly carried four people's work across three weekends. Nobody escalated. Why would they? It worked.

This one hurts the most, because it looks like culture. It looks like commitment. It is actually a system that has learned to hide its own fragility behind its best person's exhaustion. A team that only survives on one person's weekends is not a team. It's a single point of failure in a team T-shirt.

The fix is not a wellness webinar. It's asking, after every launch, "who did more than their share, and what would have happened if they'd been sick?", and then treating the answer as a bug in the org, not a badge on the person.

Five things I keep advising

I say these so often that my co-founders finish the sentences for me:

1. Ask how it worked, not whether it worked. "Whether" is a yes/no. "How" is a mechanism. Only one of them compounds.
2. If nobody can explain it, nobody owns it. Ownership without understanding is a liability with a name on it.
3. A metric without a mechanism is a rumour. Treat it like one, interesting, unverified, not to be repeated in a board deck.
4. Success hides far more than failure ever will. Failure at least tells you where to look. Success tells you to stop looking.
5. Shortcuts never vanish. They only pick their own due date. And they always pick a bad one.

The point

None of this is an argument against speed. I'm an engineer at heart and a founder by profession; I love speed. It's an argument for a habit: whenever something works, spend ten minutes finding out why before you spend ten weeks depending on it.

The cat is not a villain. The cat is efficient. Just don't eat off its plates.

This piece began as a LinkedIn post that found more readers than anything I'd written before, which tells me a lot of you have met the cat too.