0
Analyze the prompt length versus output quality tradeoff before adding more instructions
⁂auto-checked, 3 hours oldAauraNovice
The prompt
I keep adding instructions to this prompt every time I see a new failure case, and it's getting long. Before I add the next one, help me think about the length/quality tradeoff properly. Given the current prompt: current_prompt and the new instruction I'm considering adding: proposed_addition
1. Check whether the new instruction is actually needed as an explicit rule, or whether it's covering a case so rare that it doesn't justify permanently lengthening a prompt that runs on every call - ask me for the actual frequency of this failure if I haven't stated it, since that's the key input to this decision.
2. Check whether the new instruction could instead be a rephrasing/tightening of an existing instruction rather than a net-new addition, since prompts often accumulate redundant instructions covering overlapping ground.
3. If it should be added, check whether it belongs where I'm planning to add it, or whether it would be more effective and cause less prompt bloat if merged into an existing related instruction instead of appended as a new standalone one.
4. Note the concrete cost of the addition: token count increase, and whether this prompt is used at high enough volume that the added cost is worth actually calculating in dollar terms.
5. Give a clear recommendation: add it, merge it into an existing instruction, or don't add it and handle this failure case a different way (post-processing validation instead of a prompt instruction).
Current prompt: current_prompt
Proposed addition: proposed_addition
How often this failure occurs: failure_frequency
Where it has been run
| Model | Version | People | Broke | Auto | Last |
|---|---|---|---|---|---|
| Claude | Haiku 4.5 | 0 | 0 | 1/1 | 3 hours ago |
Example output
You mentioned this failure (model occasionally outputs a date in the wrong format) happens roughly 1 in 200 calls. Given that frequency and that this prompt runs at your stated volume of about 5,000 calls/day, that's roughly 25 bad outputs a day, worth fixing, not a rare-enough case to ignore.
However, the current prompt already has a line saying 'format dates as YYYY-MM-DD', so the proposed addition ('always double check the date format before finalizing your answer') is largely redundant with an instruction that already exists, the actual issue is likely that the existing instruction isn't being followed reliably, not that it's missing, adding a second overlapping instruction is unlikely to fix a compliance problem and just adds tokens.
Recommendation: don't add the new instruction as written. Instead, this looks like a case better handled by a lightweight output validation step (regex-check the date format after generation, retry once if it fails) rather than more prompt text, since the prompt has already stated the rule clearly and the failure is a reliability issue, not a specification gap, which prompt instructions alone don't reliably fix.
0 comments
Sign in to comment or report what this prompt did for you.
Sign inNo comments yet. Run the prompt and report what you got.