How to Write Better AI Prompts: A Practical Guide for Developers and Solopreneurs
Most people treat AI models like a search engine. They type a vague question, get a mediocre answer, and assume that is just how it works. It is not. The output quality is almost entirely determined by the quality of the input.
This guide covers the techniques that actually move the needle.
Start With a Role and a Context Block
The single biggest improvement most people can make is telling the model who it is and what situation it is in before asking anything.
Bad prompt: "Write a product description for my SaaS tool."
Better prompt: "You are a direct-response copywriter with 10 years of experience selling B2B software. I am launching a project management tool aimed at freelance developers who hate admin work. Write a 100-word product description that leads with the pain point."
The second version gives the model a lens to work through. It filters out generic marketing language and pulls it toward something more specific.
The role does not need to be elaborate. "You are a senior Python developer doing a code review" is enough. The point is to frame the context before the request lands.
Use Output Constraints, Not Just Descriptions
Vague instructions produce vague results. If you want a specific format, specify it.
Instead of asking for "a summary," ask for "a 5-bullet summary where each bullet is one sentence and starts with an action verb."
Instead of "make this email shorter," try "rewrite this email to under 80 words, keep the call to action in the last sentence, and cut any sentence that does not directly support the ask."
Constraints are not limitations. They are specifications. The model performs better when it knows exactly what done looks like.
Chain Prompts for Complex Tasks
One prompt rarely handles a complex task well. Break the work into stages.
If you are building a feature spec, do not ask for the full document in one shot. Run it in sequence:
- First, ask the model to identify the core user problem in two sentences.
- Then, ask it to list the three most important user outcomes.
- Then, build the spec from those outputs.
Each step produces something you can review and correct before it feeds into the next one. Errors stay small and fixable instead of compounding across a 600-word document you then have to rewrite.
This applies to code too. Ask for the function signature and a plain-English description of the logic before asking for the implementation. You catch misunderstandings early.
Use "Show, Don't Describe" for Tone and Style
Describing the tone you want is often less effective than showing an example.
If you have a piece of writing that matches the voice you are after - your own past work, a newsletter you like, anything - paste a short excerpt and say "match this tone and style."
For code style, paste an existing function and say "write the new function following the same patterns as this one." The model picks up indentation preferences, naming conventions, and comment density far more accurately from an example than from a description like "clean and readable."
Give the Model Permission to Push Back
Most AI models are trained to be agreeable. They will often produce a confident-sounding answer even when your premise is wrong or your request is underspecified.
One fix is to explicitly invite disagreement. Add a line like: "If my approach here has a problem, tell me before writing the code" or "If this brief is missing information you need, ask me for it before you start."
This sounds small but it changes the dynamic. You get fewer hallucinated answers and more honest gaps identified.
Iterate With Targeted Edits, Not Full Rewrites
When an output is 80% right, most people ask the model to "make it better" or "rewrite it." That is too vague. You usually lose the parts that were already good.
Instead, point at the specific problem. "The third paragraph is too formal - rewrite just that paragraph in plain language." Or "The function works but the variable names are confusing. Rename them and explain your choices."
Surgical edits preserve what is working. They also make it easier to track what is changing across iterations.
Test Your Prompts Like You Test Code
A prompt that works once is not a reliable prompt. Run it against five different inputs. Change the subject matter, the complexity level, and the edge cases.
If the output breaks on certain inputs, that is a bug in the prompt. Fix it the same way you would fix a function - find the condition that causes it to fail and add handling for it.
Keep a personal library of prompts that hold up across multiple tests. Reuse them. Refine them over time. Treat them as assets.
If you want to skip a few weeks of trial-and-error, the Prompt Engineering Mastery Pack at stackdrop.co.za is a $13 collection of 50+ tested prompts and frameworks covering coding, writing, analysis, and creative work - with before/after