Writing Better AI Prompts: What I've Learned After Two Years
The difference between vague and specific prompts isn't a 10x output quality gap — it's bigger than that. Here's what actually works across coding, writing, and analysis.
I've been using AI every day for the better part of two years now — to build Sozin, to write, to think through problems. In that time I've sent something on the order of tens of thousands of prompts. Most of them were bad. The ones that worked had a few things in common, and they have almost nothing to do with the "prompt engineering" tricks you see on Twitter.
This is what I actually do.
Specific Beats Clever Every Time
The single biggest lever is specificity. Not length, not formatting, not magic words. Just being concrete about what you want and what the model is working with.
Here's what I mean. A while back I wanted to add a cmd+k command palette to the app — the thing every modern tool has now. Lazy prompt: "add a command palette." What I actually sent: "Add a cmd+k palette that opens a dialog with a search input and a filtered list of actions. Esc closes it. Arrow keys move selection, enter triggers. The shortcut should only register while the dialog is closed — once it's open, the input owns the keyboard. Actions are: new chat, switch model, open settings, log out. Each shows an icon, a label, and an optional shortcut hint on the right."
Same feature. The first prompt gets you a generic palette that breaks the moment you try to wire it up. The second one gets you a working component you can drop in.
The same thing applies to writing. "Write a landing page for my AI product" is going to give you the same milquetoast copy every other founder gets. "Write a landing page for Sozin AI. The hero needs to land in one sentence — we let you switch between Claude, GPT, Gemini and a dozen others in one chat, with conversation branching. Audience is developers who already pay for two or three AI subscriptions. Tone is direct, no marketing voice. Lead with the cost annoyance, not the feature list." Now you've got something to work with.
More Context Helps — Until It Doesn't
The next thing I've learned is when to feed the model context, and more importantly, when not to.
For analysis and synthesis tasks, more context almost always helps. If I'm asking Claude to review a contract, I'd rather give it the whole document plus three related contracts for reference than ask abstract questions about clauses. If I'm asking GPT to refactor a function, I give it the function, the file it lives in, and the tests that cover it.
But for generative tasks — writing, brainstorming, drafting — extra context can actively hurt. Paste in twelve example blog posts of "your voice" and the model will produce something that reads like an average of all twelve, which is to say, blander than any of them. I've gotten better results from a single tight example plus a description of what makes my voice mine ("short sentences. opinionated. no hedging.") than from a wall of samples.
The rule I've landed on: include context that constrains the output, exclude context that dilutes it.
Tell It What "Good" Looks Like
Models can't read your mind about what a good response would be. If you have a sense of what you want — and you usually do, even if you can't articulate it — say so explicitly. "Keep it under 200 words." "I want the answer in the first sentence, then the reasoning." "If you're not sure, say so instead of guessing." "Don't use the word 'leverage'."
This last one matters more than people realize. The negative constraints — what not to do — are often more useful than positive instructions. AI defaults to a particular register (helpful, hedged, slightly corporate). Telling it to avoid that register works much better than describing some abstract alternative.
Different Models, Different Dialects
The models do respond to different styles, and this is worth knowing even if you're not optimizing hard for it. Claude is happy with XML tags and tends to follow them rigorously — <task>, <context>, <output_format>. GPT likes structured markdown and numbered steps. Gemini is loose; you can throw a paragraph at it and it'll figure it out, but it benefits from being told what to focus on first.
I don't religiously format prompts differently per model. But when something isn't working with one model, switching the structure (rather than rewriting the actual content) is the first thing I try.
The One Habit That Beats All The Tips
The single most useful thing I've learned: re-read the response and ask whether the model actually did what you asked. Half the time it didn't quite, and the fix is to point that out specifically. "You wrote three paragraphs of explanation before the code. I asked for code first, explanation second. Try again." Models take this kind of correction well, and the second response is almost always materially better.
The trap is to keep adding to the prompt instead — making it longer and longer in the hope of pre-empting every failure mode. Don't. Send a normal prompt, evaluate the answer honestly, and course-correct in turn two. That's the workflow. Everything else is window dressing.