Tripwires: Tests That Catch Your Agent Making the Same Mistake Again

I Love My Coding Agent, But It Has No Memory and I Have a Grudge

Here's the loop I kept living in:

1. The agent introduces a bug.
2. I explain the bug. The agent fixes it. We both feel good.
3. Different day, fresh context, same agent, same bug.
4. I explain the bug again.
5. It fixes it again.
6. Three weeks later: the bug is back.

The memory is gone. Not degraded. Gone. And because the agent doesn't remember, the same mistake keeps arriving with the confidence of a first draft.

My first instinct was to write a better instructions file. That mostly didn't work, and I eventually figured out why. The thing that works is a tripwire.

What a Tripwire Is

A tripwire is a test whose entire job is to fire when your agent makes a mistake it has made before.

The pattern is four steps:

1. Step 1: Agent introduces a bug.
2. Step 2: You write a test that catches that specific bug, not the general category but the actual case.
3. Step 3: That test becomes a tripwire. Any future attempt that reintroduces the bug gets caught immediately.
4. Step 4: The agent sees the failing test and course-corrects before the mistake propagates into six other files.

Write a lot of these. Tests are cheap and agent attention is not. The agent's memory is fragile; the test suite is durable. Spend on the durable side.

"Write a lot of these" used to be expensive advice. It isn't anymore, because tests and docs are free now, which means the old instinct to ration them is a habit worth unlearning. The constraint on your test suite stopped being the typing a while ago.

Why Tripwires Beat Prompt Rules

You could add a line to your CLAUDE.md: "do not do X." I've tried. Here's what goes wrong.

The agent reads that note every time it boots, and it is one line in a file full of lines. It's competing for attention with forty other rules, none of which are relevant to the current task, and all of which look equally important. Instructions files degrade as they grow, which is an unfortunate property for a thing you keep adding to.

More importantly, a prompt rule doesn't encode the specific case. "Don't mishandle empty input" is a category. A tripwire says: here is the exact input, here is the condition under which it fails, here is what we expect instead. A future agent can read the test and reconstruct the whole constraint without anyone re-explaining it.

And tests run on their own. You don't have to remember to mention the constraint, notice it was violated, or be awake. CI runs the test. The tripwire fires. The constraint holds whether or not you were paying attention.

Agents Change and Memory Rots

This is the thing I keep coming back to.

The model you're using today will be updated or replaced. The session you're in right now will be gone. The context window you're working with will be cleared, compacted, or silently truncated at the least convenient moment.

What survives all of that: the test suite.

So the rule I use now is simple. If there's something I care about (a constraint, a pattern, an anti-pattern, a lesson from an outage) and it's not in a test, then it isn't durable. It lives in someone's head, and heads forget. Mine included, which is the part I resisted admitting for a while.

This is the same argument I make about what code review is actually for. A reviewer asking "will anyone understand this in six months?" and a tripwire firing on a regression are the same mechanism pointed at different failure modes. Both are ways of moving knowledge out of a head and into something that survives.

Try It on the Next One

Next time your agent makes a mistake you've seen before, don't explain it again. That's the reflex and it's the wrong one. You're spending effort on something with a three-week half-life.

Write the test instead. Make it specific enough that the failure message tells the next agent exactly what went wrong.

Then let the tripwire hold the line while the agent changes around it.

Header photo by Carla Quario on Unsplash.