Blog · Lessons · 1 Oct 2026 · 3 min read
How to stop an AI agent from repeating the same CAD mistake
An AI agent forgets between sessions, so a lesson written as a note gets read and ignored. What works for us: every error becomes an executable rule with the command inside, numbers live in code, checks live in the producer, and debugging starts by stopping. The method behind months of CAD automation.
Short answer: turn every mistake into a rule of the form "if X happens, do Y", with the command that does Y written inside it. Put numeric values in the script as constants, not in prose. Put checks inside the program that produces the file, not in a document the agent may skip. And at the end of every session ask: would the next session, reading only what I wrote, make this mistake again?
Why notes do not work
An agent like Claude Code starts each session from what it can read: project instructions, skills, logs. A lesson written as a story is read and not applied. A rule without a command next to it is a reminder, not a rule.
The error log
We keep one file of errors, grouped by kind:
- measurement, verification, editing, order of steps,
- data, destructive actions, reuse, environment,
- closed roads: approaches tried and proven not to work, with the result.
The file ends with "the rules that sum it all up". Whoever adds a section adds its line there. A section without its summary line is a lesson no check will ever make anyone read.
Do not reference line numbers in a growing document. A line number is a lie with an expiry date.
The shape of a rule
| Error shape | Cure |
|---|---|
| Invented a value or name | Search the documents before writing |
| Estimated instead of measured | A measuring tool, run every time |
| Forgot a step | A test in the chain that fails without it |
| The user had to repeat something | A memory entry |
| A false number in a document | Remove it |
Numbers go in code. If a rule has a value (a tolerance, a gap, a text height), it belongs as a constant in the script that uses it.
Checks go in the producer. A guard that covers only one way of writing a file is a reminder. Put it where every write passes.
The debugging method
- Stop. A bug is solved by understanding the mechanism, not by running again.
- Re-read the code involved, including the lines you added: they are the most suspect.
- Write the chain: this input, these lines, this result.
- Look for signs the measure is broken: a uniform result on almost every case, a choice decided by noise, a default branch answering instead of a measurement.
- Run on one test sheet only.
- Read the logs on the topic in full before writing code. Many "new" problems were solved before.
Ask the session that made the mistakes
At the end of a session the agent reviews its errors. We found it works better to ask the working session directly how to make each error impossible, because the agent is not a reliable witness of its own mistakes when summarising later.
What it gives
The month-long dimension style bug in merged DXF drawings was rebuilt once more after it was fixed, because the lesson was written as a story. It is now a rule that starts with a question: "where were these dimensions made?"
Do and don't
Do
- Write "if X, do Y", with the command.
- Keep a list of closed roads.
- Put numbers in code and checks in producers.
- End each session by testing the rules against its errors.
Don't
- Don't write lessons as stories.
- Don't reference line numbers.
- Don't debug by rerunning with small changes.
Questions people ask
Does this only apply to CAD? No, but CAD makes it urgent: a repeated mistake is repeated on hundreds of parts, and every one looks normal.
Where do the rules live? In project instructions and skills that the agent reads at the start of a task, and in the scripts themselves. See how to check AI-generated CAD output.