AI That Builds Apps: How It Works Under the Hood

The request usually shows up in Slack on a Tuesday afternoon. Support has been eating refunds above $200 without much scrutiny, and the head of support wants one screen: every refund over $200 in the last thirty days, the customer's lifetime spend next to it, and a button to flag the ones that look like abuse. Right now somebody exports a Stripe CSV, pastes it into a sheet, and does a VLOOKUP against a Postgres export. It takes forty minutes and it happens twice a week.

Somebody on the team types that sentence into an AI that builds apps and a working screen comes back in under a minute. This is the part everyone has seen in a demo. What almost nobody explains is what actually got built. Two products can accept the identical sentence and produce two completely different artifacts: one emits a React application with a server, a database client and a deploy target, the other emits a structured definition that an existing runtime renders. The screens can look the same. Everything downstream of that moment, who can review the change, what an attacker can reach, what breaks in six months, is different.

This is the piece you want to understand before you pick a tool, because the choice is not really about generation quality. It is about what is running in production afterward.

What AI That Builds Apps Actually Produces

Strip away the marketing and there are exactly two outputs a model can hand you.

The first is code. The model writes files: a Next.js page, a React component tree, an API route, a database query, a package manifest, sometimes a Dockerfile. Something then has to install dependencies, build it, and run it on a server somewhere. The output is a real application in the ordinary sense, with all the freedom and all the operational weight that implies.

The second is a declarative definition. The model does not write executable logic. It writes a description of a screen in a fixed vocabulary the platform already understands, usually JSON: this is a metric tile bound to this query, this is a table with these seven columns, this is a filter on the status field, this is an action button that calls this connected tool with these parameters and asks for confirmation first. A runtime that shipped with the product reads that definition and draws the screen. Nothing new is compiled. Nothing new is deployed.

Both are legitimate. They fail in opposite directions, which is the useful thing to know.

Path One: Generated Code, and What It Really Costs

When the model writes code, the ceiling is high. You can build a scheduling engine, a custom pricing calculator, a weird drag-and-drop editor, anything an engineer could build, because it is the same medium an engineer works in. If your requirement genuinely has no shape in common with a dashboard, this is the only path that gets you there.

The cost lands in four places, and every one of them is a place teams get surprised.

Runtime surface. You now own a running application. Dependencies, a build pipeline, TLS, an origin, environment variables, logs. The model produced it in ninety seconds, but the thing it produced has the same operating requirements as anything else you deploy.

Credential handling. This is where the real damage happens. A model asked to "connect to the database" will happily reach for whatever credential is available. In Supabase projects that is often the service role key, which bypasses row-level security entirely. If that key ends up in anything that reaches the browser, an environment variable without the server-only prefix, a client component, a debug endpoint, the app has effectively published the whole database. Security researchers auditing publicly deployed applications generated on AI app platforms have published findings that a meaningful share shipped with database access rules left open or absent. The failure is not exotic. It is the default outcome when nobody with a security instinct reads the generated files.

Query shape. Models write plausible SQL, not careful SQL. SELECT * against a four million row events table with no limit and no index hint reads fine and takes your primary down at 9am. The generated code is syntactically correct, which is exactly why it slips through review.

Drift. Generated code is normal code, so it rots normally. A dependency ships a breaking change, an API deprecates, the schema gains a column. Now you are maintaining an application nobody on the team wrote and nobody fully read. Six months later the person who prompted it has left and the fastest fix is to regenerate, which quietly discards every manual patch applied since. Teams evaluating this tradeoff in more depth usually start with a broader survey of the category, and an honest look at what AI app makers get right and wrong is a reasonable next stop.

Path Two: Declarative Definitions, and Where the Ceiling Sits

The declarative path inverts every one of those properties. The model's entire job is to choose components and bind them to data. It cannot write a loop, cannot open a socket, cannot import a package, because the output format has no way to express those things.

A typical component vocabulary is small on purpose. In Skopx, an app is assembled from metric, table, chart, list, text, filter, action button, section, divider, stat grid, kanban, timeline, progress, callout and image. Data comes from one of three places: a connected database over read-only SQL, a connected tool such as Stripe or HubSpot or Jira, or fixed values typed into the definition. Apps stay private to the person who made them or get shared with the organization. Every action button is an explicit click and asks for confirmation before it fires.

Read that list again as a security engineer rather than a builder. The read path is read-only by construction, not by convention. The write path is not a code path at all: it is a named tool call with a fixed parameter shape, gated behind a human click. A prompt injection buried in a customer's support ticket text cannot talk the app into deleting rows, because the app has no mechanism for deleting rows. That property comes from the format, not from a filter someone remembered to add.

The ceiling is the honest cost. If your requirement is not expressible as those components arranged over data you already have, a declarative builder does not stretch to meet you. There is no escape hatch to arbitrary code, and pretending otherwise is how people end up disappointed two weeks in. The right mental model is a very good internal tool builder with sharp edges filed off, not a general-purpose development environment.

