Code Generation Prompts — The Debugger’s Spellbook

"If coding is 10% writing code and 90% convincing a model you didn’t actually break everything, this is the manual." — your (very opinionated) TA

---

Quick context (building on what you already learned)

You’ve seen image–text and audio–speech prompt patterns. You’ve also learned about Retrieval-Augmented Generation (RAG) — a key trick for grounding model outputs in external knowledge. Code generation sits at the intersection of creative instruction and rigorous specification: we want correct, executable, auditable outputs, not poetic guesses.

This guide gives you practical prompt patterns for generating, testing, debugging, and refining code. Think of it as scaffolding, unit tests, and manners — all in one.

---

Why special prompts for code? (Short answer)

• Models hallucinate APIs, versions, and behavior when not anchored. RAG helps.
• Code must be syntactically correct and match spec & environment.
• Good prompts reduce iterations, improve reproducibility, and make code review less traumatic.

---

Core prompt patterns (the weapons in your belt)

1) Spec-First (Precision Over Poetry)

Start with a clear specification: inputs, outputs, edge cases, complexity, language & versions.

Example template:

You are a senior software engineer. Implement a function `f` in Python 3.11 with this signature:

def f(input: List[int]) -> int:

Specification:
- Purpose: return the second largest unique number.
- Input constraints: list length ≤ 10^5, values in 32-bit int range.
- Time complexity: O(n) expected.
- Do not import external libraries.

Return only the function code inside a single fenced code block and include concise inline comments.

Why it works: forces the model into a constrained generation space.

---

2) Test-Driven Prompting (TDD-for-the-LLM)

Ask the model to write unit tests first, then implement code that makes them pass. Great when combined with local execution.

Prompt sketch:

1) Provide 5 unit tests (pytest) that capture normal and edge cases for `g(x)`.
2) After tests, write an implementation that passes them.
3) Return tests and code in separate fenced blocks with file names.

Pro tip: run tests locally, return failing output, and prompt the model with the failing trace (see Debugging below).

---

3) Few-shot + Annotated Examples (Show, Don’t Just Tell)

When an algorithm has many subtle variants, give 2–3 input/output examples and an annotated walkthrough. This helps models learn the intended mapping.

Example snippet:

Example 1: input: [1,2,2,3] -> output: 2  # explanation: second largest unique = 2
...
Now implement the generalized solution.

---

4) Debugging Loop: Provide Error + Ask to Fix

When code fails locally, copy the stack trace and failing test output into the prompt. Ask for precise edits (line numbers or function replacements) and reasoning.

Iterative loop (pseudo-workflow):

1. Model generates code. 2. You run tests. 3. If failing, send tests + traceback. 4. Ask for minimal diff/patch.

Prompt example to fix a failing test:

Here are the failing test outputs and traceback. Only provide the corrected function `foo` with a short explanation (2 lines) and a unified diff if needed.

<PASTE TRACEBACK>

---

5) RAG + API doc anchoring

When the model must use a library or external API (pandas, AWS SDKs, TensorFlow), fetch the relevant docs via RAG and include the exact signature and an example snippet in the prompt.

Template:

Retrieved docs: <paste doc excerpt>
Using this doc, implement X. Cite the doc line(s) you used in a one-line comment.

Why: reduces hallucinated method names and incorrect parameter orders. Always ask the model to cite the source lines if you care about traceability.

---

6) Constrained Output (Machine-friendly formats)

Force the model to produce JSON metadata or a strict file map so you can parse outputs programmatically.

Example:

Return JSON: {"files": [{"path": "src/main.py", "content": "<code>"}, ...]} and nothing else.

---

Handy prompt templates (copy-paste friendly)

1. Minimal, production-ready function

You are a pragmatic engineer. Implement NAME in LANGUAGE (version). Provide only the code in a single fenced block. Include: type hints, error handling for invalid input, and 2-line docstring. Do not output explanation.

2. Full dev cycle (spec -> tests -> code)

Step 1: Write pytest unit tests for FEATURE.
Step 2: Implement code to pass those tests.
Step 3: Output file structure as JSON.

3. Bugfix with trace

Here is failing pytest output: <paste>. Provide a patch as a unified diff, and a 1-paragraph diagnosis of root cause.

---

Multimodal touches (because we’re in that section)

• Send screenshots of error consoles: have the model OCR (or your pipeline OCRs) and include the trace as text in the prompt.
• For UI code (HTML/CSS), include a screenshot of the broken rendering along with the DOM HTML. Ask the model to modify the stylesheet to match the target image.
• For architecture questions, include a diagram (image) and ask for code scaffolding to match the components.

These bring visual context into debugging and design requests — powerfully useful when fixing layout bugs or interpreting visual diffs.

---

Table — Quick comparison of prompt patterns

Pattern	Best for	Output control	When to use RAG
Spec-First	Performance-critical code	High	Low (unless libs involved)
TDD	Correctness & edge cases	High	Medium
Few-shot	Idiomatic style	Medium	Low
Debugging Loop	Fixing failures	High	High (to verify APIs)
RAG-anchored	API-dependent code	High	Essential

---

Closing: Workflow to steal

1. Write a short spec + env (language, versions).
2. Ask for unit tests.
3. Implement code.
4. Run tests locally.
5. If failing, paste traces + ask for minimal patch.
6. For API-heavy tasks, RAG the docs first and include them.

Final expert take: Design prompts like you design APIs — explicit, versioned, and testable. If the LLM can’t give you a runnable code block and a test, increase your prompt’s specificity or fetch authoritative docs via RAG.

Use these patterns, adapt like a mad scientist, and remember: the best prompt is the one that produces code you can run in five minutes and understand in five more.

---