Nick Nisi's Fruit Fly Code Review Is Real

Nick Nisi took a male fruit fly brain, wired it to a code reviewer and let it vote on pull requests, a demo he walked through on AI Engineer that is both absurd and pointed. Nisi, a software engineer and engineering manager who leads developer and agent experiences at WorkOS, said the bottleneck is no longer writing code but reviewing it. I think he is right, and the fly makes the case better than another dashboard would.

The point is not the fly.

Nisi said we have solved the coding part with Claude Code, Codex and similar agents, and we now act as managers while CI, linting and agents like Graphite and CodeRabbit run checks on every PR. He argued a five out of five from Graphite already makes him confident he will not break production, and what matters is whether the change does what was intended, not whether a human eyeballs every line. To prove how low the bar for pattern matching has fallen, he built a reviewer from the actual connectome of a fruit fly, 176,000 neurons, 6.3 million connections and more than 125 million synapses, scanned slice by slice under an electron microscope, and left the wiring intact except for a small memory subset. That data sits inside a larger open ecosystem of connectome work that now includes MaleCNS, FlyWire and simulation templates documented in community lists like the awesome-fly collection.

How it works is deliberately biological. Nisi uses Jev, a system one model, as the fly's nose to ask 30 non-biased questions about a diff and turn the code into literal smells. During training the brain learns which smells meant good code and which meant bad, rewarded with sugar water or punished with a bitter taste that Nisi describes as dopamine signals that weaken or strengthen specific connections. At review time the smell triggers hormones, the network settles, and the fly votes. Tongue out means smells good, tongue retracted means request changes. Nisi said he tested whether the brain was redundant and found removing those memories scrambles the votes, so the connectome is doing work, not just parroting Jev.

Is it any good? Nisi ran a live game with three files from the codebase and the room went three for three while the fly went two for three, and he said his broader tests hit about 88% accuracy, with 96% and 98% on two harder plausible-mistake cases. That is better than a coin toss and worse than a good automated reviewer, which is the honest verdict. Pros: it is real, trained on the repo, catches removed conditionals and logic deletions without further tuning, and runs at fruitfly.review for anyone to try. Cons: it cannot explain a fix, it only says this smells funny, it needs the Jev nose in front of it, and on Nisi's own live backup it failed to make a distinction on a real pie extension PR he had approved. It is legit and real, not a scam, but it is not safe to gate production on its own.

The impact Nisi wants is workflow, not novelty. He proposed teams stop reviewing everything and instead maintain a team review skill, a codified checklist of what a WorkOS DX engineer, or any team, would actually block on, owned via CODEOWNERS. A lightweight classifier like Jev or similar would score complexity and risk, then Graphite, CodeRabbit, Greptile or Codo would do the deep automated review. Only failures escalate to a human, and the system should return proof that the change does what it claims, with screenshots, video, test output or smoke tests you can run yourself. That shifts budget and time from human thumbs-up to maintaining that skill and to verification artifacts. For eng managers drowning in PR queues, the change is concrete: write the rule set once, audit misses after, and let AI fix forward.

Nisi concedes Reptile, CodeRabbit and others already do this better than a fly, and that humans still own the why behind a functional change. I would not deploy a fly to protect main, but I would take his escalation ladder seriously. If a fly can be right 80% of the time, your review process that insists on a human for every diff is not rigorous, it is just slow. If a founder asked me whether to use this, I would say use the demo to force the conversation about what your team actually wants to block, then build that.