The first turn does less on purpose
Ask Vibes for an app and the first generation used to arrive knowing everything: half-written permission rules, web-audio bleeps wired to a to-do list, a defensive rulebook for collaboration you never asked about. We spent the last week pulling most of that out. The first turn now deliberately does less — and the apps got better, because the platform learned to remember what it skipped and offer it back at exactly the right moment.
Half-taught rules are worse than no rules
The forcing insight came from an audit, not a theory. We walked seven featured and production apps and asked: which of these actually needed access rules on day one? The answer was none. Every one of them functions wide open at launch — and the only thing that decided whether permissions could be added later without a rewrite was whether the documents already carried their keying fields: who wrote this, which parent it belongs to.
Meanwhile the prompt that tried to teach access control up front was producing exactly the bugs you'd expect from writing security rules with partial context. The old first-generation prompt carried a whole defensive rulebook — owner-lockout warnings, don't-invent-collaboration guards, tombstone routing — that existed only to patch the failure modes of teaching access rules before the app's data model existed. Half-taught rules produce bad rules. (We've been here before: the same reflex once made every generated app owner-gated by default.)
So we made a clean break. The first generation writes the app and its seed data, and teaches no access code at all. What it learned instead is a compact lesson about the object graph: stamp the author on every document, carry the parent id, use deterministic ids for one-per-user records, keep sharing toggles as plain fields, and don't write secrets. That's the data shape that keeps every future permission design possible — because data written before rules exist can't be un-exposed, the keying fields have to land on turn one even though the rules themselves shouldn't.
Get posts like this in your inbox
One email field. Real updates. No algorithm required.
The prompt went on a diet
The same logic swept the rest of the baseline. About 2,300 words of access-control teaching — five worked examples, roster patterns, member-only channels — moved into a skill that only rides along when your prompt is actually permission-shaped: privacy, teams, members, roles, invites. Audio moved behind a cue too: the baseline used to tell the model to wire sound effects into every app's core actions, so budget trackers arrived beeping. Now sound is taught only when you ask for something sonic — and the restraint rules ("never autoplay on load") travel with it, showing up exactly when they're relevant.
The assembled prompt for a plain single-user app shrank about 24%. Nothing was deleted — the teaching is all still there, conditioned on the one signal that matters: did this person ask for something that needs it. The baseline teaches what every app wants — seeded life, motion, a working data model. Everything only some apps want became opt-in.
Deferral is a feature, so it needs a memory
Skipping work is only safe if something remembers what was skipped. When the first turn decides your app will eventually want a backend or access rules, the classifier that routes your prompt now records the deferred capability and a plain-language reason, in your own terms: "to receive your webhook," "so only you can edit." That intent is persisted with the app.
That memory surfaces two ways.
The gold chip. Once the first build settles, a distinguished gold chip appears above the ordinary suggestion chips, labeled with the benefit in your own words: "to receive your webhook." (Deliberately no file names — the benefit is the offer.) It's an offer, never an auto-fire — tapping it is the consent moment, and the tap kicks off a platform-authored turn that narrates its plan before writing the code (for backends, that means the cache-into-your-own-database pattern, with honest degradation when a feed goes away). Dismiss it and it's gone for the session; it retires durably only when the thing it offered actually exists in your app's files.
The publish-time access wizard. The first time you publish an app that has never defined who can open or edit it, the Publish button doesn't just ship it. It pauses in a held "Securing…" state and asks the platform to write the app's access rules first — with full context now: the real schema, the seed data, everything the first turn deliberately waited for. The streaming plain-language explanation of the permission model is the progress bar, and the moment it's done, the app publishes on its own. It's fail-closed with a visible escape: if the rule-writing errors out, the app stays unpublished and you get Retry plus an explicit "Publish without access controls." Apps that already have rules skip all of this — it fires exactly once.
Even the wait teaches: while the build streams, the status line — "writing code…", "almost ready…" — renders as a button-shaped pill in the exact spot where Publish will appear. By the time the app is done, your eye already knows where the next action lives.
And the turn we freed up does research
Doing less on the visible path bought room on the invisible one. Every vibe's opening description already lives in a vector index, so the moment you fire a first prompt, a background job embeds it, finds the five most similar published apps, and folds what they shipped into a brief the next turn can draw on — "apps like this one added photo upload and a share link." It reuses the exact visibility gate as the on-page related-vibes strip (the same function, not a copy), so private apps can seed nobody's brief, and it fails closed: nothing similar means nothing persisted, not noise.
Why smaller is faster and safer at once
The thread through all of it: the first turn's job is a working app in front of you as fast as possible, plus a data shape that keeps every door open. Permission design, backend wiring, and sound belong to moments when the context exists to do them well — and the platform's job is to hold those intents and hand them back as offers, not to guess at them up front. Deferral stopped being an omission and became a product surface: a chip you can tap, a publish button that finishes the job.
The first turn does less. You get more.
See what a first turn builds
One prompt, a working app, and the rest offered when you're ready.
Start building →