Fact-Checking 109 Ingredients With Two AI Models Before Shipping
Stagioni is a seasonal produce app I built with a partner in southern Italy: it covers around a hundred ingredients across vegetables, herbs, nuts, pulses, and fruit, each with a nutrition breakdown, a chef’s tip, a food science note, and storage guidance. It’s live on Google Play, in English and Italian, with a free tier and two paid tiers behind it.
That last detail is the one that changed how I had to think about content quality. This isn’t a demo project where a wrong fact is embarrassing. It’s a published app making specific claims about nutrition and food science to paying users. If an entry says a compound does something it doesn’t, or cites a figure that’s been misremembered from somewhere, that’s not a typo. It’s misinformation with my name on it.
Where the risk actually was
The content had grown organically over several build sessions: 109 ingredient entries, 83 accompanying science and nutrition insights, written in batches as the app’s structure came together. Individually, every entry looked plausible. That’s exactly the problem with plausible-sounding claims: “looks right” and “is right” are not the same test, and I’d been the only one checking.
So I stopped adding features and ran the entire content set through two independent AI models across five rounds of back-and-forth review instead, each one briefed to hunt for factual claims rather than prose quality, and crucially, with no visibility into the other’s reasoning. Two different failure modes catch different things. A single reviewer’s blind spots are consistent, whoever that reviewer is: you miss what you habitually don’t think to check. Two independently-reasoning passes, checking each other’s work with no shared context, catch a different set entirely.
What actually turned up
Five rounds of back-and-forth surfaced a genuine list of fixable problems, not stylistic quibbles:
- A claim about pistachio trees that conflated two different biological cycles
- A blueberry health claim referencing a specific study population too narrow to support the way it was phrased
- An antioxidant capacity figure for cloves that had drifted from its actual measured value
- A cherry-and-sleep claim overstating what the underlying research actually showed
- A hemp seed omega-3 claim that needed a precise ratio correction, not just a rewording
None of these were dramatic. All of them were the kind of small factual drift that happens naturally when content gets written across multiple sessions without a systematic recheck, and every one of them would have shipped to real users if the process had stopped at “reads fine to me.”
Beyond the corrections, the pass also caught structural gaps the first draft had missed entirely: a handful of legacy entries that had never been expanded past a placeholder-level stub, and one ingredient, carrot, that had a science insight written for it but no actual produce entry. That’s an inconsistency a straightforward proofread wouldn’t have caught, because nothing about the existing text was wrong.
Why this is the more interesting lesson
It would be easy to frame two-model review as a coding technique. I’ve written elsewhere about using it for infrastructure changes. But the more useful realisation from this pass was that the same discipline applies anywhere a piece of content is making a factual claim a reader might act on, code or not. A nutrition claim in a mobile app and a security assumption in a script fail the same way: they look correct to the person who wrote them, because the person who wrote them is the one least likely to notice their own blind spot.
The fix in both cases is structurally identical: get a second, genuinely independent read before it ships, not a second glance from the same perspective that produced it.