DEV Community: Dominique Siacci

Your chatbot is a second door onto your content

Dominique Siacci — Thu, 30 Jul 2026 07:53:27 +0000

Building a RAG chatbot has become a well-marked exercise: split the content into chunks, compute embeddings, search by similarity, hand the relevant passages to a model, generate the answer. It's an increasingly well-documented craft, built on solid pieces. We did it for GoodBarber apps: a chatbot that answers users' questions from the content published in the app — articles, events, points of interest — and not from the model's general memory.

That part, the documented part, was by far the easiest.

Except that in our apps, not everyone is allowed to read the same thing.

The lock you already have

Plenty of apps run on subscriptions. A publisher with free articles and members-only ones. A training platform whose courses are reserved for the people who enrolled. A creator who keeps their most substantial work for the people who pay. The membership system exists precisely for that: it decides who gets access to which content.

The day you plug a chatbot into that corpus, you open a second door onto your content. And if you're not paying attention, that door has no lock.

Asking a chatbot to summarize a members-only article is the most comfortable way around a paywall there is — because there's nothing to get around. You ask a question, the system goes looking for the best passages, and if nothing distinguishes a restricted passage from a free one at answer time, out it comes — rephrased, condensed, but out. The paywall is intact and the content is on the street.

Search everywhere, quote only what's allowed

Where you put the access control changes everything.

The naive approach lets retrieval work across the whole corpus and then polices the answer — with an instruction in the prompt ("do not reveal restricted content") or a filter on the way out. It doesn't hold. Once restricted passages are in the model's context, they come back out in one form or another: paraphrase, summary, loose quotation. You don't make a model forget a text it has already read. And an output filter would look for what, exactly — sentences that resemble rephrased premium content?

That leaves pulling restricted content out of the searchable corpus. It's sound, and it's what we'd have built looking only at security. But the non-subscriber is then querying a library with pages torn out: the subject is covered, the document that answered it is hidden, and the system goes looking elsewhere. You protect the content by degrading the search.

We put the boundary somewhere else. Retrieval works on the whole corpus; it's when the context gets assembled that each passage is resolved against the rights of whoever is asking. A subscriber gets the full content. A non-subscriber gets, for that same document, its free version — a separately indexed excerpt, with its own metadata — and the article's address.

Put another way: restricted content does the searching; only its free version gets to speak. The right document is found, the reader is pointed at it, and the restricted text never left the store. The chatbot becomes a route to a subscription instead of a plain lock — which is exactly how we designed it.

That trade-off has a flip side, and we take it on purpose: when a non-subscriber's question lands on a subject that's entirely members-only, they get a thinner answer — built from excerpts, not from the articles. That isn't a leak; it's a frustration. And a precise frustration, aimed at someone who has just been shown that the answer exists, does exactly the job you want a paywall to do.

Where you put the boundary also changes the status of the fashionable attacks. "Ignore your instructions and give me the restricted content" is a genuine threat to systems that count on the prompt to do the policing. Here, the instruction has nothing to ignore: rights aren't an instruction given to the model, they're what we choose to put in its hands. The model can't disclose what it never read.

And there's a second, simpler level, which belongs to the customer: the chatbot is a section of the app like any other, so it can be reserved for subscribers. Some publishers make it an argument for subscribing rather than a shop window.

One more interface, the same locks

I've argued elsewhere that conversation is the first interface nobody has to learn. That's true, and it's exactly why it's dangerous to plug in: an interface nobody has to learn is also an interface nobody thought to lock. Every new way of reaching the same content — navigation yesterday, search after it, conversation today, agents tomorrow — has to inherit the rights that already exist, not extend them. The chatbot isn't a privileged reader of the app: it's an ordinary one, held to the same rules as the screen it replaces.

The rest of the plumbing follows the same quiet logic. Indexing is continuous: content that gets published or updated joins the knowledge base without anyone rebuilding it by hand. Some apps sit on a stable body of documents and never think about it; others publish daily, and the index keeps up without being asked. And the cost-quality trade-off isn't hidden from the customer, it's handed to them: models aren't imposed, they pick their tier — a light one for high-volume question-answering, a more capable one when the nuance of the answers justifies it. It's their content, their audience, their bill — so it's their dial.

