The Engineering of Intent, Chapter 29: Vibe Coding in the Backend

This is Part 29 of a series walking through my book The Engineering of Intent. In the previous chapter, we walked the 100-tip archive. Part IX of the book is the deep-dive section. Chapter 29 opens it: backend work, where Vibe Coding has arguably the most immediate impact.

Backends Are Unusually Well Suited to Agentic Development

The interfaces are textual (HTTP, SQL, protobuf). The correctness criteria are checkable (schemas, contracts, tests). The iteration surface is visible. But each backend subdomain has characteristic failure modes — and this chapter walks them.

Six Domains, Six Disciplines

1. API Design Sessions. First proposal is a draft. Iterate five or six times. The prompts that help: “what is the most common case this design would serve poorly?” and “three ways this API could evolve badly over five years.”
2. Database Migrations. Always write the reverse. Always dry-run on a production-sized clone. Always have one human reviewer specifically responsible for the migration. Ask: “what pre-existing data would this migration corrupt or mis-handle?”
3. Queues, Jobs, and Idempotency. Every job must be idempotent (or have explicit dedup), have a timeout, have a max retry, log enough to replay. Make it a standing conventions.md rule.
4. Caching. Start with TTL near zero. Raise when you measure benefit and have invalidation. Agents produce plausible-looking cache layers with aspirational TTLs; reality is more conservative.
5. Auth/Authz. Maintain a forbidden-patterns.md listing every unsafe JWT parse, every leaky permission check, every error message that reveals whether an account exists. Keep a separate security-reviewer agent.
6. Rate Limiting & Observability. Every public endpoint declares its rate-limit policy in the PR description, even “no limit is intentional.” Every endpoint emits start/end logs + metric + trace. Make the ask standing policy.

The Meta-Lesson from the Billing Rebuild

“A company I advised had a 30,000-line, 7-year-old Ruby billing service. New leadership wanted a Go rewrite. The instinct was: rewrite with an agent, ship fast. My counsel: do not. The existing code is a specification disguised as implementation. Throwing it out discards years of hard-won bug fixes.”

What worked instead: agent reads the old code and extracts a high-level behavior description per endpoint; humans clean that into a spec; the 400 integration tests are translated into spec-level tests; the Go implementation is built against the shared test suite; traffic shadow-mirrored for two months.

Outcome: shipped in four months instead of eighteen. Zero customer-visible regressions. Seventeen previously-unknown behaviors documented during extraction — three were actual bugs the new code deliberately did not preserve. The spec became a durable artifact that outlived the migration itself.

Next up — Chapter 30: Vibe Coding in the Frontend. Frontend has a different shape — visual output, fast iteration, immediate feedback. Chapter 30 walks design-system adherence, accessibility, state management, and the dashboard rebuild that shipped in eleven days.