Prompt to app is the second rung. You describe an application and a tool builds a working one: sign-in, a database, a deploy. It compresses the first hour or two of a project into minutes, and that is real. It is also the rung where the most people get stuck.
Two categories sit here.
- AI app builders, where a description becomes a running application, with no repository to begin with.
- AI backend and database builders, where a description becomes a schema, authentication, an API and the access rules around them. They sit on this rung because a generated schema is where the damage on this rung concentrates.
As on the rung below, there was no repository until the tool made one, and the conventions in it are the tool's. The difference is that an application holds data, and data outlives the code that wrote it.
What this rung is for
Getting something in front of real users quickly, to learn whether the idea holds. A prototype for a pitch next week. An internal tool with a short life and a handful of users. A working version of a flow that would take a week to explain in a document.
For those, the speed is the point and the costs below are acceptable, provided you know they are there.
Who it suits
- Founders validating an idea, who need users to touch it before paying for it to be built properly.
- Product people and designers who want a working version of a flow rather than a static mockup.
- Developers who want a throwaway prototype, and mean throwaway.
It suits less well anything that will hold money or personal data for years, unless the plan already includes the step off this rung. Be plain with yourself about the ceiling. What this rung produces is a prototype, not a product.
How to tell you are on this rung
- People sign in and their data persists, and you got there by describing it.
- You could not draw the schema or explain the sign-in flow from memory.
- There are no tests, or there are tests you have not read.
- The next feature is one the tool keeps getting wrong, and you are prompting it again rather than changing it.
The last one is the usual sign that you have reached the ceiling. Nothing is broken. It is just not yours.
What it costs you later
- A schema you did not design. Whether a refund is a column or a row of its own, how money is stored, whether absent and zero can be told apart: the tool decided, and wrote none of it down. Each is an edit while the database is empty and a migration once it is not. Designing a feature an AI coding agent cannot improvise explains why the data model is the most expensive thing to change later.
- Access rules nobody can explain. Sign-in and who can read what were generated with everything else. If no one can say which rule stops one user reading another user's records, no one can say the data is safe.
- Decisions nobody made. When a model fills a gap, it picks a data shape, an error path or a default, and the code reads cleanly either way. Human debt is usually a shortcut someone remembers taking. This kind is a set of assumptions nobody knew were there, which is the argument of Vibe coding builds fast, but can you explain it later?
- Month three. These tools are built for the first hour. Adding a feature the tool did not anticipate, getting the code reviewed, or handing it to a developer all start with someone working out what the application actually does. That work is the bill, and it arrives after the demo has gone well.
- Where it lives. Hosting and the database sit wherever the tool put them, and moving either later is a project of its own.
The step off this rung
The rung above, Agent in the editor, is where you own the repository. It is the steepest step in the pyramid, because delegation falls sharply the moment you take on the codebase. Below it you hand over everything and get an application back. Above it you are the author, and every line is yours to explain.
The route across is the same whatever built the application.
- Characterise what exists. Read the schema, the access rules and the main flows, and write down what they actually do.
- Write the requirements it never had, as claims you can test. Writing requirements an AI coding agent can build from covers the form.
- Put tests around the paths that would hurt most if they broke: money, identity, and data you cannot recreate.
- Then change it, one reviewed step at a time.
Taking over a generated prototype works through each step on an application that already has users.
If you know on day one that the application has to last, planning this step costs less than discovering it.