Build an app without coding: what that really means
You can build a working app today by describing it, without writing code yourself. What you cannot reliably do is take that app all the way to something other people depend on without ever reading any of it. Both halves of that are true at once, and most writing on the subject picks one and ignores the other.
Where exactly the line sits is the useful question, and it has moved a long way in two years.
What genuinely works now
Describing an application and getting back one that runs is no longer a demo. A tool with a plan step, a code step and a compile gate will produce a working interface, wire up state, handle the ordinary interactions, and show you the result running.
- Internal tools. A form that writes somewhere, a dashboard over data you already have, a small utility that saves a manual step. These are the strongest case by a distance.
- Prototypes for testing an idea. The whole point is throwing them away, so the bar is that it runs and someone can use it.
- Anything you would otherwise not have built. The realistic alternative to a generated tool is usually a spreadsheet and a manual process, not a hand-built application.
- First versions. Getting from nothing to something running is the part generation is best at, and often the part that stalls a project.
Where it stops being enough
The failure is not usually a dramatic one. It is the last ten per cent, and it shows up in a specific way: the change you want becomes harder to describe than to make.
You want that spacing slightly tighter but only on mobile. You want this one edge case handled differently. You have said it three ways and got three wrong answers, and typing the two lines yourself would have taken a minute. That point arrives in almost every project that survives past the first version.
It is why a builder with no editor is a trap. Adrian ships a full editor beside the preview for exactly this, which sounds like a small feature and is the difference between finishing something and negotiating with a model about it.
Compiling is not the same as working
The specific risk of building without reading code is that you lose the ability to tell the difference between an app that works and one that only appears to. A generated app can type-check, load, and quietly omit half of what you asked for — a filter wired to nothing, a save button that saves nothing, a comment where a feature should be.
A developer notices. Someone who never opens the code does not, until a user does. That is why the checks that run after the compile gate matter more for non-coders than for anyone else, and why generated apps compile but do not work is worth reading before you trust a green result.
You still own what comes out
Not writing the code does not mean not having it. What a builder produces should be a normal project in a folder on your disk — files you can open, put in version control, hand to a developer, or move somewhere else entirely.
This is worth checking before you commit to any tool, because it is the difference between a starting point and a dependency. If the output only exists inside someone's platform, you have not built an app; you have configured one. With Adrian the project is a folder, and when the day comes to hand it to a developer, that is all they need.
What it costs to try
The local path is free: models run on your own machine through Ollama, with no account, no API key and nothing metered per build. If your machine can hold a reasonable model you can build as many apps as you like for nothing, which matters when the first three attempts are throwaways.
Bringing your own provider key is also free of any markup — you pay the provider directly — and hosted agents are the paid tier for when you would rather not manage either. What each option actually costs covers the trade properly.
It is also how a lot of people start reading code
There is a version of this where never seeing the code is the goal, and a version where generation is how you get close enough to start understanding it. The second is more common than the marketing suggests.
Reading a working application that does something you wanted is a considerably better introduction than a tutorial, because you already know what it is supposed to do. Plenty of people arrive wanting to avoid code entirely and end up making small edits within a week — not because they had to, but because the gap between wanting a change and describing it got annoying enough.
The honest summary
Building an app without coding is real, and it works best when the app is small, the stakes are low, and you are the one who will use it. It is weakest when the thing has to be maintained for years, handle other people's money or data, or scale — not because generation cannot start those, but because finishing them is still engineering.
The most useful way to hold it: this removes the barrier to getting started, which for most ideas was the barrier that mattered. It does not remove the work of finishing, and a tool that tells you otherwise is one to be careful with.