Live case study
Claude Code’s self-review missed 11 issues. Here’s what caught them.
What happens when Claude Code gets independent AI reviewers?
I asked Claude Code to build an AI Email Drafter, then used MegaLens to bring independent model opinions into the workflow while Claude remained the primary builder and decision-maker.
Screen recording of the build, 1 minute 9 seconds, no audio. Long scrolling output is sped up; the findings tables are held so they can be read.
15
actionable findings
11
additional findings beyond Claude’s initial self-review
10
more issues surfaced during implementation
167
tests passing
0
regressions
$3.32
for all three reviews on this build
Plan audit $1.25 · mid-build code audit $1.23 · final security audit for the balance. Those are pay-as-you-go prices at $9 per 1M blended tokens, not provider cost. Every figure is on screen in the recording above.
This whole build’s reviews cost $3.32
The experiment
I asked Claude Code to build an AI Email Drafter. It produced the implementation plan, then reviewed that plan itself before writing any code. That self-review is a real step, and it caught real things.
Then I sent the same plan through MegaLens. MegaLens routes the work to independent models from different families and returns what they found, including the points where they disagree with each other.
Nothing about the build changed hands. Claude Code stayed the builder. The only thing added was a second set of opinions for it to weigh.
What happened
The independent review came back with 15 actionable findings on the plan. 11 of those were additional findings beyond Claude’s initial self-review. The rest overlapped with what Claude had already flagged on its own.
Claude Code read all 15 against the plan and decided which ones held up. Only the findings that survived that check were carried into implementation.
Partway through the build I ran a second review, this time on the committed code rather than the plan. It surfaced 10 more issues in the first step, which Claude evaluated and addressed before continuing with the rest of the build.
The build finished with 167 tests passing and 0 regressions.
What the reviewers actually found
Eight of the fifteen, exactly as they came back. “Caught by” is the review’s own attribution: whether a finding came from the independent models only, or from both them and Claude’s own pre-audit.
| Finding | Severity | Category | Caught by |
|---|---|---|---|
| No actual USD cost parsing from response.usage — cost cap is unenforceable | Critical | Operational | MegaLens (all engines) |
| Bootstrap is :unread query + no gmail.modify — DB loss causes mass re-drafting of old mail | Critical | Operational | MegaLens (judges) |
| Email headers (subject, from, date) injected raw into LLM prompt — no sanitization | High | Security | Both (pre-audit missed headers) |
| Draft-create → mark-processed crash window — duplicate drafts, no atomic guard | High | Operational | MegaLens (all engines) |
| Reply envelope underspecified — To, Cc, References, In-Reply-To, Reply-To vs From not addressed | High | Design | MegaLens (judges) |
| No retry budget or poison-message quarantine — bad emails retry every poll forever | High | Operational | MegaLens (judges) |
| systemd Environment= stores file paths not values — broken auth or secret exposure in /proc | High | Security | Both (my pre-audit + MegaLens) |
| SQLite without WAL mode or busy_timeout — APScheduler threads cause "database is locked" | Medium | Operational | MegaLens (all engines) |
And one I rejected
The final security audit flagged F-014, incomplete type checking. I checked it and it was wrong: from __future__ import annotations already covered the case it was worried about. It went down as a false positive and nothing was changed.
That is the normal shape of this. An outside model sees the file, not the project, so some of what it raises does not survive contact with the rest of the codebase.
Run the same three reviews on your own repo.
Try it on your repoWhat I learned
The useful part was not proving that one model is better than another. I have no interest in that question and this run does not answer it.
What it shows is narrower and more practical: different models notice different things. Some of the outside findings were genuinely useful. Some were noise. A few were confidently wrong about code they could only partially see.
That is why the judgement stays with Claude Code. It has the repository, the plan and the implementation in context. An outside reviewer has only what it was sent, so its findings are input, not instructions.
Claude Code builds. Other models challenge assumptions. Claude decides what to do with the feedback.
I build MegaLens this way too
MegaLens itself was built primarily with Claude Code, and I used MegaLens throughout its own development to review its plans and its implementation. So I was dogfooding MegaLens while building MegaLens. The workflow in the video is the workflow I actually work in.
46 of those reviews were run from my own accounts, against MegaLens’ own codebase, since April 2026. That is the count of pipeline runs the database still holds, so the real number is higher.
Transparency
- —MegaLens is a commercial, private-source product.
- —The AI Email Drafter shown in the demo is a public demo project.
- —The numbers on this page are counts from that recorded run. They are not a benchmark, and a different project would produce different ones.
- —A second recorded run of the same project, with its own counts, is documented here.
Run the same three reviews on your own repo.
It connects to the IDE you already use. Your IDE stays the decision-maker.
Try it on your repo — this build cost $3.32