Adverserial review has spread

This post was researched using chatgpt sol 6.1 on extra high using iterative adverserial refinement with human guidance and direction in prose. The human has read and hand corrected through various drafts and signs off on the articles premises

When doll came up with adverserial review it was a means to actually gain parity with people who could code by hand for those like doll, who could not and would never be able to. One of the core problems with AI is of course, it makes mistakes and those compound over time. To doll the obvious solution was to have another AI review the code and look for flaws, a different task which activates different parts of the AI's thinking. That too would make mistakes, but iteratively you could reduce them as long as you had tokens and time to spend.

This allows anyone to code even if they couldnt do it by hand. Ignore everyone who tells you differently. Some people will tell you differently with the best of intentions wanting you to learn software engineering principles and architecture concepts. Its good to learn these things. But if you are just spinning up some personal app for yourself, you dont really need to know any of this and you can just get the robots to make the thing for you and the thing will probably work good enough.

Some people will tell you differently because they think the coding should be best left to them. They are just safe to politely ignore.

Coding is for everyone now all thanks to adverserial review and real testing

And now versions of that same approach are turning up all over the place. People are building entire tools around getting the robots to argue about whether the work is any good.

Take Bluesky’s Roast. One AI looks for problems in the code. Another checks whether those problems are real. That second part is useful because the robot doing the criticizing can make things up too. Its complaints have to survive being checked.

Google built a critic into Jules, its coding agent, so proposed changes could get criticized and sent back for repairs before reaching the human. Later it added a critic for the plans. Before the robot starts building, another robot gets to question what it intends to do. Finding out the plan is bad before spending an afternoon implementing it is rather convenient.

OpenAI has an adversarial review command for its Claude Code plugin, letting people bring Codex in to challenge the work. You can point it at a particular worry and ask it to question the whole approach. This makes the “have another AI look at it” part much easier to do.

You can also give the reviewers different jobs. Addy Osmani’s adverse has one worrying about correctness, another about security, and another about whether the design has become a complicated mess. They look separately and then examine each other’s findings. These can all be the same model playing different roles. The assignment changes what each one spends its attention on.

Other versions live inside the everyday development process. Superpowers puts reviews between tasks, so mistakes can get caught before more work gets built on top of them. BMad has adversarial review for documents as well as code. Requirements can be wrong too. There is no particular reason to wait until someone has implemented them before pointing that out.

Then there are the commercial review tools. Cursor described an early Bugbot design that looked at changes several times, even showing the code in different orders to get different lines of reasoning. Qodo uses specialist reviewers and a judge to sort through their findings. It also brings in previous reviews, giving the robots some history about why the code looks the way it does.

Sometimes the challenge comes from making the software deal with awkward situations. StrongDM’s software factory uses scenarios kept outside the codebase and simulated versions of services the software depends on. The agents have to produce something that works when it is put through those scenarios. The checking gets a life of its own, separate from the robot writing the implementation.

There is a whole range here. Doll’s version has a human in the middle deciding which criticisms make sense. Other people are automating more of that process, putting critics into planning, or having several reviewers challenge each other.

And this is why doll finds the spread interesting. What helped make its own work possible is now showing up in tools built for professional software teams. This makes the world a better place for everyone. The technique was good enough for doll, good enough for other developers and good enough that anyone can make a program now.

Oh and by the way Peritus has all of that built in by default. Including a lot of the software architecture knowledge the naysayers say you need to know.