Prompt Engineering Examples for Software Engineers
Concrete prompt engineering examples for debugging, refactoring, tests, architecture, code review, and documentation.
A useful engineering prompt makes the assistant reason from the problem, evidence, constraints, and acceptance criteria—not from an isolated command. The examples below show how that changes debugging, refactoring, tests, architecture, code review, and documentation work.
Each better prompt is deliberately specific about the decision the assistant must make. You can shorten it when the task is small, but preserve the information that prevents a product-wrong change.
Debugging a flaky checkout
Problem
A checkout request sometimes succeeds after a retry, but the UI still shows the first error.
Weak prompt
Fix the flaky checkout error.
Better prompt
Symptom: A checkout request can fail once with a timeout, then succeed on the
automatic retry. The success screen does not appear after the retry.
Expected: A successful retry should replace the error state and enable the
next checkout step.
Observed: Network logs show a 200 response, but the first error banner stays.
Scope: Inspect the checkout mutation, retry callback, and screen state only.
Constraints: Keep the existing payment provider integration and error copy.
Do not hide errors before a request has actually succeeded.
First give two or three evidence-based hypotheses and the smallest reproduction
or log signal that would distinguish them. Then propose a minimal fix and a
regression test.
Why it works
The prompt separates the evidence from the assumption. It asks for a state-transition diagnosis before a rewrite and protects the payment integration from an unrelated change.
Refactoring repeated form logic
Problem
Three settings forms repeat the same loading, error, and save-state code.
Weak prompt
Refactor these forms to remove duplication.
Better prompt
The account, notification, and profile forms duplicate save-state rendering.
Identify the exact repeated behavior and the places where the forms differ.
Outcome: Reduce duplicated rendering without changing public form props,
validation timing, localized errors, analytics events, or keyboard behavior.
Scope: The three settings forms and their direct tests.
Non-goal: Do not create a general form framework or move request ownership
out of the existing feature hooks.
Recommend the smallest extraction, show the preserved contract, and add or
update tests for loading, failure, and success for each form.
Why it works
“Remove duplication” is a goal, not a design. The better prompt asks the assistant to find the real common seam and prevents an oversized abstraction.
Writing a race-condition test
Problem
Search results from a slow old query can overwrite a newer query.
Weak prompt
Add tests for search.
Better prompt
Add regression coverage for a search race condition.
Scenario: A user searches for "network", immediately changes the query to
"terminal", and the network response returns last.
Expected: The UI shows results for "terminal" only. The older response must not
replace them.
Use the existing test stack and accessible assertions. Avoid asserting internal
state names. If the production code cannot express cancellation or freshness
clearly, explain the smallest change required before writing the test.
Why it works
The test prompt defines time, user action, and visible behavior. It does not let a convenient implementation detail become the test's contract.
Evaluating an architecture change
Problem
A team is deciding whether to add a second cache layer for configuration.
Weak prompt
Add caching for configuration to make the app faster.
Better prompt
Assess whether a client-side configuration cache would improve the slow screen
without creating stale entitlement or preference decisions.
Context: The app already has a configuration provider and the screen waits for
an authenticated user. We have not measured whether fetching or rendering is
the bottleneck.
Compare: no cache, a bounded in-memory cache, and the proposed persistent
cache. Evaluate freshness, invalidation, privacy, offline behavior, and the
measurement needed to justify the change.
Do not implement anything until you state which option you recommend and why.
Why it works
The prompt makes “faster” measurable and asks the assistant to challenge the premise. A cache is not automatically a performance improvement.
Reviewing a risky diff
Problem
A pull request changes permissions and user-facing navigation in the same feature.
Weak prompt
Review this pull request.
Better prompt
Review this diff for authorization regressions, locale-breaking navigation,
and behavior changes hidden by refactoring.
Trace every changed permission decision to its caller. Verify that internal
links preserve the active locale and that denied states do not reveal protected
data.
Report only findings with evidence from the diff or its direct call sites.
Prioritize correctness and security before style suggestions. List missing
tests separately from confirmed defects.
Why it works
The review has a threat model and a scope. That produces a smaller, more actionable result than asking for generic feedback.
Updating documentation after a tool change
Problem
The local setup command changed, and the getting-started guide is now stale.
Weak prompt
Update the setup documentation.
Better prompt
Update the local setup guide for the current package scripts.
Verify each documented command against package.json and the repository's setup
instructions. Explain prerequisites, expected ready output, common failure
signals, and a safe recovery path.
Do not document secrets, values copied from a local environment, or commands
that the project does not actually run. Add a short validation checklist for a
new contributor.
Why it works
The assistant has to ground the prose in the repository rather than produce a polished but fictional guide.
Use the example that matches your task
The repeated pattern is simple: name the problem, narrow the scope, protect important behavior, request evidence, and define validation. Start with the reusable framework in how to write better AI prompts, then see prompt engineering for developers for a workflow organized by engineering role.
Production issues need an even stricter evidence trail. Continue with prompt templates for debugging production issues before you ask an assistant to propose a live-system fix. When a bug involves shell output or a script, reproduce the command-line workflow in the browser before you automate a solution.
References
These documentation links provide authoritative details for the commands used in this article.