Asked to build platform infrastructure, the agent picked a vibe

We asked an agent to implement #3323: @-mention the Vibes DIY account on Bluesky with a prompt, and the platform builds your app, publishes it public, and replies in your thread with a screenshot and a live link. Classic platform infrastructure — a listener, a credential store, guardrail state, a build queue, an operator console.

The agent surveyed the codebase, mapped what existed, and made an architecture call nobody prompted it to make: the production home is a vibe — an app on the platform itself, vibes/mention-hub. Not a new Cloudflare worker. Not a queue consumer. Not a cron server. The product. (With one deliberate exception, the build step — we'll get to it.)

What the job actually needed

Strip the feature to its requirements and it reads like an infrastructure shopping list:

• A secret store for the Bluesky app-password that no browser should ever be able to read.
• Scheduled compute to poll for mentions and post replies.
• Durable state with real access control: a ledger of every mention, what was built for it, and what got skipped by which guardrail.
• An operator console to paste the credential, tune the rate caps, and watch the pipeline.
• A data API that CI can script, so a build farm can pick up work and report back.

Six months ago each bullet meant provisioning something. What the agent noticed is that in today's platform, every bullet is a stock vibe primitive:

• The secret store is a Fireproof database whose access function assigns token docs to a channel granted to no one — a write-only vault. The owner can paste a credential in; no browser, not even the owner's, can ever sync it back out. Only the scheduled backend, running in admin mode, reads it.
• Scheduled compute is one line in backend.js: export const config = { scheduled: { interval: "1m" } }.
• The ledger is another Fireproof database; the guardrails — daily spend ceiling, per-author caps, prompt dedupe, a moderation gate, and the rule that failures never post — are pure functions with unit tests, enforced on every tick.
• The operator console is just App.jsx. Status chips, credential form, config knobs — a dashboard we'd otherwise have built in an internal tool, for free, with the same access control as everything else.
• And the data plane is scriptable from anywhere: vibes-diy db query and db put give a GitHub Actions runner authenticated CRUD on the vibe's own databases.

The precedent, and the pattern

This wasn't a first date. Two days earlier, the same architecture shipped meta-hub — the console that publishes this blog to Threads, Instagram, Facebook, LinkedIn, and Bluesky, rotating Meta's 60-day tokens on a schedule, with the same write-only vault holding the keys (#3101). That one was a deliberate experiment: can a vibe be trusted with production credentials and a real operational job?

Mention-hub is the confirmation that it's now just the pattern. Given a fresh infrastructure task and the whole repo to choose from, the agent's cheapest, safest, most reviewable path was the product's own primitives — and it took that path autonomously, then defended the choice in review. The full loop shipped in PR #3329: listener, guardrails, in-thread screenshot replies, with Charlie catching a real invariant violation (untrusted prompt text leaking into our reply's link-card metadata) before merge.

The one thing a vibe can't do

There's exactly one gap, and its shape is telling. A vibe backend can't run the codegen pipeline — building apps is the platform's job, not an app's. So that step became a deliberately thin CI lane: a cron workflow driving the public vibes-diy CLI — the same one any user scripts — to generate and publish each requested app, verify it actually serves, and write the result back.

The two halves never share a secret. The Bluesky credential never leaves the vibe's vault; the CI lane holds only a device cert. They coordinate entirely through mention documents walking pending-build → building → built → replied in the vibe's own database — the product's data layer as the message bus between the product's app runtime and the product's build farm.

Dogfooding as a completeness proof

"Feature-complete" is usually a checklist claim. This is a stronger kind of evidence: revealed preference. An agent with the entire toolbox available — workers, queues, durable objects, cron servers — keeps choosing the product, because the product genuinely is the best runtime in the room for stateful, credentialed, operator-visible jobs.

And there's a pleasing recursion in what this particular infrastructure does: it's the machinery that builds apps for strangers who ask in public. The platform whose pitch is "describe an app and it exists" now runs its own growth loop on apps it described into existence for itself.