A Playbook for Building Real Apps with AI

Gate-Driven AI Development: AI does the work, you pass the gates.

By Alex P. Wang | July 7, 2026 | Tags: AI Development, App Builders, Development Process

AI can now design, code, and test an application from start to finish. What it cannot do is know when the design is right, when the screens feel right, and when the result is safe to ship. Those are human decisions - and in this process, they are your entire job. You provide the judgment; AI does all of the engineering.

Who Is Using AI to Build Apps

This is written for app builders - the people who turn a business need into a working app. "App" is broad here: it includes AI agents - an agent is an app whose head is a conversation instead of screens. A room-booking tool. A safety-review assistant that helps a medical monitor scan study data for signals. A filings digest that briefs a financial analyst every morning. If it takes a business need and gives back working software, it is an app - and you can build it this way. You are the builder; AI is your crew. Two kinds of builder will read this differently, and the process serves both.

Neither type reads the code. AI produces too much of it, too fast, for line-by-line review to be real protection - a human skimming a thousand generated lines is false confidence, not safety. The protection is structural - a playbook of written rules the AI loads every session, explained in a moment.

The user-type builder is the real test of this process. The goal is for a technical non-coder to ship a small application successfully, with AI doing all the engineering and the gates doing all the protecting.

One honest limit: this works for small apps in domains you know - the gates only work when you can judge what right looks like, and the AI is required to say so when a project demands judgment you do not have. Large systems need engineers; everything below that line - the internal tools every business needs and never has enough engineers to build - is yours.

The Idea: Gates, Not Vibes

Gate-driven AI development splits an app project into five phases. AI executes each phase under the GDD playbook. Between phases stands a gate.

A gate is a stopping point. Work halts. AI presents evidence of what it built. You either sign off or send it back. The gate stays closed until you decide, and nothing moves to the next phase through a closed gate. If you have seen a stage-gate process in project management, this is the same idea applied to AI: the machine builds, the human approves.

The evidence at every gate is behavior, not code. Test runs, working screens, plain-language reports of what works and what does not. You never need to read a line of code to pass a gate.

What enforces all of this is the Gate-Driven AI Development playbook - the GDD playbook: a set of written rules loaded into the AI at the start of every working session. It tells the AI how to work: never guess when the spec is silent - ask; deliver a test with every step; never delete or weaken a failing test; stop at every gate and wait for a signature. The rules are organized as one always-on file plus exactly one file per phase - the AI loads only the rules for the phase it is in. The playbook constrains how the AI works, and the tests prove what the code does. If a process only works when somebody reads the code, it has already failed the user-type builder.

The playbook also learns. When a session hits a mistake whose root cause is a gap in the rules themselves, the AI logs it as a candidate in a lessons file - it never rewrites the shared rules mid-session. The builder reviews the candidates and rules on each one; adopted lessons become rule changes marked with the project and date they came from. Several of the playbook's rules entered exactly this way.

The popular alternative already has a name: vibe coding. Describe what you want, accept what looks good, repeat. It feels fast because nothing is checked - and it collapses as the project grows. Features quietly disappear. Fixes break things that used to work. Nobody can say what is actually done. The code can look right and still be wrong - it passed a glance, not a test. And when it breaks, there is no trail: no spec, no record of what was decided, nothing to check the fix against. The failure is not the AI's coding ability. The failure is that nobody defined where human judgment enters the process.

The Process

One thing runs through all five: testing. It is not a phase tucked at the end - AI validates as it goes, wherever a check is possible. The prototype is validated by you using it. The design is validated by written acceptance criteria. Every build step is validated by its own test. The deployment is validated by end-to-end checks before and after. Whenever something can be checked, AI checks it and shows you the result.

And the phases are not straight lines - every one is a loop, and the names say so. Progress inside each phase is circular; only the gates are one-way doors. The pipeline itself is the biggest loop of all: after ship, every change re-enters at the right phase - a new feature at the spec loop, a screen tweak at the prototype loop, a bug at the build loop. Ship is a gate, not an ending.

Start with the Interface, Not a Perfect Spec

The old rule said write a complete specification before coding. For anything a person interacts with, that rule fails. Nobody can design a good interaction on paper - a screen flow, a conversation, a voice exchange. You have to try it.

