An engineer working on the Grok team at SpaceXAI—Lauren Tan, who previously spent time at Cursor and Meta—recently shared details of her personal agent workflow under the name pstack. The standout metric: pstack enables her to land 2,000 pull requests monthly into production with confidence. That translates to roughly 100 PRs per working day from a single person.
While the volume is striking, the underlying direction aligns with broader expectations about AI-assisted development. What sets this apart is that these are not merely generated code snippets—they represent actual, production-ready changes. Tan identifies verification as the linchpin of this workflow, treating it as critical infrastructure rather than just another capability.
The verification skill depends on a capable runtime that agents can operate, examine, and receive structured feedback from. For a single-process application, that runtime is the application itself, spun up on demand. For systems composed of dozens or hundreds of microservices, no such runtime exists naturally, and building one that scales to hundreds of parallel agents presents the real challenge.
Verification as a throughput multiplier
Tan frames verification through a throughput lens. An agent capable of validating its own output continues working until completion. An agent that must hand off a diff and wait for human review becomes the slowest link in the chain. She argues that robust verification capabilities can amplify team output by 100 to 1,000 times.
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.
Lauren Tan
At 2,000 monthly pull requests, manual review of each change would allow roughly five minutes per PR across a full working month. Human review simply cannot serve as the verification mechanism at this scale. The verification layer must operate without human intervention and run in parallel with agents generating changes.
The single-application model
Tan's verification approach generates a command-line interface and a feature map for the application. The CLI enables agents to launch the app, navigate through it, examine state, and receive structured JSON responses. Each agent operates with its own complete application copy and can validate changes end to end.
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.
Lauren Tan
This approach works because the application runs as a single process. A frontend, a compiler, or a standalone service with a database can start from the CLI in seconds and be discarded afterward.
Teams working on complex distributed systems face a different reality. Their application emerges from interactions between an order service, a payments service, an inventory service, message queues, multiple databases, and several third-party integrations. Large organizations may have thousands of such components. Verifying a change to one service requires exercising the calls it makes and receives. The CLI can start the modified service alone—it cannot instantiate the entire system.
Why existing runtime approaches fall short
Local runtimes with mocked dependencies are inexpensive and support full parallelization through worktrees or cloud development environments. The drawback is fidelity. Mocks capture what a dependency did when someone last examined it, and they become stale the moment the real service changes. An agent verifying against mocks closes its feedback loop against outdated assumptions, and failures surface only after the change merges.
A complete stack copy per change delivers fidelity and isolation. However, costs scale with the number of services multiplied by concurrent changes, making this approach prohibitively expensive at hundreds of agents. Time compounds the problem. Provisioning a full stack takes minutes, yet the workflow requires agents to test each iteration while still developing. An environment that becomes ready after the agent has moved to its next attempt provides no value.
Shared staging environments are faithful and economical because only one exists—which is precisely the problem. A single mutable environment cannot safely host hundreds of concurrent changes. Agents overwrite each other's deployments, a broken change from one agent breaks tests for all others, and the feedback-loop property that drives the workflow vanishes.
Five requirements for agent-driven verification
Examining Tan's workflow as a specification reveals five essential properties:
- Changes must run against real dependencies, or verification becomes meaningless.
- Hundreds of concurrent changes must remain invisible to each other.
- Environment cost must scale with change size, not system size.
- Environments must start in seconds, because an agent waiting for provisioning wastes parallelism.
- Everything must be accessible through the CLI or MCP server the agent already uses.
The first and third requirements push in opposite directions. Realism demands complete system copies. Cost efficiency demands maximum sharing. Shared staging sacrifices isolation; per-change full stacks sacrifice cost. A design meeting all five must share and isolate simultaneously.
The solution treats an environment as a view into a running system rather than a copy. One stable set of shared services runs continuously, deployed from the main branch and maintained like production. When an agent needs to verify a change, it runs only the modified service—either on its own machine or as a lightweight deployment in the cluster—and connects it to the shared stack as a new isolated environment.
The architecture that does this treats an environment as a view of a running system rather than a copy.
Lauren Tan
Within that environment, the changed service becomes the authoritative version, and all other calls route to shared stable versions. The agent observes a complete, realistic system, as do the other hundred agents—each seeing a system that differs from baseline only by its own change delta. Requests carry environment identity across service boundaries, preventing one agent's traffic from reaching another's version under test. Stateful side effects that cannot be safely shared, such as queue topics or writable databases, receive a per-environment copy when necessary.
The cost model follows logically. An environment runs one or two services instead of sixty; it starts in the time a single service needs to launch; and agents can create and destroy it within their own loop. Signadot packages this pattern for Kubernetes, with the shared stable stack running in the team's existing cluster.
The complete agent-driven workflow
Combining both pieces, the workflow enabling 2,000 monthly PRs to production translates to distributed systems with minimal modification. An agent accepts a task and modifies one service. It requests an environment for that change and receives one in the time its service takes to start. It then drives real requests through the system's entry point, watching them traverse the actual dependency graph with only its own service running new code. It examines structured results, fixes failures, and retries. Once checks pass, it opens the PR, and the environment disappears at merge.
Environments stop being something the platform team hands out and become something agents create, use, and discard as needed.
Lauren Tan
For platform teams, the unit of work shifts. Currently, they provision environments—maintaining shared staging or stamping out full copies. In this model, they run one shared stable stack and the virtualization layer: context propagation across services, isolation for stateful dependencies that cannot be shared, and tooling for environment creation and teardown. Environments transition from something platform teams distribute to something agents spin up, use, and discard on demand.
Verification infrastructure as the throughput bottleneck
Tan's post is not a portrait of one exceptionally productive engineer. It demonstrates what occurs when agents execute the complete loop—writing changes, verifying them, and iterating without human intervention. The verification infrastructure forms the foundation supporting the entire workflow.
In distributed applications, that infrastructure must be a runtime environment delivering real dependencies to every agent, preventing hundreds of concurrent changes from interfering with each other, costing per change rather than per system copy, and starting in seconds. This is what converts agent parallelism into shipped code instead of a longer review queue. That runtime environment model is what Signadot was built to provide.