SpaceX AI Engineer: How to Stop Being a “Human Go-Between” for AI and Merge 2,500 High-Quality PRs in a Single Month?

Tech educator Matt Pocock sat down for an in-depth conversation with Lauren Tan (in Chinese)—known online as Poteto, creator of the open-source project pstack, and now working at SpaceX AI/Cursor.

Lauren shared that she is currently contributing to the engineering work on the Grok Bot AI Agent application, merging 2,500 pull requests (PRs) last month. (A PR is a proposed set of code changes submitted to a repository for review and merging.) The core of their discussion centered on how to stop being a "human go-between" for AI, using AI Agents and toolchains to move code work from merely generating code to autonomous verification and merging, reaching the delivery scale she described.

Throughout the interview, the workflow Lauren describes rarely touches on how to prompt faster. Instead, she spends the bulk of her time on something else: identifying why an AI Agent still requires human intervention, and then enabling the system to take over that work.

pstack is a skill plugin that organizes her development methodology into skills and workflows accessible to AI Agents. The number of PRs she cited includes numerous code maintenance changes and should not be equated with thousands of new features. What makes this number noteworthy is that continuous delivery no longer requires her to personally initiate, guide, and inspect every single task.

This hits directly on the dilemma facing many AI developers. While code generation has accelerated, an engineer's day remains consumed by "taking a quick look," "filling in some background," and "reminding it about conventions once again." The AI Agent can execute tasks for you, yet the entire workflow continues to revolve around your personal attention. The moment you spin up more tasks, the queue of questions waiting for your answer only multiplies.

Breaking out of this bottleneck requires shifting where engineering knowledge resides. The inspection methods, design conventions, and project background that previously lived only in your head must gradually migrate into tools, codebases, and information channels. Only then can AI Agents access them on demand, without pausing every time to wait for you.

Identifying Missing System Capabilities from Points of Human Intervention

Lauren’s earliest experiments did not happen within a large team. After leaving Meta, she took a break and began hacking on personal projects. While coding with AI, she found herself spending extensive time micromanaging individual AI Agents, which prompted her to start documenting her working methods as skills. Her goal was to make the AI Agent approach problems the way she did, rather than simply generating a snippet of working code.

Here lies an easily overlooked detail: at the time, she also found it difficult to measure how much improvement these skills actually brought. Writing workflow documentation is one thing; proving that an AI Agent can truly accomplish work independently is quite another.

Later, after joining Cursor, she worked on performance optimization for the Agent pane. Diagnosing why an interface stuttered required inspecting performance flame graphs to understand which operations consumed the most time, as well as examining heap snapshots to identify abnormal memory usage before tracing code issues. Initially, these observations were performed mostly by her: she inspected the tools, relayed her findings to the AI Agent, the AI Agent modified the code, and she went back to inspect the results.

In this chain, the truly scarce capability was not typing code, but obtaining and interpreting results. As long as this step constantly required a human, the AI Agent's next move remained dependent on a human.

Therefore, "Where does it need my help again?" becomes a concrete engineering question. It might mean the AI Agent lacks tools to observe runtime results; it might mean it is unaware of the latest requirements, or that the codebase fails to communicate clearly which practices are unacceptable. Discerning which capability is missing determines what needs to be built. Merely adding another sentence to a prompt often just postpones the same problem to the next iteration.

Only When Results Are Observable Can an AI Agent Move from Execution to Improvement

Performance optimization offers a clear example. When you ask an AI Agent to fix UI stuttering, after it finishes the edits, it must be able to rerun the application, reproduce the relevant interactions, and capture fresh performance metrics. Otherwise, it can only judge whether the code looks like an optimization, without any way to verify whether user experience actually improved.

The verification capabilities Lauren prioritizes are all about closing this feedback loop. Through tools like Playwright and the Chrome DevTools Protocol, an AI Agent can run the application, interact with the UI, capture traces and heap snapshots, and use those results to guide its next step. The "eyes and hands" she emphasizes refer to programmatic access to actual runtime state.

Only with repeatable checks does a task become a continuous process of improvement: modify, execute, compare results, and retain or refine the approach. She uses "hill climbing" to describe this approach—there must be criteria to measure progress so the AI Agent knows whether it is getting closer to the goal. The value of a loop stems from feedback, not from merely cycling through extra iterations.

Yet "letting the AI Agent self-verify" introduces a new form of waste. Lauren discovered that without standardized tooling, AI Agents frequently rewrite inspection scripts from scratch each time. A problem already solved by an earlier Agent ends up reimplemented by the next; occasionally, before any real work even begins, time is squandered on debugging the diagnostic tooling itself.

To eliminate this, she packaged recurring operations into CLI tools: launching environments, communicating with the browser, and collecting diagnostic data now reuse a unified implementation. Batch transformations of well-defined code patterns can likewise be delegated to deterministic scripts. The AI Agent, meanwhile, focuses on selecting approaches, interpreting findings, and deciding where to investigate next.

