The Prompt Tinkerer¶

Tinkering endlessly with a prompt to prevent errors that structural controls would eliminate deterministically.

The pattern¶

Each time an agent makes a recurring mistake, the prompt grows: another sentence, another rule, another "IMPORTANT:" prefix. The prompt becomes a long list of prohibitions, and the agent still violates some of them. This is the Prompt Tinkerer anti-pattern — using probabilistic tools (instructions) to enforce things that need deterministic tools (structure).

Why prompts fail at enforcement¶

A prompt is not a contract. Instructions compete with each other, with context, and with the model's training distribution. IFScale across 20 frontier models found compliance drops to 68% at high instruction densities, with patterns ranging from threshold decay to exponential collapse. ManyIFEval calls this the "curse of instructions": all-rule compliance falls as per-rule accuracy raised to the rule count.

Adding "IMPORTANT:" or "NEVER do X" applies social emphasis to a system with no concept of social emphasis. Each new prohibition dilutes attention for the existing ones. A hook blocks a write regardless of what the model attended to.

Drew Breunig names this accrual "prompt debt" — a maintenance liability that, like technical debt, compounds and must be paid down. He cites Datadog and Berkeley evidence that enterprises stay on older models because newer ones break brittle hand-tuned prompts. His fix is eval-as-spec plus automated prompt optimization (Drew Breunig — The problem is prompt debt).

The escalation ladder¶

When an agent repeats the same error, apply this sequence:

Prompt — rephrase the instruction and place it closer to the relevant context.
Skill — encode the correct behavior as a reusable skill the agent invokes.
Hook — block the bad output at the boundary with a pre/post-commit hook or validation step.
Tool restriction — remove the agent's ability to perform the action entirely.
Accept and verify — if none of the above is cost-effective, add a human verification gate.

Stop at the step that eliminates the error.

When prompts are the right tool¶

Prompts work for guidance, not enforcement:

Use prompts for	Use structure for
Tone and style	Binary rules ("never delete files")
Approach selection	Output format enforcement
Creative direction	Security constraints
Interpretation guidance	Permission boundaries

If "correct" has a valid range of interpretations, prompts are appropriate. If the behavior must be exactly right every time, use structure.

Symptoms¶

The prompt contains more than 5 negation rules ("never", "do not", "avoid")
The same category of error recurs despite prompt updates
You have added "IMPORTANT:" more than once
You are explaining context in the prompt that should be in project files or skills

When this backfires¶

Escalating to structure has real costs:

No hook infrastructure: without CI/CD or tool-call interception, deploying hooks costs more than the error does. Prompt-only is the right call for throwaway scripts.
Interpretive tasks: binary enforcement on soft constraints (tone, approach, style) adds rigidity without a safety benefit.
Premature hardening: tool restrictions set too early block valid use cases that emerge during development.

Example¶

An agent keeps writing files outside the project directory. The developer adds prohibitions to the prompt:

# System prompt (attempt 4)
You are a coding assistant.
IMPORTANT: Never write files outside the /project directory.
IMPORTANT: Do not use absolute paths.
NEVER create files in /tmp, /home, or any parent directory.
Do NOT use "../" in any file path. This is critical.
Always check that your output path starts with /project.

The prompt now has five rules addressing the same failure, and the agent still occasionally writes to /tmp for intermediate work. Each rule competes with the others for the model's attention.

The structural fix replaces all five rules with a single hook:

# .hooks/pre-write.sh
#!/usr/bin/env bash
# Block any write outside the project directory
realpath="$(realpath --relative-to="$PROJECT_DIR" "$TARGET_PATH" 2>/dev/null)"
if [[ "$realpath" == ../* ]]; then
  echo "BLOCKED: write target $TARGET_PATH is outside $PROJECT_DIR" >&2
  exit 1
fi

The hook eliminates the error deterministically. The prompt can drop all five prohibition lines and replace them with a single sentence of guidance: "Write all output files inside the project directory."

Key Takeaways¶

Prompts are probabilistic; hooks, schemas, and tool restrictions are deterministic
Use the escalation ladder: prompt → skill → hook → tool restriction → verify
Prompts suit guidance with a valid interpretation range; structure suits binary correctness
A long prohibition list is a signal that structural controls are overdue