Prompt Patterns and Anti-Patterns

The core claim

The point of a prompt is to specify the task completely — not to cast a spell.

Those “magic phrases” you see online rarely do anything. What actually moves quality is information completeness and explicit constraints.

A structure you can copy

Task: [one sentence]

Context:
- [relevant fact]
- [relevant fact]
- [current state / problem]

Requirements:
1. [requirement]
2. [requirement]
3. Don't [explicit exclusion]

Done means: [how you'll verify]

Of the five parts, context and what not to do are the ones people skip — and the ones that matter most.

Five anti-patterns

1. Too short

❌ "Optimize this code"

Optimize for what — performance, readability, memory? You’ll get a rewrite that changed things you wanted left alone.

✅ "Improve performance in queryUsers:
     Currently it queries row by row; 1000 rows takes 3s
     Switch to batch queries; keep the signature and return shape
     Done means: 1000 rows under 500ms"

2. Bundling too much

❌ "Refactor + add tests + update docs + check for bugs"

One problem poisons the whole batch, and nothing is verifiable incrementally.

✅ Split into four promptable passes

3. No exclusions

AI leans toward doing a little extra. Without explicit exclusions it edits things you wanted untouched.

✅ "...don't modify code unrelated to this task, and don't add dependencies"

That one line will halve your diff review time.

4. Describing symptoms instead of pasting errors

❌ "It errored, says module not found"
✅ "npm run dev fails with: [full stack trace]"

Summarizing throws away file names, line numbers, and call chains.

5. No acceptance criteria

Done according to whom?

✅ "Done means: npm test passes and /login works manually"

Three techniques that pay off

Have it restate the task first

Restate what you’re about to do in your own words. I’ll confirm before you proceed.

Cheap to correct now; ten times more expensive after execution.

Give an example

When you can’t describe it, show it:

Match this format: [paste something you’re happy with]

Beats ten sentences of description.

Set the role and audience

You’re a frontend architect with 10 years of experience. Explain this to a developer in their first year.

Role sets depth; audience sets register. These are entirely different outputs.

Iterating mid-conversation

A bad first draft is normal. Effective follow-up:

❌ "No, rewrite it"
✅ "Direction is right, but section 3 is bloated — cut it to 100 words
     and add a concrete code example"

Say what’s wrong and what you want instead of a blanket rejection.

The test

Ask yourself: could I hand this to a colleague and have them start immediately?

If not, add what’s missing. That beats any trick you’ll read online.

Next

Common Error Troubleshooting.