Coding is where prompt engineering pays the highest salary — because code is verifiable. A vague prompt for an essay gets you a mediocre essay; a vague prompt for code gets you a function that looks right and fails at 2 AM. The difference between developers who ship with AI and developers who fight it comes down to a handful of prompting patterns.
This guide is those patterns: the evidence rule that fixes debugging forever, the spec template for building features, prompts for learning, reviewing, testing and refactoring, plus the anti-patterns that produce confident broken code. Works in every tool — chat assistants, Copilot, Claude, anything. Guide #27 of the Prompt Engineering roadmap — first stop on the Use Cases track.
Whatever Your Level — Find Your Lane
The Golden Rule — Evidence, Not Vibes
Every coding prompt failure traces back to the same sin: describing the problem in feelings instead of facts.
Code + input + expected + actual + full error — the evidence pattern. It converts debugging from psychic reading into engineering, and it’s the single highest-value habit in this guide. “Trace to the divergence point” additionally forces step-by-step reasoning through your actual code instead of pattern-matched guessing.
Quick Start — Your First 3 Coding Prompts
Building Features — The Spec Template
“Write me a login system” produces generic code that fits nobody’s project. Professionals prompt with a spec:
Stack: [language, framework, versions].
Context: [how it fits — what calls it, what it calls; paste related code/interfaces].
Requirements: 1. [functional] 2. [functional] 3. [error handling behavior] 4. [what NOT to do/change].
Constraints: [style rules — naming, no new dependencies, must match existing patterns].
Deliver: the code + a 3-line explanation of decisions + what I should test manually.”
The two parts everyone skips are the two that matter most: Context (pasting the interfaces it must fit) and what NOT to change — the negative constraint that stops the AI from “helpfully” rewriting your working code.
Prompting by Task — The Developer’s Playbook
🐛 Debugging beyond the basics
- Rubber-duck mode: “Ask me 5 diagnostic questions about this bug before proposing anything” — the questions alone often reveal the answer
- Hypothesis mode: “List the 3 most likely causes ranked by probability, and the ONE test that distinguishes them” — tree-of-thought for bugs
- Heisenbug helper: “It fails intermittently. What logging should I add, exactly where, to catch it in the act?”
📚 Learning & understanding code
- The layered explain: beginner pass, then senior pass (Quick Start #1) — two altitudes beat one
- The socratic upgrade: “Explain [concept], then quiz me one question at a time until I can implement it” — reading code ≠ being able to write it
- Codebase onboarding: paste related files together — “explain the architecture, then trace how [feature] flows through it” (long-context tools shine here)
🧪 Tests
Power move: flip the order. Write the tests first from your spec, THEN ask for the implementation “until these tests pass” — turning AI pattern-matching into verified code.
♻️ Refactoring
Context Strategy — How Much Code to Paste
Chat vs In-Editor — Two Prompting Modes
- Chat assistants (ChatGPT/Claude/Gemini): best for thinking — architecture, debugging conversations, learning, reviews. Full sentences, full evidence, full specs.
- In-editor completion (Copilot-style): best for flow — here your PROMPTS are comments and names. A specific comment above the cursor (“// validate email, return helpful errors”) and honest function names steer completions more than anything else.
- The pro loop uses both: design and debug in chat → implement with completions → paste back to chat for the review + security pass before committing.
The Developer’s Daily 10
Style Matching — Make It Write Like Your Codebase
AI defaults to tutorial-style code; your project has its own conventions. One few-shot move fixes it: paste one representative function and say “match this codebase’s style exactly — naming, error handling, comment density, patterns.” One example beats ten style rules, and it’s why the spec template’s Context slot asks for a sample of your code, not just interfaces.
When the AI Is Confidently Wrong
- Demand the source of truth: “Does this API actually exist in [library] [version]? If you’re not certain, say so” — hallucinated methods are coding’s classic failure
- Cross-examine: “You claimed X. Walk through the code line by line and prove it” — pattern-matched claims often collapse under forced tracing
- Second opinion: for anything high-stakes, run the same evidence-pattern prompt fresh (or in another tool) and compare — self-consistency for code
- Ultimate arbiter: the compiler and the tests. Ties between you and the AI are settled by running it.
A Real 3-Turn Debug (Watch the Pattern Work)
Three turns, zero frustration, and a regression test so it never returns. That’s the workflow — evidence, trace, fix, test.
Anti-Patterns — How Developers Get Burned
- Vibes-based bug reports — “doesn’t work” costs three clarification turns the evidence pattern skips
- Accepting code without running it — AI code is a draft from patterns, not a verified artifact; tests or it didn’t happen
- The whole-project dump — more context isn’t better context; curate
- Letting it rewrite the world — always scope: “minimal fix only,” “don’t touch anything outside X” (see Keep X, change Y)
- No version pinning — inviting last year’s API into this year’s project
- Learning by copy-paste — shipping code you can’t explain is borrowed time; use the explainer and socratic prompts until you could rewrite it
Frequently Asked Questions
The evidence pattern: code + exact input + expected output + actual output + full error, then ‘trace to the divergence point.’ It converts debugging from guessing into engineering, and it’s the highest-value habit for any tool.
Prompt with a spec: stack and versions, the interfaces the code must fit (paste them), numbered requirements including error handling, and explicit constraints on what NOT to change. Generic requests produce generic code.
Three usual causes: missing context (it guessed your setup), version drift (it wrote against older APIs — pin your versions), and unverified acceptance (no tests). All three are fixable at the prompt level.
As a strong first pass, yes — severity-ranked reviews catch real issues fast. But they’re pattern-based: keep human judgment for architecture decisions and run a dedicated security pass on anything handling user input.
Match context to task: just the function for small bugs; the interfaces plus a style sample for features; all related labeled files for architecture questions. Whole-project dumps drown the signal.
Yes — if you flip the prompts: layered explanations, ‘quiz me until I can implement it,’ and reviewing your OWN code. The learning happens when AI checks your work, not when it replaces it.
All of them — the evidence pattern, spec template, and test-first flow are tool-agnostic. Tool-specific tips live in our Copilot, ChatGPT, and Claude guides.
Write the tests from your spec first (or have AI write them), then ask for an implementation that passes those tests. It converts ‘looks right’ into ‘provably right’ — the cheapest quality upgrade in AI coding.
One-shot it: paste a representative function from your codebase and instruct ‘match this style exactly — naming, error handling, comment density.’ A single real example outperforms a paragraph of style rules.
Pin versions in every prompt, ask ‘does this exist in [library][version] — say so if unsure,’ and verify against real docs (or a search-enabled tool). Hallucinated APIs are common on fast-moving libraries; the compiler is the final judge.
Evidence in. Verified code out. 💻
Next: Prompt Engineering for Students — guide #28.
