When AI Coding Rituals Become the Bottleneck: Why a 300M Token/Day User Gutted Superpowers

A heavy user who consumes about 300 million tokens daily explains why they ultimately chose to remove it from their workflow.

Conclusion First: I'm Not Slowed Down by the Model, but by the Process

This afternoon, I was tortured by a task again.

This wasn't a project requiring days of architectural design, nor a high-risk change like payments, permissions, or data migration that requires multi-person review. According to a normal engineering rhythm, it should be: understand the requirements, locate the code, make a small change, run the relevant tests, and finish. The actual hands-on time might not be long.

But in Superpowers' workflow, a small task is easily stretched into a complete ritual chain: first determine if any skill applies, then enter brainstorming, then write a design, then wait for confirmation, then write a plan, then decide whether to create a worktree, then dispatch an implementation agent for each task, then dispatch a spec review, then dispatch a quality review, and finally re-verify, wrap up, and report.

Each step, viewed in isolation, can find a seemingly reasonable justification. The problem is that engineering efficiency is not about stacking all reasonable steps together. Engineering efficiency is about achieving a sufficiently high correctness rate at a sufficiently low cost.

Superpowers' biggest problem is precisely turning "caution" into the default, turning "process" into the goal, and turning a task that could be completed directly into a compliance test for the process itself.

I'm not against testing, nor against reviews, nor against sub-agents. What I oppose is treating a long process designed for unstable, low-autonomy agents as a unified religion for all tasks in the era of strong models like GPT-5.6.

Who I Am, and Why I'm So Sensitive to This Problem

I'm not a user who occasionally opens a chat window, asks a question, and leaves. According to my own usage statistics, I consume about 300 million tokens daily on average. This number is not an industry benchmark, nor a promotional metric for any product; it's simply my work reality: a large volume of code reading, long-context analysis, cross-module modifications, debugging, deployment, documentation, and repeated verification, all completed within the same AI workflow.

High-frequency usage has one benefit: many processes show no problems on the first experience, but after repeating them dozens of times, the problems surface on their own.

You start to distinguish which steps genuinely reduce error rates and which steps just make the model look diligent; which outputs aid decision-making and which outputs just re-explain things you already know three times; which reviews catch defects and which reviews just package "no problems found" into a new report.

When you do only one task a day, an extra ten minutes of process might not be noticeable. When you do dozens of tasks a day, or let the model work continuously for hours, all extra steps become real delays, real tokens, real context pollution, and real attention drain.

So my dissatisfaction with Superpowers doesn't come from a single accidental inconvenience, but from an increasingly clear cost accounting after high-frequency use.

What Exactly Did Superpowers Stack Together?

I inventoried Superpowers v5.1.3 from my local cache. It has a total of 14 skills, with core rule text totaling about 3,207 lines. They roughly fall into several groups:

• Requirements & Planning: brainstorming, writing-plans, executing-plans
• Sub-agents & Parallelism: subagent-driven-development, dispatching-parallel-agents
• Workspace & Delivery: using-git-worktrees, finishing-a-development-branch
• Testing & Debugging: test-driven-development, systematic-debugging
• Review & Verification: requesting-code-review, receiving-code-review, verification-before-completion
• Global Entry & Meta-process: using-superpowers, writing-skills

The existence of a single skill doesn't mean its full body is loaded every time. What truly makes things heavy is the default connection relationship between them:

using-superpowers
    -> brainstorming
    -> writing-plans
    -> using-git-worktrees
    -> subagent-driven-development
    -> implementation
    -> spec review
    -> quality review
    -> verification
    -> finishing-a-development-branch

This is a conservative pipeline suitable for large, high-risk, multi-person collaborative projects, not a default path suitable for all daily code tasks.

Efficiency: Every Step is Reasonable, but Strung Together They're Unreasonable

Below are the real costs of several common types of steps in this chain.

