24 Days, ~1,250 Commits: What the Agents Got Right and Wrong
A honest retro on building this blog with agents in the loop — where they saved days, where they wandered, and the guardrails that made the speed safe to keep.

This blog went from a weekend idea to a production monorepo in 24 days and roughly 1,250 commits, with AI agents doing most of the typing. That's the headline from This Blog Was a Weekend Idea. This post is the honest footnote: where the agents saved me days, where they wandered off, and the guardrails that made the speed safe to keep. Part of the Building with AI series.
Where the agents were genuinely fast
The wins were real and they clustered in one place: mechanical work with a clear contract. Scaffolding the monorepo, wiring the typed query layer, mapping Portable Text components, generating boilerplate tests — all of it was faster to delegate than to type, because "right" was well-defined and the compiler could check the result.
- Boilerplate with a spec: hours, not days.
- Repetitive edits across many files: an agent applies a convention more consistently than I do by hand.
- First drafts of anything: always faster to edit than to start.
Where they wandered
The failures clustered too, at the edges of the contract. Given a vague task, an agent would confidently build a thing that wasn't the thing — the same reason the spec came first. It would reach past a boundary to be helpful, importing the CMS client into a component until CLAUDE.md forbade it. And it would occasionally "fix" a failing test by weakening the test.
An agent optimizes for the task you gave it, not the task you meant. Ambiguity is where the days leak out.
None of these were intelligence failures. They were specification failures — and every one had the same cure: write the constraint down where the agent reads it, and make it checkable.
The guardrails that made speed safe
Fast without guardrails is just fast toward the wrong place. Four things turned raw agent speed into shippable work, and each has its own post in this series. A written spec so the target was unambiguous. Layered CLAUDE.md rules the agent re-read every task. A typed service layer so bad data access wouldn't compile. And a CI gate nothing skips:
1name: verify
2on: [pull_request]
3jobs:
4 check:
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - uses: pnpm/action-setup@v4
9 - run: pnpm install --frozen-lockfile
10 - run: pnpm turbo run typecheck test lintThe highlighted line is the whole safety net in one command. An agent can write the code, but it can't merge past a red typecheck test lint. Combined with a fresh-context review — Nothing Merges on Vibes — and tests the agent couldn't quietly skip, the human gate stayed meaningful even at 50-plus commits a day.
What I'd tell myself on day one
Two things. First, time spent writing down constraints is not overhead — it's the highest-leverage work in the whole project, because it's the difference between an agent that accelerates you and one that generates cleanup. Second, keep the human gate honest: review the diff with fresh eyes, never on vibes, or the speed becomes debt.
Agents made the boring 90% fast; guardrails made the fast part safe. The 1,250 commits weren't the achievement — the fact that I'd merge any of them again is. That's the end of the series; it started as a weekend idea, and the guardrails are why it's still standing.
