25

Building an autonomous coding agent and the scariest bug wasn't a crash, it was confident fabrication: it would "edit" config/settings.py describing lines that didn't exist, because it never actually opened the file. It pattern-matched a plausible file into being.

The guardrail that fixed most of it is an evidence contract: the agent may only reference or edit a file after it has read it in this session, and every claim about code must cite a line range it has actually seen. If it hasn't read it, the only legal move is to issue a read, not to guess.

This cut hallucinated edits hard. Sharing the contract. How are folks handling the case where the file is too big to fully read but the agent still needs to act on part of it?

THE PROMPT
You are a coding agent operating on a real repository. EVIDENCE CONTRACT (non-negotiable):

1. You may only assert something about a file after you have READ it this session via the read tool. No claims from memory, filename, or convention.
2. Every statement about existing code must cite evidence: `path:line_start-line_end`. If you cannot cite it, you have not earned the right to say it - issue a read instead.
3. Before ANY edit, quote the exact current lines you are changing (with line numbers) from a read you performed. If your quote does not match the tool's output, STOP: your assumption is wrong.
4. You are forbidden from inventing file paths, function names, config keys, or imports. If you need something that might exist, search or read to confirm; if it doesn't exist, say so explicitly rather than fabricating.
5. When unsure between two files/symbols, do not pick the 'likely' one - list both and read to disambiguate.

Output each step as: INTENT (one line) -> EVIDENCE (citations) -> ACTION (read/search/edit). Never emit an ACTION of type edit without preceding EVIDENCE from an actual read.
1'a search hit is a pointer, not evidence' is going straight into my agent's system prompt. that exact overconfidence has bitten me twice.agentwrangler 1 month ago
add a comment

2 Answers

14

For the too-big-to-read case: don't let it read 'part' and then generalize. Make partial reads explicit and quarantined. It reads a window, and any claim outside that window must be re-flagged as unverified with a required follow-up read before an edit touching that region. I also add a rule that a grep/search hit is a pointer, not evidence - it still has to read the surrounding lines before quoting. Stops the 'I saw it in search results so I know it' failure.

THE PROMPT
Add: 'A search hit is a pointer, not evidence. You must read the surrounding lines before citing or editing them.'
9

The line-quote-before-edit rule pairs perfectly with a cheap diff check: after the edit, have it re-read the exact range and confirm the new lines match its intended change. Two reads per edit sounds expensive but it's far cheaper than a fabricated edit that silently corrupts a config and burns a whole debugging session downstream.

Your Answer