Step	Problem It Claims to Solve	Actual Cost for Small Tasks
Global skill check	Avoid missing processes	Adds judgment and explanation to every conversation; the model first discusses "whether to start"
Brainstorming	Avoid requirement misunderstandings	Configuration, single-function, and documentation changes are also forced through design and approval
Detailed plan	Reduce execution deviation	The plan itself becomes a second specification; its time cost can exceed implementation
Worktree	Isolate changes	Repeatedly creates isolation within an already isolated environment, generating ineffective operations
Implementation agent	Separate context	Re-transmits background, goals, files, and constraints, increasing waiting and synchronization
Spec review	Check compliance with requirements	For clear small changes, often just rephrases the requirements
Quality review	Check code quality	Needs to read the diff and context again, potentially raising low-value style opinions
Wrap-up process	Unify merging and delivery	For tasks that don't need PRs or branch operations, it's entirely extra ritual

The key is not how many seconds a certain step takes, but that these steps have sequential dependencies. The next step cannot start before the previous one finishes. The user needs to answer more confirmation questions, the model needs to send more status messages, tools need to generate more intermediate files, and the tail latency of the entire task is continuously stretched.

The most absurd scenario is: the code change itself is only a few lines, but the process artifacts include a design document, a plan, a task list, an implementation report, a spec review report, a quality review report, and a final verification report. What ultimately changes the system's behavior might be just one conditional statement.

This is not rigor. This is a mismatch between process and task scale.

Tokens: The Most Expensive Part Isn't Code, It's Repeated Explanation

When many people talk about token costs, they only focus on the code generated by the model. The actually more expensive part is often the context forced to be repeatedly transmitted by the process.

A simplified cost model can be written as:

Total Cost
= Main agent context
  + Number of implementation agents × Task context
  + Number of review agents × Diff and requirement context
  + Failed retries × All context
  + Process status messages and reports

In single-agent direct execution, the task context usually only needs to be understood once. After entering sub-agent development, the same requirement must be organized at least once by the main agent, read once by the implementation agent, read once by the spec review, and read once more by the quality review. The more tasks, the more obvious the repetition.

And this context is not a free summary. To make each agent "independent," the controller must rewrite the task background, file scope, constraints, expected output, and current state. The review agent also needs to rebuild its own judgment context. You think you're buying higher quality, but you're actually paying multiple entry fees for the same information.

The bigger problem is that tokens don't just affect the bill. The longer the context, the more likely the model is to focus its attention on process documents, status reports, and review opinions, rather than on the actual causal relationships in the code. The model starts optimizing "how to prove it followed the process" rather than "how to solve the problem fastest."

For a workflow consuming about 300 million tokens daily, this repetition is not an abstract efficiency loss, but a massive waste of resources.

Are Reviews Useful? Yes, but They Shouldn't Become a Religion

Reviews are certainly useful. Security boundaries, permission models, payment logic, data migration, concurrency control, public APIs, and cross-service contracts all deserve a second pair of eyes. The problem is that the value of a review is highly dependent on risk, and Superpowers made it a default tax.

A very simple judgment table can be used:

Task Type	Potential Benefit of Auto-Review	Worth Mandatory Multi-Round Review?
Modifying docs, config, copy	Very low	Not worth it
Single-file local fix	Low to medium	Usually not worth it
Normal business logic with existing test coverage	Medium	One targeted check is enough
Cross-module refactoring	High	One independent review can be considered
Permissions, payments, security, data migration	Very high	Manual or independent review recommended

There are three problems with mandatory reviews.

First, the review agent is not inherently more knowledgeable about the business than the implementation agent. It might find real defects, or it might treat personal style preferences as specification issues. In the end, the main agent still has to spend time judging whether the review opinion is valid.

Second, the boundary between spec review and quality review is not as clear as imagined. Incomplete specs become quality problems, and quality risks often need to return to requirement semantics. Splitting them into two agents doesn't necessarily yield double the insight; it usually just produces two overlapping texts.

Third, reviews create a dangerous sense of security. A well-written report does not mean the system is truly correct. Truly valuable verification remains executable tests, reproducible behavior, clear monitoring, and real user feedback.

Reviews should be a risk tool, not a loyalty test.

In the GPT-5.6 Era, Why This Set of Things Seems Even More Absurd

Early agents indeed needed more scaffolding. The model might not understand context, easily forget goals, couldn't stably decompose tasks, and wasn't good at self-checking. So people wrote engineering experience into hard rules, trying to compensate for the model's unreliability with process.

But model capabilities are changing, while processes easily solidify.

Strong models of the GPT-5.6 generation can already complete code understanding, solution selection, modification, testing, and error correction within the same context. It doesn't mean the model is always correct, nor that engineering discipline can disappear, but it means the default workflow should allow the model to adjust its strategy based on task risk.