So the process flips the order. Write a short high-level spec, then have AI build the app's actual interface on sample data. Usually that means clickable screens - but the same loop works when the interface is a chat, a voice assistant, or even another AI agent calling the app. AI builds it, you try every flow and ask for changes, until it feels right. The prototype you approve becomes the specification for everything behind it.

One rule makes this safe: the sample data sits behind the same contract - the fixed list of operations the app offers - that the real backend (the machinery behind the screens) will implement, so the swap later changes nothing the user sees. The architecture section explains why.

Keep one thing in mind while you play: the interface is not the app. It is the app's first head - the first of many faces the same core logic will be able to wear. What you are really shaping in the prototype loop is the app's behavior; the interface is just where you meet it. The next section makes this precise.

The Architecture: Build the App Headless

Every app in this process follows one architecture pattern. The core business logic - every function and feature the app offers - lives behind a headless layer - operations the AI can call and script directly - attached to no head. A head is whatever the user touches, and it can take many forms: a web page, a phone app, a chat or voice assistant, another AI agent acting for the user, even another program. Each one is a thin skin that calls the same layer and nothing else. The screens you prototype in phase 2 are simply the app's first head.

Screens first and headless first sound like they conflict. They do not - they order different things. Headless first means the app's operations are defined before any screen: that is the contract. Screens first means the screens are built before the real backend. The prototype's stand-in is simply the first implementation of the headless layer: AI defines the operations, gives them stand-in behavior, and builds the screens on top of them. When phase 4 replaces the stand-in with the real implementation, the contract and every screen stay put. From the first prototype to production, the UI never talks to anything but the headless layer.

This pattern is older than AI, and good engineering teams have always used it: business logic can be tested without clicking through screens, one core can serve many faces - web, mobile, automation - and the UI can be redesigned freely without touching what the app actually does.

For AI development it stops being good practice and becomes the foundation. Reasons:

• AI verifies by running commands - deterministic, fast, no browser needed
• Every gate's behavior evidence comes from this layer: real calls, real output
• It keeps AI honest: a feature does not exist until it can be called and tested
• Tomorrow's interfaces - a chat agent, a voice assistant, an automation, another app - call the same layer with zero rework

The playbook turns this from principle into instruction. It tells the AI: build the headless layer before any UI; every feature must be a callable operation with structured output; business logic never lives in a screen; a feature is done only when its operation exists and its test passes. You never have to ask for this architecture - the playbook demands it on every project.

Why AI can be trusted to test its own work

This architecture is what makes AI verification real. AI proves a feature by running it: call the operation, capture the result, compare against the acceptance criteria written at design lock. No browser, no screenshots of code, no "should work." Every feature has a test that runs, and you see the output.

Take a small example: a room booking app whose hard rule is no double bookings. AI calls create-booking twice for the same room and hour, and shows you the output: the first call returns confirmed, the second returns "slot just taken," and a third call lists the day's schedule with exactly one booking saved. Exactly what the criterion demands. That output is the evidence at your gate. You read behavior, not code.

Each build step lands together with its test, in the same checkpoint. A bug fix is not done until a test exists that failed before the fix and passes after it. And the playbook forbids the shortcuts that fake progress: a failing test can never be deleted, skipped, or loosened to force a green result.

You Always Know Where You Are

Every project carries one status file, maintained by AI, written for you. It shows the pipeline with the current phase marked, what is done with evidence attached, what is deferred, what is blocked, and exactly one next step.

Every working session starts the same way: AI reads the status file and tells you where you are, what happened last, and the single next step. You are never handed five questions at once. One decision at a time, one solid step at a time.

The project also keeps a usage log the same way: every session's time, the model used, tokens, and estimated cost - real numbers from the session records, never guesses. At ship, you get the project total in plain language: what the whole build actually cost.

Your Job at Each Gate

Every gate has two layers of checking. AI checks everything with an objective answer - completeness, consistency, tests, counts - and a gate is never even presented until those checks pass. You check the one thing a machine cannot: whether it is right for your business. Both layers must pass; then the gate opens. The clearer the criteria you set up front, the fewer interruptions you get later. You are a judge, not an inspector.

Engineer-type or user-type, the duties are identical - and neither of them reviews code. The engineer's edge is asking harder questions at each gate, not reading diffs.

