Prompts for coding vs writing vs research: what changes
The basics stay the same: a clear goal, the right context, and a set output format. What changes is what the model needs to see, what a good answer looks like, and how you check it.
At a glance
| Coding | Writing | Research | |
|---|---|---|---|
| Give it | The real code, errors, versions and how to run things | Your draft or notes, the audience, and examples of your voice | The exact question, time frame, and what sources count |
| Ask for | Small, reviewable changes and how to verify them | A set length and tone, with your meaning kept intact | Sources for each claim, and what's uncertain or missing |
| Main risk | Code that looks right but breaks something else | Generic phrasing that loses your voice, or added ideas | Confident claims, numbers or citations that are wrong |
| Check it by | Running it, testing it and reading the diff | Reading it aloud and comparing it to what you meant | Opening the sources and confirming they say what's claimed |
Coding: context and small steps
Code prompts fail most often because the model can't see enough. Paste the full error or stack trace as text, the relevant files, and your language, framework and versions. A coding tool that can read your repo, such as Cursor or Claude Code, helps a lot here.
- Diagnose before fixing. Ask for likely causes and a quick test for each before any code changes. Otherwise you tend to get a patch for the symptom.
- Keep changes small. One step at a time, with a list of files it will touch and a way to verify each change.
- Set rules once. For agents, put your test command, style rules and "never do" list in a rules file instead of repeating them in every prompt.
Try: Root-cause a bug, One small step at a time, Project rules file generator. Browse vibe coding, debugging and code review prompts.
Writing: audience, voice and limits
Writing prompts fail most often by sounding like everyone else. The fix is to say who it's for, give a target length, and show the model how you actually write.
- Name the reader. A cold email to a busy founder and a docs page for a new user need very different writing.
- Protect your voice. Paste your own draft or a past example, and ask it to edit rather than rewrite. Say "don't add new ideas".
- Set hard limits. A word count, a reading level, or "cut 30%" works better than "make it concise".
Try: Edit for clarity, keep my voice, Make it shorter, Feedback on my draft. Browse writing and marketing prompts.
Research: sources and honesty about gaps
Research prompts fail most often by sounding sure about things that aren't true. Models can invent sources, mix up dates and get numbers wrong, especially from memory.
- Turn on browsing when you need anything current, and say how recent the sources must be.
- Ask for a source for each claim, and permission to say "unverifiable" instead of guessing.
- Ask for the other side and for what's missing. A good research answer tells you where the evidence is thin.
- Open the links. Check that each source exists and says what the answer claims it says.
Try: Fact-check this claim, Steelman both sides, Literature and market scan with citations. Browse research prompts.
Whatever the task, always review AI output before you rely on it.