Prompt-to-app tools: what they do, where they stop
The first version is nearly free now. Understanding exactly where that stops being true is the difference between a tool that saves you months and one that costs you them.
Describe an app. Get an app. It works, and it is genuinely one of the more remarkable things software has learned to do.
It also has a boundary, and the boundary is sharper than the marketing suggests. This article is about where it sits and why it sits there, because if you know it in advance you can design around it, and if you do not you will discover it around week three with a codebase you no longer understand.
What they are reliably excellent at
Not damning with faint praise: these are real, large wins.
- The blank page. Going from nothing to a running skeleton used to take a day of setup and boilerplate. It now takes a sentence, and that removes the single biggest barrier to starting.
- Conventional shapes. A CRUD screen, a settings page, a signup flow, a table with filters. Patterns that appear in thousands of codebases are exactly what a model has seen thousands of times.
- Breadth you do not have. Scaffolding a piece of the stack you have never touched, competently enough to get moving, is worth an enormous amount to a small team.
- Throwaway work. Prototypes, spikes, one-off internal tools, demos for a meeting on Thursday. Anything with a short lifespan is pure upside: the long-term costs never arrive.
Where it stops
The boundary is not a difficulty ceiling. It is not that these tools can do easy things and not hard ones. They will attempt something quite hard and often succeed.
The boundary is accumulated context. It appears at the point where the correct next change depends on decisions made earlier that were never written down.
Change one: perfect
Empty repository, clear instruction, no history to be consistent with. The model has complete information.
Change eight: a coin flip
Now there are forty files. Some of them contain deliberate decisions: this table is denormalised on purpose, that retry exists because the upstream service is flaky, this validation lives in two places because one path is public. None of that reasoning is in the code. The model reads the files, infers a plausible intent, and acts on the inference.
Sometimes the inference is right. When it is wrong, what you get is not a crash. It is a second implementation of something that already existed, or a call that skips a boundary it was supposed to go through. Silent, plausible, and compiling.
| First generation | Tenth change | |
|---|---|---|
| Information available | Your whole intent, in the prompt | Whatever survived into the code |
| Failure mode | Obviously wrong: you see it | Plausibly wrong: you don't |
| Cost of a mistake | Regenerate, seconds | Debug unfamiliar code, hours |
| What you can verify | Does it run? | Does it still mean what I meant? |
Why a bigger model does not fix it
This is the part worth sitting with, because the intuitive response is to wait for the next model release.
The missing information is not in the codebase. A larger context window lets a model read more of what exists; it does not let it read a decision that was made in a conversation in March and never recorded. You cannot retrieve what was never written.
Every prompt-to-app tool is doing archaeology on its own output.
Better models make better archaeologists. They do not turn archaeology into documentation.
Working past the boundary
Three practical moves, in rough order of effort.
Write intent down where the tools can see it
A short, factual document in the repository describing what the parts are and the rules between them. Not a wiki page: something in version control, next to the code, that an agent will actually read.
Make the important rules mechanical
"The frontend must not call payments directly" is a sentence a human can ignore. As a check that fails a build, it is a rule. Anything you genuinely care about should be the second kind.
Keep a map that cannot go stale
A diagram maintained by hand is a diagram that is wrong. A map generated from the code and re-checked against it stays honest, which is the only way it stays useful.
Graphlit is a bet on the third one. You draw the architecture; it becomes a typed graph; the code is built against it and then continuously compared back to it. The drawing is not documentation that drifts. It is checked, and when the code stops matching it, that is a report rather than a surprise.
Four boxes, three arrows. No prompt.
Common questions
Are prompt-to-app tools good enough for a real business?
For the first version, often yes. The question is not whether the generated code works but whether you can keep changing it safely six months later. Teams that succeed with these tools tend to get the output into version control early and add architectural checks before the codebase gets large.
At what point do prompt-to-app tools start struggling?
Around the point where a correct change depends on a decision made earlier that was never written down. In practice that is usually a few dozen files in, or the first time you modify something built more than a couple of weeks ago.
Will better AI models solve this?
Only partly. Larger models read existing code better, but the information they are missing (why the code is the way it is) was never recorded anywhere. That is a documentation problem, not a model problem.
Draw it. Then keep it true.
Graphlit turns an architecture drawing into a typed graph, builds against it, and proves the code still matches. Free to start.