Pstack Is Agent Overkill. Use It Anyway! Last read

Rob Shocks walks through Pstack, a skill/playbook bundle from Lauren Tan (React core team, ex-Netflix, SpaceX, now Cursor) that packages a senior engineer's workflow into 20+ agent skills routed by a "potato mode" dispatcher. He uses it to one-shot a skill manager app called Molten Base, then breaks down the standout skills (arena, swarm, why, recall, interrogate, create/maintain verification, onslaught, brawl) and the underlying principles. Verdict: it roughly doubled build time and burns far more tokens than a plain agent run, but produced a noticeably more hardened app, so it's worth using selectively rather than on every project.

• Pstack is deliberately not a spec-and-planning framework like BMAD or OpenSpec test it's built to operate on an established codebase, because Lauren Tan's stance is "I don't believe in planning. The best spec is the code."
• "Potato mode" acts as a router that picks which of the 20+ skills and 22 playbooks to invoke for a given prompt.
• Arena runs three or four different models (Claude, GPT, Grok, Opus) against the same problem and grafts or rejects parts of each into the final commit test a feature Cursor shipped and later removed; swarm instead gives parallel workers different slices and aggregates the results.
• The "why" skill pulls decision context from connected MCPs and CLIs test PostHog product data, Slack threads, Sentry logs test to reconstruct ADRs rather than just reading the chat transcript; "recall" uses the same trick to resume a stale project.
• Verification is the backbone of the whole stack: create-verification writes scripts that prove real app behavior, maintain-verification keeps those scripts from drifting, and interrogate has multiple models review the same code against standards.
• In the demo run, the verification/audit phase caught three false claims the agent had hallucinated about its own work.
• Core principles include the laziness protocol (prefer deleting code, smallest change possible), redesigning from first principles as if a feature existed on day one, minimizing reader load, exhausting the design space, building a lever (a CLI or script) for anything repeated, and guarding the central context window by offloading to sub-agents.
• Benchmark: the same project took ~30 minutes with a plain model run and no skills versus ~1 hour with Pstack, at substantially higher token cost test the presenter says skip it for small design changes or front-end UI tweaks.

No planning skill, and why arena burns the token budget 2:11–3:00

It's the clearest statement of the philosophy that separates Pstack from spec-driven frameworks, immediately followed by the arena skill pitting four models against one design problem.

Lauren's personal take on this is I don't believe in planning. The best spec is the code. So there's deliberately no planning skill baked into Pstack.

The audit caught three hallucinated claims 8:37–9:25

A concrete result showing the verification machinery actually catching the agent lying about its own work, plus the point that detailed up-front plans break on contact with reality.

This is why verification is so important. The agent had realized it had hallucinated some of the details. It caught three false claims that it was able to correct.

I don't believe in planning. The best spec is the code.

The goal isn't more code, it's maximum impact with the least amount of code.

Having a compile and go green on tests is not the same as actually testing and proving it works in terms of real artifact by deeper verification.