DEV Community

Konstantin Konovalov
Konstantin Konovalov

Posted on

You Don't Need a Better Prompt. You Need a Brief.

Every few days someone asks me for the prompt that makes the model behave. The secret opener, the magic system message. I used to hunt for it too. It doesn't exist, and looking for it kept me stuck longer than it should have.

What actually moved my results was treating the model like a contractor I hired an hour ago. Fast, literal, no context about my codebase, and it will do exactly what I write down, including the parts I only meant.

Watch a vague ask fall apart

Say I want to parse a date out of some messy user field. The lazy version:

Parse the date from this string.
Enter fullscreen mode Exit fullscreen mode

The model returns something. It handles 2024-03-01 fine and quietly falls over on 1/3/24, or March 1st, or an empty cell. Not because it's dumb. Because "parse the date" didn't say which formats exist, what a two-digit year means, or what to do when there's no date at all. I had answers to all of those in my head. I just never wrote them down, so the model guessed, and its guess came from the average of the internet, not from my data.

Here's the same task as a brief:

Write a function parseDate(s) that accepts these formats:
YYYY-MM-DD, D/M/YY, and "Month Dth".
Two-digit years are 2000-2099.
Return null if the string has no recognizable date. Don't throw.
Return a Date object, UTC, time set to midnight.
Example: parseDate("1/3/24") -> 2024-03-01T00:00:00Z
Enter fullscreen mode Exit fullscreen mode

Same model. The output is now something I can actually check, because I said what "done" looks like and what the weird inputs are. That's the whole trick, and it isn't a trick.

The four gaps that ruin most prompts

When output disappoints me, I can nearly always trace it to a decision I made silently. So before I send anything, I check four things:

  • The input, and its ugly version. Empty, huge, wrong type, wrong encoding.
  • What happens when something's missing. Fail loud, skip it, or substitute a default.
  • What must not change. The signature, the existing behavior, the file I didn't mention.
  • What done looks like. One concrete input paired with the output I expect.

The last one carries more weight than the other three together. A single worked example pins down intent that a paragraph of adjectives never will.

The expensive failure nobody warns you about

The costly mistake isn't the model refusing or spitting out junk. You catch those immediately. The expensive one is the model helpfully fixing something you never asked it to touch. You said "add a field to this form," and it also tidied the validation, and two days later a different flow is broken and you have no idea why.

One line prevents it: say what stays put.

Add the phone field. Leave the email validation, the submit
handler, and the styles exactly as they are.
Enter fullscreen mode Exit fullscreen mode

Models are eager. Unbounded eagerness looks like helpfulness right up to the moment it rewrites a working thing. Naming the untouchables costs five seconds and saves the debugging session where you diff two files hunting for what moved.

Small steps you can actually verify

The other habit: stop asking for the whole feature at once. Not because the model can't produce it, but because you can't check it. One function with clear edges, you read and run in a minute. "The whole auth flow" comes back as a plausible wall of code that takes longer to verify than it would have taken to write. You didn't get leverage, you got a thing you can't inspect.

Break the work into steps small enough that each has an obvious pass or fail. Get one right, build on it. Slower to type, much faster to finish, because you're not unpicking a wrong assumption baked in three layers deep.

The point

If you tried these tools, got mush, and blamed the model, check the ask first. Most of the time the ceiling was the brief, not the model. The skill that matters now isn't clever phrasing. It's thinking one level more carefully about what you want and saying it in order: the input, the constraints, the thing that must not move, and one example of done.

Pick one annoying task and write it up that way. The output changes, and it won't be because the tool got smarter.


Written by the team behind AGINE Academy, an independent product by AGINE AI (not affiliated with Anthropic). We teach building with Claude by doing the work rather than watching lectures.

Top comments (0)