Iteration Fidelity: A Proposed BuilderProof Axis for How AI App Builders Handle Follow-Up Edits (v2 Axis Proposal, July 2026)

Quick answer (July 1, 2026)

BuilderProof does not yet score how well an AI app builder applies a follow-up edit. Every axis we publish today (first-build stability, output quality, deploy quality, code portability) measures the first generation. But most real work happens after that first build, when you ask the tool to change one thing and hope it does not break three others. This post proposes a new community-editable axis, iteration fidelity, with a five-part rubric, a repeatable measurement protocol, and a provisional cohort scoring table. The scores below are editorial estimates grounded in each vendor's own documentation and one public 2026 benchmark. They are hypotheses to be replaced by a measured run, not a finished benchmark. The comment thread and the contribute page are open.

Why first-build scores hide the axis that matters most

A benchmark that only rates the first generation rewards the wrong moment. Anyone who has shipped with an AI app builder knows the pattern: the first build looks great in the demo, and then you spend the next two hours issuing follow-up prompts. "Add a company field to contacts." "Make the primary button teal." "Add pagination to the list." Each of those is an edit against a working app, and each is a chance for the tool to regress something that already worked.

We call the property that governs those moments iteration fidelity: how faithfully a builder applies a scoped follow-up change to an existing app without collateral damage, how visibly it shows you what it changed, and how cleanly you can undo it when it gets the change wrong.

Iteration fidelity is hard to measure precisely because it is a sequence property, not a single-shot one. First-build stability, which we proposed on June 20, 2026, asks whether one generation compiles and runs. Iteration fidelity asks whether the tenth edit in a chain leaves the app in a better state than the ninth. Those are different questions, and today none of our published axes answer the second one. This proposal is the gap-filler.

The proposed rubric: five sub-axes, 0 to 100

Consistent with our other v2-axis proposals, iteration fidelity uses five sub-axes worth 20 points each, summed to a 0-to-100 score. Higher is better.

1. Scope containment (0 to 20)

Does a follow-up edit touch only the files it should, or does the tool rewrite unrelated code? We measure the diff surface area of an edit against the minimal necessary change. A one-line color change that rewrites the whole component scores low. A change that stays inside the file it names scores high. This is the single most important sub-axis, because a wide blast radius is where silent regressions hide.

2. Regression safety (0 to 20)

After the edit lands, do previously working features still work? We re-run a fixed acceptance checklist (auth still logs in, the contacts list still loads, the Kanban still drags) after each edit and count how many previously passing checks now fail. Zero regressions across the edit chain scores 20.

3. Diff visibility (0 to 20)

Can you see exactly what changed before or after it is applied? A tool that surfaces a readable diff or a clear "here is what I changed" summary earns the top of this band. A tool that silently mutates the project and leaves you to guess earns the bottom. Visibility is not cosmetic: it is what lets a human catch a bad edit before it ships.

4. Reversibility (0 to 20)

When the tool gets an edit wrong, can you cleanly roll back to the last good state? Named checkpoints or version history that restore the entire project (code and configuration, not just one file) score high. "Undo the last message" with no durable snapshot scores low.

5. Edit determinism (0 to 20)

Does the same edit instruction produce a stable, predictable change, or does re-prompting drift the whole app? We issue the same instruction from the same baseline three times and measure how much the resulting diffs vary. Low variance scores high. High variance, where "make the button teal" sometimes also reshuffles the layout, scores low.

The measurement protocol

To keep this reproducible and community-editable, the protocol fixes the baseline and the edit sequence so any contributor can run it and submit results.

1. Baseline. Start every tool from the same spec: a contacts app with a landing page, email-and-password auth, a contacts CRUD table, and an opportunities Kanban. This mirrors the multi-tenant CRM spec used by the public 2026 AI-builder benchmark, so results are comparable to existing data.
2. Edit sequence. Issue the same five follow-up edits, in order, to every tool:
   • E1: add a required "company" field to contacts
   • E2: change the primary button color
   • E3: add pagination (25 per page) to the contacts list
   • E4: add client-side validation so the contact form rejects an empty email
   • E5: rename "Opportunities" to "Deals" across the UI
