The Enso Method Get started

gstack · Garry Tan · as of September 30, 2026

Before gstack plans anything, it questions the idea

Most AI development methods take the request as given and work on building it well. gstack’s recommended first step is a Y Combinator-style office hour that challenges the idea and looks for a sharper framing, and it doesn’t stop until production is checked.

This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.

Two philosophies at a glance

gstack

Question the idea before you plan it, review the plan from every seat, then test it for real and ship it all the way to production.

The Enso Method

Take what to build from the people who own it, write all of it down, and build exactly that, proving each requirement.

Where they differ

  • Builds what is asked Challenges what to build gstack sits at the “Challenges what to build” end; the Enso Method sits toward “Builds what is asked”.
  • The developer at the keyboard decides Someone who isn’t at the keyboard decides gstack sits at the “The developer at the keyboard decides” end; the Enso Method sits at the “Someone who isn’t at the keyboard decides” end.
  • One change at a time The whole body of work up front gstack sits at the “One change at a time” end; the Enso Method sits at the “The whole body of work up front” end.
  • Ends at reviewed code Through release and production gstack sits at the “Through release and production” end; the Enso Method sits toward “Through release and production”.

What they share

  • Tests optional, or after the code Test-first, enforced gstack sits toward “Tests optional, or after the code”; the Enso Method sits toward “Tests optional, or after the code”.
  • Built for new systems Built for existing systems gstack sits in the middle; the Enso Method sits in the middle.

Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.

Interest is not demand

“Interest is not demand. Waitlists, signups, ‘that’s interesting’ — none of it counts. Behavior counts. Money counts.” That rule comes from gstack’s /office-hours skill, and it sets the tone for the method. Garry Tan, the president of Y Combinator, built gstack to turn one coding agent into “a virtual engineering team”, and its first seat is the YC partner who questions the idea before any code exists.

For a startup idea it asks one question at a time, often starting with “the strongest evidence you have that someone actually wants this”, and pushes past the polished first answer. It challenges your premises, even when you arrive with a finished plan, and makes you choose between at least two approaches. In the README’s example, someone asks for a daily briefing app and hears: “I’m going to push back on the framing … what you actually described is a personal chief of staff AI.”

The reasoning is in its ethos: “The engineering barrier is gone. What remains is taste, judgment, and the willingness to do the complete thing.”

Every seat on a team, run as one sprint

gstack calls itself “a process, not a collection of tools”: each step reads what the last one wrote.

  1. Think. /office-hours ends in a reviewed design doc.
  2. Plan. CEO, engineering, design and developer-experience reviews put each decision to you, and an outside reviewer checks the plan by default. /autoplan runs them all and saves the judgment calls for one final approval.
  3. Build. You approve the plan; the agent builds it.
  4. Review and test. /review hunts for bugs that pass continuous integration (CI) and break in production. /qa uses the running app and, where it can run tests, proves each bug with a failing one before the fix.
  5. Ship. /ship opens the pull request; /land-and-deploy merges, waits for the deploy and checks production.
  6. Reflect. /retro, and lessons logged by nearly every skill.

Tan runs ten to fifteen sprints at once and manages them “the way a CEO manages a team: check in on the decisions that matter, let the rest run.”

Built for founders who still ship

gstack is for the person who owns the product: “Founders and CEOs — especially technical ones who still want to ship”, and tech leads who want “rigorous review, QA, and release automation on every PR”. It is at its best when the idea is still unproven and you deploy the result yourself.

It asks for your time while planning: run the reviews one by one and you answer “15-30 intermediate questions”. It installs with Git and Bun into Claude Code or nine other agents.

It suits you less if product decisions belong to someone who isn’t in the chat, since its reviews put each one to you, or if you only want a few tools. The README’s advice: try four commands, then “Stop there. You’ll know if this is for you.”

Where the Enso Method made a different call

Both write the plan down before code, research before asking you, and hold tests to one bar: a test earns its place only if it would catch a real regression. They part on three things.

Whether the idea gets pushed back on

gstack

It questions the request, asks for evidence of demand, and offers bigger versions of the plan, each yours to accept.

The Enso Method

It takes what to build from the people who decide, makes it precise and adds no scope; their open questions go to them as proposals.

Choose by situation: an idea you own and haven’t proven suits gstack; one that a client or business owner has already decided suits the Enso Method.

How much to finish while you’re there

gstack

“Boil the Ocean.” If the complete version costs only minutes more, “do the complete thing. Every time.” /autoplan also fixes the files the plan touches and the files that import them; unrelated work waits.

The Enso Method

Only what an acceptance criterion requires. “Noticing something does not create work.”

Choose by situation: in your own codebase, finishing the neighbours is cheap and yours to approve; on work delivered against agreed requirements, every change should trace to one.

Where the work ends

gstack

In production. Once you approve, it merges, waits for the deploy, checks production health without trusting “merge or HTTP 200”, and watches the live site.

The Enso Method

At a reviewed, tested commit that you make. It has no deploy or production check of its own; release is your pipeline’s job.

Choose by situation: if you deploy from GitHub yourself, gstack covers the last mile; if releases go through your team’s own process, the Enso Method hands over at the commit.

Where gstack shines

  • QA that uses the product. /qa drives a real browser signed in as you, or calls your API and command line, and where it can, reproduces each bug in a failing test first. Apart from a browser check on UI fixes, the Enso Method never explores the running product.
  • A second opinion from another AI on plans and code, by default when the Codex command line is installed. The Enso Method’s reviews use the same model.
  • A memory. Nearly every skill ends by logging what it learned, and later reviews say “Prior learning applied”. The Enso Method keeps no store of lessons.
  • Parallel by design. Built for ten to fifteen sprints at once, with version numbers that don’t collide between them.

How the Enso Method differs, and why

Whether to question the idea is where gstack and the Enso Method part first. gstack is built for a founder: it challenges the idea and the plan with you, finishes everything within reach, and carries the work through to production. The Enso Method is built for building what someone else has decided: it makes their intent precise, does exactly what the requirements ask and proves each one, while their open questions go to them as proposals.

How the Enso Method works Compare all the methods

Get started

gstack is free and open source (MIT). It runs in Claude Code and nine other coding agents; the install steps are in the README at github.com/garrytan/gstack.