If AI can generate an app, what's an app builder even for? Here's the honest answer from inside one: AI is brilliant at the blank page, and useless at year two. Unless it sits inside a framework that carries everything the demo skips.
The question deserves a straight answer
The question isn't silly. From the outside, the logic looks airtight. Frameworks and app builders existed because writing software was slow and required rare skills. AI now writes software in seconds, from a sentence. So the middle layer is dead weight. If you build app-building software for a living, as I do, you've heard a version of this every week for two years. Sometimes as a question. Sometimes as a eulogy.
The people asking aren't wrong about what they've seen. A model produces in thirty seconds what used to take a sprint. Any answer that starts by minimizing that will be dismissed, and should be. So let's start from the other end.
What AI does excellently
AI has solved the blank page. Ideation, first drafts, scaffolding, boilerplate: the whole from-nothing-to-something phase of building has gone from days to minutes, and the something is often good. Exploring five variants of a flow used to be a budget question. Now it's a coffee break. The tedious transcription work that filled the middle of every project, the code that is neither hard nor interesting, is exactly what these models produce best.
I mean this concession fully, not tactically. It's a real, permanent gain, and it lands where our industry's costs were dumbest. Nobody's professional pride should be invested in hand-typing boilerplate.
But look at where the gain lands: at the beginning. Everything I just listed happens in the first week of a project's life.
What still requires the framework
Now run the tape forward. The generated app works, it ships, time passes. And time is where the demo's assumptions die.
Software that lasts needs an architecture that stays coherent as it grows. Screen thirty has to obey the same conventions as screen three, or every change becomes archaeology. It needs output quality that holds on real devices, with real data volumes, under real OS updates, at the level app stores and users actually demand. It needs maintenance as a process: someone watching the deprecations, the API changes, the security patches, for years, without being asked. And it needs consistency, visual and functional, which is a property of the whole product, not of any single generation.
That maintenance load isn't an abstraction, by the way. It has a calendar. Apple: since April 28, 2026, every submission or update must be built with the latest SDK, a bar that moves up every year. Google Play: your app must target an Android API level less than a year old or updates get blocked, and after two years the app stops being visible to new users. Meta ships a new Graph API version roughly every quarter and retires each one after two years, at which point calls simply return errors. Add the payment, ads and analytics SDKs riding their own cycles, and you land on the industry's standard estimate: maintaining an app costs 15 to 20% of its initial development budget, every year. None of that work shows up in a demo. All of it is mandatory.
Generation is an event. Those four things are processes. A model, however capable, fires at time T and moves on. That's the asymmetry the framework question misses: AI is brilliant at the blank page and useless at year two. Not because it writes bad code. Because year two isn't a code-writing problem, it's an ownership problem. And a framework is, structurally, the thing that stays. Opinions encoded, invariants enforced, an engineering team amortized across every app it carries.
I'm not the only one landing here, by the way. From the code-framework side, Ayobami Ogundiran has argued that AI made frameworks more important, not less, because agent state, asynchronous UIs and browser-native agents are exactly the kind of new problems that demand new abstractions. His argument is about the new problems AI adds. Mine is about what time does to any app. The two point the same way: the layer that carries structure doesn't lose value when generation gets cheap.
So the conclusion we reached, building an app platform in the middle of this wave, was almost geometric. Don't put AI in place of the framework. Put it inside.
AI wired into the framework
"Inside" means each AI capability plugs into the platform's guarantees instead of bypassing them. The clearest illustration is the furthest we've pushed it: the AI Extension Builder. The customer describes a custom section in natural language. The assistant generates its code, renders it live, and what comes out plugs into the platform's own APIs: geolocation, content, push, commerce data. You can keep prompting, or open the code and edit it directly.
Now look at the economics of that, because it's the same arithmetic I defend elsewhere about the real cost of freedom. Whatever app you're building, most of it already exists in formalized form: lists, accounts, search, push, payments. Features that have been studied, optimized and debugged against years of production. Asking a model to regenerate them is asking it to re-create, quickly, problems that were already solved slowly. So the split writes itself. The platform carries the 90% that isn't specific to you. The AI builds the one part that is genuinely yours, the part no roadmap could have anticipated, in a dedicated section.
Picture a gym app. Class schedules, memberships, push notifications, the coach's content, payments: all of it comes with the platform, studied and debugged years ago. What doesn't come with it is the feature this particular gym lives by, say a real-time occupancy gauge, updated by the staff from the front desk, with a push when the floor frees up. No backlog anywhere contains that. The owner describes it, the AI builds it, and the section calls the same push and member APIs as everything else in the app. Generation gets spent exactly where it produces something nobody else could have shipped, and nowhere else.
And because the generated section lives inside the frame, it inherits everything the frame guarantees. The hosting, the design system, the deployment path, the API surface. That's the ownership layer a standalone generator leaves you without. It also bounds the risk: if your custom section turns out to be a bad idea, the blast radius is one section, not the app. The frame doesn't just make AI output safer. It makes being wrong cheap, and being wrong cheaply is the condition for experimenting at all.
When a customer needs a feature the platform doesn't have, the answer used to be "wait for the roadmap". It isn't anymore, and it isn't "here's a raw code generator, good luck" either. The genesis of that feature is a story of its own, and my colleague Dumè tells it. (The same wiring runs through the smaller assistants in our back-office, a palette generator whose output lands in the design system's semantic color roles, drafting tools whose output lands in the content model. The Extension Builder is just where the pattern is easiest to see.)
My colleague Muriel takes the public form of the question, will AI kill app builders, from the user's side. Two years into the "AI killed the framework" era, our conclusion is the opposite of the eulogy. Generation got cheap. So everything generation doesn't do, architecture, guarantees, maintenance, coherence, got relatively more valuable. The framework was never the slow part we tolerated. It's the part that stays.
Mathieu Poli — Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI — and everything that happens when the three meet. · X: @hellomathieup
Top comments (0)