The One Prompt That Changed How I Use AI

xundao — Fri, 24 Jul 2026 01:02:07 +0000

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.

I Quit Corporate to Build AI Alone - Here's Week 1

xundao — Thu, 23 Jul 2026 12:51:30 +0000

The last day of my corporate job was a Thursday. I remember walking out of the office building, laptop bag slung over one shoulder, and thinking: that's it. No more standups. No more Jira tickets someone else wrote. No more pretending I cared about quarterly OKRs for a product I didn't believe in.

The first Monday morning alone was disorienting in a way I didn't expect. For six years, my calendar had been filled by other people. Now it was a blank white rectangle stretching into infinity. I sat at my desk at 8:30 AM and realized nobody was waiting for my status update. Nobody cared what I did that day. The silence was louder than any open-plan office.

I panicked, obviously. That first day I wrote exactly zero lines of code. I reorganized my Notion. I watched three YouTube videos about solo founder productivity. I had a minor existential crisis around 2 PM and went for a walk that lasted two hours. By evening, my only tangible output was a grocery list.

Tuesday was slightly better. I opened VS Code. I stared at the blank terminal. I typed mkdir xundao-ai and then sat there for another thirty minutes trying to decide what framework to use. (I went with Next.js. I always go with Next.js. The decision took far longer than it should have.)

Here's what nobody tells you about quitting your job to build alone: the hardest part isn't the code. It's learning to trust your own decisions again. In corporate, every choice has a committee attached to it. You can blame the architecture on the tech lead, the timeline on the PM, the bugs on the offshore team. When you're alone, every bad decision has exactly one person's name on it.

By Wednesday I had a working prototype - barely. It was a simple AI automation tool that took a user's natural language description and turned it into a workflow. The UI was ugly. The error handling was nonexistent. But when I typed "send me a Slack summary of yesterday's GitHub commits every morning at 9 AM" and watched it actually work, I felt something I hadn't felt in years. It wasn't pride exactly. It was more like relief. I could still do this.

The rest of the week was a blur of coding, breaking things, fixing them, and slowly remembering what it felt like to build something because I wanted to, not because a sprint board told me to. I deployed to Vercel on Friday afternoon. Zero users. Zero customers. Just a domain name and a bunch of code that existed because I decided it should.

Week 1 taught me something surprising: the blank calendar isn't the enemy. It's the point. The emptiness is where the work actually happens - not the cushy kind of work with peer reviews and deployment pipelines, but the raw, uncertain kind where you're standing at the edge of what you know and what you don't know, and nobody is going to tell you which way to jump.

I share more of the unfiltered reality at xundao.xin.

DEV Community: xundao

The One Prompt That Changed How I Use AI

I Quit Corporate to Build AI Alone - Here's Week 1