Prompt Engineering Patterns for Code Generation

Most developers treat prompts as throwaway strings. Type something, hope for the best, retype when the output is wrong. That is the slow path. After six months of daily AI-assisted coding, I have settled on four prompt patterns that produce useful output on the first try.

Pattern 1: Anchor to an Existing File

The worst prompt is 'write me an API endpoint.' The best prompt is 'add an endpoint to src/routers/posts.py that follows the pattern of get_post.' Anchoring to a real file tells the agent what 'good' looks like in this codebase.

Pattern 2: Constrain the Output

I always specify the boundaries. Not 'write tests' but 'write three pytest tests in tests/test_posts.py covering the 200, 404, and 422 cases.' Three specific tests are faster to review than ten generic ones.

Pattern 3: Name the Failure Modes

If I know a common mistake, I mention it in the prompt. 'Do not catch all exceptions; let unexpected errors bubble up.' 'Do not add a new dependency; use the stdlib http.client.' Naming the failure mode prevents it.

Pattern 4: Demand the Smallest Diff

Agents love to over-refactor. I add 'make the smallest diff that accomplishes the goal.' The output becomes a surgical change instead of a file rewrite.

A Full Example

Add a slug uniqueness check to src/utils/slug.py. Follow the
pattern of the existing generate_slug function. If the slug
exists in the posts table, append a numeric suffix. Do not
add new dependencies. Make the smallest diff possible.

Four sentences. Each one removes a source of ambiguity. The output is usually correct on the first attempt.

The Anti-Pattern to Avoid

Do not prompt in stages like 'first build X, then build Y, then integrate them.' Agents lose context between turns. One prompt with the full plan beats three prompts that each forget the previous.

The Mindset Shift

Prompts are not conversation. They are specifications. Write them like you would write a ticket for a new hire: concrete, bounded, with examples. The more precision you add, the less rework you do.

Save Your Best Prompts

I keep a prompts.md file in every project. When a prompt works well, I paste it there with a one-line note about what it did. Over time, that file becomes a library of recipes. The next time I need a similar change, I copy the old prompt and adjust the specifics.

Read the Diff Before Accepting

Even with a perfect prompt, the agent occasionally misreads intent. The diff review is the last line of defense. I never accept a multi-file change without opening each hunk and reading it. That two-minute review catches almost every subtle error that slipped past the prompt and the tests.

See the Anthropic prompt engineering guide for deeper patterns that transfer to any code generation workflow.