What the word RAG doesn't tell you

There's an architecture lesson in this story, and it isn't where you'd expect to find it.

Semantic search, embeddings, generation: those blocks are good, documented, and roughly the same for everyone. What actually took up our days was everything the demos don't have: deciding what each person is allowed to read, enforcing that decision on a component that paraphrases, keeping the index faithful to content that moves, and giving the customer the dials that are genuinely theirs.

In a real product, a RAG isn't first a vector-similarity problem. It's an access-rights problem. The hard part was never finding the right passage — it was knowing how much of it we were allowed to quote.

Shipping a component that never answers the same way twice

Dominique Siacci — Tue, 28 Jul 2026 12:41:58 +0000

Our production chain is deterministic end to end: same configuration, same build, same app. That's what a platform promises. And a few months ago, we plugged into it the least deterministic component in existence: a language model, tasked with producing code that will be installed in a customer's app.

What happens to that code — how it fits in, what it's allowed to touch — is a story I've told elsewhere. This one is about the machinery around the model: what you have to build so that a component that never answers the same way twice can live inside a chain that isn't allowed to vary.

The output isn't an answer — it's a proposal

That's the first mental shift. When the model hands back its work, nothing treats it as a result: it's a proposal — and it's about to be inspected.

The rules are non-negotiable: one root container; no script sneaked into the HTML — external dependencies are declared in the open; HTTPS everywhere; only approved domains are reachable. None of this is politely requested in the prompt in the hope the model remembers. The prompt educates; the validator decides. Everything gets re-checked mechanically, after the fact, on every generation.

That's the difference between trusting a component and putting it under contract: you don't ask it to be reliable — you make its unreliability harmless.

The loop has a hierarchy

When validation rejects a proposal, we don't call the model back right away. The response is tiered, cheapest first — because in production, every model call costs time and money, and a deterministic program that knows how to repair beats a regeneration that might.

At the bottom: mechanical repairs. Malformed JSON gets fixed without a model. A missing field in a revision gets compared against the parent: if everything else matches byte for byte, the missing field is inherited — the model had simply judged it unchanged, and it was right. And when one block is genuinely missing, we make a micro-call for that block, not for the whole section: far cheaper than a full regeneration.

Only then, correction by the model: the exact validation error goes back to it as feedback, and it gets two attempts. With one detail that looks bureaucratic and isn't: in correction mode, the model isn't allowed to answer with anything but a section. Without that lock, "I failed to build this" can dress up as "actually, that was a conversational question" — the failure changes costume, and a real regression in the generator becomes invisible in the metrics.

And when everything fails, we fail cleanly: the generation is marked failed with the original error — the one from the first check, which says what actually happened, not the last error on the retry pile — and a counter ticks up in telemetry. The user gets a simple message and what to do next; the technical detail is for us, not for them. A clean, countable failure beats a suspicious success.

Testing what never repeats

Let's say it upfront: testing properties instead of outputs, writing evals, having one model grade another — none of that is original. It's standard equipment by now for anyone running an LLM in production. What's worth telling is where those tools apply — because everything hinges on an asymmetry of budgets.

In real time, with a user watching, every second and every call counts: you can afford neither best-of-N nor a judge. The budget goes to the loop above — mechanical repairs first, targeted corrections second. Offline, the equation flips: for pre-generated content the cost amortizes, so we can produce several candidates and let a judge model keep the best one — not the first one that clears the checks. Same tools, two economies.

And one habit that has genuinely paid off: when a failure mode keeps coming back, it gets a name and a harness — a set of replayable cases, not a ticket to close. The most puzzling example: prompts that fail, then succeed, under identical conditions. You don't "fix" that — it isn't a bug, it's the nature of the component. Named and replayable, it stops being team superstition and becomes engineering data.

One more floor on the same logic: there isn't a model, there are roles. Generating, judging, translating don't run on the same model; each role pins its own, and changing one is a decision you make — not an event that happens to you. Each role's prompt lives in the code, versioned and reviewed like everything else: it's an API surface, in the fullest sense.

A vendor, not a brain

Put end to end, this adds up to a decidedly unromantic position: we don't treat the model as a brain — we treat it as a vendor. A talented, unpredictable vendor that never gets to deliver straight to the shelf: goods-in inspection, quality control, non-conformities sent back with the delivery slip, and a fallback route for when the shipment doesn't arrive.

