Build1 publisher3 min readPublished
Lauren Tan's 2,000 pull requests a month rest on an app that fits in one process
Her verification skill generates a CLI that starts the whole application and hands back structured JSON, so the agent can close its own loop. Dozens of services do not start from one CLI.
The Engineer · Build desk
What happened
- Lauren Tan, an engineer on the Grok team at SpaceXAI who previously worked at Cursor and Meta, published a guide to her personal agent workflow, pstack.
- The New Stack reports that the workflow has let her ship 2,000 pull requests a month to production with high confidence.
- Tan names verification as the most critical piece of the workflow and treats the skill that lets an agent check its own work as critical infrastructure.
- She claims strong verification skills can multiply a team's output by 100 to 1,000 times.
- The New Stack argues the skill depends on a runtime the agent can drive and inspect, and that a system of dozens or hundreds of services has no such runtime by default.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint At this volume the checking layer has to run unattended and in parallel with the agents producing work, so the review queue is no longer where a team decides whether a change is correct.
- decision Tan puts stack selection in the verification column. A team that cannot start its application from one command is then choosing between building a runtime and capping agent throughput.
- exposure Teams whose agents verify against mocks get a clean green loop and meet the drift in production, after the merge has already happened.
- cost Buying fidelity instead means paying services times concurrent changes; at the low end of the article's ranges that is 10,000 service instances per wave of agents.
The verification skill generates a command line interface and a feature map for the application [9]. Through it an agent starts the app, navigates it, inspects state, and reads structured JSON results back [9]. The JSON is what lets the loop close without a person in it, because an agent can branch on a parsed field. Each agent gets a complete copy of the application and tests the change end to end [10].
The precondition is strict. This works because the application fits in one process [12]. A frontend, a compiler, or a single service with a database starts from a CLI in seconds and is thrown away afterwards [12].
Tan's throughput argument is about who waits for whom. "An agent that can check its own output keeps working until the task is done. An agent that can't hand you a diff and wait makes you the slowest component in the loop," she wrote [5]. The New Stack puts hand review at about five minutes per PR if one person read all 2,000 across a full working month [7]. Take her own figure of nearly 100 PRs per working day [3]. That sets the month at 20 days [19]. Two thousand changes at five minutes each is 10,000 minutes, or 166 hours, about 8.3 hours of review every working day [20].
A system made of dozens or hundreds of services comes with no such runtime by default [13]. The application is the interaction between an order service, a payments service, an inventory service, a queue, several databases and a handful of third-party APIs, and at larger shops the service count runs into the thousands [14]. A pull request to one service is verified by exercising the calls it makes and receives, and the CLI that starts the changed service leaves the rest of the system down [15].
Both substitutes have known failure modes. Local runtimes with mocks are cheap and run fully parallel on worktrees or cloud development environments [16]. Mocks encode what a dependency did the last time someone looked, and they drift the moment the real service changes; the agent's loop closes cleanly and the failure appears after merge [16]. A full copy of the stack per change is faithful and isolated, but its cost scales with the number of services times the number of concurrent changes, and time is the bigger problem [17]. Multiply the lower bound of the article's own ranges: a hundred services against a hundred parallel agents is 10,000 service instances standing up at once [21].
Tan is direct about what the runtime is worth paying for. "I personally feel that agentic verification is so important that I would unironically suggest building your own rich debugging tools, or even choosing a different tech stack, in order to have unfair advantages and extreme productivity in building software," she wrote [11]. The 100 to 1,000 times output multiplier is her claim [6]. The New Stack does not report an independent count of what landed, and credits the 2,000 figure to her guide [2].
What to watch
- Whether anyone publishes a service-graph runtime that stands up hundreds of parallel verified copies without full-stack cost per change.
- Whether Tan or others report post-merge defect rates alongside the PR counts, which would test the 'high confidence' half of the claim.
- Whether cloud development environment vendors offer mocks pinned to live service contracts, closing the fidelity gap the article describes.