Vibes DIY
Vibes DIY / Blog
From the build log

270 PRs in 17 days — the speed was the safety

We pulled the numbers on every PR merged into this repo between June 12 and June 29. As of the analysis snapshot (midday June 29 — a few more merged while the analysis ran, which is itself a data point): 270 PRs, ~223k lines of churn, a median PR of 196 lines across 5 files, merged in a median 0.8 hours. 80% landed in under six hours. 95% were agent-authored. One human — jchris — merged 261 of them.

The obvious reading is "reckless." The number that refutes it is the median. The interesting claim, and the reason this post exists, is that the velocity and the safety weren't in tension. They were the same property.

Title card: “velocity = safety” set over a starling murmuration, in the Vibes DIY teal-and-goldenrod style.
A flock of workstreams, one shepherd: many small coordinated moves beat one big one.

Small because sliced

The median PR is tiny because big work got sliced, not because the work was small. 18% of the PR titles literally contain slice, phase, step, or bucket; 29% reference a parent issue that holds the plan. The scary churn is quarantined too: the top 10 PRs account for 53% of all the lines, and about six of them are obviously-mechanical sweeps — renames, vendored lifts, generated fixtures. Strip those out and the typical change is a couple hundred lines you can actually read in one sitting.

Three real migrations shipped inside this window — retiring the /chat route in favor of /vibe, de-fireproofing our identity stack, and building the eval harnesses that let prompt and model changes be measured instead of guessed. None of them ever existed as one terrifying PR. Each was a stack of small, individually boring merges, any one of which could be reverted with git revert and a shrug.

The caution dial

Small slices alone don't make this safe. The human element does — and it isn't gatekeeping, it's shepherding: choosing where the flock goes, and how carefully to tread, dialed per-PR to risk and reward. The clearest evidence is the same person, on the same day, running opposite caution settings:

Get posts like this in your inbox

One email field. Real updates. No algorithm required.

PRWhat it wasCaution setting
#2827Sidebar links move to the /vibe routeShipped hot in 25 minutes, no flag — the blast radius was a string prefix
#2837First new-vibe-builds-on-/vibe flow, enabledMerged only after an end-to-end preview run and a P1 fix from review
#2835Vibe SSRLanded dormant behind a flag, production explicitly off
#2494A riskier changeHand-written hold: "do not merge until after the next prod deploy of main, so the change deploys in isolation and any regression is unambiguously attributable"

That's the whole model. High velocity is the risk-control mechanism, not the thing you trade against it: small revertible slices plus a human turning a caution dial per-PR beats big-bang merges guarded by hope.

The bottleneck was never the code

Here's jchris's framing of why this works at all:

I would not have been able to maintain focus for these tasks; the agent holds the context, and I dip in when decisions are required, so I can shepherd a flock of workstreams without the risk that comes from fractured focus.

The hard part of building was always deciding what matters, not typing. The agent absorbs the context-switch tax — it holds the state of each workstream between decisions — so one person gets the throughput of many parallel threads without the attention-splitting risk that usually comes with them. The 0.8-hour median merge isn't a human racing; it's a human answering a well-framed question and getting out of the way.

The tools improve on demand

The speed compounds because the tooling improves while the work ships, pulled into existence by real walls rather than speculation. Twenty-two of our agent runbooks were touched inside this same 17-day window, and the new ones each mark a wall someone actually hit: a slim wrapper because the GitHub API output drowned the agents (June 25), out-of-the-box browser screenshots in cloud sessions (June 28), a headless prod-verification round-trip for an auth ship (June 29).

The forcing function was getting everything to run in cloud sessions. That started as a latency hack — jchris was on a Greek island, the codebase was across an ocean — and became the way of working: most of this window shipped from a phone at the beach, faster and better, because using the product under real-world conditions calls forth the next improvement without breaking stride.

The honest trade-off

None of this is free, and the discipline is the price. It only works if slices are independently shippable — the vibeApi ?? chatApi fallback that let both routes coexist, flags that default off, spec-first design PRs before the code that implements them. And it only works if every tool improvement is demand-driven and written down where the next agent will find it. Slicing without that discipline just gives you 270 ways to half-break prod, and speculative tooling burns exactly the time the slicing saved.

Built at this pace, for people who build.

The same loop that ships this platform ships your app: describe it, and it's live.

Start building →

Enjoyed this? Get the next post by email

One email field. Real updates. No algorithm required.

Prefer a feed? RSS · Atom