For years, a lot of developer products shipped two things. An API, and a no-code builder on top of it for teams that didn't want to write against the API. Embeddable checkout builders, drag-and-drop login screens, form builders, dashboard builders, and pricing table builders. We built one of those, a no-code builder for billing UI, and this week we killed it (for new accounts).
The reason is coding agents. The builder existed because writing UI was expensive, and now agents made it cheap. When an engineer can describe a screen and ship it in their own design system the same day, a canvas full of toggles and drop downs is the slower path.
But agents didn't make the rest of the stack easier. They made it more important, because more of the code calling our API is now written by something that doesn't deeply understand billing.
We think this holds well beyond billing. With agents, the UI layer is disposable and the service underneath is the product. The services that win will be the ones whose APIs are hard to use wrong.
Why no-code existed
No-code builders trade flexibility for not writing code. That was a good trade when frontend time was scarce. A login page, a checkout, an admin dashboard, and a pricing table are all screens nobody sets out to build, and a builder let someone on the product team ship one in an afternoon.
The trade has a ceiling, and most teams that build one of these tools hit it. Ours looked like this. One customer wanted to highlight a recommended plan. Another wanted to filter plans by firmographic data. A third needed buyers to accept terms of service before signup. Each request was reasonable and unique to one customer, and in a builder the only way to say yes is an option for everyone. We kept saying yes until the builder felt limited and heavy at the same time.
What agents changed
Agents removed the reason to live with the ceiling. The way out of a builder used to be writing it yourself, which meant weeks of frontend work nobody had time for. Now it's a prompt and an afternoon of review. Once the custom version costs about the same as configuring the generic one, the generic one loses.
That's true for any builder whose output is UI inside someone else's product. It's less true for tools whose users will never open a terminal, and we'll come back to that.
What agents didn't change
An agent can write a convincing screen for almost anything. It can't tell whether the screen is right.
A login form takes minutes. Session expiry, token refresh, and what happens when someone is removed from an org mid-session are where the bugs live. An admin panel can show a role toggle, but the API has to be the thing that refuses the action. A receipt can show a tax line, but something has to know which rate applies in which state. A pricing table is trivial until it has to handle proration on a mid-month upgrade, a credit grant that expired last week, or an overage that has to match the invoice to the cent.
In each case the UI is a thin view over logic that has to be right every time, and the cost of getting it wrong lands later, on a customer. If an agent writes that logic into your repo, every bug in it is yours to find and fix. Generated UI is disposable. You can throw a screen away and regenerate it. You can't regenerate an invoice that already went out, or take back access that already leaked.
Make the API hard to use wrong
If more of your API's callers are agents, the shape of the API becomes the guardrail. An agent will do the obvious thing with whatever you return, so the obvious thing has to be correct.
In billing, that looks like this. If the API returns a company's raw credit grants, the natural way to show a balance is to add them up, expired grants included. If it returns the live balance, there's nothing to get wrong. Return list prices and tier definitions, and every client does its own tier math. Return prices already computed for that customer, and none of them have to.
Stripe worked this out years ago with Elements. You get a card field to style however you like, and the card data and the logic behind it stay on Stripe's side. A few rules follow from the same idea. Decide on the server and send the browser only what it needs to render. Scope credentials to one customer and keep them short-lived. Validate every state change on the server before it touches anything irreversible, like a charge. And ship logic as tested package code, not as source to copy. Copied markup can drift without hurting anyone. Copied logic drifts into bugs.
Where this goes
The next round of billing UI won't sit on a settings page. It'll sit next to the button that spends the money, showing what an action will cost, why a limit stopped it, and when the credits run out. That was never going to come out of a builder. It'll come out of whatever agent you use, calling a service it can trust. We think the same goes for most of what builders used to do.
Top comments (0)