An agent for ten people

Somewhere in your group chat there is a thing everybody wants and nobody has.

Ours is a friend who plans the week. It would sit in the group, read everyone's commitments each week, and decide whether this one is a coffee or a happy hour. It would remember that last week was a call and who missed it. It would treat Thursdays as sacred, because we said so once and meant it.

Nobody is going to build that. It is too small to be a product, too specific to be a template, and roughly ten people want it. That is not a gap in the market — it is the definition of the software that never gets made, and it happens to overlap almost exactly with the software that would matter most to the people in it.

The cost was never the describing

Here is the thing that changed underneath, and it is worth being precise about it. Describing that agent has never been the hard part. Anyone in the group could say what it does in two sentences, and has, several times, usually in the same conversation where somebody says "someone should build that."

The cost was everything around the describing. Pick a stack. Make an account. Name the thing. Set up a database, decide who is allowed to write to it, get a URL, keep the URL alive. By the time you reach the two sentences you actually cared about, you have spent an evening on a set of problems that are identical for every app anyone has ever made and interesting to no one.

So the useful question is not "can a model write this app." It has been able to for a while. The question is how much of the setup a person has to survive before the model gets a turn — and the honest answer, until recently, was still too much of it.

Five words that make it a participant

We put the argument on its own page, because it changes what you think you're making. What you describe isn't a tool you use and close. It's a participant:

• Persistent — it keeps its history.
• Interactive — it changes with the people in it.
• Connected — it works with other services.
• Faithful — it follows your intent.
• Long-lived — it stays useful.

Take those five together and the word "app" stops fitting. A thing that remembers, responds, holds a role, and is still there a year later is closer to a member of the group than to software. That's why the page says friends: not because the promise is an AI companion, but because the group gets closer when something in it keeps the thread.

None of that is exotic. It's just a set of properties that used to cost a developer, and the whole project is making them cost a sentence instead.

The two moments where people were stopped

If setup is the enemy, then the work is subtraction, and it's worth naming the two moments we found people stalling in — both in the first sixty seconds, both invisible in any usage chart, because a person who bounces at a wall doesn't file a report.

You needed a name before you had anything

An app has to live somewhere, and somewhere on Vibes is /vibe/<your-handle>/<your-app>. No handle, no address; no address, nowhere to build. For a while we solved that by quietly minting a handle for you — you typed a sentence, and an account somewhere acquired a public name it never chose, which would then appear on the URL of everything it ever shipped. That's a strange thing to do to someone in their first ten seconds, so we stopped.

Which left the obvious fix: ask for the name first. A form, then the app. And that's exactly the wrong trade, because the entire product is how little stands between typing a sentence and watching an app appear. Putting a text field there spends the one moment that convinces people.

So the first build now runs unowned. You submit the prompt, the code starts streaming into a live runtime shell immediately, and the name chooser sits on top of the build while it happens. You are picking a name while the thing assembles behind the card — which is a much better moment to be asked, because you can see what you're naming. Nothing is claimed until you choose. When you do, one server-side operation takes the handle, takes an address, and if the build finished while you were deciding, publishes it right then. The app you were already watching just gets a home.

The detail we enjoyed most is one nobody will ever see. A build with no owner still needs something in the column where an owner's name goes, so it carries a reserved sentinel — and that sentinel must never be mistaken for a person, not in a URL, not in a request, not on screen. What makes that safe is one character. Every handle is run through a sanitizer that can only ever emit lowercase letters, digits and dashes, so the sentinel leads with a tilde: ~draft. It isn't unlikely to collide with somebody's real handle. It is unable to. And because every query that filters on an owner's handle is already comparing against sanitized output, drafts drop out of all of them for free, without a single line of code that mentions drafts.

You needed to stay and watch

The second one is smaller to describe and was costing more.

Publishing on Vibes is the default — every edit ships, there's no draft state to remember and no button to find. But the release itself used to be minted by a piece of browser code: a bit of the page noticed a new version had been saved and asked the server to publish it. Which quietly meant the release only happened if you were still there. Close the tab while the last tokens are streaming, lose signal on a train, drive the whole thing from the command line instead of the web app, and your generation landed in the database as a version nobody ever released. It built fine. It just never went live, and nothing said so.

Now the server mints the release itself, in the same code path that saves the work. Publishing is a property of the generation finishing, not of a browser watching it finish. The browser still asks too, as a backstop — the operation is idempotent, so a second request costs nothing — but it is no longer the thing the outcome depends on.

What deliberately did not move is the interesting half. If you've pinned your app to a specific version, the automatic release is suppressed rather than rejected — your pin keeps winning. And when the person generating is a collaborator you've granted access, their turn persists without publishing: moving your live release automatically is yours alone. They can still publish deliberately, which is what the grant is for, and unpublishing and ownership stay with you regardless. Those used to be rules enforced in the browser. They're now enforced on the server, where they can't be skipped by closing a laptop.

Accessibility is mostly subtraction

Neither of these is a feature you can put on a pricing page. There's no new button. The best case for both is that you never notice them, because the thing you were doing simply worked.

That's the shape of this kind of work in general, and it's why it tends not to get done: the wins are invisible, the people they help are the ones who would otherwise have left without saying anything, and every fix is a removal. The platform now handles the naming, the address, the database, the permissions, the serving, and the release, which is the whole point — generated code should only write what makes your app different. Everything else is substrate, and substrate you have to configure yourself isn't substrate, it's homework.

Which brings it back to the friend who plans the week. It still isn't a product and still isn't a startup and still, as far as we can tell, only about ten people want it.

It just takes two sentences now.