Stop Prompt Engineering — Just Describe the Problem

Traditional prompt engineering involves creating detailed instructions upfront — defining roles, specifying output formats, anticipating edge cases — all before seeing a single line of output. This method is fundamentally flawed because it relies on guesses rather than actual outcomes.

You are an expert React developer with 15 years of experience.
Using TypeScript strict mode, create a reusable data table
component with sorting, filtering, and pagination.
Follow the compound component pattern.
Use generics for type safety.
Include proper error boundaries.
Use Tailwind CSS for styling.
Ensure WCAG 2.1 AA accessibility.
Add comprehensive JSDoc comments.
[...200 more words of instructions...]

Make me a data table component.

Then complain about what's wrong.

The "careful" prompt took ten minutes to write. It still produced output that needed three rounds of corrections. The short prompt got to the same place in two messages — because the corrections you write after seeing output are always more precise than the instructions you write before.

Iterative feedback outperforms upfront specification for three concrete reasons:

The most common mistake when giving feedback is telling the AI what to do instead of what is wrong. When you prescribe the solution, you are doing the model's reasoning for it — and often getting in its way.

| Prescribing a solution (weaker) | Describing the problem (stronger) |

|---|---|

| "Add IndexedDB caching with a 5-minute TTL" | "This breaks when the user goes offline" |

| "Use a try/catch and set error state" | "The app crashes silently when the API is down" |

| "Add debounce with 300ms delay" | "The search fires on every keystroke and hammers the server" |

Describing the problem gives the model room to pick the right approach. If your codebase already uses a service worker for offline support, prescribing IndexedDB might actually conflict with it. Describing the problem lets the model use what is already there.

This feels counterintuitive, but expressing genuine frustration or enthusiasm gives the model useful signal about severity and priority. You are not just describing a bug — you are communicating how much it matters.

The second version communicates: this is blocking, it affects user trust, and it should be prioritized. The model calibrates accordingly — treating it as a correctness issue, not a polish item.

Emotional framing works in the positive direction too. "That's exactly the pattern I wanted — do the same for the other three endpoints" is clearer than "apply this pattern to the remaining endpoints." The enthusiasm signals the approach should be preserved, not improved upon.

When you want a style or tone shift, showing a before/after is faster and more accurate than describing it abstractly. The model can pattern-match on concrete examples where abstract descriptions can be misinterpreted.

"Make the error messages more user-friendly."

"Right now it says 'Error: ENOENT: no such file or directory, open /tmp/upload-1234'. It should say something like 'We couldn't find that file. Try uploading it again.'"

The contrast example locks in the register, the length, and the level of technical detail you want — none of which "user-friendly" communicates on its own.

Use contrast whenever you want to shift tone, verbosity, or phrasing style. It removes ambiguity that adjectives like "simpler," "cleaner," or "friendlier" consistently leave open.

Here are three complete feedback loops showing natural-language complaints producing correct output faster than upfront specification.

• Round 1: "Write a function to validate email addresses."

- Output: A 40-line function with regex, error classes, domain validation, and internationalization support.

• Round 2: "Way too much. I just need a basic sanity check — does it have an @ and a dot? 3-4 lines max."

- Output: A clean 3-line function.

The complaint was faster than specifying "minimal" upfront because you didn't know how verbose the output would be until you saw it.

• Round 1: "Create a modal dialog component."

- Output: Built with vanilla JavaScript and CSS.

• Round 2: "No — we use Radix UI. We already have @radix-ui/react-dialog installed."

- Output: Rebuilt using the Radix primitive with your project's design tokens.

One sentence correction. No upfront specification could have prevented this because the mismatch only became visible once output existed.

• Round 1: "Add a caching layer to this API."

- Output: Redis-based caching with a new npm dependency.

• Round 2: "We don't use Redis. Use the existing Convex query cache pattern from lib/cache.ts."

- Output: Refactored to use existing infrastructure.

• Round 3: "Good. But TTL should be 5 minutes for this endpoint, not the default 60 seconds."

- Output: TTL parameter updated.

Three rounds. Thirty seconds of feedback. A template could never have encoded "use the cache pattern from lib/cache.ts" — that knowledge only exists once you've seen the wrong output.

