Building an app with AI

Which part of an app does AI actually build?

An answer that judges models fairly needs a number, and we took ours from one of our own products, because it is the only project we can count to its last line.

Our freelance marketplace plugin, rgb-freelance, has three folders. The screens folder is 3,231 lines, the logic behind the screens is 11,597 lines, and the look, meaning CSS and JavaScript, is 3,135 lines. That is 17,963 lines in total, in which the share of the screens is a little under a fifth. This is not a mobile app and we do not claim it is; it is a web product with users, projects, messages and files, and the shape of its division is the shape you see in a mobile app too.

Now lay the map over the models. That one fifth, the screens, is exactly what models genuinely build well today: forms, lists, empty states, responsive layout. Those middle two thirds, meaning who sees what, where the money is calculated and what happens when the server does not answer, are exactly where generated code usually looks complete and is not.

So the claim "build the app with AI" is neither a lie nor the whole story. More precisely: it makes the fastest part faster. If that is your expectation you get a real gain; if your expectation was a finished product, you discover the difference when you have real users.

Prototyping speed: what genuinely changed

Before the list of risks, an admission that gets made too rarely: something here genuinely changed, and belittling it is as careless as inflating it.

What used to be the hardest part of starting a product, getting an idea to something you can hold and show somebody, is now possible inside the same meeting. Three screens with fake data, a sign in flow, and a list that scrolls. For an app this matters even more than for the web, because people judge an idea differently on a phone than on paper.

The real value of that speed sits where it is least considered: the cost of throwing work away. When a first version takes half a day, abandoning it is easy too. Teams that spend months on the first version become attached to it in proportion, and let go of a bad idea later. This is the one place where cheap code is genuinely a strategic advantage rather than a saving.

And let us state the boundary plainly, because it gets blurred everywhere: a prototype is not a product. A prototype that works has still seen no real user, no weak network, and nobody deliberately sending wrong input. The distance between those two is the same two thirds from the previous section, and no model shortens it for you. If you have met this argument from the web side, vibe coding, its upside and its dangers takes the same position with more detail on the code.

Four things that break in an app a model wrote

These four are not written from guesswork; each has a source, and each source is the word of the company selling the tool.

One, the key inside the app. A misunderstanding has to be cleared first: not every key inside an app is a danger. Google own page about Firebase keys writes that they are "public by design" and only identify your project and app, and that if your setup follows the guidelines they do not need to be treated as secrets and it is safe to include them in your code. But that same page carries an explicit exception which is exactly what shows up in generated apps: never include the Gemini Developer API in the allowlist for a publicly accessible key. Meaning a model that drops the AI key next to the Firebase key inside the app has apparently done the same thing and has actually left your account open.

Two, the permission nobody wrote. Generated code usually builds the optimistic path fully and the pessimistic path not at all. The OWASP Mobile Top 10 gives its first place to improper credential usage and rates its prevalence common, its detectability easy and its impact severe; meaning this class of mistake both happens often and is found easily, which is a bad combination. The first question to ask generated code is this: where was it checked that this user is allowed to do this?

Three, code that cannot be maintained next month. Unlike the previous two this risk is not a security one, and for that reason it surfaces later. The problem is not bad code, it is ownerless code: four pieces from four different answers, each with its own pattern, and nobody knowing why any of them is there. It has a simple fix that has nothing to do with AI: before accepting any piece of code, be able to say in one sentence what it does.

Four, licensing. Here too the reality is more moderate than either popular story. The GitHub documentation about Copilot writes that suggestions are checked against public code, and that when a match is found the URLs of the files and the name of the license that applies to that code are logged so you can decide yourself. The same page says these matches typically occur in less than one percent of suggestions, and two more important points: the check runs only for accepted inline suggestions, and code you wrote yourself or a suggestion you altered is not checked at all. So a measuring tool exists, but it is limited, and having it on is a setting rather than a universal default.

The right order: specification first, then code

All four items above share one root and it is not technical: a model was asked to write code while nobody had made the decisions yet. A model does not decide, it fills the blank, and it fills the blank with the most conventional thing it has seen.

So change the order. Three passes, in this order, and skip none of them.

The first pass is the specification and contains no code: the feature list in plain language, the shape of the data, and who sees what and changes what. If you have read what an app backend is, this is that access table, and this is exactly its place, before generation.

The second pass is generation, and its input is the output of the first pass, not your verbal description. The difference between those two is large: with the feature list and the data shape in front of the model, there is nothing left to guess, and the code it produces can be compared against a document.

The third pass is review, and it should not be done in the same session that generated the code. A separate pass with one specific question: where does this code assume the user is telling the truth. That pass is what appears in the next section as a recipe.

One rule holds across all three and is the simplest of them: no generated code you cannot explain in one sentence enters the project. Not because it must be wrong, but because when it breaks nobody knows where to start. Coding with AI opens the same rule from the programming language side.