This represents a pragmatic division of labor. Steps that can be unambiguously expressed as code are centrally maintained and reused repeatedly; judgment that requires contextual understanding is left to the model. Skill documents outline how work should proceed, sparing every task from reinventing the wheel.

Nor does this capability serve only her. Lauren noted that her team has established automatically maintained verification skills across various applications for shared use. Once one person wires up an application's inspection harness, everyone else's AI Agents can inherit it without having to reinvent the wheel. Verification thus evolves into team infrastructure: it demands continuous upkeep alongside the application, but pays recurring dividends across different tasks.

The inspection methods themselves still demand engineering judgment. The two discussed how AI Agents tend to write "tautological tests": tests that appear to verify functionality on the surface, but in reality merely mirror the implementation logic, offering no meaningful validation. Offloading test execution to an AI Agent does not eliminate the human need to judge what defects a test can genuinely uncover. Rigorous acceptance criteria are what truly constitute a reusable capability.

The Codebase Should Enforce Experience at the Exact Moment Errors Occur

Observing runtime results addresses whether a change is effective; codebase constraints address which patterns should never enter the codebase in the first place. The two complement each other.

Lauren mentioned that early iterations of Grok Bot consisted of roughly eight massive files, each exceeding ten thousand lines. In an architecture like that, when an AI Agent appends new features, the path of least resistance is usually to shove another block of logic into the same file. A human can repeatedly prompt it to modularize, but in the absence of explicit conventions for directories and entry points, every addition forces a structural architectural choice anew.

The internal desktop application framework she introduced, Dune, provides a much clearer path for organizing features: each feature lives in its own directory, integrates via standardized registration and discovery mechanisms, and is bounded by linting and static analysis rules that restrict anti-patterns. Where to implement a new feature and how to wire it up are already embedded directly within the development environment.

This aligns with the concept of type narrowing she knows well: reducing possible paths to make permissible approaches explicit. The goal is not to hardcode every judgment call, but to avoid relitigating settled engineering consensus on every turn.

Prompts can describe standards, but lint rules return concrete errors the instant a standard is violated. When an unacceptable modification is blocked, the AI Agent can correct it within the active task. Human experience is thus transformed from "something someone must remember and remind others of" into "a condition that work encounters as it proceeds."

Such an environment benefits human colleagues as well. Lauren specifically highlighted newly onboarded engineers: explicit conventions lower the friction of assimilating team idioms. The team’s development practices naturally become clearer and far easier to follow.

The Challenge with Multiple AI Agents: How to Share a Unified Working Picture

Once an individual AI Agent can execute, observe, and self-correct, one category of burden still reliably falls back on humans: feeding it fresh context.

The requirements provided when a task begins are merely a snapshot in time. Users keep reporting bugs, teammates add constraints, and priorities shift. If that information remains trapped in Slack, Linear, email, or X, an AI Agent can work tirelessly toward an objective that is already obsolete. The human once again becomes a glorified messenger shuffling updates across tools.

The outer loop and inner loop Lauren describes are designed precisely to bridge these two sides. The outer loop pulls continuously evolving context from external tools; AI Agents in the inner loop leverage that context to drive code forward. She utilizes connectors in Grok Bot to aggregate relevant updates and funnel them into Cursor Projects. The crux is ensuring the AI Agent accesses actual information rather than guessing in a vacuum.

In the example she gave, an AI Agent subscribes to a Slack channel and, upon receiving a bug report, investigates and reproduces it first. The verification skills built earlier prove essential here: checking whether the issue persists on the latest main branch while accounting for user environment differences, state, or missing dependencies. Receiving a message is merely the starting line; diagnosing the problem and determining whether code changes are warranted must precede any action. Only by linking information channels with verification tools can we alleviate the dual burden of both relaying feedback and interpreting it on the AI Agent's behalf.

Once information arrives, dispatching work cannot be a mechanical matter of "one report, one AI Agent." She and Matt discussed scenarios involving clusters of related performance complaints: minor variations across reports can actually illuminate a shared root cause. If dispatched in isolation, each AI Agent risks patching only immediate symptoms or duplicating effort on identical fixes.

This is where the coordinator comes in. It orchestrates tasks, passes context, and delegates execution, allowing related issues to be understood in aggregate. Lauren connected this to her prior experience managing teams at Netflix: providing high context so executors can exercise judgment reduces step-by-step micromanagement. For an AI Agent, this means not only specifying the goal, but also ensuring it can surface the information necessary to make informed decisions. Parallel execution is only valuable when the dependencies and relationships between tasks are clear; multiplying the number of tasks does not automatically multiply meaningful output.

Code sweeping illustrates this principle even further. Lauren runs a background AI Agent continuously hunting for React anti-patterns, but instead of altering files immediately, it logs findings to a document. Reviewing these accumulated insights every few days enables her to spot recurring systematic issues. Fixing an overarching rule or architectural design all at once is often far more impactful than patching issues piecemeal.

This introduces a crucial pause into high-velocity execution: record findings first, then observe patterns. Both coordinators and sweep logs help the system perceive structural relationships beyond isolated tasks, preventing teams from mistaking frantic activity for genuine resolution.

