Do What You Say Say What You Mean

A Practical Guide to Do What You Say Say What You Mean

The basic idea is straightforward, but most people fumble it in practice. When you give a language model an instruction, the gap between what you wrote and what the model actually does is usually wider than you expect. "Do What You Say Say What You Mean" isn't some fancy framework. It's just the discipline of making sure your input and your desired output are locked together tightly enough that there's no room for the model to interpret things loosely. I used to get frustrated when my prompts would produce results that were technically correct but practically useless. The model would follow the letter of my instruction while completely missing the intent. That's a classic alignment problem, and it's the core issue this whole concept tries to solve.

The Setup Method

Here's how I actually build prompts that land correctly the first time instead of requiring three rounds of back-and-forth. You start by writing the output you want, not the instruction you think you need to give. Look at a few examples of perfect outputs in whatever domain you're working in. Then you reverse-engineer the input that would generate something that close. The trick most people skip is negative constraint framing. Instead of only telling the model what to do, you explicitly tell it what not to do in the same breath. "Explain the concept, but do not use bullet points or headers, and keep the total word count under two hundred." That third clause alone prevents about half the common failure modes I see in practice.

The Definition People Actually Need

Do What You Say Say What You Mean means your prompt has zero ambiguity between the literal instruction and the intended outcome. It's achieved through specificity in three areas: format constraints, scope boundaries, and tone anchors. Leave any one of those out and the model will fill the gap with its own assumptions, which are almost never the right ones. Most beginner guides stop at "be specific." That's not actionable. Here's what actionable looks like. Instead of writing "Write a product description," you write "Write a 150-word product description for a wireless charging pad aimed at remote workers, using a casual but professional tone, structured in two short paragraphs with no bullet points." That's the difference between guessing and having a real conversation with the model.

A Real Edge Case That Broke My Workflow

Last year I was trying to get consistent JSON output from a model for a data migration script. Every time I ran it, the model would add trailing commas, include explanatory text outside the brackets, or vary its key naming conventions between camelCase and snake_case randomly. The output was technically valid JSON about half the time. The other half it would parse fine but the schema would shift between runs, which completely broke the downstream script I had written. The workaround was brutal but effective. I stopped asking for raw JSON and started asking the model to output a Python dictionary representation first, then explicitly instructed it to run json.dumps() on that dictionary before presenting the final result. I also pinned the exact schema using a strict example format in the prompt itself. That cut my manual cleanup time from about twenty minutes per batch down to maybe two minutes where I was just verifying field values instead of restructuring malformed output. It felt ugly at the time but it worked consistently. The model treats dictionary-to-JSON conversion as a mechanical step rather than a generative one, which removes a huge source of variability.

Common Pitfalls That Waste Hours

The biggest mistake I see is assuming the model reads your mind about context. If you reference a document, a previous message, or an implicit domain without stating it explicitly, the model will make a reasonable guess. Reasonable guesses are wrong more often than you'd think in technical work. Another trap is over-specifying without leaving breathing room. If you constrain every single variable, the model becomes brittle. Change one parameter and the whole output falls apart. You need to identify which constraints are hard requirements and which are preferences. Hard requirements go in the main prompt. Preferences can be handled in a follow-up refinement pass. Here's something counter-intuitive that took me months to internalize: sometimes giving the model a slightly worse example produces better results than giving it a perfect one. A nearly-perfect example forces the model to make the final adjustments itself, which engages its reasoning more actively. A perfect example lets it pattern-match and copy, which means it copies any quirks or edge-case behaviors embedded in that example too.

The Limitations Nobody Talks About

This approach works well for structured, well-defined tasks. It breaks down badly when you're dealing with genuinely open-ended creative work where the requirements shift mid-task or where the definition of success is subjective. You'll spend more time refining prompts than you save on execution. In those cases, iterative dialogue with the model is more efficient than trying to nail everything in one prompt. There's also a cost consideration. Highly constrained, specific prompts tend to be longer, which means more tokens processed and higher API costs. A well-crafted constrained prompt might be four or five times longer than a vague one. For a one-off task that's fine. For something you're running thousands of times through an automation pipeline, the token economy matters. If you're doing this at scale, I'd recommend building a small validation layer after the model output rather than trying to prevent every possible failure mode in the prompt itself. Catch malformed outputs, reject them, and retry with a clarified prompt. That's usually cheaper than optimizing the prompt to near-perfection for edge cases that only appear ten percent of the time.

Putting It Into Practice

Start with a single prompt you've been struggling with. Write down exactly what went wrong in the output. Identify whether it was a format issue, a scope issue, or a tone issue. Add the missing constraint type and test again. Don't rewrite the whole prompt. Just add one thing. See what happens. Repeat until the output matches your expectation consistently across at least five trials. The discipline here is noticing which constraint type is missing rather than assuming you just need to write a better prompt. Usually you need a more precise one.