Repeated agent mistakes
Why your coding agent keeps making the same mistake.
A coding agent does not remember last week’s fix. The correction lived in a chat that ended, and the next session starts from the code, which shows the fix but not the mistake it prevents or why it matters.
- The fix
- Visible in the code
- The mistake
- Gone with the chat
- Why it matters
- Nowhere near the file
- A test that guards it
- Only if someone wrote one
A lesson that is not attached to the file it protects rarely reaches the next edit.
The correction lives in the chat.
Each new session, each switch to another agent or model, and each long session that gets summarised starts without the corrections you made along the way. The agent is not ignoring you; it never saw them.
Notes files help, but only for the lessons someone remembers to write down, and only if the agent reads the right note at the right moment.
Make the lesson reachable from the file.
Whatever tools you use, a lesson sticks when it is attached to the code it protects and checked when that code changes.
- Write a regression test for every fix you do not want to see undone
- Record the symptom and the files the bug lived in, not only the fix
- Keep that record next to the code, not in a chat or a ticket
- Make sure the next change in that area runs the test that guards it
How Kaplira keeps the lesson.
When a governed run closes as a fix, Kaplira records the known error: the symptom, the files it lived in, and the checks that guard it. The next time an agent is about to touch those files, it gets that error first and is asked to acknowledge it.
The record comes from how each run is closed, not from a document you write separately, and you delete what turns out to be wrong. Kaplira does not guarantee the mistake cannot happen again. It makes sure the next agent is told before it edits.
Continue exploring
CLAUDE.md ignored
Why rules get skipped, and how to put the ones that matter in front of the edit.
02.md file sprawl
What to keep in your agent’s notes, what to cut, and what to stop writing by hand.
03Regression prevention
Carry known errors, guardrails, and required tests into the runs that follow.
04Architecture drift
Bring architectural boundaries into the run, then review the changed responsibilities.
Governance is easier to judge on a real run.
The desktop app is free, no signup is required, and the run record stays on your machine by default. Tell me which part of your review actually needs proof — that is what decides what gets built next.
Governance applies to integrated workflows that use the project contract. It does not replace your executor’s sandbox, access controls, tests, or human review, and it does not guarantee correct code. Read the run evidence and security boundaries to see what the record proves.