# The One Prompt That Changed How I Use AI > Source: > Published: 2026-07-24 01:02:07+00:00 *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.