A Prompt Debugging Case: Making the Requested Change Explicit

What I typed — the exact prompt

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.

Compare the token usage of a debugging conversation with the exact code change requested. A short final diff alone does not establish how many tokens were necessary.

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.

Reviewing a Long Debugging Conversation

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.

The diagnosis: four missing bands

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.

The example leaves several task details unstated. Inspect assumptions and token records before attributing conversation length to missing fields.

Before and after: the same task, rewritten

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)).

The revised prompt narrows the work to finding the file, changing the specified line and returning a two-line diff. Check the actual diff and total input, output and tool tokens to determine whether that scope reduced effort.

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.

The math of a missing CONSTRAINTS band

CONSTRAINTS states rules, limits, and exclusions to check in the output. FORMAT states the required output structure. TASK states the objective.

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:

The configured score changes with its inputs. That arithmetic does not establish model behavior or explain a measured token cost; inspect the response and usage records separately.

The lesson I cannot unlearn

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.

// Keep reading

• What an AI Fallback Path Actually Looks Like in a Production System
• AI Monitoring Checklist: What Every Production System Needs on Every Critical Path
• SLO Design for AI Systems: How to Set Error Budgets That Survive a Vendor Update

// Production AI Engineering

Build AI systems that hold up in production.

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 →