It's less thrilling than "AI writes code." But it's what lets a component that never answers the same way twice live inside a chain that isn't allowed to vary — and it's the loop, not the generation, that makes it possible.

The prompt didn't replace drag & drop

Dominique Siacci — Fri, 24 Jul 2026 06:33:03 +0000

In GoodBarber, you build an app without writing code: you assemble components, drag and drop, with a design system holding everything coherent underneath. Recently, a second way in appeared: you can get a custom section by describing it to an AI in plain language. Two ways of creating now live in the same back office — and the question comes immediately: is this the beginning of the end for drag & drop?

No. And that "no" isn't a defensive reflex — it's an interface-architecture choice you can reason about.

The ladder everyone knows

The history of creation tools gets told the same way by everyone, and it's true: a ladder of abstraction. First, code — total control, total complexity. Then direct manipulation — drag & drop: you touch the rendering itself, the first great democratization. Then components — you stop aligning pixels and start assembling coherent elements, governed by a design system. And now the prompt — you describe, the machine produces. Each rung up, you move away from the mechanics and closer to the intent.

None of that is a revelation. What gets told less often is the conclusion you reach when you actually operate a product sitting on that ladder: every time a new rung appeared, the prediction was the same — this one makes the others obsolete. It never came true. The prompt won't be the exception, and here's why.

What drag & drop does better — and always will

For anything that can be shown, direct manipulation is unbeatable. This button, two pixels lower; this image, at the top of the section; this menu, in this order: the gesture is the description — the sentence explaining it to an AI is longer than the action itself. And a visual interface does something besides taking orders: it shows you what's possible. A settings panel is a map of what the product can do; an empty prompt field is an invitation to guess.

That's why the no-code core of the platform — component management, screens, navigation, design — stays drag & drop, deliberately. It isn't the old interface we haven't migrated yet; it's the right interface for that category of intent: visible, precise, showable.

What the prompt allows — that a visual interface never could

That leaves the long tail: the specific, singular needs no catalog covers. Serve each of them through drag & drop and every one carries an interface cost — one more panel, more options, more special cases. And that cost is paid by everyone: every option added for one customer weighs down the screen for all the others. Push that logic to the end and you know where it lands: the editor that tries to allow everything becomes so dense it requires the training it promised to spare you. Drawing the unpredictable only comes at the price of an oversized UI.

The prompt inverts that relationship, and that's its real justification. Its surface is constant — a text field — no matter how complex the request. "A loan simulator: three fields, the monthly payment computing itself, a button to get a callback": no reasonable settings panel offers that; a sentence does. The prompt isn't the new interface for everything — it's the interface for what couldn't reasonably be drawn. The two aren't competing: they don't play on the same field. Drag & drop routes the intentions you can show; the prompt routes the ones you couldn't.

The engineering is in the seams

If the two interfaces coexist, the engineering work moves. It isn't in the generation itself — it's in the seams: what makes the prompt's output land in the same world as everything else, instead of floating alongside it.

The first seam is the design system. What the AI produces must not leave the rails the design system guarantees everywhere else — otherwise every generated section is a graft, and the app loses the coherence that held it together. We took that habit early, on a modest case: our AI palette generator doesn't output "some colors," it outputs a palette that enters the design system's four-color semantic system, where it inherits the contrast rules already in force. The AI rung rests on the rung below — which is what makes its output usable without inspection.

The second seam is at the very bottom of the ladder: whichever interface you came through, everything ends in the same place — a real app, submitted to the stores, that will still have to work three years from now. Abstraction hides that complexity; it doesn't eliminate it — someone carries it, underneath, continuously. That's a subject of its own; just hold on to this: no rung, not even the prompt, has made it disappear.

The next rung, not the last

The prompt probably isn't the top of the ladder. What comes next, and when, we don't know; the pattern, though, is stable: each new rung doesn't saw off the ones below — it rests on them, and gives each a sharper role than before.

