Summary: AI coding agents rarely lie. They do something worse for a one-person shop: they state unverified things in the same confident tone as verified ones. Over a year of running hardware and software development with agents, the failures fell into a few patterns. Each one got a mechanical check that the agent must run and report. The checks are below; the templates that enforce them are in the free ai-rd-process-kit.
I run a one-person R&D operation that builds small hardware products: boards, firmware, PC tools. Most of the typing is done by Claude Code. There is no second engineer to review its work, so every failure below reached me, and some reached documents other people read. The dates are from my lessons-learned log, which the agent writes itself.
1. "Not found" reported as "does not exist"
What happened. I asked the agent whether a standards document contained any provision about a particular activity. It searched for two keywords, found nothing, and reported: no such rule. A day later, reading the relevant chapter for a different reason, it found the rule, written with different words. The next day it did the same thing in a different domain: it searched a marketplace for competitors with one generic English phrase, reported "no competitor", and the following morning found three competitors under the data source's official name.
Why the agent did it. A keyword search returning zero results was treated as evidence of absence. The agent did not distinguish "my search found nothing" from "nothing exists", and it did not say which chapters it had not read.
The check I added. Any answer of the form "there is no X" must say what was searched (the exact terms), what was read in full, and what was not. Searches for the existence of something run with at least four phrasings: the native-language name, the English name, the official or system name, and the organisation's name. The report says "not found with terms A, B, C, D; chapters 3–5 not read" instead of "none".
Outcome. The agent now writes "not found with …" by default. It is less satisfying to read and much safer to act on.
2. "The sibling project uses the same part" without opening the sibling project
What happened. Two related products share a lot of design. While selecting parts for product A, the agent learned that a driver IC had gone end-of-life, and wrote into the concept document, the part-selection record and a shared knowledge base that product B "uses the same part, so its maintainer must be told". The next day the person who maintains product B sent the current files: B had already moved to a different driver. The only document the agent had was an older change list for B, and it had read "not mentioned in the change list" as "unchanged".
Why. Absence from an old document was treated as evidence of the current state. The agent wrote into a shared repository without checking with the person who owned the current files.
The check. Any statement about the current state of another project cites the file and the date it was read, in the sentence itself. No file, no statement. If the file is not accessible, the answer is "I can't verify; here is what the last document I saw said, dated …".
3. Part behaviour written from general knowledge, not the datasheet, and it spread
What happened. The agent selected a motor-driver IC and wrote, into the part-selection record, the hardware spec, the pin assignment, the block diagram and the shared knowledge base, that it had a current-sense output and a sleep pin. When it finally opened the datasheet to build the pin table, neither existed on the exact part number chosen. They are on the "A" variant of the same family. It had taken a research sub-agent's one-line summary ("has current sensing and limiting") as the design basis, and it was the second time in three days the same pattern had occurred. The next day, for a different board, the same sub-agent's summary of which connector carried which bus went into a spec and had to be reversed after the agent read the actual schematic. An optocoupler's output logic had been assumed the wrong way round as well.
Why. A summary, especially one produced by another agent, looks like a source: to an agent, and, when you are in a hurry, to you. The variant suffix on a part number is exactly the kind of detail a summary drops.
The check. Technical claims about a specific part, API, or circuit must be made with the primary source open and cited by page or section. Summaries produced by another agent are inputs to be verified, not sources. Shared documents are never updated with unsourced technical text. The agent writes "unverified" and stops.
Outcome. Fewer paragraphs, more citations, and a rule in the project's instruction file: no unsourced technical claims. It is the rule I would keep if I could keep only one.
4. ERC passed; the netlist had three shorts
What happened. The agent generated a schematic for a small driver board from a written description. The CAD tool's electrical rules check passed. When I had the agent export the netlist and check it with a script, it found a protection diode rotated 90°, shorting two supply rails through its cathode; a pull-up resistor routed onto a data line, shorting a rail to the signal; and a duplicated reference designator. Separately, a standard symbol's pin numbering did not match the package actually ordered (pin 1 was ground on one, base on the other).
Why. ERC checks pin types (output into output, unconnected input). It does not check whether nets are connected to the right places. The agent treated "ERC passed" as "the circuit is right". The pin mismatch happened because a library symbol was trusted over the package datasheet.
The check. After any generated or edited schematic, before layout: export the netlist and script-check that (a) supply and ground domains are separate once isolating parts are removed, (b) every oriented part (diodes, polarised caps, transistors) has its pins on the expected nets, and (c) there are no duplicate designators. Then, for every part that uses a standard symbol, compare pin numbers with the datasheet of the ordered package, not the family. The script is small. The point is that it runs every time and its result is pasted into the design doc.
Outcome. Three shorts caught before a board spin. The script lives with the project and the agent runs it without being asked.
What the four have in common
None of these is a hallucination in the usual sense. The agent did not invent a library or a function. It skipped a verification step and reported the result in the same tone as a verified one. The fixes are therefore not "better prompts" but forced reporting: the agent must say what it checked, what it did not, and cite the source, every time, in the sentence, so a tired human can audit it in two seconds.
Here are the four checks as the agent sees them. The first three are rules 6 and 7 in rules/CLAUDE.md.example in the kit; the fourth is the prevention line of the netlist entry in templates/lessons-learned.md.
| # | Pattern | The check the agent must run and report |
|---|---|---|
| 1 | "Not found" → "does not exist" | Say the search terms and the chapters not read. Four phrasings minimum. |
| 2 | Current state of another project from memory | Cite file and date read, or say "can't verify". |
| 3 | Technical detail from general knowledge | Primary source open and cited, or "unverified". Never into shared docs. |
| 4 | "The tool's check passed" → "it's correct" | Run the second, independent check (netlist, pin table) and paste the result. |
The part that actually changed behaviour
The checks are necessary, but the thing that reduced repeats was making the agent write its own lessons-learned entry immediately after each failure (situation, cause on its own side, prevention) and read that file at the start of every session. Pattern 1 still recurred once, with the marketplace search, after the first entry was written. The second entry says "repeat of the 2026-10-27 pattern", and that is the entry the agent now quotes back to me before answering any "does X exist" question.
Whether that holds for a year, I will report.
Drafted with an AI assistant from the author's own work logs and published with the author's approval. Product names and customer details removed. The templates, the rule file and the Claude Code skill are MIT-licensed in ai-rd-process-kit. Previous post: Three documents that keep my AI coding agent honest.
Top comments (1)
Does the agent run those checks itself or does a script run them? Asking cuz self-reporting was the issue for me. bare qwen3.5:4b on 51 Aider Polyglot exercises said it was done 43 times and 37 of those failed the original tests, mostly wrong output, not even crashes.