Two eyes beat one

In short: One model writes code, a second one reviews it — independently, in its own role, with a different failure profile. Instead of the same model rubber-stamping its own work, you get a four-eyes principle for AI-assisted development. The reviewer changes nothing directly; it writes audit logs and plan files. The implementer turns those into a fusion plan and only then builds. The best part: it needs no special infrastructure — chat and a handful of files are enough. And the whole thing is available as a free kit to take with you.

The problem: a model that nods at its own work

If you build with AI, you know the moment. The model writes a block of code, you ask "does this hold up?", and it answers, confidently, "yes, looks good." Sometimes it's right. Sometimes it defends a decision that was flawed from the start — with the same confidence it used to write the flaw a minute earlier.

That's not an accusation against the models. Models aren't perfect; hallucination is part of the technology, not a bug you can argue away. The honest conclusion isn't "then I won't use AI" — it's: work around it cleverly. You build structures that catch the weaknesses instead of pretending they aren't there.

And one of the cheapest, most effective structures is ancient — it comes from every workshop, every newsroom, every film edit: have someone else look at it. Two eyes beat one.

The trigger

Honestly, the spark wasn't some brilliant insight of mine — it was a YouTube video. Someone mentioned, in passing, that they use two models while developing: one that builds, one that reads along. That stuck.

Shortly before, I'd already started wiring a multi-model pattern into my projects — inspired by Andrej Karpathy's llm-council, a small open-source experiment in which several models work on a question together and rank each other before an answer lands. The idea behind it is simple, and strong precisely because of that: several perspectives checking each other are, on average, more reliable than a single one congratulating itself.

Going from "several models advise on a question" to "one model builds, another reviews the code" is a small step. The principle is, really, completely obvious — it's just the logical thing to do when you care about quality. I only poured it into a fixed routine.

The idea: separate roles, don't stack models

The decisive point isn't "more AI." It's role separation.

The first model is the implementer. It writes and changes code. The second model is the reviewer — and it deliberately must not touch the product code. Its job is a different one: read, cluster risks, find weaknesses, and capture the result as an audit log and a concrete plan file. Criticism becomes material, not a silent rewrite.

Why that's more than cosmetics:

• A different failure profile. A second model trips over different things than the first. What one misses, the other catches — and vice versa.
• Nobody defends their own code. That's the psychological core. A model that just built something is inclined to like it. A model in a pure reviewer role doesn't have that reflex.
• Review becomes traceable. Audit logs tied to files and commits make visible what was checked — not just "had a look."
• Long runs become possible. A file-level done list keeps the same files from being re-checked over and over across a big project. That's how the whole thing scales instead of losing the thread after three files.

And then comes the part that matters most to me: the implementer does not adopt the review plan blindly. It reads the audit, writes its own plan, compares the two, and builds a fusion. Only that fusion gets implemented and verified. No "the reviewer has spoken, so I'll do exactly that" — but two perspectives merging into a better third.

My part: directing

Here I have to be honest, and that honesty matters to me: I don't write this code myself. I'm not a classic developer. The complex code comes from the AI. What comes from me is something else — and that's exactly my job.

For me it feels like steering a producer or directing. I cast the roles, I define the gates, I decide what gets checked and when a fusion is good enough to ship. The models are my crew; I set the direction, the method and the quality bar. And honestly: I enjoy it. It's the same work I love — shaping a whole out of many parts and talents until it works in the end.

That's the vibecoder reality: I can't hand you a perfect algorithm. But I can set up a system where two AIs keep an eye on each other, and I can make sure something tested comes out — not something that merely sounds convincing.

Deliberately manual — and why that's a cost decision

An honest word on the mechanics, because it's easily misread: this is not an automation that runs out of the first tool and ships the code to the second model via API. It's a manual handoff — I start the reviewer by hand and kick off the review by hand.

That's on purpose, and the reason is mundane: cost. I have a subscription with Anthropic (for Claude) and one with OpenAI (for GPT, which I use through Codex). Both are flat-rate. So I deliberately run both tools — implementer and reviewer — on those subscriptions, not via API keys with pay-per-use. That's exactly where the split into two separate, hand-operated tools comes from: the implementer builds, then I start the reviewer separately and trigger the review.

You could automate it — the code would then move to the review model automatically, typically over the API (or a router like OpenRouter that taps the model quota and bills separately, pay-per-use). More convenience, more automation — but extra cost on top, even though the subscriptions are already running. That adaptation is possible anytime; I deliberately didn't build it. For my day-to-day, the small manual step is cheaper than an API bill ticking up with every run — and that trade-off is part of the decision.

Why it's worth the effort (already today)

You could object: that's just a workaround. True. But a good one. As long as models hallucinate — and they all do, including the current ones — the question isn't whether you counter it, but how cheaply and how reliably. A second role that costs nothing but a little discipline and a few files is one of the cheapest insurances you can build into an AI workflow.

My hunch: this is a transitional technique. Today's models don't think this way on their own yet — you have to organize the second perspective by hand. Future models will move in this direction and probably do it automatically: build first, then check hard in a separate role before they ship anything. Until then, I organize it myself. And even when it becomes standard, the principle stays the same — it just gets more convenient.

Rebuild it — the kit is free

🎁 Grab the kit — free & open source

The complete two-LLM review routine as a ready-made package: an agent rule, the reviewer skill, plan templates and a chat-handoff template. No login, no special infrastructure — copy and go. Open source under GPL-3.0.

→ View open-skills on GitHub · Tutorial: set it up step by step

This article explains the why. The how — step-by-step installation, setting up the skill globally, running the review loop — lives in the linked tutorial. Deliberately separated: the principle here, the instructions there. So you don't have to scroll through a setup guide to grasp the idea — and not through an essay to put it to use.

Jens Fehrmann does end-to-end AI integration — from feasibility study to tested end-application. As a vibecoder: concept, architecture and method from him, the code from the AI. Built on 16 years of film and CGI, from Dresden.

Sources & transparency - Andrej Karpathy, llm-council (open-source project; several models jointly assess a question): https://github.com/karpathy/llm-council - The free kit for this article (open-skills, GPL-3.0): https://github.com/jnsfhrmnn/open-skills - Own operational experience: the implementer/reviewer routine described here comes from my own work across several projects (own observation, not externally linkable).

Trademarks, logos and model names mentioned belong to their respective owners; no cooperation or partnership is implied.