I used to leave things out of prompts because I thought the model would know. I understood that LLMs predict the next token and have no persistent memory. But when I sat down to write a prompt, something odd happened: I wrote the main request and stopped, because the rest felt obvious.
The model has seen my previous messages. It knows the codebase. It can tell I want something short. It will avoid approaches I dislike. I did not think any of this out loud. I just felt it was obvious, so I did not write it down.
This is the habit of leaving things out. It goes deeper than laziness. It is a mistake about what kind of thing the model is. I was treating it like a person who shares my context. People who share your context do not need everything spelled out. You say "grab the thing" and your partner knows which thing. You say "make it cleaner" to a designer and they know what you mean because they know the project.
The model does not share my context. Every prompt starts fresh with no history. The model knows everything in its training data and nothing about me, unless I write it in the prompt. Bad outputs come from the gap between what I assume it knows and what it can actually see.
Here is the pattern made concrete. These are real prompts I wrote before I understood this problem, paired with what I should have written instead.
What I typed: "Review this function and suggest improvements."
What the model did: It rewrote the function with new variable names, new control flow, a different signature, and three paragraphs of explanation I did not want. It made the function better by its own idea of "better," which was not mine.
What I should have written: "Review this function for correctness and performance only. Do not suggest renaming variables. Do not change the function signature. Do not restructure control flow. Find bugs and O(n) or worse operations that could be faster. Output: a bulleted list of issues, each with a one-line fix suggestion."
The difference is the CONSTRAINTS band. The first version had none. The second names three things the model must not do and two things the output must have. With constraints, the model works in a narrow corridor. Without them, it searches the full space of possible improvements, including things I did not want at all.
What I typed: "Summarize this article in a few sentences."
What the model did: It wrote four sentences with hedging words, passive voice, and corporate language. Technically correct. Completely wrong for my use case: a short caption for a LinkedIn post aimed at engineers who hate corporate speak.
What I should have written: "PERSONA: Blunt technical writer who avoids corporate language. CONTEXT: This summary will be used as a caption for a LinkedIn post aimed at working engineers. CONSTRAINTS: Max 2 sentences. No passive voice. No words like 'innovative', 'leverage', 'holistic'. TASK: Summarize the key technical finding of this article."
Same task. Very different output. The model did not know the audience, the tone, the length, or the banned words. I assumed "a few sentences" implied all of that. It did not. I just wished it did.
What I typed: "Why is this function returning None?"
What the model did: It listed seven reasons why a Python function might return None. Generic and educational, with example code for each case. Useful for a beginner. Useless for me: I needed it to look at my specific code and find the missing return statement on line 34.
What I should have written: "CONTEXT: Here is the function [code]. It returns None when input is an empty list. CONSTRAINTS: Do not explain generic Python return behavior. Look only at this code. TASK: Identify the exact line or condition where None is returned when the input is empty."
In every case, the vague prompt invited the model to guess what I needed. In every case it guessed wrong. Not because it was a bad model. Because guessing was the only option it had.
When I measured quality across 275 structured prompts, I found that CONSTRAINTS accounts for 42.7% of output quality, more than any other band. More than TASK, which carries only 2.8%. More than FORMAT at 26.3%. More than PERSONA, CONTEXT, and DATA combined.
This surprised me at first. Then I thought about it from the model's side. The model's job is to complete the prompt in the most helpful way its training allows. Without constraints, "most helpful" expands to fill the entire search space. With constraints, "most helpful" means finding the best answer inside a tight box.
CONSTRAINTS is not a list of prohibitions for the sake of control. It is the shape of the task. It tells the model where the work ends. Without that shape, the model does not know where to stop. A task without a boundary is not a task. It is a blank check.
CONSTRAINTS is not a list of rules. It is the encoding of my expertise. Every constraint I write reflects something I know about what good output looks like here. "No passive voice" encodes what I know about the audience. "Touch only this file" encodes what I know about the codebase boundary. "Max 2 sentences" encodes what I know about the format.
When I leave CONSTRAINTS empty, I am not trusting the model. I am withholding my expertise from it. I am asking it to produce expert-quality output while hiding the expertise it needs to get there. That is unfair to the model and costly for me.
Everything I know about my project, my audience, my standards, and my preferences lives in my head. The model has access to none of it unless I write it in the prompt. This is the knowledge transfer problem. It is the main reason explicit prompting matters.
Think of it this way: every prompt is a transfer of knowledge. I have information the model needs. The model has skill I need. The exchange happens at the prompt. If I send incomplete information, the model fills the gap with its own defaults, and those defaults are generic, not specific to my situation.
The sinc format is a checklist for this transfer. It has six bands, each one a category of information the model needs. PERSONA carries the role context. CONTEXT carries the situation. DATA carries facts and references. CONSTRAINTS carries my expertise about what "good" means here. FORMAT carries the output shape. TASK carries the actual request.
When I fill all six bands, I have given the model what it needs to be precise. When I leave bands empty, I am hoping it will fill them from its defaults. Sometimes the defaults are close enough. Often they are not. And I have no way to know ahead of time which situation I am in, because the gap between what I assume and what the model can see is invisible to me until the output arrives.
When I started writing longer, more explicit prompts, I felt strange about it. It seemed like I was over-explaining, treating a smart system like it could not make basic inferences. I worried I was being too fussy.
I was wrong. Explicit prompting is not fussy. It is kind.
It is kind to the model because it gives the model what it needs to succeed, not just what feels sufficient to me. It is kind to me because it produces outputs I actually want, instead of outputs that need three rounds of fixes. It is kind to the conversation because the first response is usually the final one.
I stopped hoping the model would understand me. I started writing prompts that needed no understanding, only execution. The model does not need to understand. It needs to execute. Execution requires complete information. Complete information requires all six bands.
The habit I had to break was the hope. Not the laziness, not the good intentions: the hope that my unstated assumptions would somehow transfer. They do not transfer. They never did. I could not see the gap between what I assumed and what the model could see, so I mistook lucky guesses for real inference.
Write it down. All of it. Every constraint, every assumption, every boundary. The Genie cannot read between your lines. Write the lines.
// Production AI Engineering
sinc-LLM designs, audits, and stabilises production AI infrastructure: from vendor evaluation and cost accountability to incident controls and MCP architecture.
See what we do →