Your AI gave you screens, not an app

Ask a coding agent for a booking app and you get five good-looking screens and an app that does not exist. The list does not open the detail. The tab bar is drawn on one screen and missing on another. The back button goes somewhere odd. One maker who timed it found that wiring screens together took more than half of all AI-assisted build time. The screens were never the work. The wiring is, and prompts are the wrong tool for it.

1. What the wiring actually is

Between any two screens there are decisions a generator skips:

• The kind of move. Does this tap switch tab, push a screen onto the stack, or raise a sheet? Each has different code, a different back behaviour and a different feel.
• What travels. The row you tapped has to arrive on the detail screen as data, not as a copy of the mock-up’s text.
• What is shared. The tab bar, the header style, the theme, the safe-area insets: one source, rendered by every screen, or they drift.
• What happens on the way back. A saved edit should show in the list without a reload.

None of this is visible in a screenshot, which is why screenshot-driven generation gets it wrong: it is copying the part it can see.

2. Why agents reach for web answers

Most of the code an agent has learned from is web code. Left to guess, it builds a mobile app the way it builds a website: a route per page, a header drawn on each page, a back arrow of its own. On a phone that produces exactly the “website in a box” feel, and it produces it confidently.

The fix is not a better prompt. A prompt is prose, and prose about navigation is ambiguous in the same places the agent is weak. The fix is structure.

3. Hand over the navigation as data

Describe the app as a graph: screens, and for each arrow between them, the kind of move. “Diary → Booking: push. Diary → New booking: sheet. Tab bar: Diary, Clients, Services, Profile.” Given that, an agent has nothing to guess about shape, and spends its effort where it is strong: making each screen work.

Better still, draw it. A visual design tool that stores the arrows as data (not as lines in a picture) can hand the agent the graph directly, and the agent’s job becomes filling in a wired shell rather than inventing one.

4. Give it a shell that is already right

The parts every app shares (the tab bar wiring, the provider order, scroll insets, platform branching between iPhone and Android) are the same across apps and the easiest for an agent to get subtly wrong. Hand them over as a skeleton that is already verified on both platforms, and let the agent put screens into it. That is the difference between “build me an app” and “build these seven screens into this app”.

5. Check the wiring, not the screens

Review the result by tapping, not by looking. Open every screen from where it should be reachable, go back, switch tabs, rotate through them. A tool that checks the generated code for the known traps (a tab bar drawn twice, a glass view faded with opacity, a screen with no route) catches more than a human eye on a screenshot.

Where to start

Before your next prompt, write the graph: every screen, every arrow, the kind of each. Hand that over with the design and watch how much less the agent guesses.

The App Builder is that graph as a canvas: screens on a board, arrows that say push, sheet or tab, and a “Send app to agent” that hands your agent the wired shell plus your screens. The agent builds what you drew, not what it inferred.