Guide
You generated a front end. Now make it do something real.
Five steps, three mistakes, and no version numbers — because a guide about tools that ship weekly goes stale in a month if you write down menu items.
The interface arrived in about a minute and it is genuinely good. Then it needs to remember a customer, take a payment, and not show one person another person's data — and that is a different kind of work, which is where most of these projects stall.
The shortcut is to stop building that half. Everything below is about the seam.
The five steps
Decide which half you are keeping
Keep the pages, the styling and the flow — that is the part worth having and the part the tool is genuinely good at. Do not keep the generated tables, auth or access rules; those are the half you are replacing, and carrying them forward is what makes the rest of this awkward.
Get a token that can do exactly one thing
Ask for the narrowest scope that makes your first screen work — reading contacts, say. Resist the urge to grant everything "for now"; a token that starts broad never gets narrowed, and there is no admin scope here to fall back on anyway.
Replace one screen’s data, not all of them
Pick the screen with the least logic and point it at real data. It will surface every assumption the generated code made about shape, loading and errors — cheaply, on one screen, instead of expensively across twelve.
Delete the generated data layer once, deliberately
Do it as its own step, not gradually. A half-migrated app with two sources of truth is worse than either version alone, and it is the state most of these migrations quietly stall in.
Subscribe instead of polling
Once it works, stop asking repeatedly whether anything changed and get told instead. This is usually the difference between an app that feels generated and one that feels built.
The three that make it painful
Rebuilding your screens to match our shapes
Do the opposite — map at the edge. Keep your components as the tool wrote them and translate in one place, so a change on either side is one file rather than a sweep.
Carrying the generated auth "for now"
Auth is the piece most likely to be quietly wrong in generated code, and it is the piece you least want to debug later. Replace it in the first sitting, before you have twelve screens depending on its assumptions.
Asking the assistant to "connect it to the API" in one prompt
It will invent endpoints that sound plausible. Give it the published capability list and the scope names first, then ask for one screen. Grounded, it is excellent at this; unguided, it writes fiction that typechecks.
What to hand your assistant
Give it the objects and their scope names before you ask for code. Grounded in a real capability list it does this well; unguided it invents endpoints that sound plausible and typecheck.