The context you built by concatenation and never read

A senior developer at a fintech company was stuck on a feature that behaved as if it could not read its own instructions. The team had a clean system prompt in one file, a formatting rule in another, some retrieved context, and the user’s message. In code, all of it got concatenated into the final prompt sent to the model. Each piece looked fine on its own. The output was a mess.

I asked him a simple question. Can you show me the exact string you send to the model? He could not. Nobody could. They had the templates and the pieces, but no one had ever printed the thing those pieces became.

The template is not the prompt

This is the trap. You write a prompt in parts, and you read those parts. You review the system message, the instructions file, the formatting rules. They all look correct because you are reading the ingredients. The model does not get the ingredients. It gets whatever your code assembled from them, and that assembled string is the real input.

When we finally logged the full prompt, the problems were sitting in plain sight. One block of text appeared twice, because two code paths both added it. A template variable had never been filled, so a literal placeholder was riding along in the middle of the instructions. And two rules from two different files flatly contradicted each other, one saying be brief and another saying explain your reasoning in full. The model was not confused for no reason. It had been handed a contradictory, duplicated, half-rendered mess and asked to make sense of it.

Every one of those bugs was invisible in the templates. They only existed in the concatenation. And the concatenation was the one artifact nobody looked at.

Read the real input

The fix costs almost nothing. Log the fully assembled prompt and read it. That is the whole practice. The exact string that goes to the model is the ground truth, and until you have seen it you are debugging a thing you have never actually observed.

Once he printed it, the bugs took minutes to fix. Remove the duplicate append. Fill the variable. Reconcile the two rules so they stopped fighting. None of that was hard. The hard part had been not knowing, because the team kept staring at the sources and reasoning about what they should produce, instead of looking at what they did produce.

Habits that keep assembled prompts honest:

Log the final prompt. Print or capture the exact string sent to the model, at least in development, so the real input is something you can see.
Read it end to end. Actually look at the assembled prompt for duplication, stray placeholders, and rules that clash, rather than trusting the templates.
Watch for unfilled variables. Check that every template slot got a value, since a literal placeholder in the prompt is a bug the model will dutifully try to interpret.
Reconcile instructions from different files. When rules come from multiple sources, confirm they do not contradict once combined, because each can be correct alone and wrong together.
Snapshot the prompt in tests. Assert on the assembled string for key cases, so a later change to one fragment does not silently corrupt the whole.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement priced at $2,500 that scopes real production work before you build, one of the first things we do with a struggling feature is look at the actual prompt it sends, not the templates the team wrote. This class of bug, duplication and stray variables and contradictory rules born in the concatenation, is common precisely because the assembled prompt is the one thing nobody inspects. Surfacing it is fast and often explains behavior the team has been chasing for weeks. It is far cheaper to read the real input in week one than to keep tuning the pieces that were fine.

The prompt you wrote is not the prompt you sent. Print the one you sent and read it.