How the Two Approaches Compare Where It Matters

The row worth sitting with is "worst case from one bad prompt." That single asymmetry explains most of the disagreement between engineers and operators about these tools. The operator is comparing a good outcome to forty minutes of spreadsheet work. The engineer is comparing a bad outcome to a breach notification.

Security: Where AI That Builds Apps Gets Dangerous

Three specific mechanisms cause nearly every incident. None of them are subtle once you know to look.

The credential with too much reach. Every generated app needs to authenticate to your data. If the model is handed an admin-scoped key, or picks one up from an existing environment file, that app's blast radius is the entire database regardless of what the screen displays. The screen might show one team's tickets while the underlying connection can read payroll. Fix: connect with a role that can only read what the app is allowed to show, and verify the role, not the UI.

The key that crossed the browser boundary. Server-only secrets end up in client bundles constantly in generated projects because the framework's convention for marking them is a naming prefix, and models are not reliable about naming conventions under pressure. Fix: open the deployed page, view source, search the bundle for your key prefixes. It takes two minutes and it is the single highest-yield check on this list.

The action with no human in the loop. The most dangerous generated app is not the one that reads too much. It is the one that writes, on a schedule, driven by text it read from somewhere. Ticket bodies, email subjects and CRM notes are attacker-controlled input in any business that serves the public. If a model reads that text and can then call a write API without a person confirming, you have built a remote code path for your customers. Fix: no unattended writes from AI-composed parameters. Every mutation gets a click.

There is a fourth thing, less dramatic, that costs more money in aggregate: nobody deletes these apps. An app built for one quarter's launch keeps holding a live database connection two years later. Whatever you adopt, keep a list of what exists and what each one connects to.

The Step Most Tools Skip: Reading the Real Data First

Here is the difference between a demo that impresses and a screen someone uses on Monday.

A model designing a layout from a schema alone is guessing. It sees a column named status and assumes a filter with a handful of options. It sees description and assumes it fits in a table cell. It sees amount and reaches for a bar chart. Then the app hits production data and every guess is wrong: status has 40,000 distinct values because someone stuffed free text into it, description averages 900 characters and destroys the row height, and amount spans six orders of magnitude so the chart is one visible bar and two hundred invisible ones.

The fix is not a better prompt. It is running the query first and profiling what comes back before choosing components. Skopx does this ahead of design: it executes the query and reads a profile of the actual result set, column types, value ranges, text lengths, so the layout is chosen against real data rather than against a schema's promises.

What a profile actually changes:

• Cardinality decides the control. Three to twelve distinct values become a filter chip row. Thousands become a search input. This is the single most common layout mistake in generated dashboards.
• Text length decides the container. Under about sixty characters goes in a table column. Multi-paragraph text needs a detail view or it will make every row unreadable.
• Null rate decides whether the column exists. A field that is empty in 94 percent of rows is not a column, it is a footnote, and a metric computed over it is misleading.
• Numeric distribution decides the mark. Values clustered tightly suit a bar chart. Values spanning many orders of magnitude need a formatted stat or a log scale, otherwise the chart communicates nothing.
• Row count decides pagination and defaults. Forty rows can render as a list. Four hundred thousand rows need a default filter, or the first load is the last thing that page ever does.

If you are evaluating tools, this is a concrete thing to test. Point two candidates at your messiest real table and see which one produced a layout that survives contact with the data. Most of the perceived quality gap between products in this category comes from this one step rather than from model choice. The same principle carries over to reporting surfaces generally, which is why a careful dashboard builder evaluation looks at data profiling before it looks at chart styling.

What Declarative App Builders Cannot Do

This is the section vendors leave out, so let me be direct about it, including about our own product.

Skopx apps read from connected systems and take actions through connected tools. They do not store their own records, and there is no form component that creates new data. That is a real boundary with real consequences.

It means those apps are consoles, dashboards, review queues and admin views over data that already lives somewhere else. A refund review screen over Stripe and Postgres: yes. An operations console showing yesterday's failed syncs with a button to retry each one through the connected tool: yes. A pipeline view over your CRM with a button that updates a deal stage: yes, with a confirmation click.

An application that must be the system of record is not something Skopx does today. If you need an applicant tracking system where candidates are created and their history lives inside the app, that is not this. If you need an invoicing system that generates and stores invoices, that is not this. If you need a delivery management app where dispatchers create delivery records, that is not this. Those require the app to own a data store and to accept structured input, and a read-plus-action model does not cover them.

The general test: write down where the data would live if the app did not exist. If the answer is "in Postgres, in Stripe, in HubSpot," a declarative console fits. If the answer is "nowhere, the app creates it," you need something that owns storage and forms, and you should look at builders designed around that, starting with an overview of what no-code AI app builders actually cover.

Knowing this in advance is worth more than any feature list. Most disappointment with these tools is a mismatch between "app" meaning a view and "app" meaning a system.

