When AI Coding Rituals Become the Bottleneck: Why a 300M Token/Day User Gutted Superpowers
Teams adopting AI-coding agents often inherit heavy, ritualized pipelines designed for weaker models. At scale, those rituals become the dominant cost — multiplying token spend, latency, and context pollution — while the model's actual capability to self-correct inside a single context goes unused. The fix is risk-calibrated process, not process elimination.
Superpowers bundles 14 skills into a default pipeline that forces brainstorming, detailed planning, git worktrees, sub-agent dispatch, spec review, and quality review on every task, including single-line config changes. A user who runs this workflow at industrial scale — roughly 300 million tokens per day — reports that the sequential dependencies and repeated context handoffs between agents multiply token consumption and wall-clock time far beyond what the actual code change requires. The process artifacts (design docs, plans, review reports) often outweigh the code change itself, and the model's attention shifts from solving the problem to proving process compliance.
The core failure is a mismatch between task risk and process intensity. Rules written as absolute mandates — "if there's a 1% chance a skill applies, call it" or "no production code without a failing test first" — leave the model no room to calibrate its approach. In the GPT-5.6 era, where a single strong model can understand, modify, test, and correct code within one context, this fixed heavy pipeline compresses the model's effective autonomy rather than enhancing it.
A local experiment stripped the skill set from 14 to 6 lightweight versions and cut the core rules from 3,207 lines to 110. The result was a three-tier system — Lite, Standard, Strict — that matches process intensity to actual risk, reserving sub-agents and independent reviews for security, payments, and major refactoring. The takeaway is not that process is bad, but that uncalibrated process becomes a tax that wastes tokens, attention, and time on low-risk work while creating a false sense of security on high-risk work.
Superpowers' pipeline is a textbook case of process calcification: rules written for unstable early agents survived into an era where a single strong model can self-correct inside one context, turning helpful scaffolding into deadweight.
The cost model reveals that token waste is not in generated code but in repeated context handoffs — the same requirements and diffs get read three or four times by different agents, each time rebuilding judgment context from scratch.
Review agents create a dangerous asymmetry: they can flag style preferences as defects but carry no accountability for false positives, forcing the main agent to spend tokens adjudicating review quality instead of code quality.
The '1% rule' is an anti-pattern for AI workflows — it converts low-confidence triggers into high-frequency process loads, exactly the opposite of how risk-based engineering should work.
Cutting 3,207 lines of rules to 110 is not just simplification; it proves the original complexity was rule-stacking, not problem-inherent. The engineering problem didn't demand 14 skills; the process design did.
The three-tier Lite/Standard/Strict model is effectively a risk-budgeting system for AI workflows — it reserves expensive multi-agent review for changes where the cost of failure justifies the cost of process, and lets everything else run lean.
The core friction is that heavy AI-coding workflows impose a discipline tax that outpaces model improvement. The mandatory pipeline of design docs, sub-agents, and multi-round reviews inflates token costs and latency without proportional quality gains for simple changes. A competing view holds that domestic models still need this structure, but the dominant sentiment is that as frontier models improve, stripping away ritualized processes in favor of direct execution, small-step planning, or linear code structures yields higher efficiency and better project control.
Back when Superpowers was really popular, I didn't try it. The most direct reason was that I felt its internal workflow was too detailed and complex. Sure, it can enforce a standardized workflow and make the model work according to a paradigm, but I always felt that as models improve, this problem should resolve itself. I originally standardized a workflow for internal business implementation, but later gave up and just wrote the fixed standards as skills. As the models improve, the output gets more and more accurate, the number of conversation turns decreases, and token consumption isn't large.
Domestic models still need it. It's just that GPT has evolved.
Good article. It's exactly what I've encountered. I get bogged down by the process for simple system feature changes and requirement optimizations. I'm now even questioning whether abstracting the business layer itself has value, and whether this kind of review can cover subsequent business changes. I'm already considering deleting all the reusable abstract business code. For the small project I'm doing myself, the most granular business parts are explicitly forbidden from having any intra-project calls. All business functions are written within that business itself, only allowing calls to package functions. I've deleted all the intermediate jumps. Instead, development efficiency went up (any function is completed within a limited window, forbidding reliance on code functions from any other script, ensuring any business change is completed within a single complete code structure). I'm even wondering if the logical thinking and solutions based on software development are wrong. Using linear repetition for my tasks is a better solution, completely avoiding context drift and the situation where readability gets worse the more you change it.
I discovered this earlier when using openspec or speckit, though that was at the beginning of the year. Later I felt that every time the content was output, I still had to review it, and the final result wasn't necessarily good. So I just directly used plan + small task breakdown, which is the small-step, fast-run model. It requires a bit more human involvement, but overall efficiency actually went up. Before, a small requirement with a whole SPEC, running the tasks would take me 2 hours. Now it's very fast. Project control is also much better.