I asked AI to check AI. It cost more, caught nothing, and broke good articles.
I run a few product sites where AI writes the articles. Power stations, gear, that kind of thing. The articles go straight into the site's Git repo as MDX.
Product articles have one job. Get the specs right.
Battery capacity. Number of ports. Charge time. One wrong number and the article is useless. Worse, it's confidently wrong, and readers notice.
So I did the responsible thing. I added an AI fact check.
Every article got researched on the web. Every claim got checked against the research. If something didn't match, the check blocked the article or tried to fix it.
Sounds great, right?
Eight PRs of whack-a-mole
It kept blocking good articles.
I patched it. It found a new way to be wrong. I patched that. It found another one.
8 PRs in a row. Each one fixing the last false alarm.
At some point I stopped patching and did what I should have done on day one. I replayed the check over everything I had saved. 1,075 lines from real articles.
The result:
- 0 real errors caught
- 8 false alarms
- 3 "auto-fixes" that turned a correct line into a wrong one
Read that again. It caught nothing, and it broke more than it fixed.
And the bill? 61% of what the check cost was the web research step. Most of what it found was data already sitting in the product catalog.
So I was paying one LLM to go find numbers I already had, so a second LLM could compare them with numbers a third LLM had typed.
That's not quality control.
That's an expensive game of telephone.
Stop letting the LLM type numbers
The fix wasn't a better checker.
The fix was taking the numbers away from the LLM.
Before, the writer produced prose with the numbers baked in:
The SOLIX C300 has a 288Wh battery, enough for a laptop and a few phones.
Now it writes a variable instead:
The SOLIX C300 has a <Spec item="power-stations/anker-solix-c300" field="specifications.capacityWh" />Wh
battery, enough for a laptop and a few phones.
The real value gets filled in from the catalog on save, preview, export, and push. The field is just a path into the item's JSON (every site's catalog looks different, so it has to be flexible).
The rule is simple:
The catalog is the source of truth. The LLM writes the sentence around it.
If a number is wrong, it's wrong in exactly one place. Fix it in the catalog, and every article is fixed.
"Okay, but what if I check the catalog instead?"
Yes. I tried that too. Smaller scope, same idea: compare each catalog item with the manufacturer's page.
First live run: 5 products, $0.85 (that's $0.17 per product), 10 differences flagged.
5 were real. I fixed them by hand.
The other 5:
-
LFPvsLiFePO4. Same battery chemistry, different name. - A 0–80% fast-charge time compared with a full charge.
- A group of USB-C ports read as one port.
Every one of those is fixable with a special case. And I already knew how that story ends. Every special case exposes the next edge case.
Same trap. Smaller scale.
I deleted that one too.
Where an AI check still makes sense
To be fair, this isn't a "never let AI check anything" post.
The catalog check did find 5 real mistakes. Catalogs that were written fast (especially by AI) are exactly where errors sneak in.
So if I ever bring it back, it'll be a one-time check when a catalog is first imported. Run it once, show the differences, let a human decide. Not a robot that runs on every article and edits things on its own.
What I'd do if you're building something similar
- If a fact exists as data, insert it. Don't ask an LLM to restate it.
- Before you patch a check, replay it over all your saved data. One live failure tells you nothing about the rate.
- Count the cost per catch, not just the cost per run.
- Make deleting a feature an option on the table, not a failure.
So, was it worth it?
Here's my honest answer.
The check made the product feel safer. The variables made it actually safer.
The final diff was +147 / −12,852 across 79 files. Less code, lower bills, and the articles got more accurate.
Don't make the AI remember the facts. Make it impossible to get them wrong.
(All of this happened while building NichePressa, the engine that writes those articles and commits them to the repo. If you run a Git-based blog, that's what it's for.)
Where do you draw the line between what the LLM writes and what has to come from data? I'd love to hear how you handle it. Drop it in the comments.
Top comments (2)
0 real errors caught and 3 auto-fixes breaking correct lines across 1,075 lines is the stat that kills it. The catalog check finding 5 real errors in 5 products suggests the checker was not useless, just pointed at the wrong layer.
Exactly. That’s the part I underplayed in the post.
The per-article check was looking at prose that came from the catalog. So when the catalog was right, it had nothing to find. And when the catalog was wrong, it agreed with the wrong number, because it was checking the article against the same source.
The 5 real errors were all in the catalog itself. That’s where mistakes actually get in, especially when a catalog is filled in fast (or by AI).
The catch: precision was 50%, and half the flags were things like LFP vs LiFePO4. That’s fine when a human reviews 10 flags once, and terrible as an automated gate on every article.
So if it comes back, it’ll be a one-time check when a catalog is imported, with every difference shown for a human to approve. Right layer, run once, a human decides.