Skip to main content
The promise of AI-assisted development is that anyone can ship a working app. The reality of running one in production is that “working in the demo” and “safe to charge a credit card on” are not the same thing. The gap between them is the central problem this page is about. By the end you will know why arbitrary code resists deterministic safety checks, why that gap widens when an AI writes the code, and how gavAI’s design — strongly-typed JSON with per-component validation — collapses an app’s surface to something exhaustive checks can actually cover.

​
The verification problem with arbitrary code

A program written as code — even a small one — has an effectively unbounded state space. Consider what determines whether a single endpoint behaves correctly: You cannot exhaustively check this. Static analysis covers some classes of bug. Tests cover specific examples. Type systems prune the tree to a smaller set. Code review catches things a reader can hold in their head. None of these are exhaustive; together they sample the state space. The places they don’t sample are where production incidents come from. The discipline of senior engineering is largely about narrowing the state space until the questions you can’t answer don’t matter. It is hard, it takes years, and most production incidents come from the cases that slipped past the narrowing.

​
What AI assistance changes

Generating code with an LLM does not change the verification math. It changes two things downstream of it: A model can write a payment integration that ships and clears card payments correctly all day. It can also leave a token in a log line, leak a customer email in an error message, or retry a non-idempotent write under load. These failures are not in the foreground of “does it work in the demo.” They are in the long tail of “does it stay safe when something goes sideways,” and that tail is exactly the part exhaustive checks cannot reach when the surface is arbitrary code. This is the gap between vibe-coded demos and production-grade apps. It is not a question of effort. It is a structural property of how much state space the artifact carries.

​
The platform’s bet: shrink the surface

gavAI’s design is the consequence of taking that gap seriously. Instead of producing arbitrary code that has to be verified after the fact, the platform produces a typed JSON document that is verified at every boundary by construction. The artifact is not code; it is data with a known shape. The shape is fixed. Each block is one of a known set of types, each with a declared schema for its inputs. Each capability call is a named, typed action with declared inputs and outputs. Each write to a workspace’s data passes through a schema validation before the database sees it. There is no arbitrary code path inside an app because there is no arbitrary code.
a-payment-integration.json
{
  "block": "Cta",
  "props": {
    "headline": "Start your Pro trial",
    "cta_label": "Subscribe",
    "on_click": {
      "capability": "collectPayment",
      "args": {
        "plan_id":     "plan_pro_monthly",
        "success_url": "https://app.acme.com/welcome",
        "cancel_url":  "https://app.acme.com/pricing"
      }
    }
  }
}
This is a payment integration. The set of things that can go wrong with it is bounded by the schema of collectPayment — plan_id must be a known plan id, success_url must pass the platform’s URL validator, and so on. The runtime checks every one of those constraints before any provider code runs. There is no log statement that could leak a token because the page does not hold one. There is no SSRF in success_url because the URL is validated against the workspace’s allow-list before redirect. There is no retry storm because retry semantics live in the platform, not in this declaration.

​
Per-component validation, all the way down

The bounded surface only delivers if validation is exhaustive at every layer. The platform validates four boundaries on every operation. Each layer’s check is exhaustive over its own surface. The schema declares every legal shape. The validator rejects everything outside that shape. There is no path through the platform that bypasses these checks because the path is the platform.

​
What “exhaustive” actually means

Calling a check “exhaustive” is a strong claim. The precise version of it is narrower than it sounds. The bargain is that the part you can verify is exactly the part that historically produces the long-tail production bugs: input validation, retry safety, type coercion, secret handling, provider-API misuse. The part the platform cannot verify — your business logic’s intent — is also the part a human reviewer is actually able to read in one sitting and reason about, because the artifact is small.

​
What you give up

Trade-offs are not free. The bounded surface costs you arbitrary expressiveness. These are real costs. If your app needs arbitrary code — a research prototype, a one-off integration with an exotic protocol, a deeply custom rendering pipeline — gavAI is not the right tool. If your app fits the shape that 95% of production SaaS fits — pages, forms, data, payments, emails, workflows, agents — the trade is a good one.

​
The result, stated plainly

A page on gavAI is a JSON document. The document’s shape is checked by a schema. Every operation it performs is a typed capability call with its own schema. Every write to data is a schema-validated transaction. Every outbound call is a perimeter-checked dispatch. There is no path through the app that skips any of these checks because they are not optional decorators — they are the spine the app runs on. This is what “predictable by design” means. Not that nothing can go wrong, but that the set of things that can go wrong is bounded by declarations the platform can exhaustively check. The remaining surface — the part where a human still needs to think — is small enough that a human can actually think about it.