The previous post made the case for layering three open-source tools, gstack, Superpowers, and Visual-Explainer, into a coordinated engineering team that thinks strategically, enforces process, and communicates visually. The stack works. The more interesting question, after running it for a while, is when it does not.
The harder skill is not getting the team to ship features faster. The harder skill is knowing the situations where the team is the problem, and reaching for something smaller. Six concrete cases where the three layers turn from force multiplier into productivity drag.
five-minute utility scripts
The stack assumes the work is non-trivial. /office-hours frames the problem. /autoplan structures it. Superpowers enforces TDD. Visual-Explainer renders flow diagrams. The whole apparatus exists to discipline a multi-day feature.
For a script that batch-renames two hundred files, or scrapes a single API endpoint into a CSV, that apparatus is friction. By the time the planning phase has produced a TDD outline, a one-liner shell command would have already finished the job. The cost of running the stack is not the tool calls. It is the time spent agreeing on an approach for something that does not require agreement.
The rule I use: if the work would take a competent human under ten minutes, skip the stack. Open a plain Cursor or ChatGPT session, write the line, run it, move on.
genuinely novel research and zero-to-one work
Models are excellent at remixing patterns that exist in their training data. They are weak at producing patterns that do not yet exist. For ninety percent of engineering work this distinction does not matter, because most engineering work is not zero-to-one.
For the work that is, the stack actively hurts. /plan-ceo-review produces a confident-sounding business case for a solution direction that has no evidence of working. Superpowers locks TDD around an unstable target. Visual-Explainer renders beautiful diagrams of an idea that has not yet been validated. The output looks rigorous; the underlying work has not actually been done.
In novel territory, the stack's comfort and structure are the wrong tools. Whiteboards, pen-and-paper, and unstructured exploration with a single model in plain conversation produce better results, because the early phase requires divergence, not discipline.
hardware and hyper-specialized domains
FPGA bitstream programming. Quantum simulator code. Medical-device firmware. High-frequency trading execution engines. Embedded systems with hard real-time constraints. These domains share two properties: training data for them is thin, and the failure modes are physical rather than logical.
A general agent stack does not have enough high-quality material in its weights to reason confidently about timing closure on a Xilinx part, or about the actual electrical behavior of a power-on reset circuit. /qa cannot run against the real hardware. /plan-eng-review produces architecture diagrams that look correct and miss silicon-level gotchas. The result is code that simulates cleanly and fails on the first physical board.
In domains where the constraints are physical, the stack should be limited to tasks that are clearly within the model's training data: documentation, glue code, test scaffolding. Humans should own everything that touches the metal.
legacy monoliths with obscure tech stacks
Fifteen-year-old Java running on WebSphere. ColdFusion behind a proprietary auth layer. A .NET 2.0 service whose source nobody can find. The challenge is not the size of the codebase. It is that the codebase encodes context the model was never trained on.
/investigate runs in loops because the context window cannot hold the relevant tribal knowledge. /qa cannot reproduce the runtime environment. The Superpowers worktree pattern depends on a CI loop that does not exist. The agent reads the code, generates plausible-looking changes, and has no way to validate them against the real system.
The pattern that works in this category is the smaller one. Skip the full stack and use a single agent in chat as a translator. Paste a function, ask what it does, paste the next, build understanding incrementally. The orchestrated team adds nothing when the bottleneck is the human's understanding of the system, not the agent's productivity.
brand-sensitive creative work
Landing pages, marketing sites, product design where the brief is "make it feel premium," "make it feel us," or "make it expensive." The stack will produce competent variants. /design-shotgun generates options. Visual-Explainer makes them legible. Every variant will be technically correct.
None of them will resolve the question that matters, which is whether the work feels right. That judgment lives in human taste, in cultural context, and in the specific resonance the brand has with its audience. An agent cannot evaluate "expensive feeling" because the concept is not legible to it. The stack's contribution is to produce more material to choose from. That helps when the choice is between visible alternatives. It does not help when the choice is between barely-distinguishable alternatives where only a person with the brand in their head can tell them apart.
For this kind of work, generate the variants with the stack if it speeds you up, but make the final call yourself. Do not ask the agent to decide.
air-gapped or heavily regulated environments
Government contracts. Hospital networks. Banks running classified workflows. Air-gapped industrial systems. Anything inside FDA, HIPAA, or SOC 2 boundaries that prohibits feeding proprietary code to an external model.
The stack as designed runs against Claude Code, Codex, and other cloud-hosted agents. If your environment cannot reach those services, for compliance, classification, or contractual reasons, the entire stack is unusable. Even when the network technically permits it, regulatory frameworks often prohibit submitting source code, patient data, or classified specs to a third-party model.
The right move here is to recognize that the stack is not the answer. Self-hosted models running on approved infrastructure can do parts of the work, but the orchestrated team pattern depends on tooling that is not available in the air-gapped tier. Plan around it.
the skill that actually matters
Reading these six cases as a list, the pattern is consistent. The stack is built to discipline ambiguous, human-scale, well-trodden engineering work. When the work does not match that profile, when it is too small, too novel, too physical, too obscure, too subjective, or too restricted, the stack adds cost without adding value.
The skill the stack does not teach is the skill of recognizing which category a problem is in before you start. That is the call that separates someone who ships fast from someone who looks like they are shipping fast and ends up in a planning loop on a problem the stack cannot solve.
The previous post argued for using all three layers when the work fits. This post argues for the opposite move: knowing when to leave them all turned off. The two arguments are not in tension. Mastery of the stack is not using it more. It is using it exactly when it helps, and reaching past it when it does not.