Choosing a Path Without Regretting It

Run these questions in order. The first "yes" answers the question.

1. Does the app need to store records that exist nowhere else? If yes, you need storage and forms. A read-and-act console cannot do it, no matter how good the generation is.
2. Does it need logic that is not "query, filter, display, act"? State machines, recursive calculations, custom auth flows, real-time collaboration. If yes, generated code or an engineer.
3. Will it face people outside your company? External exposure raises the review bar sharply. Generated code aimed at the public internet needs an actual security review before launch, not a glance.
4. Is it a view over systems you already run, used by your own team? This is the sweet spot for declarative. Build it, share it, move on.
5. Is it disposable? A screen for one launch week is fine to generate loosely. Something four teams will depend on for two years deserves the same scrutiny as any other production system.

For teams that mostly answer "four," the practical calculation is about who can own the result. A declarative app can be maintained by the operations lead who understands the data, because reviewing it means reading a list of components and checking their bindings, and that is a skill an operator already has. Generated code needs someone who can read a diff. That is a staffing decision more than a technology one, and it usually decides the outcome. The Team plan that covers this path is $16 per seat per month with 2.3 million AI tokens included per seat and no API key needed, with full details on the pricing page.

How to Prompt Either Kind of Tool Well

Whichever path you pick, prompt quality follows the same rules, and they are less about phrasing than about supplying facts the model cannot infer.

Name the source and the exact tables or objects. "Our Postgres, tables refunds, customers, orders" beats "our data" by a wide margin, because it removes the model's need to guess joins.

State the filter that defines the working set. "Refunds over $200, last 30 days, excluding test mode" is a specification. "Show me problem refunds" is a mood.

Say who reads it and what they do next. A screen for a support agent processing a queue looks nothing like a screen for a VP glancing at a number, even over identical data. The audience determines density, sort order and default filters more than any other input.

Describe actions as explicit verbs against a named system. "Button that adds a review_flag tag to the customer in HubSpot" is buildable. "Let them mark it as bad" is not.

Then iterate on the built thing rather than rewriting the prompt. Both kinds of tool respond better to "the table should sort by amount descending and drop the currency column" than to a rewritten paragraph, because a targeted change touches one binding while a rewrite regenerates everything and loses your earlier corrections. If you want a longer walkthrough of that loop with worked examples, this guide to building an app with AI covers the iteration pattern in more detail.

FAQ

Does AI that builds apps write real code, or just configuration?

Both exist, and the product should tell you which. Code generators emit files you can read, deploy and eventually maintain. Declarative builders emit a structured definition that an existing runtime renders, with no new code shipped. Ask the vendor a plain question: "after I build an app, what new code is running that was not running before?" If the answer is "none," you are on the declarative path, and your security review is about data connections rather than about source files.

Is a declarative app automatically safer than generated code?

Safer by default, not safe by definition. The structural wins are real: read-only queries, a fixed component set, actions restricted to named tool calls with confirmation. But the app still inherits whatever the connection can reach. If you connect a database role that can read every table, a declarative app can still surface data the viewer should never see. Scope the connection to what the app needs, and check sharing settings before an app goes organization-wide.

What happens when the underlying schema changes?

A renamed column breaks a declarative app loudly and locally: the bound component fails and you repoint it in place. Generated code fails less predictably, sometimes silently, because the query might still run and return the wrong thing. Neither approach protects you from a schema change nobody announced, so if your data team ships migrations regularly, agree on a notification path before you build screens on top of their tables.

Can I export the app and take it with me?

With generated code, usually yes, and that portability is a genuine argument for that path. With declarative definitions, you can typically export the definition, but the definition only means something to the runtime that reads it. Treat it as configuration you can archive and re-import rather than as an application you can host elsewhere. This is a fair reason to keep genuinely long-lived, business-critical systems in code you own.

How much should one app try to do?

Less than you want. The apps that get used are the ones that answer one question or handle one queue. The apps that get abandoned are the ones that tried to be a department's whole workspace, because every added section made the page slower and the defaults worse for everyone. Build the refund review screen. If the same team then needs a chargeback screen, build a second app rather than a second tab.

Do these tools replace engineers?

They replace a specific, unloved slice of engineering work: the internal screen that nobody wants to own, that gets deprioritized for two quarters, that operations papers over with a spreadsheet in the meantime. Anything with real logic, real storage or real external exposure still wants an engineer. The honest framing is that this shrinks the internal tooling backlog rather than the team, and teams weighing that against traditional low-code app builder options usually find the difference is speed of the first version, not the ceiling of the tenth.

The Short Version

An AI that builds apps is doing one of two things: writing code that you will then operate, or writing a definition that something else renders. The first buys you an unlimited ceiling and hands you a production system to secure and maintain. The second caps what you can build and removes most of the ways it can hurt you.

Neither is the correct answer in general. But you should know which one you bought, because the security review, the maintenance plan and the person who owns it on a Tuesday afternoon all follow from that single fact.