Most developers use AI as autocomplete and stop there. The larger gains come from the tasks engineers postpone: reviewing unfamiliar code, planning a refactor, writing tests for legacy modules and producing an honest post-mortem. Each of those is a prompt problem before it is a coding problem.
What is the biggest mistake developers make when prompting?
Withholding context. A model given a bare function has no idea whether it runs at the edge, whether the input is user-controlled, or which style guide applies. The output is then generic and often wrong in ways that are expensive to catch.
The fix is a short context block at the top of every prompt: language and version, runtime, what the code does, and the constraints that matter. Three lines of context change the quality of the answer more than any clever phrasing.
How do you get a code review worth reading?
Ask for a prioritised list, not prose. Request correctness bugs first, then security, then readability, each with a line reference and a specific fix. Explicitly forbid a full rewrite — otherwise the model returns a reformatted file and you cannot tell what actually changed.
The most valuable instruction is the last one: tell the model to list its uncertainties separately. A model that says it does not recognise a helper function is far more useful than one that confidently assumes. That list becomes your checklist of things to verify yourself.
Can AI plan a refactor safely?
It can plan one well if you make it plan before it writes. Describe the current structure, the pain you are trying to remove and the constraint that nothing may break, then ask for a sequence of small, independently shippable steps with the risk of each step named.
Review the plan, discard the steps that assume something untrue about your codebase, and only then ask for code, one step at a time. Refactors go wrong when the model produces a thousand lines at once and the diff becomes unreviewable — sequencing is the whole safeguard.
What is the fastest way to add tests to legacy code?
Ask for the test cases before the test code. Paste the function and request a list of behaviours worth testing: happy path, boundary values, error paths, and any case where the current behaviour looks unintentional. That last category regularly surfaces real bugs.
Once you have approved the list, ask for the tests in your framework, with your naming convention, and with no mocking beyond what you specify. Tests written from an agreed list are readable; tests generated in one shot tend to assert whatever the implementation already does, which proves nothing.
How do you use AI for documentation that stays accurate?
Generate documentation from the code, not from intent. Prompt for docstrings that describe parameters, return values, thrown errors and side effects, and instruct the model to mark anything it has to guess at as unverified. Those markers show you precisely where the code is unclear enough to deserve a comment — or a rewrite.
For README and architecture notes, feed the model the directory tree and a few entry-point files, and ask for a short orientation document aimed at someone joining next week. Keep it under a page; anything longer goes stale.
What does a good incident post-mortem prompt include?
Supply the timeline, the impact, the contributing factors and what was done to restore service. Ask for a blameless write-up that separates the trigger from the underlying cause, lists the detection gap, and proposes action items that are specific and owned.
Add a constraint that no action item may be "be more careful". Forcing the model toward mechanisms — an alert, a test, a guardrail, a rollback path — produces the kind of follow-up work that actually prevents a repeat.
How should a team share prompts?
Check them into the repository alongside the code they serve, as plain markdown with bracketed variables. A prompt in version control gets reviewed, improved and reused; a prompt in someone's chat history is lost the moment they change teams.