AI Mistakes at Work: Who Never Gets Fooled

Who catches AI mistakes at work? Not the smartest person in the room. It has never once been the smartest person in the room.

AI Mistakes at Work: Who Never Gets Fooled who-is-awake-at-2am

Here is the pattern I keep running into with AI mistakes at work, and it took me an embarrassingly long time to see it. The person who catches the bad output is almost never the most experienced person on the team. It is not the senior architect. It is not the one with the certifications and the strong opinions about naming conventions. It is whoever is going to get the phone call at 2am when the thing falls over. Same room, same screen, same words on it. Completely different reading.

A quick note. The people and situations below are composites, blended and reshaped so nobody is identifiable. If you think one of them is you, it is not, though I understand why you would think so.

Why the Sharp People Get Fooled Fastest

This sounds backwards, so let me lay it out.

Expertise is mostly a very fast pattern matcher. Twenty years in, you do not evaluate things from first principles anymore. You glance, and something in the back of your head says yes, this is the shape of a correct answer, and you move on. That reflex is the entire payoff of a long career. It is why you are worth what you are worth.

Now consider what the machine is actually best at. Not being right. Producing things that have the shape of being right. Correct structure, confident tone, plausible numbers, sensible headings, the right vocabulary in the right places.

So the machine’s specialty is a perfect key cut for the expert’s lock.

The beginner has to read the whole thing because they do not recognize any of it. The expert recognizes it immediately, which is exactly how they miss it.

The junior takes forty minutes and asks three dumb questions, one of which turns out to be the whole problem. The expert takes ninety seconds and says looks fine. Both of them are behaving completely rationally given what they know. Only one of them just shipped the bug.

Two People, One Screen, Ninety Seconds Apart

I have watched this happen so many times that I have stopped calling it a coincidence.

A migration script comes back from the machine on a Thursday afternoon. Beautifully formatted. Better commented than anything a human being has ever written at five o’clock. It goes to the architect first, a man with fourteen years on that system who is, and I want to be clear about this, genuinely excellent. He scrolls. He nods. He says it looks clean and he goes to lunch. Ninety seconds, start to finish.

Then it goes to the woman who has the pager that weekend.

She does not scroll. She stops somewhere around line forty and says, out loud, to nobody in particular, what does this do to the archive table. Twenty minutes later four of us are standing at a whiteboard and lunch is a distant memory.

He is the better engineer. I would hire him twice. He is simply not the one whose Saturday was sitting on the table.

Nobody packs a parachute more carefully than the person who is about to jump with it.

Distance Is the Actual Problem

AI Mistakes at Work: Who Never Gets Fooled someone-else-will-catch-it

Watch where a piece of work sits in a building. If you wrote it, it is yours, and you will defend it in a meeting like it is your own child. If a colleague wrote it, it is theirs, and some quiet part of your brain clocks off without asking your permission first.

Generated output sits in neither place. That is the whole trouble.

Nobody wrote it, so nobody is defending it. Nobody built it, so nobody has that protective twitch you get about your own work. It arrives from nowhere, wearing a nice suit, and every single person in the room assumes somebody else already looked at it properly.

Then it goes to production, and the ownership question gets answered very fast and very unpleasantly at 2am.

The output nobody wrote is the output nobody owns, and the output nobody owns is the output nobody reads.

Six weeks after one of these, I sat on a call with a team who had not slept much, and somebody said the sentence I have now heard a hundred times. It looked fine when we tested it.

It did look fine. That was the problem. Looking fine is the product.

Before You Turn This Into a Blame Machine

I want to be careful here, because there is a bad version of this idea and it spreads faster than the good one.

The bad version is: make people afraid, and they will check more carefully. That is wrong, and I have watched it fail in real buildings. Frightened people do not review better. They review defensively. They approve things quietly so as not to be the one holding it, they stop asking questions that might make them look slow, and the good ones update their resume.

Accountability and punishment are not the same thing, and organizations confuse them constantly.

Accountability is: you will be there to see how this turns out. Punishment is: you will pay for how this turns out. The first one sharpens attention. The second one destroys it, because the rational move under punishment is to touch nothing.

What you actually want is consequence without cruelty. You want people to live with their decisions, not to be prosecuted for them.

Four Things That Actually Change the Outcome

Ask who is awake at 2am. Before anything ships, out loud, in the room: if this is wrong, who gets the call? If the answer is nobody, or if it is somebody who is not in this meeting, you do not have a reviewer. You have a spectator with opinions.

Give the reviewer the pager. Whoever approves it carries it for the first two weeks. That is the entire intervention, and it costs nothing. Watch how the quality of the review changes when the reviewer knows their own weekend is on the table.

Make somebody re-derive the important number. Not review it. Re-derive it, separately, and then compare. Reviewing a number means checking that it looks like a number. Producing it yourself means actually understanding where it came from.

Let the sharpest person go last. Genuinely. Have the least experienced person read it first, out loud, and let them ask the dumb questions before the expert’s pattern matcher fires and closes the conversation. That reflex is worth a fortune and it is also a door slamming shut. Slam it later.

The Good News, Because There Is Some

AI Mistakes at Work: Who Never Gets Fooled i-checked-it-myself

The thing that protects you is not intelligence, and that is genuinely good news, because intelligence is mostly issued at the factory and you cannot order more.

Caring is available to anyone. Being the person who has to live with the answer is a position you can choose to stand in, on purpose, even when nobody assigned it to you. You can decide to be the one who opens the plan. You can decide to be the one who asks the dumb question at four o’clock on a Friday when everyone else has a coat on.

That is not a talent. That is a decision, and it is available on a Tuesday to a person with no certifications at all.

This is one of the threads running through my book AI: Nobody’s in There. But we’re still in here. It is thirty short essays on judgment, learning, and work. One of them is called Why the Smartest People Get Fooled Fastest, though at the time I wrote it I had not yet worked out that the defense is not being smarter. It is standing close enough to the outcome that you cannot look away from it. Every essay is free to read at pinaldave.com, and there is a paperback on Amazon.

The machine will keep producing things that look right, because looking right is the entire trick and it is very good at it. Somebody in your building has to be close enough to the consequences to feel the itch. Might as well be you.

The best reviewer in the building is not the smartest person there. It is the one who has to be there when it breaks.

Reference: Pinal Dave (https://blog.sqlauthority.com/), X

AI, Developer
Previous Post
AI Code Review Bottleneck: Nobody Owns It

Related Posts

Leave a Reply