If the prompt is written as "must call skill if there's even a 1% chance it applies," the model has no room for risk judgment. If it's written as "any project must be designed first, even a configuration change," the model cannot shrink the process according to task scale. If it's written as "no production code can be written without seeing a failing test first," the model will treat the test form itself as the goal.

This is not enhancing the model; it's compressing the model's effective degrees of freedom.

The model could clearly solve the problem in ten minutes, but is required to spend ten minutes explaining why it can't solve the problem yet. The model could clearly choose one verification based on risk, but is required to prove it completed the full ritual. What the end-user sees is not a smarter engineer, but an engineering assistant constantly filling out process forms.

The Most Absurd Part Isn't a Specific Step, but Those Hard-Threshold Phrasings

Several types of phrasing in Superpowers are particularly illustrative.

The original rules of using-superpowers require: if there's even a 1% chance of applicability, the skill must be called, and it must be checked before any reply or action.

The original rules of brainstorming require: any project must be designed first. It even lists todos, single-function tools, and configuration changes as cases that cannot be skipped, and requires writing a design document, committing it, waiting for user review, and then entering planning.

The original iron law of test-driven-development is: no production code can be written without first seeing a failing test.

The original rules of verification-before-completion include success expression, committing, creating a PR, moving to the next task, and even dispatching agents within the scope of re-verification.

These sentences, viewed alone, all seem to protect quality. Put together, they become a system that prioritizes protecting the process first, and protecting the result second.

Truly mature engineering norms should be written as "do this when the risk is high enough," not "always do this." Treating all exceptions as laziness and all simplifications as violations ultimately only makes the model better at obeying text, not making software more reliable.

I Finally Ran a Local Experiment: 14 Became 6

I didn't continue arguing "whether this methodology has theoretical value," but directly ran a local streamlining experiment.

From the original 14 skills, I removed:

• subagent-driven-development
• dispatching-parallel-agents
• requesting-code-review
• receiving-code-review
• executing-plans
• using-git-worktrees
• finishing-a-development-branch
• writing-skills

The remaining 6 skills were modified into lightweight versions:

• Only do brief brainstorming when requirements are truly unclear.
• Only write a short plan when multiple files and sequential dependencies exist.
• Only do systematic debugging for complex bugs; fix simple errors directly.
• Only adopt test-first when behavior is complex and the testing benefit is clear.
• Run one targeted verification before finishing non-trivial tasks.
• Only consider extra processes when explicitly requested by the user.

The result was that the core SKILL.md dropped from about 3,207 lines to 110 lines. This number is not a performance benchmark, nor does it prove all teams should do this, but it proves one thing: the original complexity was not inherently required by the engineering problem itself, but was created by stacking rules.

I also added a more direct global preference: unless explicitly requested by the user, do not dispatch sub-agents, do not dispatch automatic review agents, and by default, the main agent completes the implementation and performs one targeted verification.

This is closer to the AI engineer I want, not an AI process administrator.

What I Think Engineering Norms Should Look Like in the GPT-5.6 Era

I don't advocate deleting all norms. I advocate grading norms.

Lite: Default Mode

Applicable to documentation, configuration, single-file modifications, simple bugs, and clear small features.

Understand goal -> Modify -> Targeted test or check -> Explain result

No long design, no worktree creation, no agent dispatch, no automatic review.

Standard: Normal Complexity Tasks

Applicable to multi-file changes, changes with interface impacts, or features requiring a clear sequence.

Short plan -> Implementation -> Relevant tests -> One self-check

The goal of the plan is to reduce omissions, not to create a document longer than the code.

Strict: High-Risk Tasks

Enabled only for security, payments, permissions, data migration, public APIs, cross-service contracts, and major refactoring.

Design discussion -> Plan -> Implementation -> Independent review or manual review -> Integration verification

Even for Strict, it should be explicitly chosen by the user or project lead, not automatically triggered by a "1% possibility."

This grading does not lower standards. It applies standards where they are truly needed, leaving time for truly important judgments.

Not Against Discipline, but Against Making Discipline the Goal

What annoyed me most this afternoon wasn't that the model made a mistake. Model mistakes are acceptable; at least errors are visible, reproducible, and fixable.

