I Made a Fruit Fly Review My Code - Nick Nisi, WorkOS
Nick Nisi argues that human reviewers have become the bottleneck in software development and demonstrates a simulated fruit fly connectome trained to judge code quality, reaching about 88% accuracy in testing. He then proposes a tiered review system where team skills, classifiers, and automated reviewers send only risky pull requests to people, backed by verifiable proof.
Code is being written faster than ever, and the bottleneck has moved to the human reviewer. Nick Nisi, who leads developer and agent experience at WorkOS, argues that CI, linters, and agent reviewers already catch much of what matters, yet every pull request still ends up waiting for a person. Teams have become managers of agents rather than writers of code, so the real question is why a human needs to read every diff when what matters most is whether the change does what it is supposed to do.
Why review still matters, but for a different reason
Nisi does not think code review will disappear. He thinks its purpose will change. A strong automated signal, such as a perfect score from an AI reviewer, is often enough to conclude that a change is unlikely to break production. What stays human is context: explaining what is being proposed and why it matters to the people who depend on it. Reviewing simply to catch missed bugs is a job he no longer believes only people can do.
A fruit fly on the review desk
The ‘bug’ in software traces back to a literal moth found in a relay in 1947, and Nisi’s talk uses a bug to find bugs. His test subject is a connectome of a male fruit fly, built from electron microscope scans of its brain, with 176,000 neurons, about 6.3 million connections, and over 125 million synapses. Others have made this kind of simulated fly play Doom or Beat Saber. Nisi instead had it review JavaScript, and he changed nothing about the wiring except a small subset of neurons used to retain memories of what good and bad code look like.
Turning code into smells and teaching taste
The fly has no native concept of code, so an AI model acts as its nose. It asks around 30 unbiased questions about each change and converts the answers into odors, so the diff becomes literal code smells. Those smells are matched against the fly’s memories, which were formed during training on the codebase. Good code is associated with sugar water and bad code with a bitter taste. Each test result acts as a teacher: a passing test delivers a reward signal that strengthens the wiring toward approach, and a failing test delivers a bitter, dopamine-like punishment that strengthens avoidance. The fly’s verdict is its tongue. If the tongue extends, the change smells good and gets an approval. If the tongue retracts, the change should be revised.
Nisi was worried the fly would be redundant, with the AI doing all the judging and the insect just reporting it. To check, he removed the memories. The fly then scrambled its responses, with the tongue extending when it should not, which suggests the brain itself is doing the evaluation.
Testing the fly against the room
In a live round, the audience reviewed three random files from the codebase. The room got three out of three, and the fly got two out of three, failing on the one the audience rejected. Nisi reports the fly was right about 88% of the time in testing. On harder tests, it caught the first example 96% of the time and a very plausible mistake 98% of the time. A real pull request from one of his Pi extensions was less clear-cut, and the fly could not distinguish it either, so the backup result was used.
The fly has clear limits. It cannot communicate, it does not know JavaScript, and it cannot say how to fix a problem, only that something smells wrong. Still, it is good at spotting changed logic, altered conditionals, and removed logic, which makes it useful for keeping a review on track. What it cannot do is explain why a change is happening, and that is the part Nisi believes humans must keep.
Escalating only the reviews that need a human
Rather than reviewing everything, Nisi proposes a tiered flow. The first layer is a team review skill, a maintained checklist of the minimum a team would look for in any change tagged to it through code owners. The DX team’s checklist would differ from a platform team’s. The second layer is a lightweight classifier that asks whether a change is too complex, whether it does what it claims, and how much risk it carries. The third layer is an automated reviewer such as Reptile, Code Rabbit, or Graphite. Any failure escalates to a human. A PR that passes every layer can merge on its own.
When something does slip through, the response is an audit. Teams can strengthen the review skill or the automated reviewers so the miss is caught next time, and AI can help write the fix. Humans then receive a summary explaining why the change happened, including any business logic changes and alternatives that were tried and discarded.
Proof instead of review
If humans stop reading the code closely, they need evidence that the change does what it should. Nisi suggests agents supply it through screenshots, videos, test results, command outputs, smoke tests that can be run directly, or clear steps to reproduce the behavior for manual testing. Human checks can diminish gradually as teams come to trust these verification methods.
Nisi’s demo of this approach is available at fruitfly.review, where readers can run their own pull requests through the fly.