LIVE: Poteto (creator of pstack) on shipping 1,000's of PR's a month at SpaceX

Lauren Tan, known as Poteto, explains the large monthly pull-request count by describing connected workflows rather than thousands of manually initiated chats. External signals bring work in, coordinators organize related tasks and agents execute inside a prepared environment.

She explicitly says the count is not 2,500 features. Much of it is gardening: improving structure, removing recurring problems and making the environment better for everyone. The number is her report in the interview, not an independent audit of production impact or a target other teams should adopt.

Tan prefers a Michelin-kitchen metaphor because producing more should not mean abandoning craft. A solo cook does every step; a chef coordinating others must instead arrange tools, ingredients, preparation and timing.

The analogy points to environment design before multiplication. More people in an unprepared kitchen can create confusion, just as more agents can amplify a weak setup. The human remains associated with the final outcome. Delegating implementation changes the work of responsibility rather than making it disappear.

The speakers connect domain expertise to the ability to articulate goals and recognize bad work. A term such as test-driven development or a tautological test can compress a rich expectation into a short instruction, if its meaning fits the task.

That does not make a keyword a correctness guarantee. Tan’s starting problem was spending too much time micromanaging and correcting a single agent. The more useful question became which part of her expertise could become a repeatable process, a tool or a constraint so that the same correction would not be needed again.

Performance work exposed the limits of being a human proxy between an agent and browser tools. Tan wanted the agent to run the application, interact with it and collect traces or snapshots instead of relying on her to relay every observation.

That feedback enables a loop: try a change, observe the result and compare it with a rubric before trying again. It can support hill-climbing on a measurable objective, but the objective and observation still need to be meaningful. An agent claiming it verified something is not equivalent to the application having been exercised and the result checked.

Tan describes a small CLI around browser and debugging APIs. Its point is not novelty, but avoiding a pattern where every agent recreates a slightly different verification script and throws it away afterward.

A reusable tool can make mechanical steps consistent and faster, while a skill explains the workflow and when to use it. The same distinction can help migrations: a mechanical syntax transformation may belong in a codemod, while deciding whether the transformed program preserves behavior still requires evidence and judgment.

The discussion describes conventional feature directories, lint rules, type constraints and runtime checks as ways to narrow the paths available to an implementation. Tan’s internal framework example aims to make the expected place for a feature obvious and discourage giant catch-all files.

The feedback process matters more than the framework name. Observe a recurring workaround or mistake, then ask whether a rule, abstraction or tool can prevent that class of failure. Not every one-off needs another rule, and no finite set of constraints makes all bad code impossible. The aim is to reduce unnecessary choices and recurring errors.

Tan calls implementation toward an intent the inner loop. Bug reports, changing requirements and operational context arrive through outer systems such as team messages and issue trackers. Without a connection, a human has to carry every update inward and the original intent snapshot can go stale.

Her account connects those signals to coordinators that group related work and delegate bounded tasks. The agents should retrieve real evidence, reproduce a reported bug and determine whether it still exists, rather than guess. A separate agent for every incoming report can miss a shared cause and duplicate effort, which is why retaining the broader thread matters.

One routine in the interview scans for problematic code patterns but appends findings to a document instead of fixing each one immediately. Looking across that buffer every few days can reveal that many findings are variations of the same issue.

This is a deliberate alternative to reflexively spawning more work. The artifact creates room for a human or coordinator to identify the pattern, choose a broader repair and improve the environment. The relevant scale is useful grouped work, not the maximum number of simultaneous agents.

Tan does not describe reading every pull request before it lands. She describes rigorous sampling, multiple verification passes, browser interaction and later inspection of commit history, followed by correction or reversal where needed. She also acknowledges substantial token costs and the time required to build this setup.

The key qualification is that this trust was earned through a particular environment and repeated observation. Installing a skill library does not transfer that evidence to another codebase. Post-merge inspection is her reported operating choice, not a universal recommendation to remove blocking review from every kind of change.

The host raises one-way doors such as data loss and work in difficult-to-verify domains. Tan recognizes verifiability as a limit and says she does not have a complete answer. The discussion of proofs expresses a direction of interest rather than a demonstrated solution for every production risk.

A successful test, compilation or proof checks something under particular assumptions. It does not physically restore lost data or establish that all requirements, permissions and real-world consequences are correct. The interview’s trust-ladder idea therefore needs a boundary: scope and evidence must match the consequence, especially when undoing a change is not straightforward.

The closing advice is to inspect past work for moments where a person repeatedly intervened. Those corrections can reveal a missing rule, a useful reusable tool or a workflow worth encoding as a skill.

The speakers treat skill libraries as malleable process written in language. Combining them should serve an understood workflow, not loyalty to a brand or an assumption that more instructions are better. The durable practice is to understand and sharpen one’s tools, then keep checking whether they produce the intended result.