Writing Prompts That Get Real Development Work Done

The failing pattern: terse commands

"Fix the bug in the login flow."

What the model receives: a task, no context, no constraints. It guesses. The guesses are sometimes right, often close, occasionally disastrous.

The working pattern: brief like a colleague

You would never tell a new engineer "fix the bug" and walk away. You would say: here is the bug, here is what we tried, here is what we ruled out, here is the constraint, here is the file to look at first.

"Fix the login flow bug where users get redirected to /login after a successful POST. I already checked the session cookie is being set — verified in Network tab. I think it is the middleware at middleware.ts:18 returning early. The matcher config excludes /api/auth but maybe not the redirect. Start there."

Same model, different result. The prompt gave it a starting point, a hypothesis, and things to skip.

Include the evidence, not a summary of it

Paste the actual log line, actual error, actual config snippet. Summarizing loses the details the model needs.

"It throws a TypeError."

versus

TypeError: Cannot read properties of undefined (reading 'headers')
    at middleware (middleware.ts:18:22)
    at NextRequestHandler (…)

The first is a label. The second is an address.

Say what you want the output to look like

"Find the bug and suggest a fix."

versus

"Find the bug. If you are confident, apply the fix and run the tests. If you are unsure, stop and ask before changing anything."

The second sets a policy. The model follows it. No more surprise rewrites.

Use file paths and line numbers

Prompts that name src/auth/session.ts:42 outperform prompts that describe "the session code." The model reads the file, not your mental model of it.

Constraints beat prohibitions

Telling the model "do not add comments" works. Telling it "the code style here uses no comments except for non-obvious whys — match that" works better because it explains the rule. The model can then apply judgment in edge cases.

Don't delegate understanding

"Based on your analysis, refactor the service."

This pushes the synthesis onto the model. Output quality drops because the model does not know what you learned from its analysis. Instead:

"Your analysis showed the service has three tightly-coupled concerns — auth, billing, emails. Extract billing into its own module at src/billing/. Keep the public API the same. Skip auth and emails for now."

Specific, scoped, based on a concrete outcome.

The sniff test

Before sending a prompt: could another engineer on your team start from it cold? If not, the model is working with less too. Add what they would need: file paths, the failing command, what you tried, the constraint you are operating under.

That is the whole craft. Prompts are briefings, not commands. Brief well, and the model delivers work that is actually useful — not impressive demos, but work.