What annoyed me was that, in a task that could have been closed quickly, I constantly saw new processes, confirmations, reports, and reviews. Each one told me the system was very cautious, but didn't tell me with equal force that the system was closer to the result.

I'd rather let the model make a test-detectable error directly on a low-risk small task than have it spend a large number of tokens first proving it knows what norms are. I'd rather glance at the diff and run a test myself than start another context, wait for another result, and judge again whether the judgment is trustworthy, all for a low-value review report.

The value of AI tools is to amplify human judgment and lower execution costs. If a workflow makes people spend more time waiting for processes, explaining processes, and approving processes before finally getting to problem-solving, it has already deviated from the purpose of a tool.

Superpowers once tried to solidify experience into guardrails. The problem is that when guardrails are too many, too dense, and too low, they are no longer guardrails, but a narrow road that forcibly slows down all vehicles.

In the GPT-5.6 era, what we need is engineering discipline with judgment, not indiscriminate process compliance.

I don't want the model to think less. I just want it to spend its thinking on code, data, and results, not on proving how many rituals it has completed.

This is why I say: for high-frequency AI engineering work, Superpowers, with its ungraded, risk-uncalibrated, default mandatory reviews and sub-agents, has transformed from a "capability enhancer" into an "efficiency tumor."

Technical Appendix: This Isn't Emotion, but Identifiable Mechanism Problems

Several Hard Trigger Points in the Original Rules

The following are not my secondary summaries of Superpowers, but typical hard thresholds used in its skill files. The file names are their actual locations within the plugin.

File	Original Tendency	Runtime Consequence
skills/using-superpowers/SKILL.md	"Must call if there's even a 1% chance of applicability"	Low-confidence judgments also trigger the full process
skills/brainstorming/SKILL.md	"This applies to every project, including simple config changes"	Small changes cannot start directly
skills/writing-plans/SKILL.md	Requires breaking work into complete, executable plan tasks	Plan cost and implementation cost are inverted
skills/subagent-driven-development/SKILL.md	Create a new implementation agent per task, then do spec and quality reviews	One change becomes multiple context handoffs
skills/requesting-code-review/SKILL.md	Requires review for every subtask, major feature, and before merging	Review changes from a risk tool to a fixed tax
skills/verification-before-completion/SKILL.md	Requires fresh verification before any completion expression, commit, or next task	Status communication also triggers extra checks

The common problem with these rules is not that they are "completely wrong," but that they write "usually helpful" as "always mandatory." Once the trigger conditions are too broad, the model cannot make normal engineering trade-offs based on task scale and failure cost.

1. Rule Trigger Layer

The frontmatter description of a skill participates in trigger judgment. As long as the description is written as "any conversation," "any feature," "any bug," the trigger surface expands dramatically. The global entry then requires "must call if 1% applicable," which is equivalent to turning low-confidence judgments into high-frequency loads.

2. Context Replication Layer

The sub-agent architecture requires repackaging the task background for each agent. The implementation agent, spec review agent, and quality review agent often read the same requirements and diff separately. The task itself hasn't increased, but the input context has been replicated multiple times.

3. Interaction Waiting Layer

Agent calls typically involve startup, waiting, aggregation, and retries. Even if each agent is fast, serial dependencies still stretch the total time. What the user waits for is not code computation time, but handoff time between multiple roles.

4. Judgment Pollution Layer

When the context simultaneously contains requirements, plans, implementation reports, review reports, and fix suggestions, the model must spend extra attention judging which layer is the current fact. More process documents don't necessarily mean more clarity; they might just increase the chance of state conflicts.

5. Quality Diminishing Returns Layer

The first targeted test usually finds the most direct problems. The second independent check might find boundary conditions. The third review on the same small task, different in form but highly overlapping in information, often sees rapidly diminishing returns. If the process doesn't incorporate this diminishing returns curve into its decision-making, it will treat low-return checks as fixed costs.

6. The Correct Control Variables

What truly should be controlled is not "whether a certain skill was called," but:

• How high is the change risk;
• How great is the cost of failure;
• Whether there is an independent knowledge blind spot;
• Whether there are executable verification methods;
• Whether the user explicitly needs additional review.

These variables determine the process intensity. Any fixed process triggered only by keywords, detached from risk, will ultimately waste resources on simple tasks and create a false sense of security on complex tasks.