The curb cut and the robot
In the 1970s, disability activists in Berkeley went after their city's curbs — a few guerrilla ramps hacked in by night (a legend even 99% Invisible calls "a little bit exaggerated"), and then the campaign that actually won: pressing the City Council in 1971 until ramps went in citywide. The curb cuts were for wheelchairs. Then came the strollers, the delivery carts, the cyclists, the travelers wheeling luggage — until designers gave the pattern a name, the curb-cut effect: build for the person the environment excludes, and you routinely build something everyone uses.
Fifty years later the pattern delivered its best punchline. Sidewalk delivery robots — machines nobody in 1972 was designing for — roll through those same ramps. They have to. A robot cannot hop a curb, cannot improvise, cannot read a sign that says "step up here." The ramp built for the person who couldn't negotiate the exception turned out to be the on-ramp for the machine that can't.
We've spent the last year living a software version of this story, and it's the most interesting thing we know about the platform we're building.
What we flattened
Vibes DIY was designed for someone who has never deployed anything: describe an app in plain language, get a live URL a minute later. Taking that person seriously means flattening every curb an expert has learned to hop without noticing:
- There is no build to configure. The deploy pipeline compiles, bundles, rewrites imports, and serves — deterministically, at deploy time, the same way for every app. There's no config file because there's no configuration.
- Publishing is the default, with a real version lock. Shipping isn't a ceremony to get right; not-shipping is the explicit act.
- Permissions are one server-side function. Who can write what is a single reviewable
access.jsthat runs only on the server — not a constellation of rules spread across client checks, database policies, and middleware that can disagree. - The data layer is local-first. Writes succeed on the device; sync is a background loop; offline isn't a mode anyone has to handle. There is no loading-state footgun because there's no loading state.
- The app runs in a sandbox with a curated import map. Dependencies resolve through the platform, inside a frame that can't reach what it shouldn't. Supply chain is a platform property, not a per-app vigilance exercise.
Notice what's not on the list: capability. Apps ship server-side backends, custom access logic, real npm surfaces. What got removed is never the ceiling — it's the class of 3 a.m. incident under it.
Get posts like this in your inbox
One email field. Real updates. No algorithm required.
The leak test
Here's where the experts in the room fold their arms, and here's the part we most want them to hear.
Joel Spolsky's Law of Leaky Abstractions says all non-trivial abstractions leak. Experts don't actually distrust abstraction — they live on abstractions — they distrust the leak, because they're the ones who get paged by it. And the standard platform economics make leaks permanent: the platform ships an abstraction, the abstraction leaks, and the platform ships documentation. "Note that under load, X may actually Y." The leak becomes the user's job. Read any mature platform's docs as a genre and you'll see it: documentation is a leak ledger.
A beginner platform cannot run that ledger, and this is the forcing function that makes the whole thesis work. Our median user cannot read the escape-hatch docs, cannot hold the workaround in their head, cannot tell a leak from their own mistake. So for us a leak isn't a footnote — it's a lost user, which means it's a bug, which means it gets fixed at the layer that leaked. When we found write paths that could skip a platform guarantee, the fix wasn't "remember to opt in" — the guarantee moved to the one choke point every write passes through, and the opt-in was deleted so no future caller can forget. When platform invariants need enforcing, they live in the deterministic deploy-time transforms — applied retroactively to every already-deployed app — not in a prompt, not in a doc, not in anyone's memory.
An abstraction isn't finished when there's nothing left to add. It's finished when there's nothing left to explain.
That's the first half of the pitch to experts: a platform for everyone is the only kind that can't afford leaky abstractions — and several million people who can't work around your leaks are the most honest fuzzer your abstraction will ever have.
Then the robots showed up
An AI agent is the ultimate beginner. It has no tribal knowledge, no memory of last quarter's incident, no fear, and it reads your documentation exactly as well as its context window allows. If your platform's safety lives in docs, an agent is unsafe on it by construction — the same way a delivery robot can't read "step up here."
So it shouldn't have surprised us — but it did, and delightfully — that everything we flattened for the newcomer turned out to be exactly what unattended automation needs. One-command, idempotent deploys with nothing to misconfigure. A blast radius bounded by the platform, not by the operator's care: the sandbox, the server-side access function, an MCP session pinned to a single app so a confused agent can't wander. Atomic page releases behind a version lock, so a bad frontend ship rolls back — while server-side code always runs the live release, so the fix for a bad backend ship is one more ship, never an archaeology dig. No side-channel state to drift, because there's no side channel.
This isn't a hypothetical roadmap. Agents operate this platform today: they pick apps and ship changes, they work in cloud sessions end to end, they diagnosed and repaired the festival app in our last two posts, and a public @-mention can kick off a build with no human in the loop. We never built an "agents platform." We built curb cuts, and the robots rolled through.
For everyone, therefore for you
"For everyone" is the phrase that makes an expert close the tab — it sounds like "not for me." We think the implication runs exactly backwards, three ways:
| What the beginner needed | What the agent needs | What the expert gets |
|---|---|---|
| Can't configure a build — so there's nothing to configure | Nothing to misconfigure at 3 a.m., unattended | Deploys you can delegate without a runbook |
| Can't read escape-hatch docs — so leaks are bugs | Only reads docs as well as its context window | Abstractions that actually hold |
| Can't judge blast radius — so the platform bounds it | Needs hard walls, not conventions | A fleet you can sleep through |
| Gets publish-by-default with a version lock | Gets idempotent, atomic releases | A bad page release rolls back |
First, delegation. You don't need the footguns removed — until you hire a thousand interns. Solo, your skill substitutes for safety; the moment you want agents shipping on your behalf, every footgun becomes a liability you carry while asleep. The bumpers you'd sneer at for one lane are the entire game when you're bowling a thousand at once.
Second, leak economics. You will never get a leak-free abstraction from a platform whose users can tolerate leaks, because tolerated leaks get documented instead of fixed. You get it from a platform whose users — human and machine — can't. Someone else's first-time builder is your regression test.
Third, floor, not ceiling. The flattening is all downside-removal. The backend, the access logic, the data model, the npm surface are still yours — and still there at 3 a.m., unhaunted.
Curb cuts never made a corner worse for people who could step up the curb. They made the corner better for everyone, and they made the robots possible — decades before anyone knew that's what they were for. That's the platform we're building: for everyone, which is precisely why it's for you.
Bring your fleet — or just your idea
Describe an app in plain language and it's live in a minute. Your agents can do the same.
Start building →