AI-Written Apps: Can You Review the Diff and Merge With Confidence?

The bottom line first: When AI can write any code, “writing it fast” stops being an advantage; everyone has it. What becomes scarce is whether you can press Merge with confidence. That confidence comes down to one question: did the AI hand you something you can review, govern, and take responsibility for?

Start with a scene that’s already playing out every day.

An engineer asks a coding agent to “build a little customer-support refund app.” Half an hour later, a working app appears: frontend, endpoints, database migrations, tests — the whole thing, CI all green. She opens the PR and sees a single line: +8,142 −0.

Then she freezes.

She did not write these eight thousand lines. She has not read a single one. Which file enforces the cap on refund amounts? Will this endpoint also return other people’s refund records? If she changes it, will it ripple into reconciliation? She does not know, and neither does anyone else. Green CI only proves “the code runs in a self-consistent way.” It does not prove “it does the right thing, and only what it is allowed to do.”

She has two bad options: pretend she reviewed it and hit Merge, dropping a black box nobody understands into production; or actually read all eight thousand lines line by line, at which point she might as well have written it herself. This is the new bottleneck of the AI era: not writing code, but signing off on it.

Writing Code Got Commoditized; Trust Did Not

For the last decade, an engineer’s scarce skill was “being able to build it.” That skill is being erased by AI, fast and completely. When the marginal cost of generating an app trends toward zero, “fast” stops being anyone’s moat — your competitor’s agent is just as fast.

What gets pushed to the foreground is something that was always there but used to be hidden under the cost of writing code: someone has to be accountable for this code. Someone has to be able to answer “what data did it read, what actions can it take, who’s on the hook when it breaks, and can the audit trail find it?” Once AI cuts the cost of “writing” to zero, “reviewing and governing” becomes the most expensive — and most critical — part of the whole pipeline. Reviewability is the new moat in the age of AI-written code — not who generates the most, but whose output dares to ship.

This is the flip side of the same thing covered in vibe coding technical debt and why agent pilots fail before production: vibe coding lets everyone generate apps, but once generated, nobody dares ship them — because nobody can review them and nobody can vouch for them. The only difference is perspective. Those pieces look at it from the enterprise and the decision-maker’s side; this one looks at it from yours — the person with a finger hovering over the Merge button.

Why “Just Have Another AI Review It” Cannot Close the Loop

The natural rebuttal is: if AI can write it, just have AI review it. Code-review agents and automated security scanners exist now.

That path stops some of the damage, but it cannot close the loop that actually matters.

Go back to that GET /api/refunds. It returned everyone’s refund records, yet it would pass nearly every automated check: no syntax errors, no null pointers, and tests written by the same agent, which naturally tested “you can look up a refund” but not “should you be able to look up someone else’s refund.” What AI review is good at is whether the code is correct against itself: are there bugs, does it match known vulnerability patterns, is the style consistent? It cannot answer three questions that live outside the code: should this code be reading this table at all? Should this action be moving this money? Is this even the business rule we wanted?

Those answers are not in the code; they are in the permission model, in the approval policy, and in the business intent. Two AIs nodding at each other is not governance. The answer auditors, legal, and security teams want, “who authorized it, and who is accountable,” is something no review model, however capable, can sign for. “AI reviewing AI” can reduce the labor of reading code, but it cannot replace the “should it?” judgment that a human has to make. The problem loops back to where it started: a human has to be able to review it, and eight thousand lines is too much.

The Way Out: Shrink What the AI Hands You

You cannot review eight thousand lines, and you cannot maintain a system nobody understands. They are the same problem: the implementation pile creates “comprehension debt,” as described in that piece.

So change the shape of what the AI delivers: don’t have it generate the implementation, have it generate a declaration. For that same refund app, what the AI should hand you isn’t eight thousand lines of code — it’s a metadata diff like this:

+ object: support_refund
+   amount: currency (min 0)
+ permission: support_agent
-   allowDelete: true        # the agent's first draft granted too much
+   allowDelete: false       # pulled back on review: support can't delete refunds
+ flow: refund_amount > 500 → requires finance approval

You can read these dozen lines line by line, review them in five minutes, and roll them back with one click. More importantly, review is no longer “can I finish reading this?” but “is this permission right, and is this approval threshold reasonable?” That is a business question you can judge, and one you should judge. The leaky GET /api/refunds never appears here: support_refund’s read permission is declared as “scoped to the caller’s permissions,” the runtime enforces it accordingly, and the path to over-broad access is closed at the source.

So where did the implementation go? The implementation belongs to a repeatedly-audited runtime shared by all apps (ObjectOS), not freshly regenerated per app. “Should it?” — can it read, can it delete, does it need approval — is enforced by the runtime at execution time, not buried in eight thousand lines and left to luck.

A Loop That Actually Closes

Draw it as a flow and you get a closed loop where a human is always present but never drowned in line count:

Look at step ④: because the business definition itself declares the objects and permissions, the runtime projects it into a set of governed tools — so the same agent that “wrote” this app can later operate it within the same permission boundary (look up refunds, initiate refunds), every step carrying an identity and leaving a trail. Writing it and using it share one governance layer.

The Limits

This approach has limits, and they need to be said plainly.

First, not everything can become metadata. A brand-new real-time algorithm, a one-of-a-kind rendering pipeline — those still need real code, and someone still has to grit their teeth and review that part. Metadata won’t help you there, and forcing it does more harm than good. Where it shines is the 90% of business systems that enterprises rebuild over and over.

Second, trust gets transferred, not eliminated. You no longer review each app’s implementation one by one, but you have staked your trust on the runtime, which must be seriously reviewed once and continuously maintained. Still, the trade is clear: under the traditional approach, every AI-generated app means trusting a fresh pile of new code; under the metadata approach, you review the runtime once, and every app it derives afterward inherits the same validated permissions and audit. Reviewing once beats reviewing a thousand times. It is a better trade, but it is still a trade.

Closing

AI writing code won’t put engineers out of work, but it will change the gate engineers most need to guard: from “can I build it” to “do I dare to sign off on what the AI built.”

And whether you dare to sign off comes down almost entirely to what the AI puts in front of you — eight thousand lines of implementation you can’t finish reading, or a few dozen lines of declaration you can review and the runtime can govern. Don’t send your agent off to write a pile of code — send it to generate a target you can review and the runtime can hold up.

npm i -g @objectstack/cli && os start

Point your coding agent at a declarative, governable target instead of “build me a CRUD app” — then look at the next PR’s diff, and see if it’s finally small enough that you dare to hit Merge.