Superpowers Writing Plans in Practice: A Good Plan Cuts Token Usage in Half

Why Your Superpowers Token Consumption Is So High

When doing Vibe Coding with Superpowers, many people find their Token consumption shockingly high. On the surface, it seems like the execution phase is burning through Tokens, but the root cause often lies in the planning phase—if the plan isn't well-written, the subsequent execution will involve repeated trial and error, wasting Tokens for nothing.

Vibe Coding refers to a programming paradigm where developers describe their intent in natural language and let AI handle most of the code generation. In this mode, there's a strong correlation between Token consumption and task quality: every "failed guess" by the AI means additional context filling, error fixing, and regeneration—all billed by Token. The Context Window of large language models is limited. When erroneous code and fix records keep piling up, they not only consume Tokens but also dilute the proportion of useful information, causing subsequent output quality to decline further—creating a vicious cycle.

This article walks through a real-world project to explain in detail how to properly use Superpowers' Writing Plans skill, enabling AI to generate high-quality development plans and control Token consumption at the source.

Recap: From Brainstorming to Technical Stack Selection

In the previous phase, we used Superpowers' brainstorming skill to complete requirements analysis, produced a project specification document, and finalized the technical stack selection. Here's the project overview:

• Project Goal: Develop a Bug collection tool
• Core Functionality: Collect Bug information from multiple data sources
• Display Mode: Command-line/TUI mode
• Development Language: Rust

The specification document is ready, and now we enter the Writing Plans hands-on phase.

Understanding the Nature of Writing Plans: Plans Detailed Enough to Include Code Implementation

First, a key insight must be established: the plans generated by Superpowers are extremely detailed, containing specific code implementations. This means if the code in the plan is wrong, the consequences will be catastrophic.

The Nature of LLM Code Generation Is Probabilistic Inference

Developers who frequently use AI for coding should all appreciate this: LLMs writing code is fundamentally probabilistic inference based on training data. The underlying mechanism of large language model code generation is conditional probability prediction based on massive training corpora—the model doesn't "understand" code logic but rather predicts "what token sequence is most likely to appear after this context." GitHub, Stack Overflow, open-source repositories, and similar sources constitute the bulk of training corpora, so generation quality for high-frequency content like React, Python standard libraries, and common REST patterns is far superior to niche SDKs or private APIs. This uneven data distribution phenomenon is called "Training Data Bias." For mainstream tech stacks with sufficient training, output quality is high; but for niche scenarios (domains with insufficient training data), models tend toward "hallucinatory completion"—generating API calls, parameter names, or return structures that look reasonable but are actually wrong. The model itself cannot perceive these errors, making the error rate extremely high.

The Chain Reaction of an Incorrect Plan

What happens if you enter the execution phase with a plan that has the "right direction but wrong implementation details"?

1. Best case: The AI in the execution phase catches the error and fixes it—but this itself wastes a significant amount of Tokens
2. Worst case: The test cases themselves are wrong, and all the AI's efforts go toward satisfying an incorrect test case. Even if the tests eventually "pass," the actual results drift further and further from the correct answer

The conclusion is clear: To save Tokens, you cannot allow the AI to produce incorrect, misleading code during the planning phase.

Practice: Identifying Where AI Is Most Likely to Make Mistakes

Returning to the Bug collection tool project, where is AI most likely to make mistakes?

The Subtraction Principle

Popular tech stacks (like Rust standard libraries and common frameworks) are well-covered in AI training—these don't need extra elaboration. However, note that providing too much redundant information isn't helpful either—the key is precisely supplementing the parts AI doesn't know.

Finding the Real Blind Spots

In this project, where AI is most likely to err is the API specifications for Bug data sources. These API documents have limited coverage in training data, and if AI writes blindly, it will almost certainly get things wrong.

Solution: Let AI Write Plans by Referencing Documentation

The solution is straightforward: download the API documentation for the three data sources to local storage and let AI write the plan by referencing these documents.

Step-by-Step Operations

Step 1: Use the Default Command to Fetch API Documentation

The Default command mentioned earlier in the "Spending Control" chapter—many URL-to-Markdown tools are wrappers around it. Execute the command directly in the window using an exclamation mark, and the command output will fill into the editor's context.

The API documentation has pagination; just download it locally.

Step 2: Avoid Context Pollution

After downloading, return to the conversation and inform the AI that documentation collection is complete. Pay special attention to the "context pollution" issue here: the Context Window is the maximum number of tokens a large model can process in a single inference, currently ranging from 32K to 200K for mainstream models. The API documentation download process may generate substantial intermediate output (such as HTTP response headers, pagination metadata, etc.). If left directly in the conversation flow, this noise occupies precious context space and may mislead the model's understanding of document structure. Isolating the download step from the plan generation step is a standard "Context Hygiene" practice that ensures only high-quality, effective information remains in the subsequent context window.

Step 3: Fix the Specification File First

Before formally writing the plan, have the AI reference the API documentation to fix errors in the specification file. The Specification Document (Spec) is the bridge between requirements and implementation. In AI-assisted development workflows, it's not only a reference for human developers but also an "anchor" for AI code generation. An accurate Spec narrows the model's output space from "all possible implementations" to "implementations that meet business constraints," significantly improving generation quality. Conversely, errors in the Spec will be faithfully "amplified" by the AI—the model will generate self-consistent but incorrect code based on wrong premises, and the further into execution, the harder the deviation is to correct. This is the core value of the "fix specs first, then write plans" step.

Step 4: Generate the Plan

After fixes are complete, formally have the AI generate the development plan. The final plan reached over 2,000 lines, covering detailed implementation specifics.

Model Selection and Cost Optimization Strategy

This section uses Claude 3.5 Sonnet (KM2.6) to generate the plan. But in the next execution phase, we'll switch to MiniMax 2.5 for actual coding.

This introduces an important concept—the Advisor Pattern. This is a multi-model collaboration architecture gradually taking shape in the AI engineering field: use high-capability, high-cost models (like Claude 3.5 Sonnet, GPT-4o) for planning, review, and critical decisions, while using low-cost, high-speed models (like MiniMax, Haiku, Gemini Flash) for batch execution and repetitive tasks. The economic logic of this strategy is similar to the "strategic consultants + execution team" model in enterprises.