Putting these pieces together makes the infrastructure work people need to do much clearer to identify:

These capabilities do not need to be erected overnight. The purpose of this breakdown is to pinpoint exactly where your attention is bottlenecked. Lauren uses the analogy of "building a proper kitchen before opening more restaurants" to illustrate scaling prerequisites: ensure that tooling, standards, and verification within a single project are robust enough to shoulder the workload before extending those capabilities to more projects. Simply opening more AI Agent windows is no substitute for building this foundation.

Humans Can Step Back from Direct Execution, but Remain Accountable for the Entire System

Lauren explained that she reverse-engineered her setup from a single question: "How can an AI Agent merge code autonomously?" If she ultimately still has to review each change herself, delivery velocity remains limited by how much code she can personally inspect. The verification tools, architectural constraints, and context pipelines outlined above all exist to prevent work from pausing at every juncture to wait on her.

As this environment matured, Lauren described letting AI Agents work autonomously overnight and merge code (in Chinese), allowing her to simply review the commit logs the following morning. She is also explicit that reaching this state demanded immense time and effort; it is not something effortlessly unlocked merely by installing pstack.

Her fully autonomous mode spins up dedicated verification AI Agents to run the application, simulate user interactions, surface regressions and implementation defects, and then loop through remediation and re-testing. Such verification burns substantial tokens, and the number of verification Agents can be adjusted. Relieving humans of manual inspection comes at the price of tooling maintenance and compute overhead.

Meanwhile, she continues to perform spot checks on the code. The point of spot-checking is not merely catching an isolated defect, but diagnosing whether the system is systematically producing recurring anti-patterns. Isolated bugs can be patched locally; when multiple AI Agents converge on the same flawed shortcut, it means going back to examine skills, type constraints, lint rules, or developer tooling.

This expands the human responsibility from handling every immediate step to refining the environment through which all future tasks flow. A human judgment that stays trapped in a chat thread may have to be repeated next time; encoded into appropriate tooling or rules, later work can continue to benefit.

Yet delegation demands sober risk assessment. Matt pressed her on the distinction between easily reversible "two-way door" decisions and potentially destructive, data-losing "one-way door" decisions. Lauren anchored her answer on verifiability: the easier a task is to evaluate programmatically, the easier it is to establish confidence in autonomous delivery; for domains resistant to verification, she did not offer a general answer.

Verifiability and reversibility must be evaluated separately. A passing test suite proves that verified assertions were satisfied; it will not recover lost data. How much autonomous authority a team can grant depends both on the thoroughness of verification and on what happens if the judgment is wrong. The conversation later touched on formal proof and Agent-oriented programming languages—explorations that reflect an aspiration for stronger verification down the road, rather than a guarantee that every current PR is mathematically proven.

This is where the "Michelin-starred kitchen" metaphor proves truly apt. The head chef might not personally cook every single dish on the line, but still organizes the brigade, preps the tools, establishes quality standards, and judges whether what is served meets those standards. Stepping back from hands-on execution does not diminish accountability for the final output.

Domain expertise therefore has more places to contribute. Knowing what users actually want, which implementations are worth retaining, and which tests are meaningless all demand seasoned experience. The more adept models become at implementation, the more critical it is for humans to articulate these judgments clearly and embed them into a working environment the model can use.

Near the start of the interview, Lauren framed the core bottleneck as "the transmission of intent"—whether the product in your mind can be faithfully communicated. Matt brought up test-driven development (TDD) as an example: writing expected behavior as tests before implementing the solution. Introducing this methodology nudges the AI Agent to prioritize tests and behavioral specifications, reshaping how it sequences its work. Professional experience lies in knowing what to emphasize, what to rule out, and recognizing when an AI Agent has drifted off course. If ideas remain unformed, the two also suggested prompting the AI Agent to ask probing follow-up questions to help clarify thinking. Crisp objectives can coalesce through dialogue, but verifying "this is what I want" still requires human discernment.

Wrapping up, they recommended reviewing historical conversations with AI Agents. Those transcripts filled with repeated corrections, added context, and re-explained steps reveal how work actually unfolds in practice. Lauren's recall skill emerged from a concrete friction point: while troubleshooting virtualization issues in Cursor, new chat threads needed to inherit context from previous sessions. Codifying that pattern into a skill reduced the burden of rewriting lengthy explanations every time.

This accumulation is highly personal. In her post sharing the interview, Lauren recommended pairing her skill plugins with Matt's, cherry-picking what fits one's own workflow. The tools that truly matter are the ones tailored to shoulder your specific engineering intuition. Lauren also observed that as models grow more capable, skills can increasingly focus on high-level workflows while shedding verbose implementation minutiae. What a skill needs to preserve is how work progresses, when to perform verification, and what criteria govern the next decision; details the model can handle natively no longer require pages of instructions. For anyone looking to reshape their workflow, a great starting point is the very last time you had to interrupt an AI Agent: can that manual intervention become a capability it acquires for itself next time?

Sources: Full interview between Matt Pocock and Lauren Tan, Lauren's original post sharing the interview.