Can a gate run with no human at all? One can: gate 4 - and only when nothing deviated. You already signed every acceptance criterion at the design lock, so if every test passes and nothing was deferred, there is nothing left for a human to judge; AI reports the pass and moves on. The rule is general: a gate can run without you only when you fully defined and signed its pass criteria at an earlier gate, and nothing deviated since. A deferral, a changed criterion, a flagged risk - any of these reopens the human check. The other four gates stay yours: what you want, how it feels, what the rules are, and whether to ship are not machine questions.

Notice what is not on your side of any gate: reviewing code, writing code, debugging. Your job is judgment. The AI's job is everything else.

And this is where AI development raises the stakes. When AI writes all the code, the leverage moves to the gates: a well-defined gate catches a wrong turn in minutes; a missing or vague one lets it compound for weeks. Defining the right gates - what must be true before work continues, and who is fit to judge it - becomes the core skill of the app builder. Vague gates are just vibe coding with extra steps.

The Tools: Which AI, and How

The process is tool-agnostic, but not every AI qualifies. A chat window that only talks cannot run this playbook. The AI you use must be an agent: it works in your project folder, not in a conversation.

Four requirements, no exceptions:

• It reads and writes files - the code, the spec, the status file
• It runs commands and tests - verification is the backbone of every gate
• It loads written rules at the start of every session - that is how the playbook governs it
• It shows its work - test output, screenshots, reports you can read

As of this writing, four tools clear the bar: Claude Code (terminal and code editor), Claude Cowork (desktop), OpenAI Codex, and Google's Gemini CLI. Plain chat - ChatGPT, Claude, or Gemini in a browser tab - does not: it cannot run a test or keep a status file, so there are no gates, only vibes.

The Claude pair maps cleanly onto the two builders. Claude Code and Claude Cowork are the same agent underneath. Claude Code wears a developer's shell: terminal, code editor, version history. Claude Cowork wears a desktop app: folders, tasks, plain screens. The engineer type will feel at home in Claude Code. The user type should start with Cowork for the spec, the prototype, and every gate review - and let the build and ship loops run on whichever tool can execute tests and keep checkpoints. The tools are converging fast; the requirement list above, not the brand, is what matters.

The agentic code editors - Cursor, Google's Antigravity, VS Code with an agent extension - live in the same family and can run the playbook too. They are built for people who want the code visible on screen. Nothing in this process requires that; nothing forbids it either.

The "how" is simpler than it sounds. Each of these tools has a standard place for standing instructions - a file the AI reads automatically at the start of every session. The playbook lives there. Set it up once, and every session starts governed: the AI reads the status file, tells you where you are, and proposes the single next step. Then you type your opening prompt - like the one in the walkthrough below.

A Walkthrough: The Room Booking App

The phases are abstract until you watch one project go through them. Here is a small one: a firm of twenty people wants an internal app where staff book meeting rooms, everyone sees the day's schedule, and an admin manages the rooms.

Phase 1 - Spec Loop

The whole project starts with one plain message - something you could type today:

AI asks its way to the spec. Who may cancel a booking - anyone, or only the person who made it? When two people want the same room, does someone approve, or is it first-come-first-served? Phones or desktops? Do outside guests ever book? Each answer tightens the draft, and a few answers later the spec is done:

That is the entire phase 1 deliverable. Writing more now is wasted effort: half of it will change the moment you see real screens.

You: typed the opening prompt, answered the questions, pushed calendar sync into the non-goals, locked the spec.
AI: asked the questions, drafted and redrafted after each answer - and kept it to two pages.

Phase 2 - Prototype Loop

AI starts by picking the stack - a standard web framework, chosen by the playbook's criteria - and creating the project in a fresh home on GitHub. Then it defines the API contract - the operations the app will need: list rooms, list a day's bookings, list free slots, create a booking, cancel one. Then it builds the real screens against a stand-in version of that contract, loaded with deliberately ugly data: a room with a sixty-character name, a day with zero bookings, a day with forty, a booking with no note.

Your job is to use it, not admire it. You click through every screen and question the flow. The first prototype lets staff request any time slot, with a pending queue where the admin resolves overlapping requests. You ask the obvious question: why can staff even pick a taken slot? Show only the free ones. One question, and the whole approval queue disappears - the booking form becomes a list of open slots, and overlaps become impossible by design. You also decide the today view should be the landing screen, not a menu item. Each change costs minutes, because there is no backend behind the screens to rewrite.

