The Engineering of Intent, Chapter 40: The De-Vibing Protocol — Stabilization Sprints for Production

This is the final post in the series walking through my book The Engineering of Intent. In the previous chapter, we trained the eye. Chapter 40 closes the book with the remedy for the 40,000-line weekend — the bounded, agent-assisted stabilization sprint that retroactively produces the specs, tests, and architectural documentation a fast vibes-only build skipped.

The Remedy Is Not “Rewrite It”

The autocomplete trap and the forty-thousand-line weekend produce codebases that are plausible but unspecified. The instinct is to rewrite. The book’s final chapter argues against — rewriting forfeits the momentum, the learnings, the working shape.

The remedy is a two-week De-Vibing Protocol: bounded, agent-heavy stabilization that moves a project from 90% vibes / 10% rigor to something like 50/50 without halting feature development. It’s the procedure I wish every solo founder had known before their seed-round due diligence started.

Recognizing When You Need It

Any three of these seven symptoms are sufficient:

1. You cannot explain, without re-reading the code, what a module does.
2. Test coverage is below 30%, or the tests were auto-generated against the code and can’t catch regressions.
3. You’ve introduced two or more bugs this week that a spec or type check would have caught.
4. A new collaborator takes more than three days to make their first useful change.
5. You’re afraid to refactor anything because you don’t know what will break.
6. The word any appears in your type annotations more than once per hundred lines.
7. You are considering a rewrite.

The Sprint Shape: Two Weeks, Four Tracks, 60/40 Split

Two weeks. Not more (indistinguishable from rewrite), not less (insufficient). Runs alongside normal feature work, not instead — 60% de-vibing, 40% urgent customer/feature work. Stopping feature work entirely is a mistake; the business doesn’t pause and the team revolts within a week.

Four parallel tracks, all agent-heavy:

• Track 1 — Archaeology. Reverse-engineer a one-page spec from each significant module. Agent extracts, human corrects.
• Track 2 — Characterization. Retrofit tests against current behavior. A safety net that catches accidental changes; correctness comes later.
• Track 3 — Type Hardening. Replace any with meaningful types. Agent reads call sites, infers real shapes, proposes concrete types.
• Track 4 — Architecture Documentation. Produce architecture.md, AGENT.md, and the decision log that should have existed from day one.

“Each track is agent-heavy. None of this work should be done by hand. The value the human adds is review, prioritization, and the occasional hard architectural call. The agent does the typing. Target output per engineer per day: one module’s spec, or one file’s characterization tests, or one module’s type hardening. This pace is realistic with agents; it would be laughable without them.”

The Failure Modes to Watch

Common failure modes of the sprint itself: perfectionism (a spec so detailed it takes a day per module — wrong, one page in two hours is the target); scope creep (every retrofit reveals a bug someone wants to fix — log as follow-up, don’t fix in-sprint); political fatigue (people who didn’t cause the debt resent cleaning it — remind the team that in two weeks, everyone owns the codebase, not its history).

Characterization tests have two specific traps. First, tests against agent-generated code without external ground truth are a closed loop that can pass while the system is broken — manually verify at least one test’s expected value against the actual system. Second, tests that merely call the function and assert its result matches its result are useless implementation duplicates — the prompt template ships in the book, and you need it.

After the Sprint: Three Disciplines

The sprint ends. What then?

1. Every PR touching a module must update its spec. No exceptions. Stale specs are worse than none — they lie.
2. Code review rejects any on sight. Type-hardening is cheap to maintain, expensive to redo.
3. Every architectural change gets a decision-log entry. Three sentences: context, decision, rationale.

Closing the Series

This is the last post in the blog series. Forty chapters, forty teasers, one core idea: the discipline of clear intent, the value of rigor under pressure, and the importance of craftsmanship outlast any one model, tool, or wave. The practices change; the posture doesn’t. The engineer who holds the posture is the engineer I’ve wanted to write to for the last two years.

If you’ve read along: thank you. If you’ve shipped something cleaner because of one of the posts, that’s why the book exists. If you want the whole system in one place — every framework, every case study, every checklist, every appendix — the book is where it all fits together.