The prompts that survive contact with real codebases

Prompt guides love greenfield demos. Real work happens in codebases with five years of history, three naming conventions, and a module everyone’s afraid to touch. Here are the prompt patterns that survive that.

1. Point at the code, don’t describe it

Weak: "Add validation to the signup form."

Strong: "In app/auth/signup.tsx, add email validation matching the pattern already used in app/auth/login.tsx. Follow the error-display convention from components/FormError.tsx."

Agents do dramatically better with file paths than descriptions. Every vague noun ("the signup form," "the usual pattern") is a guess you’re forcing. Names of files are facts; descriptions are interpretations.

2. State the constraints before the task

Agents optimize for completing the request as stated. If you don’t state the constraints, they don’t exist:

• "Don’t add new dependencies."
• "Keep the change under 100 lines."
• "Match the existing error-handling style, check lib/errors.ts first."
• "This table has 40M rows; the migration must not lock writes."

The best prompt engineers aren’t clever with words. They’re thorough with constraints.

3. Ask for a plan on anything non-trivial

For changes touching more than two files: "Propose a plan first. Don’t write code yet." Review the plan, correct the misunderstandings (there will be some), then say go.

This feels slower. It isn’t; it’s the review you’d do anyway, moved before the work instead of after. Catching a wrong approach in a plan costs a paragraph; catching it in a 400-line diff costs an afternoon.

4. Give it the failing state

"It’s broken" produces guesses. This produces fixes:

• The exact error message and stack trace
• The reproduction steps (or the failing test)
• What you already tried

Debugging prompts are information-delivery problems. The agent can’t see your screen, so put your screen in the prompt.

5. Demand the boring parts explicitly

Agents skip what you don’t ask for. End significant prompts with an explicit checklist:

"Include: tests for the new behavior, updated docs if the API changed, and a note on what you deliberately didn’t handle."

That last clause, asking what it didn’t handle, is the highest-value sentence. It forces the agent to surface its own blind spots instead of silently shipping them.

6. Iterate on the prompt, not just the output

When the agent gets it wrong twice, the problem is usually the prompt, not the model. Ask yourself:

• Was there an unstated assumption? (State it.)
• Was there a missing file reference? (Add it.)
• Was the task actually two tasks? (Split it.)

Prompting is debugging your own instructions. Get clinical about it.

The meta-pattern

Every pattern above is the same idea: replace interpretation with specification. Demos reward clever phrasing; real codebases reward precision. The engineers getting the most from agents aren’t prompt poets, they’re the ones who write the clearest tickets.