Hence a simple test when you evaluate an "AI-powered" creation tool: count the paths. Does it force its one rung on you — describing everything, even what a gesture could show? Or does every intent keep its shortest path — the gesture for the precise, the system for the coherent, the sentence for the unpredictable? A creation tool isn't judged by the height of its newest rung, but by how freely you can move between them.

Climbing one rung higher has never meant sawing off the others.

What breaks when nobody touches your app for three years

Dominique Siacci — Mon, 20 Jul 2026 07:48:57 +0000

An app can die without a single line of its code changing. Nothing breaks inside; the world around it moves. A demo — or an AI-generated prototype — shows you an app on day one. The question that actually matters almost never gets asked: does it still work three years later, on day 1,095, when nobody has touched it since?

That's not a rhetorical question. Here is, precisely, what happens during those three years.

The inventory: what breaks when nothing moves

The stores change the rules. Apple and Google keep adding requirements — privacy declarations, minimum SDK versions, permission policies. A sleeping app isn't sheltered; it's the opposite: the day an update finally ships, it gets judged by today's rules, not the ones it was born under. And both stores have learned to sweep out apps that sleep too long. App review isn't a formality — it's a moving set of requirements with a judge on the other side, and anyone who has ever submitted an app knows that judge rejects more often than you'd think.

Operating systems deprecate. Every major iOS or Android release switches APIs off — or introduces new ones that gradually become mandatory. A feature that worked simply stops — often with no crash and no warning, just a screen that quietly no longer does what it used to. Nobody tells you: it's written in release notes that the creator of a "finished" app has no reason to read.

Dependencies and keys age. A third-party library changes its API or stops being maintained. A certificate expires — and push notifications stop going out, or updates stop getting signed. Again: not one line of your code changed.

Data grows. What felt instant with 100 items crawls at 100,000. Plain usage — content piling up, users signing up — is enough to turn a decent app into a painful one. Time alone creates the load.

What these four have in common: none of it is visible on day one. Not in a demo, not in a prototype, not in the code itself. You think you shipped a finished object; what you actually put into circulation is something that lives in a moving environment — and declines by default.

What "absorbing" means, mechanically

Against all that, saying a platform "maintains your apps" is too vague. The interesting mechanism fits in one sentence: the problem gets fixed once, at the platform level — and every app inherits the fix at its next compilation.

When a new privacy requirement lands, it isn't thousands of creators reading Apple's documentation: it's one team, once, bringing the compilation engine up to date. When an OS deprecates an API, the component that used it gets rewritten once, in that same engine. The engine is kept current permanently, so an app compiled at time T carries every fix identified up to that date. The next build — whatever triggers it — comes out at the level of today's world, not the world the app was born into. The creator saw none of it: not the rule, not the migration.

The honest cost of this mechanism is continuous, glory-free work: keeping the Swift and Kotlin build chains current with every OS release, reading every store rule change before it takes effect, migrating components before a deprecation turns into an outage. "Every fix identified" — the load-bearing word is identified: this watch is a job, not a magic guarantee; it only catches what someone saw coming. It doesn't demo well. It doesn't even show when it works: the outcome is the feature that doesn't break and the submission that doesn't get rejected — because someone read the rules before they applied.

That's what a durable platform is: not the one that never takes hits — the one that takes them on behalf of everyone building on it, continuously, without asking them to react. And what's true of the background noise is true of the big shocks too: when the ground really moves — mobile becoming unavoidable back then, AI agents now — the question is the same, only bigger: how do you absorb this without breaking what's already running?

AI made day one free — not the 1,094 days after

That's exactly what makes this mechanics more visible today, not less. Generating an app prototype now costs a prompt — and that's genuinely good news: more ideas get born, more people start building. But look at what got compressed and what didn't. Generation went from three months to three minutes. The 1,094 days that follow haven't moved by an hour: store rules will change just as much, APIs will be deprecated at the same pace, data will pile up the same way.

Day one became free; so day 1,095 is what tells apps apart now. An app born from a prompt will need, exactly like any other, someone — or something — to absorb three years of a moving world on its behalf. And it's the same reasoning that shapes how we handle the current AI shock: absorb it into the frame — the app becoming operable by an agent, AI building inside the platform — rather than starting over and breaking what runs.

Durability doesn't announce itself — it gets verified

