
Who reviews the code an AI app builder writes? The builder's own tooling does. As of 7 September 2026, each of the four builders we track weekly – Lovable, Bolt, Replit and Base44 – documents an automated review of the code its own product just generated, scoped mainly to security, dependencies and whether the app behaves when it runs. What none of them documents is several models reading that code independently and then critiquing each other, and none of them returns a judgement on whether the app was worth building at all.
What each AI app builder checks in its own generated code
Each of the four publishes an automated pass over generated code in its own documentation. Below is what each vendor says, read on 7 September 2026, with nothing filled in by us (the same rows sit in our full comparison table, kept current on the same weekly check). Replit and Base44 both name third-party analysis engines; only Replit documents a gate that can stop a release.
Lovable documents two checks: a basic configuration and dependency scan, and a deep scan it calls "a thorough agentic review of your codebase". Both are listed as available to all plans, with scheduled deep scans reserved for enterprise. – docs.lovable.dev/features/security
Replit documents a security agent that runs a full review of the codebase – threat model, routes and APIs, injection and cross-site classes – combining the static-analysis tools Semgrep and HoundDog with model reasoning. Around it sit free automatic dependency-CVE scanning and a pre-publish gate that can block publishing on a critical finding. – docs.replit.com
Bolt documents a project security audit that "reviews your whole project, including your code and database, fixes what it can", on paid plans, with a lighter database check on all plans. – support.bolt.new/building/security It is also the earliest of the four we recorded: our own competitor snapshot dates the audit to Bolt's release note for 27 to 31 July 2026. Bolt publishes only the current week's note, so that dating rests on our snapshot rather than on a page you can open today.
Base44 documents a security scan – data permissions, exposed secrets, unauthenticated functions, credit protection and security headers – available on every plan including free; code-vulnerability scanning specifically is gated to the Builder plan and up. – docs.base44.com An optional third-party Wiz connector adds dependency and static analysis on top, itself gated to Builder plan and up, and Base44's docs state it "doesn't consume Base44 credits". – docs.base44.com
None of this is uniformly free. Lovable lists both of its checks on all plans, Bolt keeps the full project audit on paid plans, and Replit documents its dependency-CVE scanning as free. What sits behind each vendor's paywall beyond that is not documented, so we do not claim it.
Anyone who has used one of these tools has watched a scan run. A page claiming that nobody checks the generated code would simply be wrong.
Why one automated review of AI-generated code is a thin review
Because one pass produces one report, and a report with nothing beside it gives you no way to separate a real finding from a confident one. You see the conclusions that survived. You never see the objections another competent reader would have raised, because no second reader was in the room.
Beyond the tool names Replit lists and Lovable's word "agentic", nothing in the four vendors' documentation says what reads the code from end to end or how many readers there are, and we are not going to guess. What they publish is the artefact, and the artefact that reaches the founder is one report with one conclusion and no dissent inside it.
The other limit is scope. What is documented is security, dependencies and the behaviour of the running app. That is worth having, and we do not run most of it. It is also a different question from the one the founder actually has: does this code do the thing I described, and is it built the way a careful reader would have built it? A clean security report and a wrong app are entirely compatible states.

Round two of a consensus run: every answer is relabelled Member A, Member B and so on before the models read each other. The code's stated reason is that anonymised labels reduce brand bias in critique.
Does any AI app builder tell you whether to build at all?
No. None of the four documents a step that runs before the app exists and returns a judgement on whether to build it. That was checked against all four changelogs and product pages on 31 August 2026, and read again on 7 September, with the same result.
The closest thing on the market is Replit's Growth Kit, released on 28 August 2026. Its fifteen skills include a Consumer and Viral Potential Assessment, described as pressure-testing whether an app idea has the potential to go viral, and an ICP and market-sizing skill, which needs no app to run. But the page's own headline is "You built the product. Now build the business.", and nothing in the kit produces a judgement on whether to build in the first place. It is a kit for the app you already have.
The same week showed the pattern plainly. Base44 added a first-campaign credit to its Google Ads wizard on 1 September; Replit shipped project analytics inside its growth pane on 4 September. Three of the four now sell something that happens after the app exists. Nothing moved ahead of the build.
The build is the cheapest part now. One sentence produces a working preview in minutes. What did not get cheaper is building the wrong thing, and every reviewer these four ship starts work after that decision has already been made.

