# We let an AI write code inside our no-code platform. Generating it was the easy part. > Source: > Published: 2026-07-13 11:24:13+00:00 A no-code platform that generates code sounds like a contradiction. It isn't — but it pays to be precise. "No-code" actually covers two different worlds. There's wiring an app's logic together yourself in a visual interface — which is still, fundamentally, programming. And there's configuring pre-built blocks without ever touching the logic. We're firmly in the second camp. So when we generate code with an AI, it isn't to turn you into a programmer: it's to produce the one piece you're missing, the day your need outgrows the catalog. Generating that piece, in 2026, is nothing special — everyone can do it. What kept us busy was the other end of the problem: what does it take for a piece of app generated by an AI to still be there — alive, safe, maintainable — long after the prompt? Let me say it again, because it's counterintuitive: the hard part isn't the generating. A model that spits out plausible code is everywhere now. What matters — and what's hard — is getting that code to fit in: to plug into the rest of the app, and to hold up over time. Here's the concrete flow, from the back office: you describe the section you want. The assistant generates it and renders it live, in context; you refine with the prompt, or edit the code directly when you want to take the wheel. So far, nothing you haven't seen elsewhere. The difference is underneath. The section doesn't run in a vacuum: it can reach into the app — who's signed in, the content you've already published, the phone's location or camera — through a set of capabilities the platform opens to it, and nothing else. So what comes out isn't a snippet to paste somewhere else: it's a section that lives in the app — and that will have to keep living there. That "keep living there" is where all the work is. The part you'd expect — validating the output, stopping the AI from doing anything stupid — is table stakes. We do it; it's not remarkable. What's more interesting: our guardrails aren't there first for security. They're there for longevity. A narrow, reliable surface survives years of updates; an "anything goes" one breaks the first time the ground shifts. Three choices in that spirit. We keep it narrow, on purpose. A section can only reach what the platform opens to it — a surface declared up front and checked server-side, not a promise made in the prompt. Narrow by design: what's narrow and stable keeps working; what's broad and open eventually breaks on its own. We steer the model away from its instincts. An LLM has habits: it reaches for solutions that assume a server you run — but a section runs on the user's phone, not on your backend. A good part of the work is pushing it, explicitly, away from what it learned and toward what holds up in that context. Generate, validate, correct — in a loop. The model doesn't hand back a blob of code: it has to produce a fixed structure that passes validation before anything becomes installable. If it fails, the exact error goes back to the model to fix; the most common slips get repaired automatically rather than shipped broken. It's that loop — generate, validate, correct — not the generation, that separates "looks like it works" from "it installs." The rest follows the same logic: a section can't read another section's data, call a domain you haven't declared, or ship a key in the clear. Nothing spectacular taken one by one. Put together, it's the difference between a demo and something you'd dare leave running in a customer's app. What that unlocks turns out to be more varied than you'd expect — because the missing piece can be almost anything. Often it's mundane, and that's fine. A running club wants its upcoming race calendar: the owner drops in a logo and a CSV of dates, writes "show these races, our logo up top," and the section comes out in the club's colors, with the real dates. Sometimes you need a real backend. A yoga studio wants to handle bookings: "this week's classes, a button to reserve a spot, and the number of spots dropping as people sign up." The assistant wires up a Supabase database behind it — tables, row-level access rules, key handling — on its own. The section no longer has just a screen: it has shared, persistent data behind it. And sometimes you ask for the improbable — that's the best test. We had it generate Flappy Rush: a playable Flappy Bird clone with a leaderboard shared across all players. To be clear: GoodBarber isn't a game engine, and your app doesn't turn into a game — what it proves is that you can drop a mini-game into a page of a real app. The game isn't the point. The point is that the day the catalog doesn't have what you need, you stop setting it aside: you describe it. That's why we say "prompt-to-section," not "prompt-to-app." The feature is in beta, open to everyone — and we don't claim an AI builds your whole app from a prompt. We say the opposite, and it's a sturdier claim: the AI produces the missing piece, inside a frame that holds. If that piece is still there in three years, it won't be because of the prompt — it'll be because it inherits a frame that absorbs, continuously, what slowly kills an app nobody touches. It's the same logic behind making our platform operable by an AI agent instead of building our own agent, and it's why, for us, AI doesn't replace the frame: it adds to it. The prompt is one more layer. What's underneath hasn't changed.