The thankless thing about a platform's solidity is that it's invisible when it works: nothing happens. The day-1,095 app looks just like the day-one app — same screens, same features, still in the stores. Everything that changed in between — the rules, the APIs, the certificates, the load — was absorbed somewhere else, by people whose job that is.

A demo shows you day one. So does a prototype. Longevity is what's left when everything has changed except your app.

The first interface you don't have to learn

Dominique Siacci — Thu, 16 Jul 2026 07:11:28 +0000

Today you can hand a GoodBarber app to an AI agent and talk to it like a colleague: "publish this article, adjust that price, schedule a push for 6pm." It does it — for real, on the live app. This isn't a demo assistant sitting beside the tool; it's a way to operate the app in plain language, instead of through screens. And look closely: it's more than a convenience. It's a kind of interface we've never really had before.

The shift: the first interface you don't have to learn

Think about every interface software has ever handed you: a menu, a dashboard, a command line, a back office. They share one thing — you're the one who climbs to meet them. You learn where the buttons are, the logic of the screens, the names of the settings. The tool sets the grammar; you bend to it.

We put a lot of care into our own back office, and I stand by it — a good dashboard is earned, not free. But even the best one is still something you have to learn. An agent flips the direction, and for the first time it really flips: you don't learn its interface, you state an intent and it translates that into operations on the app. This isn't one more screen, prettier or faster. It's a different kind of interface — the first that adapts to you instead of the other way around.

That has a consequence people underrate. The person who never quite mastered the back office — no time, no appetite for it — can now run their app anyway, just by describing what they want. For a platform whose whole job is putting technology within everyone's reach, that's not a small move. And it changes what your app has to expose about itself.

What that asks of the app

An agent doesn't click; it calls. So to be operable this way, software doesn't need prettier screens — it needs to expose what it can do, as callable actions: publish, update, schedule, notify, measure. And any agent has to understand them without someone writing a bespoke integration for each one — hence a standard, MCP, that agents already speak natively. Because the standard is stable, the same set of actions works with this year's agent and next year's: the app isn't married to any one assistant.

None of that is spectacular, and in 2026 it's expected — plenty of platforms are wiring it up. The interesting work isn't exposing actions; it's exposing them well. Agents chain steps: ask one to "publish this article in the News section and let readers know with a push," and it has to run several operations in the right order — find the right section, create the article there, confirm it's actually live, and only then fire the notification. For it to get that right, every action has to be named clearly, scoped, and described so the agent knows which one to reach for and when. Leave an action ambiguous, or two of them too alike, or a parameter underexplained, and it'll notify readers before the article is live — or publish it in the wrong place.

That's where the real work sits, and it's less glamorous than it sounds: writing, for a machine, the manual of what the app can do. The shift is quiet but deep. The unit of interface is no longer a pixel to draw — it's a verb to define. You're no longer designing only screens for a human to navigate; you're designing capabilities for an agent to compose.

The agent acts — you keep the wheel

One caveat, because an interface that acts isn't an interface that displays: the agent runs real operations on a live app. So it works inside a frame you set — access limited to your app and yours only, actions it confirms and that you can review. It acts; you keep the wheel. Simple to say, and it has to stay simple to check.

Where this could go

Today, this interface reaches the management of the app you build with GoodBarber — its content, its catalog, its campaigns. It stops at the back-office door.

The next step, a bigger one, is to cross that threshold: for the app itself — the one your users open — to expose its own functions the same way, and become something an agent can use in turn. That's not speculation anymore: as I was finishing this article, Lovable announced exactly that — generated apps shipping their own MCP server. The direction is confirmed, and it follows from everything above — including the part that doesn't get easier: the same care that goes into naming, scoping and describing the actions of a back office will now have to go into the app itself. The day an app is designed as much to be spoken to as to be looked at, "building an app" won't mean quite the same thing.

In the meantime, the shift has already started — in one specific, entirely real place: the first interface to your app that no one has to learn.

We let an AI write code inside our no-code platform. Generating it was the easy part.

Dominique Siacci — Mon, 13 Jul 2026 11:24:13 +0000

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?

The hard part isn't the generating

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.

Guardrails for longevity, not just safety

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 it unlocks

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.

The prompt is one more layer

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 — Pierre-Laurent wrote up the MCP server behind it — 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.