You: clicked every screen, asked the taken-slot question, moved the today view to the landing screen, locked the prototype - AI will not lock it for you.
AI: defined the contract, built the stand-in backend with ugly data, deleted the approval queue and rebuilt after each decision - and decided nothing itself.

Phase 3 - Design Loop

When the screens feel right, you lock them. AI harvests the prototype into a written spec: every screen, every flow, the contract frozen. Every behavior becomes an acceptance criterion - one testable sentence each.

Locking criteria forces the design questions vibe coding never asks. One remains even after the free-slots-only decision: what happens when two people grab the last free slot at the same moment? First one wins; the second sees "slot just taken." That is a business decision, not a coding decision - you make it, and the criteria record it.

Behind the scenes, AI also designs the data model, the failure handling, and the security rules - engineering work, governed by its playbook. Your part is judgment on the business rules; AI's part is the engineering underneath them. What you sign is the plain-language summary: what the app will do, what it will not do, and what was deferred. AI waits at this gate until you sign. Nothing gets built from an unsigned design.

The same goes for the technology itself. Which framework, which database, where it runs - those are machine questions, and the playbook carries the criteria: boring mainstream tech, the smallest stack that serves the spec, managed hosting that can be undone in one command. The framework was already picked when the prototype started - the screens are built on it; the design loop tests the rest of the picks against the real design and locks the full stack here. You never get asked "which database?" What you get is one line: "Standard web stack, one server, database included, about ten dollars a month - approve the cost?" You approve the bill and name the account it runs under. The technology is AI's call, made by rules you can read.

Unless you want it to be yours. An engineer-type builder can lean in here - name a framework you trust, point at the database your company already runs, veto a hosting choice - and AI treats your preference as a binding constraint. The design loop carries both kinds of calls: business calls are always yours; technical calls are AI's by default, yours the moment you claim one. The process never requires that input. It just accepts it.

You: made the business calls - first-wins on the race - claimed any technical calls you wanted, signed the plain-language summary.
AI: harvested the spec, froze the contract, wrote the acceptance criteria, designed the data model, failure handling, and security underneath.

Phase 4 - Build Loop

AI now implements the real backend to the frozen contract. The rhythm is fixed: one step, its test, a checkpoint. Every acceptance criterion from phase 3 becomes an automated test.

Your involvement here is light but real. When the spec is silent on something, AI stops and asks you - one question at a time, never a batch, in plain language. It does not guess, and it does not "improve" the design on its own. At the gate, you read the coverage report, not the code.

Nothing hides in that report. "Deferred" means you agreed to defer it, and the status file remembers why.

You: answered the occasional one-at-a-time question, read the coverage report, accepted the email-notification deferral.
AI: implemented all five operations, wrote and ran every test including the race cases, checkpointed each step - and kept the status file current.

Phase 5 - Deploy Loop

AI runs the full app locally and walks the golden path: book a room, watch it appear on the today view, cancel it, watch it free up. Then it presents the deployment plan and states the way back before anything moves: previous version restorable in one command, database change reversible. You give the go - AI never deploys on its own. Only then does it deploy in the documented order and repeat the same booking walk against the live link, with the evidence shown to you.

You: read the way-back statement, gave the go.
AI: ran the booking walk locally and on the live link, deployed in order, showed the evidence.

And live is not the end. Next month someone wants recurring bookings. The change re-enters the pipeline at the right door: a new feature goes back to the spec loop, a screen tweak to the prototype loop, a bug to the build loop with a regression test that proves the fix. The status file keeps the history; the gates keep the discipline. The process is a cycle, not a one-shot. An existing app can join the same way: adopt the process and it enters this loop directly, its spec recovered one signed slice at a time as changes touch it.

What to Remember

And starting is small. The playbook is a small folder of plain markdown files - one always-on rules file plus one per phase: point your AI tool's instructions file at them, type one honest paragraph about your problem - like the opening prompt above - and ask the AI to take it from there, one question at a time.

Final Thoughts

Every generation of tooling moves the human up one level. Compilers moved us past assembly. Frameworks moved us past boilerplate. AI moves us past the code itself, but it does not move us past responsibility for what ships.

Gate-driven development is how that responsibility gets exercised without reading code: clear phases, one status file, behavior evidence, and a human signature at every gate. It is a slower start than vibe coding and a much faster finish.