Lauren Tan, an engineer on the Grok team at SpaceXAI, has shipped 2,000 pull requests (PRs) a month to production with high confidence using her personal agent workflow called pstack, according to a recent guide she published. That's nearly 100 PRs per working day from a single engineer. The guide argues that verification—the ability for an agent to check its own work and continue until a task is complete—is the critical infrastructure enabling this level of productivity, and Tan describes it as the foundation on which the entire workflow depends.
At 2,000 pull requests monthly, a human reviewer would have roughly five minutes per PR across an entire working month. The workflow relies on agents generating a command line interface (CLI) and feature map for the application, allowing each agent to start the app, navigate it, inspect state, and read structured JSON results. Each agent receives a complete copy of the application and can test changes end to end. For a single application that fits in one process—a frontend, compiler, or standalone service with a database—this runtime can start from a CLI in seconds and be discarded afterward. But for teams building complex distributed applications made up of dozens or hundreds of services, no equivalent runtime exists by default, and creating one that keeps pace with hundreds of parallel agents becomes the hard challenge.
According to Tan, agents with strong verification skills can multiply a team's output by 100 to 1,000 times because "an agent that can check its own output keeps working until the task is done," while one that can't "hand you a diff and wait makes you the slowest component in the loop." The report states that Tan 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." The problem for distributed systems is that existing runtimes don't survive hundreds of parallel agents: local runtimes with mocks are cheap but drift from reality, full copies of the stack are faithful but too expensive and slow to provision, and shared staging environments can't host hundreds of concurrent changes without agents overwriting each other's work.
The report identifies five requirements for verification when the callers are agents: changes must run against real dependencies, hundreds of concurrent changes must be unable to see each other, environment cost must scale with the size of the change rather than the system, environments must come up in seconds, and all of it must be reachable through the CLI or MCP server the agent already uses. The architecture that satisfies these requirements treats an environment as a view of a running system rather than a copy, with one shared set of stable services running continuously from the main branch while agents run only the services they modified and join them to the shared stack as isolated environments. Requests carry their environment identity across service boundaries, preventing one agent's traffic from reaching another agent's version under test. This pattern makes an environment cost one or two running services instead of sixty and ready in the time a single service takes to start, allowing agents to create and destroy environments inside their own loop.
For platform teams, the unit of work shifts from provisioning environments to running one shared stable stack and the virtualization layer that supports it—context propagation across every service, isolation for stateful dependencies, and tooling for environment creation and teardown. Environments stop being something the platform team hands out and become something agents create, use, and discard as needed. The report concludes that verification infrastructure is the foundation the entire loop stands on, and in distributed applications, that infrastructure must be a runtime environment giving every agent real dependencies while keeping hundreds of concurrent changes isolated at the cost of a change rather than a system copy. The real constraint on agent-driven development won't be how fast models can write code—it'll be whether infrastructure teams can provision verification environments at the speed and scale agents demand, turning what was once a provisioning workflow into a real-time orchestration problem that most platforms weren't designed to solve.