Loading today’s stories
Build1 distinct publisher3 min readUpdated
The Superpowers methodology puts three steps ahead of implementation, and its own example counts nine open decisions behind a three-word feature request. None of those are model problems.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
The useful number here is not in the tooling. It is in the arithmetic of a single short request: the source enumerates nine unanswered questions behind "Add team invitations", covering email delivery, expiry, revocation, granted role, users who already have accounts, users who belong to another organisation, auditability, resend, and which failure states users can see [5][1].
A worked outcome statement in the same material answers several at once. Organisation owners can invite an email address to a workspace, invites expire after seven days, can be revoked, grant a selected role on acceptance, and must not expose workspace existence to unauthenticated users [7]. That is a requirement and an acceptance checklist in the same sentence, which is the whole trick.
The cost asymmetry is what makes the sequencing defensible. Rewriting a paragraph of design is cheap. Unwinding a migration, an endpoint and the UI states hung off them is not, and the source's point is that an agent which creates an invitations table has already decided the things nobody asked it about [6]. The design checklist reflects that: seven areas, and every one of them is the kind of work that hardens on contact, including ownership boundaries, API error behaviour, authorization, lifecycle rules, backward compatibility, operational failure modes, and explicit non-goals [9][2].
Then there is the enforcement problem. Of the six steps, only red/green TDD is machine-checkable without a person in the room [3]. Design approval is defined as a human saying yes to product behaviour, delivered in chunks small enough to actually read [8]. Meanwhile the same repository describes subagent-driven development for executing and reviewing tasks [12]. So the one gate that cannot be automated sits inside a workflow built to automate the rest of the loop, which is where adoption will either hold or quietly collapse into rubber-stamping.
The plan artifact is the part most teams will underrate. It is meant to name the files, the change and the validation method per task, and to be specific enough that a different developer or a different agent can execute it without reinterpreting the original request [10]. The invitation example slices into eight ordered tasks, ending with rollout and monitoring documentation [11][3]. Written that way, the plan, not the prompt, becomes the thing under version control and the thing a reviewer can diff against.
What the material does not contain is measurement. There is no before-and-after rework figure, no defect count, nothing quantifying what the gates save [4]. The argument rests on a claim about model behaviour rather than evidence about outcomes: agents are good at filling gaps with plausible assumptions, and a patch that compiles and passes a narrow test can still solve the wrong problem [1][2]. That is a reasonable read of how these tools fail. It is also, for now, an assertion, and anyone adopting the process is buying the reasoning rather than the data.
Ranked by verification strength, evidence, and original report placement.
The fastest way for an AI coding agent to create expensive work is to start coding too soon, because AI agents are very good at filling gaps with plausible assumptions.
A typical failure sequence: a request arrives, the agent infers the missing requirements, selects an architecture, edits several files and produces a plausible patch. The patch may compile and may pass a narrow test, and can still solve the wrong problem.
Superpowers is a methodology and set of composable skills that asks the agent to clarify the outcome, develop and get approval for a design, make an implementation plan, use true red/green test-driven development, carry out the work in small tasks, and review what was built. Only after approval does the workflow move to implementation.
Each gate targets a different failure class: clarification catches misunderstood outcomes, design review catches wrong shapes and missing constraints, planning catches hidden dependencies and sequencing errors, tests catch behavioral regressions, and review catches mismatches between the intended change and the actual diff.
The request "Add team invitations" leaves unanswered whether invites are email-based, whether an invitation expires, whether it can be revoked, what role an invited person receives, what happens if they already have an account, what happens if they belong to another organization, whether the action is auditable, whether an administrator can resend, and which failure states are visible to users.
A coding agent that immediately creates an invitations table has already made decisions; a structured workflow makes those decisions visible before they become database migrations, endpoints and UI states that are expensive to unwind.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but single-source and argumentative
The workflow description is specific and internally consistent - a named six-step sequence, a nine-item decision list, a seven-area design checklist and an eight-task plan slice - and is attributed to the Superpowers repository and README. But it rests on one publisher, and every efficacy assertion is reasoned from failure modes rather than measured, with no trial, metric or independent corroboration in the cluster.
No adoption evidence in cluster
The source describes a repository and methodology but supplies no releases, deployments, user or download counts, team usage disclosures or third-party reports. Nothing in the supplied material indicates who, if anyone, is running this workflow in practice, so adoption cannot be scored without inventing facts.
Prescriptive confidence ahead of measurement
The framing - that agent failures happen before compilation and the fix is a human sign-off rather than a better model - is a causal efficacy claim, while the supporting material is a single walkthrough with a hypothetical invitation feature and no measured outcomes. The gap is moderate rather than severe because the descriptive claims about the methodology are concrete and the article itself concedes limits, noting that TDD guarantees only that selected behaviour is checked and not a correct product decision.
No disclosed relationships
The supplied material contains no information about the author's relationship to the Superpowers repository, no sponsorship, funding, employment or commercial interest disclosure, and no vendor product being sold. Assigning an incentive score would require inferring facts the cluster does not provide.
Confident on description, weak on effect
There is reasonable confidence that the methodology exists as described, since the steps, checklists and repository practices are reported in specific, enumerable form. Confidence that the gates deliver the claimed reduction in wasted agent work is low: one publisher, no adoption signal, no measurement, and no contradicting or corroborating source to triangulate against.
build
Thirty minutes a day, and none of it from letting the agent write Swift1 distinct publisher
build
Thirteen tasks green, then "give up (Recommended)" on the one that needed understanding1 distinct publisher
build
The bug in agent memory is not volume, it is that everything recalled has equal authority1 distinct publisher
build
Do not let the model that wrote the diff approve it: the case for a cross-vendor review gate1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026