Every documented review in this market starts once the thing exists. The decision that costs the most is made before any of them run.
What a multi-model review of AI-generated code looks like
In ewpire's Code, any version of the generated app can be sent to Consensus with one action, Review with consensus – the same engine the Idea validation template uses. Three rounds: several models read the code separately, then read each other with the names removed, then one synthesis returns the answer together with a map of where they disagreed. The disagreement stays in the artefact instead of being smoothed into a single tone.
Round one: every seat answers independently and in parallel, none of them seeing another seat's answer. Round two: each seat receives all the other answers, relabelled Member A, Member B, Member C, and writes a critique of them – correctness, edge cases, complexity and security, down to the exact step or line that fails – with explicit permission to say plainly that the others are all correct, if they are. Round three: a synthesizer receives the question, every first-round answer and every critique, and must return one answer plus an honest map of the disagreement.
The review is not part of the build. The code comes out of the model you picked in Code, or the one Auto chose, in its own pass; the review is a separate set of calls to the default Consensus models, each reading the version's files.
Each seat also ends its first answer with one machine-readable line: its position – support, mixed or oppose – and a score for how strongly it holds it. The numbers on the result are computed from those lines, never guessed from the prose.
Two rules sit on top of those positions, and each exists to stop a single model deciding something on its own:
Silence is not agreement. A seat that states no position is left out of the count, never counted as agreeing.
The split travels with the answer. The areas of disagreement name which model holds which position, so the disagreement can be shown rather than collapsed.
The confidence figure follows the same discipline. It is computed from the seats' own stated positions, not from the synthesizer's opinion of itself, and when fewer than two seats state a position, no number is shown at all. Substituting a plausible number is exactly the behaviour that rule replaced.
And the panel is asked about four things, not one: correctness, security, accessibility and design craft, file by file, with what to change first.
What a multi-model code review is not, and why it is not a security audit
It is not a security audit and it is not a certification, and it replaces neither. We run no static analysis of our own, no dependency-CVE database check, no external test against the running preview, and no gate of our own that stops a publish on a critical finding. Every one of those is something the builders in this article do ship and we do not.
In Code the review runs only when you ask for it, after the preview already exists, and it never holds the app back, so it would be untrue to say that nothing reaches you until the models agree. What is true is narrower and still useful: the models read the code separately, they read each other without names, and where they disagreed stays visible to you. Independent readers increase the probability that a defect gets seen, and only that. Models trained by different labs still share blind spots, and the size of that overlap is measured: across more than 350 models, two wrong models gave the same wrong answer about 60% of the time on HELM against a 33% chance baseline. Nothing here promises that none is missed.
When the models find problems, the review lands in the project conversation with a link to the full consensus, where the areas of disagreement are the point rather than a footnote. What comes back is a deliberation to argue with, not to act on.
How to check the idea before there is any code
The step that runs before any of this is the Idea validation template in Consensus, and it is the same panel one stage earlier: the idea goes in instead of the code, and what comes back is one synthesized answer with a confidence figure and the areas of disagreement. It does not hand down a build-or-do-not-build ruling, and it would be a worse product if it pretended to. What it does is put the question this market currently skips, and show you which parts of the answer the models could not agree on.
If you want the off-screen version first, our guide to validating a startup idea before you build covers who to talk to and what to test, and why one model's yes proves so little covers what a single assistant's approval is actually made of.
The account is free; runs are paid from a prepaid balance. Top up from $10 plus a 5% service fee – no subscription – and every consensus shows its estimated cost before it runs. You can put your current idea through the Idea validation template, or a version you built in Code through a consensus review.
FAQ
Who reviews the code an AI builder writes? The builder's own tooling does. As of 7 September 2026, each of the four builders we track weekly – Lovable, Bolt, Replit and Base44 – documents an automated review of the code its product generated, scoped mainly to security, dependencies and whether the running app behaves. What none of them documents is several models reading the same code independently and then critiquing each other on the record.
Does any AI app builder tell you whether an idea is worth building? No. Checked across all four vendors' changelogs and product pages on 31 August 2026 and read again on 7 September, none of them ships a step that runs before the app exists and returns a judgement on whether to build it. Replit's Growth Kit comes closest, with fifteen skills including a viral-potential pressure test and an ICP and market-sizing skill that needs no app to run, but its own page headline is "You built the product. Now build the business."
Is a multi-model code review the same as a security audit? No, and it should not be described as one. Security is one of four things the panel is asked about, alongside correctness, accessibility and design craft. There is no static analysis, no dependency-CVE database and no test against the live preview behind it, and no certification comes out the other end.
If the panel finds nothing wrong, is it safe to ship? No. A panel narrows where to look, it does not certify, and the measured overlap between models' errors is large enough that several of them can be confidently wrong together. Read a clear result as a shorter list of places to look, keep whatever security tooling your stack already has, and ship on your own judgement.
What happens when the models disagree about a build? The disagreement is reported rather than resolved by averaging. The synthesis lists the areas of disagreement and which model holds which position, a seat that states no position is left out of the count rather than counted as agreeing, and when fewer than two seats state one, no confidence number is shown.