Not all feedback produces the same quality of correction. Here is the pattern:

| Ineffective | Effective | Why it matters |

|---|---|---|

| "The error handling is wrong" | "Wrap the fetch in try/catch and show a toast on failure" | Specifies location and desired behavior |

| "Make it look better" | "Match the card style from components/ui/Card.tsx" | Gives a concrete reference point |

| "Use a better pattern" | "This needs to work offline — no external network calls" | States the constraint, not the solution |

| "That's not right" | "No external dependencies — use what's already in the project" | Makes the exclusion explicit |

The common thread: effective feedback is specific enough that there is only one reasonable interpretation of what needs to change.

Iterative feedback is not always the right tool. Upfront specification adds value when feedback loops are impossible or expensive.

The key insight: even these detailed prompts are built from iteration. You ran the task manually first, complained your way to the right output, and then codified the working approach. The prompt is a distillation of feedback — not a replacement for it.

There is a lifecycle to good instructions that most developers miss:

1. Session 1: You complain: "Don't use console.log — use our logger at lib/logger.ts."
2. Claude saves to memory: "User prefers lib/logger.ts over console.log."
3. Session 5: You notice every new developer makes the same mistake. This should be a project rule.
4. You add to CLAUDE.md: Use lib/logger.ts not console.log in production code.
5. Every future session: Every developer on your team gets this rule applied automatically.

Your complaints become your team's engineering standards. The feedback loop is not just about one conversation — it is institutional knowledge building in real time. The most valuable entries in any CLAUDE.md file started as someone's frustrated correction in a chat window.

The workflow in practice is faster than it sounds:

1. State what you want in one plain-language sentence (5 seconds)
2. Scan the output for the first thing that is wrong (10 seconds)
3. Describe that problem specifically using one of the three techniques (5–10 seconds)
4. Repeat until the output is mergeable (usually 2–3 rounds)
5. Move on — don't chase perfection

Total time: 30–90 seconds. This compares to 10+ minutes crafting a "complete" prompt that still requires the same number of corrections.

The key discipline is scanning for the first thing wrong, not cataloguing everything at once. Giving the model one problem at a time produces cleaner corrections than a list of six issues in a single message.

This approach scales across every AI coding tool, not just Claude:

• Claude Code (terminal): Type your complaint directly. "The types are wrong — user.id is a string here, not a number" is a complete correction.
• Cursor: Use inline edit mode with a one-line description of the problem. No multi-paragraph prompt needed.
• Copilot Chat: Reference the specific line and describe what is wrong, not what the fix should be.
• ChatGPT/Claude.ai: Paste the output, say what's wrong, and ask it to redo the specific part that failed.

In each case, you are having a conversation — not submitting a specification. The interface is different; the technique is the same.

Stop iterating when:

• The code works correctly for your actual use case
• The style is close enough to your project's conventions
• You would spend more time describing changes than making them yourself

Keep iterating when:

• There is a correctness issue (wrong logic, security problem, broken types)
• The approach conflicts with your architecture in a way that will compound
• The code introduces patterns that will need explaining to every future reviewer

The target is "good enough to merge," not "would pass a code review at Google." Knowing when to stop is the last skill in the stack — and often the hardest to develop.

1. Start simple. One plain sentence beats a ten-line prompt. See what you get, then correct it.
2. Describe problems, not solutions. Let the model pick the approach — you decide which approach it picked.
3. Use emotional framing. Severity and enthusiasm are useful signals, not noise.
4. Use contrast examples. Show before/after when you want a style or tone shift.
5. Reference existing code. "Match lib/auth.ts" beats a paragraph explaining authentication patterns.
6. Codify what works. Repeated complaints become CLAUDE.md rules, memory entries, and team standards.
7. Stop when it's mergeable. Perfect is the enemy of shipped.

The old mental model: "I need to write the perfect instruction to get the perfect output."

The new mental model: "I'll describe what I want, see what I get, and steer from there."

This is not laziness. It is applying the model's actual capability — adapting to natural language feedback — instead of working around it with elaborate upfront structure. The AI is a collaborator that responds to conversation, not a compiler that executes specifications.

Stop engineering prompts. Start having conversations.