Prompt Engineering for Developers

Describe the result you need

Suppose an assistant keeps “fixing” a port parser by accepting inputs your application must reject. A longer request is not necessarily the solution. The missing information may be the input policy: whether spaces, signs, fractions and trailing characters are allowed. Prompt design makes that policy visible and testable.

A prompt is part of an application interface. State the task, relevant context, constraints and expected output. “Fix this” leaves important questions unanswered: what is broken, which environment matters and what must remain unchanged? Precise instructions reduce ambiguity, but they do not replace testing.

For coding help, supply a minimal reproducible example, the exact error, dependency versions and expected behaviour. Distinguish observations from your own hypothesis. If you say “the cache is broken” when all you know is that a page is stale, you may steer the investigation away from the actual cause.

Use a small, inspectable request

The example asks for a proposal with verifiable criteria. It does not ask the model to rewrite the whole module. Small scope makes it easier to compare the proposed change against the contract and to reject unrelated alterations.

Examples help when a desired format or classification boundary is difficult to describe. Include a difficult example as well as a normal one. Keep example outputs correct: a model can imitate a mistaken example just as readily as a good one.

Task: Review the supplied parsePort function.
Expected: accept decimal integers from 1 through 65535.
Reject: empty text, fractions, signs and trailing characters.
Environment: TypeScript in a Node server.
Constraints: preserve the public signature; add no dependency.
Output: explain the failure, propose a small patch, list tests.
Evidence: [paste the function and the failing input here]
If a requirement is ambiguous, ask before choosing a policy.

Keep external content in its proper role

Documents, logs and retrieved pages are evidence, not trusted instructions. Label them clearly and tell the model how they should be used. However, labels and delimiters are not a security boundary: malicious text inside a document can still influence a model. Enforce tool permissions and data access in application code.

Avoid sending secrets, unnecessary personal information or entire logs when a redacted extract will do. Do not include a password and then rely on “never reveal this” to protect it. Minimize what enters the request, and review provider retention and processing settings separately.

Test prompts as part of the feature

Keep a versioned set of representative inputs and acceptance criteria. Compare old and new prompts on the same cases, including edge cases and missing information. Measure useful outcomes: valid structure, supported claims, correct code behaviour and appropriate abstention. An impressive single response is weak evidence of an improvement.

Change one important variable at a time where practical. Record the model, relevant settings and source material. A prompt that works for one model or context size may not transfer unchanged. Prefer a short prompt with a clear contract over accumulating contradictory instructions after every failure.

Use examples to reveal the boundary

A zero-shot request describes the task without demonstrations; a few-shot request supplies example inputs and desired outputs in the context. These examples guide the current generation rather than retraining the model. They are useful when prose leaves a boundary ambiguous, but they can also teach the wrong rule if they are incorrect or unrepresentative.

For the strict port parser, the contrast between “80” and “80abc” exposes the numeric-prefix mistake. Include the lower and upper bounds as well. State that leading zeros are allowed if that is the policy, and say whether whitespace should be rejected. Examples complement the written contract; a handful of examples cannot cover every possible input.

Compare an original request with a revised request on the same saved cases, including at least one case not used as a demonstration. Check whether the suggested implementation obeys the policy by running independent tests. If it fails, classify the failure: missing requirement, ignored requirement, wrong code or wrong test. That diagnosis is more useful than repeatedly adding “be careful” to the prompt.

Input -> expected result
"80" -> 80
"00080" -> 80 (leading zeros are allowed)
"80abc" -> null (reject trailing characters)
" 80" -> null (reject whitespace)
"0" -> null (below the minimum)
"65535" -> 65535 (upper bound included)

Explain how your proposal handles each boundary.
Do not claim tests passed unless you actually ran them.
State any requirement the evidence does not settle.

Sources & further reading

Primary references for the concepts in this guide. Examples and exercises are illustrative; verify provider-specific behaviour against the version you use.

• OWASP: Prompt injection prevention
• GitHub: Prompt engineering
• GitHub: Writing tests with Copilot