Spec-driven development is getting slow

A few months ago I spent a very long time building a project management system (SCRUM / Evidence Based Management inspired) and ended up with something I did not fully understand, and that was flawed in ways I could not quickly fix. That is the honest starting point of this post. The tooling I used was the superpowers plugin for Claude Code, which routes nearly all build work through a heavy production pipeline: brainstorm, design spec, implementation plan, TDD, subagent-driven development with a reviewer per task. On paper that is exactly what you want when you care about quality. In practice, on the newest models (Fable 5 and Opus 4.8 at the time), it produced rigorous code in directions I did not want, at a pace that made course-correcting expensive. I was burning through my Claude subscription really quickly, which also made me question whether the real frontier models are even still worth it.

It was a lot better to use superpowers when the models were less intelligent. Now that they have become smarter it actually feels like the quality is degrading. The models did both: they over-built some things, but mostly they drifted, building features the wrong way while taking very long. A cheaper, less intelligent model let me do the work a lot quicker, and although it did not one-shot anything, that was never the goal to begin with.

So I forked superpowers and inserted two-speed lanes into it. Full spec-and-review ceremony on every task burned my subscription and slowed the build to a crawl, so the fork keeps upstream’s rigor where it pays and skips it where it does not, and defaults to the cheap lane. I am not the only one complaining either, multiple users are reporting they think superpowers is getting slower (issue 2017). A day after I added the routing change, upstream independently shipped its own answer to the same pain: a three-path router, released in v6.3.0. The problem was real.

What the fork actually adds

Twelve commits over three days at the end of July, roughly 2,200 lines of new skills and docs. Counting the eval infrastructure I wrote and reverted, about 3,000 lines were written and 760 reverted. The lanes:

• experiment and harden-experiment: a zero-ceremony throwaway lane. Every experiment keeps a small living document recording what was validated, what was rejected, what is dirty, and an iteration log. Once an experiment has proven itself, harden-experiment reads that document and rebuilds the thing under the real pipeline. The experiment code is evidence, not the implementation: it gets rewritten, never promoted.

• quick-spec and promote-quick-spec: a lean three-bullet intent lock (files, logic, risk) with an explicit go/no-go before any implementation, then a full-auto hardening run: compressed design, edge cases, security, test strategy, subagent-driven execution. Quality may expand, the product scope may not.

• quick-review: a fast pre-commit diff scan for bugs, debug leftovers and secrets. Not a substitute for a real review on production work.

• tokenburn: builds an evidence pack from a session (transcripts, task briefs, review diffs, commit lists) so a third party can judge how the agent process went: waste, scope creep, loops, duplicate reviews. It measures process, not tokens, and never invents token counts.

On top of the lanes sits a routing patch: “let’s build X” no longer silently enters the full design flow. You get one short menu, it defaults to the experiment lane, and full brainstorming only runs when you pick it, or when a hard gate applies (auth, payments, security) and you confirm.

The tradeoffs that mattered

Rewrite, don’t promote

The experiment lane deliberately throws its own code away. When a validated experiment gets hardened, the code is not carried over, it is rewritten under the full pipeline, and the only thing that survives is the living document. That means writing the real thing twice, which is the cost. I am fine with it because the throwaway exists to find out what you actually want, and promoting it would inherit every guess it made on the way. The document is the feature memory: it lets a real spec get written after the chat context is long gone, without dragging dirty code into production.

The same-day reverts

On 29 July I wrote roughly 760 lines of eval infrastructure: a bash test suite with fixtures, and then a local eval harness with five scenarios. I reverted both the same day. It did not really make sense to make a benchmark for a human-in-the-loop fast-iteration workflow, there is no way to create one, at least I do not think so. What would actually help is a way of visually seeing the entire application quickly, so you can see the model start to drift and catch it before it goes off the rails completely. That tool does not exist yet, not in the fork and not anywhere I have found, and it is the gap that is still open.

Scope lock over scope creep

In the promote lane, allowed growth is hardening the same behavior: null and invalid inputs, races, authorization, injection, retries, tests that forbid unexpected states. Forbidden is any new user-visible feature. Unexpected behavior should be forced out by tests, not hoped away. The cost is that the lane feels rigid when the original spec turns out to be missing something real, but that is what the experiment lane is for: fix the intent there, then promote.

The audit

I built the measurement instrument and pointed it straight at the session that motivated it. One slice of the management system work took roughly 27 subagent runs for 11 tasks, plus a final review. The product outcome was good, around 897 tests green and a clean typecheck. The process cost was not. A single fix loop took three commits and three review passes: the first fix over-generalized and created the next finding, and the correct fix was narrower. That one task ate about 22 percent of all subagent runs, one task out of eleven. Meanwhile the purely mechanical tasks still paid a full implementer-plus-reviewer pair, and the final whole-branch review mostly re-listed issues that were already known. The same session had a slice done the inline way as a contrast, and it was faster with fewer redundant gates. The audit ran on 30 July, and the quick-spec hardening commits landed the day after: the measurement fed the tooling.

Honest caveats

Everything I know about whether this works comes from my own sessions. Not one other human has used the fork, and it might not be a good workflow fit for everyone. I have noticed my quality and speed going up, but that is not measured, it is more of a feel thing, though I have noticed real wall-clock differences by making use of my workflow.

The fork is local. There is no remote, no pull request, it is installed only for me, so you cannot install it. Both eval attempts were reverted within hours, so nothing guards the skills’ behavior except me using them. And the fork’s own promote step is as slow as the thing it was built to fix: today, as I write this, I promoted an experiment to a real spec and the speccing has been running for an hour and a half. This is way too long to quickly iterate and I really like it to be faster.

Upstream shipped its three-path router in v6.3.0 on 12 August. I have not looked at it yet, I have not had the time. So when this post says the pain was independently diagnosed, that is based on knowing the router exists, not on reading it.

Where it sits now and what comes next

The fork is what I use now: it is installed as my own plugin and the official one is disabled. It is a secondary project, I have a few ideas to make it better, but first I want to collect more data by using it. The management system that motivated all of this was rebuilt from scratch with the learnings, took about the same amount of time, and is now something I am actually happy with. I will write about that system separately in a later post.

The one thing I would carry forward: forcing the model to visually show things to the user, different visual representations that the user can quickly process. Concretely, a way to quickly see database schemas and API routes, a short way of reading what a thing does, why it is there, and what depends on it. I have not tried it yet, so that is something to find out.

The thing I would move, not cut: the speccing ceremony. It is too slow for iteration, but it is needed for production grade code, the superpowers framework as it is is really powerful at creating solid, rigorously tested code. Maybe I would let it spec things and build things out overnight when I am asleep.

Quick inference is the most important thing for my workflow in the coming months. It is what enables iterating at lightspeed.

The part that would generalize

When the bottleneck is steering, the workflow’s job is to keep you in the loop, and the model’s job is to show you things you can process quickly. Quality does not have to be perfect at first. Failing quickly and iterating on the design, especially at the beginning when you are trying things to see what works and what does not, beats a correct-but-slow pipeline that drifts away from what you asked for. The audit put a number on what the slow lane costs. The drift-catcher is the missing piece, and it is the next thing I am going to try.