I Ran the Same Photo Through 3 AI Models. They All Disagreed. Here's the Bug.

Mohit — Sun, 23 Aug 2026 18:01:56 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The Bug That Taught My AI to Say "I'm Not Sure"

The Project

I'm building AURA AI — a personal presentation, grooming, fitness, and lifestyle coaching app that analyzes a user's photos and lifestyle info to generate a personalized improvement plan. Before writing a single line of production code, I was stress-testing the "brain" of the app: the prompt that turns a few selfies into a structured, safe, evidence-based report.

To do that, I ran the exact same test — same photos, same lifestyle data, same instructions — through three different AI models: Claude, Gemini, and DeepSeek.

The Bug

The first few runs looked great individually. Each model produced a clean, confident report: skin texture notes, hair analysis, posture observations, a prioritized "what to improve" list.

But when I lined the three reports up side by side, something was off. The same input photos were producing different conclusions depending on which model I asked — and sometimes even between two runs on the same model. One report would call a shadow under someone's eyes "visible fatigue lines." Another, using a photo taken in different lighting, wouldn't mention it at all.

The models weren't malfunctioning. They were doing exactly what I told them: describe what's visible in the photo. The actual bug was upstream — in my inputs. My test photos varied wildly in lighting, angle, and distance, and the AI had no way to tell the difference between "this is a real feature of the person" and "this is a shadow because the bedroom light was warm-toned." It was confidently reporting photographic noise as fact.

That's a genuinely dangerous bug for an app that's supposed to give people advice about their own face and body — confidently-wrong output is worse than no output.

How I Found It

I built what I ended up calling a Problem Detection Engine: instead of trusting the AI's first answer, I made it run a self-audit checklist after every report, forcing it to answer PASS/FAIL on questions like:

Did I treat an inference as an observation?
Did I confuse a lighting artifact with a genuine feature?
Did I compare this photo to another under inconsistent conditions?

Running this audit across all three models is what surfaced the pattern. It wasn't one bad output — it was a systemic gap in how any model handles uncontrolled input photos.

The Fix

I fixed it in two layers, because patching the prompt alone wasn't enough:

1. Constrain the input, not just the output.
I wrote an explicit photo capture protocol into the pipeline — fixed camera distance (1.2–1.5m), eye-level angle, tripod-stabilized, consistent lighting — and replaced my inconsistent test set with a controlled one. Garbage in, garbage out applies just as much to vision prompts as it does to databases.

2. Make uncertainty a first-class output.
Instead of a binary "this is a feature," I added a confidence system: every observation now gets tagged LOW / MEDIUM / HIGH confidence, and anything with unreliable lighting or angle gets explicitly flagged as "not determinable" rather than guessed at. If the evidence is bad, the AI now says so instead of filling the gap with a confident-sounding guess.

The Code

Here's a simplified version of the confidence-tagging rule I added to the prompt, so the model flags uncertain observations instead of guessing:

For every visual observation, output:
{
  "observation": "<what you see>",
  "confidence": "LOW" | "MEDIUM" | "HIGH",
  "reason": "<why this confidence level>"
}

Rules:
- HIGH: clearly visible under consistent, even lighting
- MEDIUM: visible but lighting/angle introduces some ambiguity
- LOW: could plausibly be a lighting artifact, shadow, or angle distortion

If confidence is LOW, do not state the observation as fact.
Instead output: "Not determinable from this image — retake under
even, front-facing light."

This one rule is what turned "confidently wrong" into "honestly uncertain" — the exact fix the self-audit below confirms.

The Result

Re-running the same three models on the corrected photo set collapsed the inconsistency almost entirely — the reports agreed on what was actually observable, and openly disagreed (flagged as uncertain) on the handful of things that genuinely were ambiguous, instead of silently picking different answers.

What I Took Away From This

The most dangerous bugs in an AI product aren't the ones that crash — they're the ones that answer confidently and wrong. Cross-testing the same prompt across multiple models turned out to be a great debugging technique on its own: if three independent systems disagree on the same input, the bug usually isn't in any one of them — it's in what you're feeding them.

I'm still pre-code on the full AURA AI build, but this round of prompt-level bug hunting is exactly what's shaping how I design the real pipeline: validate the input before you ever trust the output.

Warm Hearth — A Landing Page Built Around One Fire

Mohit — Mon, 17 Aug 2026 06:16:34 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

Warm Hearth — a landing page for a comfort food restaurant built around one idea: everything on the menu comes from the same wood-fired hearth in the back.

Instead of treating "comfort food restaurant" as a generic brief, I anchored the whole page to that single hearth:

An interactive hearth centerpiece. Right after the hero, there's a hand-drawn CSS/SVG fire pit you can click to "stoke." The flame flares, embers burst upward, and a small honest counter tracks how many times you've stoked it this visit — no fake global numbers, just a real, session-based response to your click.
Four dishes, each with real cultural identity. Ramen, warm pies, a cheesy pasta bake, and gulab jamun — each with its own hand-drawn SVG illustration and a border motif pulled from its own cuisine (a jade-and-gold double line for the ramen, a scalloped pastry edge for the pies, an Italian tricolor accent for the pasta, gold paisley tones for the gulab jamun) rather than one generic card style stretched across all four.
Living detail, not static photos. Steam rises off the ramen, pies, and pasta bake using the same wisp animation as the hero's hearth, so the whole page reads as one consistent "warmth" language. The gulab jamun gets a syrup shimmer and drip instead, since steam isn't the right detail for a syrup-soaked sweet.
Price tags that hang like real kitchen tickets — pinned by a string, swaying gently, and giving a small "flicked" swing on hover instead of sitting flat on the card.
Mira, an illustrated host in the corner who offers a rotating table tip when you click her — a small personal touch instead of a static "contact us" widget.
Built for actual use, not just to look good in a screenshot: keyboard-focusable tab filters, a skip-to-content link, aria-live regions on the interactive parts, and full prefers-reduced-motion support that disables every animation without breaking the page.

Demo

Journey

Since I opened the hearth question yesterday, I stopped treating this as "a comfort food restaurant" and started treating it as "a restaurant that runs on one hearth" — that reframe is what changed everything. The dish illustrations, the steam animation, the stoke-the-fire interaction, even Mira the host all trace back to that one fire instead of being separate decorations bolted onto a generic template.

The part I'm proudest of is probably the smallest one — the price tags. Real kitchen tickets hang from a pin and string and sway slightly; giving them that same physics (idle sway, plus a decaying "flick" on hover) took more tuning than I expected, but it's the kind of detail that makes the page feel handmade instead of templated.

What I'd do next with more time: add a couple more dishes so the category tabs have more to filter, and build out a proper "our hearth" story section with the history behind it.

DEV Community: Mohit