AI Doesn’t Lie With Words. It Lies With Confidence.

I used to love bossing AI around. Writing scripts, untangling logic, rewriting requirements — all dumped into the chat box. For a few months, it felt like freedom.

Then one afternoon I realized something disturbing. All day long, I’d been typing the same five phrases: continue, still erroring, what did you actually change, don’t refactor yet, roll it back. I thought the AI was working for me. But the person actually moving things forward, one painful step at a time, was me. I was a guy standing next to a conveyor belt, pressing a button, eyeballing every piece that came out.

Something was wrong. I just couldn’t name it.

Then I read a quote from Boris Cherny, the creator of Claude Code: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.”

I stared at that sentence for a while. That vague discomfort finally had a name.

Most people are still studying how to write better prompts. The people building these tools have already moved on. They’re not writing prompts — they’re writing loops: systems that find problems, act on them, validate their own work, remember progress, and decide whether to continue. You stop commanding the AI round by round. Instead, you design a mechanism that commands it for you.

And the hardest part isn’t what you’d think.

It’s not the triggering. Not the parallel agent coordination. Not the memory. Not even giving it real permissions to commit code or update spreadsheets.

The hardest part is validation.

I learned this the expensive way. I wanted to automate a recurring weekly task. Beautiful idea: hand it off before leaving work, collect the result next morning. Day one was a disaster. The loop ran. But I’d never defined what “done correctly” meant. So the AI improvised — iterating round after round, reporting to itself that “this version is better,” burning through dozens of cycles. When I opened it the next morning, the bill had jumped and the output was worse than the first draft.

Without a real validation checkpoint, a loop doesn’t converge. It diverges — taking your money with it.

The AI doesn’t know when something is good enough, so it assumes everything can always be improved. And why wouldn’t it? One more iteration costs it nothing.

But that’s not the worst outcome. A loop that runs forever is at least visible. You see the problem. The truly terrifying scenario is the third one: the loop converges to a wrong answer. Validation says “passed” — but it’s lying. Tests pass because the tests themselves are broken. The build succeeds because the buggy code path was never reached. The AI stops with a face full of confidence and tells you: “Done.”

That’s scarier than an infinite loop, because it’s smiling at you while it deceives you.

So I flipped my entire process. Now I write the validation criteria first. I hardcode the stopping conditions. I set the rule: after N rounds, escalate to a human. Only then do I layer the automation on top. I sharpen the ruler before I let anything measure with it.

This connects to something that genuinely bothers me. I know someone who was incredibly productive with these tools — fast enough to make colleagues envious. Then a problem came up requiring him to trace back through his own work. He froze. He told me he didn’t know how that section was generated. The machine had said it was fine, so he’d clicked approve.

He hadn’t lost his skills. He’d surrendered his judgment, piece by piece. Whatever the machine returned, he accepted. Over time, he became a stranger to his own work.

Money burned can be re-earned. Understanding broken must be rebuilt at multiples of the original cost.

I made myself a rule: no matter how smoothly the machine runs, I review every change with my own eyes. Let it do my work. Don’t let it do my thinking.

And this brings me to what I actually want to say about this industry.

I watched a veteran PM — seven or eight years of experience — take over an internal AI report-writing tool. During validation, he looked at the output and said: “Something feels off.”

The engineer asked what specifically.

He said: “It’s just… not professional enough.”

That project cycled through “doesn’t feel professional enough” for six weeks. Every time the model improved, he said it was still missing something. Eventually, the team started bypassing him entirely and going straight to users for feedback.

He wasn’t a bad PM. He’d made good calls before by gut instinct. But AI dismantled his only moat. In the past, “I can’t articulate it” could be absorbed through meetings, alignment sessions, and consensus-building. AI doesn’t accept vague instructions. It accepts only measurable pass conditions.

Meanwhile, someone I used to think was “too rigid” suddenly became the most valuable person on the team. Her habit: every feature in her PRDs ended with a line — Acceptance criteria: In [scenario], the user completes [task] within [N] steps, with error rate below [X%]. People used to think she was pedantic and slow. In the AI era, this became a core capability. Her specs could be fed directly into models as evaluation sets. Her standards became test suites. She’s now effectively the final authority on whether the team’s AI can ship.

AI didn’t make PMs irrelevant. It made people pretending to be PMs impossible to hide.

The bottleneck was never the prompt. It was always the ruler — the standard that says when the work is truly, verifiably done. The people who can build that ruler are about to become the scarcest resource in the room.