Prompt Engineering for Developers — Patterns That Actually Work

Most prompt engineering advice is written for people chatting with chatbots: "ask it to think step by step," "give it a persona," "be polite — it performs better." None of that survives contact with a coding agent staring at your repository.

Developer prompting is a different discipline, and it has almost nothing to do with magic words. It's spec-writing at speed: communicating a task precisely enough that a very fast, very literal, occasionally overconfident collaborator can execute it — and you can review the result. If you've read our guide to reviewing AI-generated code, this is the other half of the loop: prompting is how you make the review easy.

Here are the seven patterns that actually change outcomes with coding tools, each with the weak version everyone writes and the engineered version that works.

Pattern 1 — Context before ask

Models can't read your mind, your ticket tracker, or the three conversations you had in Slack about this feature. They can only read what's in the prompt and the files you point them at.

Weak: "Fix the login bug."

Engineered: "In src/auth/session.ts, refreshSession() throws when the token is expired instead of redirecting. Reproduce with: log in, wait for expiry, click any nav link. Fix the redirect path only — don't touch login()."

The engineered version names the file, the function, a reproduction, and the scope. Same tool, same model — ten times more likely to produce a reviewable diff. Before every non-trivial prompt, ask: what does this AI not know that I know? Then say it.

Pattern 2 — One ask per prompt

Compound prompts produce compound messes. "Add validation, then update the docs, then refactor the helper" comes back as one sprawling diff where the three threads tangle — and your review checklist has to untangle all three at once.

Weak: "Add email validation and also fix the CSS on the form and write a test for both."

Engineered: Three prompts, in order, each building on the reviewed result of the last: "Add validation to the email field" → review → "Add a test covering empty and malformed input" → review → "The form's submit button shifts on mobile — fix the CSS."

This is the same small-steps discipline as small commits. Each prompt produces a diff you can actually verify, and a failure in step two never poisons step three.

Pattern 3 — State the constraints, including the negatives

Every unstated constraint is a decision the model makes for you, and models default to the most general, most verbose interpretation. Constraints are where you cash in specificity:

• Stack: "This is a Next.js app with Tailwind — no new dependencies."
• Style: "Match the existing patterns in this file; no reformatting."
• Scope: "Only session.ts. Do not modify tests or types files."
• Output contract: "Return only the changed function, no commentary" — or the reverse, "explain your approach first, then the code."

The negatives matter most. "Don't touch other files" prevents the adjacent edits that bloat diffs. "No new dependencies" prevents the mystery npm package in your lockfile. Tell the tool what not to do, or it will helpfully do it.

Pattern 4 — Show, don't just tell (examples)

Descriptions are ambiguous; examples aren't. When output shape matters, one concrete example beats a paragraph of adjectives.

Weak: "Write a function to format the user data nicely for the dashboard."

Engineered: "Write formatUser(u) that returns exactly this shape:

{ label: "A. Lovelace (Admin)", value: "usr_123", enabled: true }

Handle missing role as \"Member\". Null id → return null."

Now the model isn't guessing what "nicely" means — it's filling in a contract. The same pattern applies to tests (show one test, ask for the rest in that style), migrations, config — anywhere format is the requirement.

Pattern 5 — Ask for the approach before the code

For anything bigger than a typo fix, invert the order: reasoning first, code second.

Engineered: "Before writing code: in two sentences, describe how you'd fix the N+1 query in getDashboard(), and name the files you'd touch. Wait for my OK."

This buys you three things: a cheap checkpoint before expensive code generation, a map for the review that follows, and — when the plan is wrong — a five-second correction instead of a 300-line rewrite. On agentic tools, the same effect comes from plan mode or first-draft mode; use them whenever the change will span files.

Pattern 6 — Diagnose failures; don't re-roll

When the output is wrong, the reflex is to regenerate. Resist it. A re-roll with the same prompt plus "make it better" tends to produce a different wrong answer. Failures carry information:

• Wrong file or function touched → your context was too thin. Re-prompt with Pattern 1.
• Hallucinated API → the model is guessing outside its knowledge. Paste the real signature or docs excerpt into the prompt.
• Works but over-engineered → your constraints were too loose. Restate scope (Pattern 3) and ask it to simplify.
• Loops on the same error → context is polluted. Start a fresh session with a tight summary of the current state.

Treat a failed generation like a failed test: read the error, form a hypothesis, change one thing in the prompt. Developers already have this skill — it's debugging, aimed at a different kind of stack.

Pattern 7 — Version your prompts

Any prompt you write twice is a prompt you should have saved. Keep the ones that work — the strict code-review prompt, the test-generator, the commit-message format — in one place (a prompts.md in the repo, or your tool's custom commands), and iterate them like code:

• Name them: review-diff, gen-tests-edge, explain-unfamiliar.
• When output drifts, fix the prompt, not just the instance.
• Share them with your team; a good prompt is team infrastructure.

This is also where system prompts in your own AI apps come from — the same engineering, applied to a product instead of a workflow.

The patterns at a glance

Pattern	Use when	One-line rule
1. Context first	Every non-trivial prompt	Say what the AI can't know
2. One ask	Tempted to say "and also"	One diff per prompt
3. Constraints	Output looks right but wrong	Include the negatives
4. Examples	Output shape matters	Show one, ask for many
5. Approach first	Multi-file changes	Plan is cheaper than code
6. Diagnose	Generation failed	Change one thing, don't re-roll
7. Versioning	You wrote it before	Save, name, iterate

Anti-patterns to unlearn

• The essay prompt. Six paragraphs of context where six bullet points would do — long prompts dilute the actual ask. Dense and structured beats long.
• Politeness bargaining. "You're the world's best developer" changes nothing measurable. Constraints change everything. Spend your tokens on specifics.
• Prompt archaeology. Recycling a 40-message conversation as context for a new task. Old failures poison new generations — summarize state and start fresh.
• Accepting to stay in flow. All seven patterns collapse if you skip the review. Prompting and reviewing are one skill with two halves.

FAQ

Is prompt engineering still a thing in 2026, or do smarter models make it obsolete?

The chatbot tricks are obsolete — modern coding models don't need ceremony. The engineering is more valuable than ever: naming the right files, scoping the ask, stating constraints, and reviewing output. As models absorb more ambiguity, the remaining human skill is precision about intent. That's spec-writing, and it doesn't age out.

What makes a good prompt for a coding agent?

File paths, reproduction steps, scope limits, and an output contract — enough context that the model isn't guessing, and enough constraints that the diff comes back small. If your prompt would let a competent human stranger start work without asking questions, it's good. Our seven patterns above are just that rule, expanded.

How long should a prompt be?

As long as the context requires and not a word longer — usually 3–8 dense lines for everyday tasks. Bullet-pointed context beats prose. The failure modes are both directions: too thin produces guessing, too long buries the ask.

Do prompt patterns transfer between tools like Cursor, Claude Code, and Codex?

Yes — that's the point of treating them as engineering patterns rather than tool tricks. Context, scope, constraints, examples, and review discipline work everywhere. Tool-specific syntax (custom commands, plan modes, file references) is a thin layer you relearn in an afternoon; the patterns in this guide are the portable 90%.

Where do I practice prompt engineering with feedback?

Build real things: take a project through the learning roadmap, prompt every stage, and review every diff — the log of what failed and why is the training data for your instincts. The free DevKingOv courses build exactly this loop, and a 1-on-1 mentor can audit your prompts and reviews directly — the fastest feedback loop there is.