Prompt Engineering

Introduction

Designing effective prompts and providing well‑structured context are essential to ensuring that coding assistants generate accurate, secure, and high‑quality outputs for software engineers. Effective prompts act as the “specification layer” of AI interactions: they define the micro‑task, the boundaries, and what “done” means, so the assistant can generate reviewable, testable changes instead of confident guesses. A well‑designed prompt turns the assistant into a precision tool embedded in an engineering workflow (review, tests, CI), not a generative engine operating without guardrails.

Key principles

• Write prompts like you write user-story: one persona, one micro‑goal, measurable acceptance criteria. If you can’t test it, you can’t prompt it.

• Pertinent context only: give the smallest set of signatures, invariants, and examples that make the task unambiguous. Extra files are usually liability, not help.

• Constrain the output for review: ask for a patch‑like structure, limited file touch, and a self‑check so you can validate quickly and safely, by explicitly asking the model to list potential issues or verify its own output against the acceptance criteria

• Structure your prompt with PCIE proposition (Persona, Context, Instruction, Example )

Example

BAD PROMPT

Improve the security and performance of our createUser service and write tests. 
Here's the entire repository (ZIP attached) with the complete .env file. Use 
what you want (libraries included) and refactor if necessary. Release all the 
final code directly.

• ❌ Vague and multi-target objective: drift and responses are hard to test.
• ❌ Over-sharing of context (full repository, .env secrets): risk of leaks + hallucinations.
• ❌ Implicit/absent constraints.
• ❌ No defined output format: verbose diffs, hard to review.
• ❌ No acceptance criteria: “better” remains subjective and difficult to validate.

GOOD PROMPT

Persona:
You are a Senior Backend Engineer & SDET. You favor minimal diffs, no new deps, 
clear tests, and no secrets.

Context:
Target: createUser(email: string, password: string): Promise<User> (TypeScript).

Invariants:
- email must be valid
- password ≥ 12 chars and includes lower/upper/digit/special

Scope:
- services/user/createUser.ts
- tests/createUser.test.ts

Do not change the public API, formatting, or introduce dependencies.

Instruction:
- Add input validation in createUser
- Add Jest tests for valid/invalid email and password edge cases

Constraints:
Minimal diff, no new deps, keep existing hashing, style unchanged.

Acceptance:
- public API unchanged
- all new tests pass
- only the two files modified
- no secrets/PII

Example (shape only):

Section 1 — PATCH:
Small unified diff adding validation + throwing InvalidInputError('email' | 'password')

Section 2 — TESTS:
Jest cases for:
- invalid email
- short password
- missing character classes

Section 3 — SELF-CHECK:
- API unchanged
- no deps added
- diffs minimal
- no secrets

Effective prompt design requires supplying:

• A clear objective expressed in one concise sentence.

• Minimal but sufficient context: signatures, invariants, business rules, examples, or existing tests.

• Explicit constraints (format, style, allowed operations, security rules, non‑functional requirements).

• Representative examples of expected inputs and outputs when applicable (few‑shot scaffolding).

• Defined boundaries: what the assistant must not change, generate, or assume.

• Sanitized content, free from secrets, credentials, or sensitive configuration.

Drawbacks / anti-patterns

• Overly vague prompts that cause irrelevant or unsafe suggestions.

• Over-sharing context (full modules, multiple files) leading to hallucinations or leakage risks.

• Implicit constraints or expectations instead of explicitly stating what is required or forbidden.

• “Best solution” requests without acceptance criteria (produces persuasive prose instead of testable outcomes).

• Letting the assistant run multiple steps without human validation.

• Trusting outputs without tests or human review (plausible ≠ verified).

• Accepting large diffs or full rewrites when only a small change was required.

• Relying on AI to infer business rules without providing them explicitly.

External references

• Wikipedia
• Google