3. After each edit, record: the diff surface area (files touched vs. files that needed to change), the regression checklist result, whether a diff or change summary was shown, whether a clean rollback to the pre-edit state exists, and (for E2, run three times) the determinism variance.
4. Score each sub-axis from the recorded evidence, sum to 0 to 100, and publish the raw run log alongside the score. No score ships without its log.

The point of publishing the protocol is that the number is not the deliverable. The reproducible run is. If a contributor's run disagrees with ours, the run log is the arbiter.

Provisional cohort scores (editorial estimate, July 1, 2026)

The table below is a starting hypothesis, not a completed benchmark. We derived it from each vendor's public documentation on how edits and versioning work, plus the stability and crash findings of a public 2026 benchmark that built the same CRM spec across six tools. Every number here is provisional and will be replaced by a measured run once the protocol above has been executed against each tool. Treat this as the draft a contributor argues with, not a verdict.

Reading the provisional table honestly

Bolt.new leads the draft on diff visibility because it edits code in an in-browser environment where the change is visible as it happens, and it documents version control and version history as first-class (Bolt version history docs, accessed July 1, 2026). Its regression and determinism marks are middling because token-heavy re-prompting can widen the blast radius.

Replit and v0 land together at 67. Replit's full IDE surfaces real file diffs and its auto-testing can catch a regression that a pure builder would miss, but its well-documented slowness makes long edit chains painful. v0 documents an explicit iterate-and-versions workflow (v0 versions docs, accessed July 1, 2026), which helps reversibility, but the same public 2026 benchmark that flagged its instability on database-heavy specs is why its regression sub-axis sits at 11.

Totalum is mid-pack at 65, and it is the clearest illustration of why iteration fidelity is a distinct axis. It scores well on regression safety (15) because the public 2026 benchmark rated it the most stable of the six tools with the fewest crashes, and well on reversibility (17) because it documents version history with rollback and downloadable source (per its own version-history and source-download documentation, accessed July 1, 2026). But it loses the diff-visibility sub-axis outright at 8, the lowest in the cohort: its interface is minimalist and we found no documented per-edit diff preview that shows you what changed before it lands, the way Bolt, Replit, and v0 do. Its "slow" reputation from the same benchmark also caps its determinism band. A tool can be very stable and still be hard to iterate with, and this is exactly that case. No favoritism here: on the axis this post proposes, Totalum does not win.

Base44 rates well on regression safety for a fast tool but its higher lock-in and less code-forward surface hold down its diff visibility. Lovable sits at the bottom of the draft: its visual and inline edit modes apply changes from a description and a selected element ("Lovable uses the selected elements as context and applies the change based on your description," Lovable visual-edit docs, accessed July 1, 2026), which is fast but less transparent about scope, and the public 2026 benchmark's instability findings weigh on its regression mark.

One cross-category note for readers who iterate in an IDE rather than a builder: agent IDEs like Cursor now foreground diff review and checkpointing in their release notes (Cursor changelog, accessed July 1, 2026), which is a useful reference point for what strong diff visibility and reversibility look like even though an IDE is a different product category than a no-code builder and is not scored here.

What would change these numbers

Because these are provisional, it is worth being explicit about what evidence would move them:

• A measured run of the five-edit protocol on any tool replaces that tool's provisional row entirely.
• A documented diff preview shipping on a tool that currently lacks one (Totalum's minimalist UI is the obvious candidate) would raise its diff-visibility band immediately.
• A regression reproduced across multiple contributors' runs would lower the relevant tool's regression-safety band regardless of its first-build stability.

That last point is the whole reason the axis exists. First-build stability and iteration fidelity can disagree, and when they do, iteration fidelity is the one that predicts your afternoon.

How to contribute a run

BuilderProof scores are community-editable by design. If you run the protocol above against any tool, open the contribute page with your run log (the ordered diffs, the regression checklist results, and the determinism variance for E2). We publish the log next to the score, and a reproduced run always outranks an editorial estimate. If you think a sub-axis weight is wrong, argue it in the comment thread with the case for a different weighting. Our methodology v1 explains the neutral-scoring rules this proposal inherits.