← All posts
PlatformOctober 25, 2026·3 min read

Writing code is cheap. Verifying it isn’t.

As code got cheaper to write, the bottleneck moved to verifying and versioning the products it lands in. That takes more than code: design, user experience and engineering.

Ran Mizrahi
Ran Mizrahi
Founder & CEO

As code got cheaper to write, the bottleneck moved. It’s no longer writing code. It’s verifying and versioning the products that code lands in.

An agent can write thousands of lines before lunch. Another agent can review them after lunch. The code can pass every check, and you still don’t know if checkout works, if it still looks right, or which version your customers are running.

Code is cheap. Knowing what you ship isn’t.

Every new model writes code faster, and AI review keeps up with it. But a second model reading the same diff isn’t proof. One change to a shared part can land in a storefront, an invoicing app and a mobile checkout at once. Verifying all of that by hand doesn’t scale, so more of it ships on hope.

written by AIverified in the productunverifiedlast yeartoday
The gap between the two lines is change that reaches users without anyone seeing it work.

Verifying a product is more than code

Take one change to Payments. Engineering needs to know it builds, passes its tests and keeps its contract. Design needs to know checkout still matches the design system. Product needs to know the flow still makes sense to someone paying on their phone. Security needs to know it doesn’t widen who can see card data. AI review covers the first. The rest need someone to see the product working, and to own the parts it’s built on.

A diff can’t tell you which products it reaches

Plenty of tools can tell you which code a change affects. Few can tell you which products it reaches, and whether customers can still use them.

Read the diff3,412 lines, one reviewer
Review the graph554 lines need a person
The same change, twice. As a diff: 3,412 lines and no map of where they land. As a graph: eight parts. Six are already trusted, two add new behavior and need a person.

A diff shows what changed in the code. It can’t say which products the change reaches, or whether they still work. A graph can. It knows that Payments is used by the storefront, invoicing and mobile checkout, so it knows exactly what has to be verified, and where.

Six of those eight parts didn’t change. They’re existing versions someone already approved, which the change now uses. Their lines fill the diff, but nothing in them is new. Had the agent edited any of them, it would be a new version and need review like any other.

Every product, live in a preview

When a part changes, every product that uses it is rebuilt with the change, tested in a clean build and deployed to a preview. Not a simulation. The real app, running the new code, where engineering, design and product can each check what they own.

storecheckoutmobileinvoicesadminpaymentsrebuilt and tested in a clean build

4 passed. Invoices needs a look. Tests decided, not reviewers.

Change Payments, and every app that takes payments is rebuilt and tested in a clean build. Four pass and keep their trust. Invoices broke: Payments now defaults to the customer’s currency, and Invoices still assumed dollars.

A part whose contract didn’t change keeps its approval, but that alone isn’t the proof. The proof is every product passing with the change inside it. Side effects and changed defaults show up as a failing app, not as a surprise in production.

The people who own the product decide

What’s left goes to the people who own it. The Payments owner approves the Payments change. The Invoices owner sees Invoices failing in its preview, and why. A designer checks the checkout screens, not a diff. Each person checks their own product running with the change, not 3,412 lines shared across four teams.

  • DesignThemeMiraApprovedWorks the same for everyone
  • PlatformNavigationAllenApprovedWorks the same for everyone
  • BillingPricingRanNeeds RanAdds a new plan
  • PaymentsCheckoutDanaNeeds DanaChanges what other apps use
Every scope has an owner. Owners see the change in the apps they own. One decision per product, not 3,412 lines across four teams.

No app starts from a blank page

Anyone can build an app now, agents included. Design owns the design system. Product owns flows like checkout. The platform team owns login, permissions and personal data. Each is a part with an owner and an approved version.

  • DesignDesign system✓ v4.2
  • PlatformLogin & permissions✓ v3.1
  • ProductCheckout flow✓ v2.8
  • NewClass bookingsNeeds review
studio.acme.app/bookings
Studio
Admin
This weekMon · Flow yoga12/16Wed · Strength9/12Fri · Pilates14/14
Class pack · 10$160Pay

3 parts arrive approved by their owners. 1 new block is all that needs review.

A new app, built from parts that already have an owner and an approved version. Only the new block goes to review.

So a new app only needs review for what’s new. Change a part you don’t own, and its owner reviews it. Standards stop being a doc. They’re the parts every app is built from.

Components carry the trust

Once a component is verified, that version stays verified. The approval belongs to the version, not to a pull request, so it carries over every time the part is reused. Only new behavior, a changed contract or a failing product needs a person. When a new version ships, you see which products have moved to it and which are still on the old one, and each team moves when it’s ready.

6 of 8components were already trusted — 84% of the changed lines
6 trusted · 2,858 lines2 new risk · 554 lines
Six of eight parts arrived at versions already approved, 2,858 of the 3,412 lines in the diff. Only the two with new code needed a person.

So stop measuring how much code an agent generated. Measure what you know about what you ship: which products a change reached, which version each one runs and who signed off. This site is the proof: 25 pages built on 9,800 lines written once and reused 294 times. Each reuse kept the approval of the version it used.

Machines find every product a change reaches and prove it still works. Versions carry that trust forward. The people who own each part, from the design system to auth, decide what ships.

The same idea fixes source control, too: a bigger repo isn’t the fix. Try Bit Cloud.