Tags: ai, productivity, beginners, programming
Six months ago I was using AI wrong. Not "wrong" in the sense that I was getting bad outputs — I was getting perfectly reasonable outputs. That was the problem. Reasonable is the enemy of useful.
Here's the context. I was building an automation pipeline that needed to parse user-submitted descriptions of business workflows and map them to actual API calls. My prompts looked like what you'd expect: "You are an expert developer. Given the following user input, generate a JSON schema..." followed by a wall of instructions longer than most README files. The outputs were fine. They were also boring, generic, and wrong about 30% of the time in subtle ways that took me hours to debug.
Then I stumbled across a technique that changed everything. I don't remember where I found it — probably some obscure Reddit thread at 2 AM — but the core idea was so counterintuitive that I almost dismissed it entirely.
The technique is this: instead of telling the model what to do, tell it what it did wrong.
Here's the actual prompt structure that transformed my workflow:
First pass: "Here is a user request. Generate a solution." Standard stuff.
Second pass: "Here is the solution you just generated. Now list everything wrong with it. Be brutal. Find edge cases I haven't considered. Identify assumptions that might break. Flag anything that a senior engineer would reject in code review."
Third pass: "Here is the original problem, your first solution, and your critique. Now generate a final answer that addresses every issue you identified."
That's it. Three messages instead of one. It sounds trivial. It also cut my error rate from roughly 30% down to under 5% in the first week of using it.
Why does this work? I have some theories. LLMs are fundamentally pattern-completion machines — when you ask for a solution, they complete the pattern of "person asks question, expert answers question." The expert persona tends toward confidence and conciseness, which means the model glosses over uncertainty. By explicitly requesting a self-critique, you're forcing the model into a different pattern: the rigorous reviewer who gets paid to find problems. Suddenly it notices the missing null check, the edge case where the timezone is UTC+14, the assumption that the user's input will always be in English.
The weirdest part? The model often catches things I wouldn't have caught myself. Last week it pointed out that my workflow parser would break if a user included emoji in their step descriptions. I had been testing with clean ASCII inputs for two weeks and never once considered that someone might write "Step 1: Check email 📧." The model caught it because in critique mode, it was actively hunting for failure modes rather than trying to sound competent.
This technique has become my default for anything non-trivial. I do it with code generation, with content writing, with system design. The pattern is always the same: generate, critique, regenerate. Three passes. The extra latency is maybe thirty seconds. The reduction in downstream debugging time is measured in hours.
I suspect this works because it mirrors something that good engineers already do instinctively: rubber-duck debugging, code review before pushing, the second draft that's always better than the first. The model is just a very fast rubber duck.
The one thing I'll add: this works best with models that have strong reasoning capabilities. I use it primarily with Claude and GPT-4-class models. On smaller models the critique phase sometimes hallucinates problems that don't exist, which defeats the purpose. But if you're working with frontier models and haven't tried self-critique prompting yet, you're leaving a surprising amount of quality on the table.
I write about practical AI workflows — not the hype, just the stuff that actually ships — at xundao.xin.
SOCIAL SHARE CARD GENERATOR