I will give you the exact words I typed. Here they are:
"Change the line where the timeout is set to use the environment variable instead of the hardcoded value."
Twenty words. One sentence. One task. I typed it in about four seconds, hit Enter, and went to make coffee. When I came back, the context window was almost full.
That prompt cost 80,000 tokens. The change I wanted needed only 3 tokens: swap one string literal for one variable reference. The ratio of tokens spent to tokens needed was about 26,666 to 1.
I did not understand what went wrong until I looked at the prompt word by word. That look became the start of everything I now know about prompting.
The model started reading files. It found a config.py with a timeout field. It found a client.py with a timeout on an HTTP request. It found a db.py with a connection pool timeout. It found a queue.py with a retry timeout. It found a server.py with a socket timeout. It found constants in constants.py and a settings object in settings.py.
For each one it asked: is this hardcoded? Is there an environment variable pattern here? Should I change this one? Should I change all of them? The model was not broken. It was doing what I asked. It was finding "the line where the timeout is set," and there were eleven such lines in my code.
Halfway through the context window, the model started making changes. It changed three of the eleven. Then it changed its mind. It rolled back one. It checked imports. It added an os.environ.get call. It wrote a helper function. I had not asked for a helper function. I had not asked it to touch imports. I had said "the line," and the model, seeing eleven options, chose to be thorough rather than ask.
That is what a thoughtful model does with a vague wish: it covers everything, picks nothing precisely, and spends a lot of tokens doing it.
After the incident I ran my original prompt through what would become the sinc diagnostic. I asked: which bands are filled, and which are empty?
PERSONA: empty. The model did not know what kind of engineer I am, what my code style is, or whether I like helper functions.
CONTEXT: empty. No file named. No function named. No hint about which timeout I meant. No information about the size of the codebase.
DATA: empty. No variable name. No current value. No environment variable name. No pattern from the rest of the project.
CONSTRAINTS: empty. No rule to touch only one file. No rule to leave other files alone. No rule against helper functions. No rule against changing imports. No rule to ask instead of guess.
FORMAT: not stated. No instruction to show a diff, a full file, or a short inline edit.
TASK: present, but very thin. "Change the line" with no pointer to the line.
Five of six bands were empty or nearly empty. I gave the model a task and nothing else. The model filled all the empty bands with its best guess. That guessing cost 80,000 tokens.
Here is the prompt I should have written:
PERSONA: Senior Python engineer, this codebase, no surprises.
CONTEXT: Pipeline project. File: queue.py, function: _build_client(),
line 47. Current value: timeout=30. Env var: QUEUE_TIMEOUT (int, seconds).
Pattern used elsewhere: int(os.environ.get('VAR_NAME', default)).
CONSTRAINTS:
- Touch ONLY queue.py, ONLY line 47.
- Do NOT modify any other file.
- Do NOT add helper functions or abstractions.
- Do NOT change imports if the os module is already imported; add it
only if missing.
- Do NOT touch any other timeout in this or any other file.
- If the os module is not imported, add ONLY: import os
FORMAT: Show the diff for line 47 only. One before line, one after line.
TASK: Replace the hardcoded integer 30 on line 47 of queue.py with
int(os.environ.get('QUEUE_TIMEOUT', 30)).
That prompt uses more words. But it spends far fewer tokens, because the model runs it in one pass. It finds the file, finds the line, makes the change, and stops. The output is a 2-line diff. Total spend: under 500 tokens. Savings: 99.4%.
The key is the CONSTRAINTS band. Each line of it is a wall. The walls stop the model from doing things it would otherwise try. Without walls, the model wanders. With walls, it walks a straight path from prompt to output.
I measured this across 275 prompts after building the sinc framework. CONSTRAINTS carries 42.7% of output quality. That is the biggest share of any band. FORMAT is second at 26.3%. TASK, which most people think matters most, carries only 2.8%.
That surprised me at first. It should not have. CONSTRAINTS tells the model what cannot happen. A model with no constraints searches a huge space. A model with clear constraints searches only the small slice where all the rules are met.
The math is multiplicative, not additive. The sinc SNR formula is:
If CONSTRAINTS is empty, the product goes to zero. It does not matter how good your TASK description is. The Genie has no walls, no limits, no fences. It will explore every corner of the space that technically fits your words. That exploration is what my 80,000 tokens paid for.
I think about that incident every time I start a new prompt. Before I write the task, I ask: what are the walls? What am I assuming the model will not do? What scope limit is in my head but not on the page?
Those missing pieces feel obvious to me because I know the code. The model does not. It does not know which timeout I meant. It does not know that other files are off limits. It does not know I want a diff and not a full rewrite. It does not know any of this because I did not write it down.
The lesson is not "be more careful." The lesson is that good prompting needs a framework, not just care. Without a framework, CONSTRAINTS stays empty. Filling it is hard. You have to think about what must not happen, and that is harder than thinking about what should happen.
The sinc format made CONSTRAINTS required. When I fill out a structured prompt, the CONSTRAINTS section sits there waiting. I cannot skip it. Every time I fill it in, I am building walls that keep the Genie on the path I chose, not wandering the open space it would find on its own.
Eighty thousand tokens taught me that. I have not paid that price again.
// 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 →