From Blank Prompt to Engineering System

gstack, the open-source project in garrytan/gstack, is the subject of this series. The question is not how many slash commands it contains, but how it tries to turn an AI coding session into an engineering system: one that can clarify a goal, carry decisions into implementation, observe a real application, test what changed, and keep a human responsible for consequential choices. That matters because an agent can produce code quickly while still misunderstanding the product, missing a browser failure, or declaring victory on evidence that no longer matches the current code.

The useful reader outcome is a mental model, not a memorized catalog. gstack combines specialist workflow skills, a browser layer, release checks, safety controls, and persistent learning. The central claim is that speed becomes more valuable when it is carried by explicit stages and trust boundaries. The rest of this series examines how those parts connect, where they create leverage, and where the repository itself says they stop being guarantees.

The problem behind the virtual team

The project presents gstack as Garry Tan’s answer to a practical question: how can one builder ship with the leverage of a much larger engineering group? Its README describes a virtual team inside Claude Code: a CEO who challenges the product, an engineering manager who fixes the architecture, a designer who looks for generic or careless interface decisions, a reviewer who hunts production bugs, a QA lead who opens a browser, a security officer who audits threats, and a release engineer who gets the work over the line.

That description is easy to mistake for branding. The more important point is the division of labor. Each role is a different question applied at a different moment. A product review asks whether a requested feature is the right response to a real problem. An engineering review asks how data, state, failure, and tests fit together. QA asks what a user can actually do in the running application. A release workflow asks whether the current tree has fresh evidence behind it. The roles matter because a single coding prompt tends to collapse all of those questions into one optimistic act of generation.

The project’s own productivity story makes a strong version of this argument. The README reports three production services and more than forty shipped features in sixty days, alongside a maintainer-reported comparison between normalized logical code change in 2026 and a 2013 pace. It argues that raw lines of code are a poor measure because AI inflates them, then presents a much larger result after its own normalization. That is relevant evidence about what gstack is meant to enable, but it is not independent proof that gstack alone caused the outcome. The figures are a maintainer’s account, supported by a linked methodology and reproduction script, not a controlled study.

A more defensible starting point is visible in the repository’s structure. gstack is built around a workflow that crosses boundaries: from a person’s intention to a plan, from a plan to code, from code to a browser-visible result, and from a result to a release decision. The repository calls it a process rather than a collection of tools. That distinction is the key to understanding everything else.

Process is the product

The named sequence is simple: Think → Plan → Build → Review → Test → Ship → Reflect. Its significance lies in the handoffs. Office-hours produces a design document that later planning skills can read. Engineering review can produce a test plan that QA picks up. Review findings can lead to fixes and new regression tests. Shipping checks whether tests, reviews, coverage, documentation, and current-tree verification are aligned. Reflection and learning preserve useful decisions for later work.

Consider the project’s own example. A user asks for a daily briefing app. A literal coding assistant might start with calendar APIs, a database table, and a page that lists events. In gstack’s office-hours example, questioning reveals a different problem: multiple calendars contain stale information, locations are wrong, preparation takes too long, and the useful outcome is closer to a personal chief of staff than a calendar view. The point is not that every feature request hides a grander product. The point is that the first artifact should capture the pain and the premises before implementation makes the initial wording expensive to change.

From there, the roles narrow the uncertainty in sequence. A CEO-style review can ask whether the broad vision should be pursued or whether a narrow daily briefing is the better wedge. An engineering review can then ask what happens when calendar access succeeds but enrichment fails, which work is synchronous, and how duplicate jobs or low-confidence results are handled. The browser and QA stages eventually test whether the chosen flow works for a real user. The same request has passed through product meaning, technical state, and observable behavior instead of remaining one sentence in a chat transcript.

In an unstructured session, context lives mostly in the conversation. The agent may remember why a decision was made for a few turns, then lose the reason while implementing a neighboring task. gstack’s answer is to make important context durable. A design document carries the product framing. A plan carries technical choices and unresolved trade-offs. A QA report carries browser evidence. A regression test carries the exact behavior that once failed. A release check can tie a completion claim to the tree that was actually tested. These are not merely notes. They are checkpoints that let one stage challenge the assumptions of another.

The handoff is also a division of ownership. The product stage owns the question of value and scope. The engineering stage owns system boundaries and failure paths. The browser stage owns direct observation of an interface. The release stage owns whether the evidence is current enough to support publication. No single artifact answers all four questions, and gstack does not pretend that one model response can do so reliably. The workflow is useful precisely because it gives each question a place where it can be asked and a later stage where its answer can be tested.

/autoplan makes the dependency explicit. It runs CEO review, then design review when the work has interface scope, then developer-experience review when the work is aimed at developers, and engineering review last. The order matters: engineering is the required shipping gate, so it must see the plan after earlier stages have amended it. The system can resolve mechanical questions automatically, but it separates those from taste decisions and User Challenges. A close choice between two viable designs can wait for one final approval gate. A case where both model voices want to change the user’s stated direction also waits for the user.

This is a different idea of automation from “let the agent decide everything.” It automates repetition around a visible decision structure. The human does not need to answer every low-value question, but they remain the authority when the choice changes the product, carries meaningful risk, or depends on context the models do not have.

flowchart LR I["User intent"] --> P["Plan and review artifacts"] P --> B["Build"] B --> V["Browser and code verification"] V --> S["Ship and deploy"] S --> R["Reflect and learn"] R --> I

The loop also explains why gstack cannot be understood as a set of interchangeable utilities. A browser without a plan can confirm that a page loads while missing the behavior that matters. A review without a clear scope can produce technically plausible objections to the wrong product. A ship command without fresh verification can publish code that changed after the tests ran. The value is in the relationship among the stages.

Speed needs a governor

The project’s builder ethos is unusually direct about speed. It argues that AI-assisted implementation makes completeness cheaper, so teams should prefer the complete version when the remaining work is genuinely small. It also says to search before building and to treat user judgment as the rule that overrides the others. Those principles pull in different directions. “Boil the Ocean” pushes against premature shortcuts; “Search Before Building” pushes against reinventing existing solutions; user sovereignty limits both when the builder’s context points elsewhere.

That tension is productive because it keeps speed from becoming the only metric. If an agent can implement a feature in minutes, the scarce resource may shift to deciding whether the feature is right, observing whether it works for a real user, and verifying what the agent changed. gstack therefore treats planning, browser access, review, and release evidence as part of the product, not as bureaucracy added after the model has finished coding.

There is a practical consequence for how a reader should evaluate the project. The interesting question is not whether every role is needed on every change. gstack itself describes smart routing: a backend bug need not trigger a full design review, while a new user interface may need design and browser inspection. The process is meant to be selective without becoming improvised. Its value appears when a change crosses several kinds of uncertainty, when a solo builder cannot hold all the context at once, or when the cost of a missed production issue is higher than the cost of one more structured check.

The rest of this series follows that argument through the system. It first examines how gstack turns a vague request into a buildable direction. It then looks at the two browser engines that let the workflow observe real behavior, before tracing review, QA, shipping, and production checks. The security chapters ask what the agent may read, mutate, or send, especially when a web page or a remote agent is involved. Finally, the series follows the durable layers that let approved work compound across sessions, hosts, and teams.

The practical judgment is therefore narrower than “AI can replace a team.” gstack offers a way to make one person’s agent-assisted work more structured, observable, and repeatable. Whether that structure pays off depends on the project’s platform, browser needs, tolerance for persistent state, and willingness to keep human gates meaningful. The next question is where that structure begins: before the first line of code, with a decision about what is actually being built.

References