How I run a read-before-write rule with my AI agent
The thing my AI agent gets wrong most often isn't logic, it's editing a file it never actually read. One of the many rules I have for it is to read the file first, this session, before it changes anything, and not let it just promise it did.
The thing my AI agent gets wrong most often isn't logic, it's editing a file it never actually read.
It happens like this: I ask for a change, and the agent writes a perfectly reasonable-looking edit based on what it reckons is in the file, from the name or from something it saw two steps ago, or from not much at all. The file doesn't say what it assumed. Sometimes that blows up straight away and I lose ten minutes. Sometimes it's completely wrong and I only lose the afternoon to it later, which is worse, because by then I'm thinking about something completely unrelated and it's a genuine mental stretch to get back to what I was doing before.
So one of the many key rules I have for the agent, which is the kind of thing that sounds too obvious to bother writing down, is very simple:
Read the file before you change it.
Read it this session. Not from memory, not from the name, not "I think I looked at it earlier." If it's about to edit something, it reads the actual current contents first, and only then makes any changes.
The reason it's worth making a rule of is that an agent has none of the habits a person has. When I open a file to change line 40, I can't help seeing the 39 lines above it go past on the way down. The agent doesn't. It's just as happy producing an edit to a file it's only ever heard described as it is editing one it's actually read. That's because generating plausible text is the whole job, and a plausible edit to an imagined file is just as mathematically and probabilistically valid as an edit to the right file. That's the irritating (but predictable) part - the wrong version and the right version look identical right up until you run it.
The other thing I learned is that asking nicely doesn't hold. Whilst a line in the prompt telling it to read first works fine on a good day, it's exactly the changes you most wanted it to slow down on where it talks itself past the instruction. So I don't let it promise. If it's about to write to something it hasn't read this session, the write just doesn't happen, and it goes and reads first. A gate, not a guideline.
If you want to borrow the rule
You don't need my setup, and the specifics matter less than the idea anyway. The bits worth copying:
- Make it a hard stop, not a request. A line in a prompt is a suggestion the agent follows until it's inconvenient (if it even reads the full prompt). Something that refuses the write is a rule, and the gap between the two shows up very rapidly.
- "Read" means this session, not ever. "I read it earlier" is how the stale assumptions get back in. The file might have changed, and the agent's memory of it is lossy regardless. The only read that counts is the one that just happened.
- Make the failure cheap. When it trips, the agent should just go read the file, not get clever and route around it. A control that nags but doesn't actually stop anything trains everyone to ignore it.
- Read the neighbours too. The change is rarely contained to one file. Read the thing you're editing and the things that lean on it before deciding the edit's safe.
None of this is exotic, nor is it particularly clever. It just plays on how LLMs actually function, and helps compensate for the intrinsic shortcomings.
People assume the interesting part of working with an agent is the prompts, or the model, or the orchestration. For me it's mostly been boring rules like this one, wired in so they can't get skipped. The thing's fast and it's good and it's wrong often enough that I won't let it act on vibes. Reading the file first is just how I make sure that when it's sure of itself, it's at least sure about something real.