Building a Lights-Out Factory with a Dozen Agents: Lauren Tan's Trust Ladder and the Michelin Kitchen

From "Meat Proxy" to "Lights-Out Factory"

If you're still micromanaging your AI coding agents one by one, you may be missing the bigger picture. Lauren Tan—former Meta React team member and current engineer at Cursor (now renamed SpaceX AI)—recently shared her practice of using a dozen coordinated agents to merge over 2,500 PRs per month into production. Behind this number is not a frenzy of stacking agents, but an engineering philosophy about the "trust ladder" and the "kitchen environment."

In the interview, she admitted that she initially fell into the trap of personally overseeing every agent: "I spent way too much time just micromanaging one agent." The turning point came when she realized the real bottleneck wasn't model capability, but humans acting as "meat proxies" passing context between agents and tools. To break this bottleneck, she had to redesign the environment the agents live in, rather than trying to directly re-engineer the agents themselves.

The Trust Ladder: From Solo Work to Parallel Management

Lauren describes the agent adoption process as climbing a "trust ladder." At the lower rungs, humans must constantly intervene and verify each output step, with very low trust; as the environment and verification tools mature, agents can take on greater responsibility and humans gradually step back.

She emphasizes that this ladder cannot be skipped. Without reliable verification, there can be no real trust, and you'll ultimately fall back to the "lock down and micromanage" mode. Therefore, she spent a lot of time building an open-source skill system called PStack, the most critical piece of which is the verification skill.

"Even if you don't use PStack or my skills, I think the most important skill in your toolbox should be verification."

The essence of the verification skill is to give agents "hands and eyes," enabling them to run code, interact, capture trace information, and debug on their own like a real user. Without this layer, agents cannot truly close the loop and iterate, and humans must forever act as intermediaries.

Environment Is Everything: Why a Michelin Kitchen Is More Apt Than a Software Factory

Lauren doesn't like the term "software factory" because it easily evokes low quality and mechanical replication. She prefers the "Michelin kitchen" metaphor for the ideal agent work environment—equally focused on efficiency, but with greater emphasis on craft and quality.

In this metaphor, the human engineer is the head chef and the agents are sous-chefs. The head chef no longer personally minces every clove of garlic, but must be responsible for the kitchen layout, sourcing and storing ingredients, and final quality control. Mapped to engineering practice:

• Skills are recipes and standard operating procedures
• CLIs and deterministic scripts are specialized kitchen tools, like a garlic press
• Lint rules and type systems are the kitchen's physical constraints that make erroneous operations hard to perform
• Verification loops are the tasting and quality-control steps

She specifically points out that many teams mistakenly believe agent capabilities are entirely determined by the model vendor and that humans cannot intervene. In reality, environment elements like codebase structure, constraint rules, and verification tools are fully within engineers' control and have a huge impact on agent performance.

Verification: The Most Important Skill

In Lauren's practice, verification is the key that makes the trust ladder actually work. When she was optimizing performance for Cursor's agent window, the first truly effective skill was enabling the agent to run performance profiling itself, capture stack snapshots, and determine whether improvements were effective.

She draws on the idea of "hill climbing": given a scoring criterion or evaluation rule, an agent can keep trying improvements in a loop, because the verification step lets it autonomously judge whether each change is moving in the right direction. This freed her from micromanaging performance tuning.

To make verification easier, she also extracted deterministic parts into custom CLIs. For example, the "glue code" interacting with Playwright and the Chrome DevTools Protocol was encapsulated into scripts, so agents don't have to reinvent the wheel every time. She observed that without CLIs, each agent would rebuild its own verification scripts, causing massive duplication and speed loss.

"I try to extract the deterministic parts into code and leave only the parts that truly require judgment to the agent."

This principle also applies to code migration scenarios—using AST crawling and code mod scripts for mechanical transformations, rather than having the agent rewrite from "feel" each time.

Hill climbing is a local search strategy in optimization algorithms: starting from an initial solution, iteratively trying neighboring solutions, accepting a new solution if the objective function value improves, otherwise keeping the current solution, until no better solution can be found. In the context of AI agents, hill climbing is a metaphor for an agent continually attempting improvements within a verification loop, judging whether each change is effective based on scoring criteria (such as performance metrics or test pass rates), thereby autonomously moving toward the goal. Lauren Tan uses this idea to let agents autonomously iterate on tasks like performance optimization, while humans only need to define clear evaluation rules. This requires the verification step to provide immediate, reliable feedback signals; otherwise, the hill-climbing process may lose direction or get stuck in local optima.

Connecting Inner and Outer Loops: Letting Agents Find Their Own Work

The 2,500 PRs per month don't come from 2,500 manual conversations. Lauren splits the work into two loops:

• Inner loop: engineers and agents collaborate in the codebase, advancing tasks around clear intent
• Outer loop: bug reports, feature requests, and discussions in external systems like Slack, X, email, and Linear

In the past, she was the "human ferry" between the two loops, constantly ferrying external context to agents. Now, she uses tools like GrokBot to subscribe to Slack channels, X mentions, or Linear issues, and feeds information directly into Cursor's Projects coordinator agent via MCP or custom connectors.

Cursor's Projects feature provides a "coordinator agent" that doesn't do the work itself but, like an executive chef or chief of staff, assigns tasks and supervises sub-agents. When a flood of bug reports suddenly arrives, the coordinator agent can determine the best topology and efficiently distribute tasks to a team of sub-agents. Lauren currently has more than 10 such "chiefs of staff," each responsible for a different domain—performance, user bug fixes, even exploring rewriting the app in different languages.

Automated Review and the Boundaries of "Lights-Out"

Faced with the question "How do you review 2,500 PRs?", Lauren's answer is: sampling, not full blocking.

At a fixed time each day, she spot-checks merged PRs, rigorously scrutinizing code quality and looking for error patterns agents repeatedly make. If a problem appears only once, it can be let go; but if multiple agents repeatedly take the same shortcuts or propagate the same temporary workarounds, that signals the environment needs fixing—adjust lint rules, type constraints, or skills, rather than blaming an individual agent.

Her agents are set to fully autonomous mode: each PR triggers a strict verification loop, spawning multiple verification agents to perform fuzzing—actually running the app, simulating human clicks, finding regressions and bugs, then fixing them and repeating until the PR reaches a mergeable state. This process consumes a lot of tokens, but the number of verification agents can be adjusted.

"I wake up in the morning and review by looking at the commit history. If I find a problem, I correct it, roll back, and add a new lint rule."

She admits that on the first day of enabling this "lights-out" mode, she was very scared, worried about causing a production incident. But the dual safeguards of environment and verification ultimately let her sleep soundly.

Not Every Domain Can Go Lights-Out

Lauren carefully points out that this approach is highly dependent on the verifiability of the work. Many tasks in software engineering can be programmatically verified, so one-way doors can become two-way doors—rollback is possible after merging. But for domains where verification is difficult, such as healthcare, law, and finance, fully autonomous PR merging is not realistic.

She places her hope in programming languages more oriented toward agents, such as Bend, which combines programming with mathematical proofs. If proofs can show that code is correct in all cases, then merging no longer requires humans to review line by line. But that day has not fully arrived.

One-way door vs. two-way door is a classic metaphor in product and engineering decisions, popularized by companies like Amazon. One-way door decisions are irreversible or extremely costly to reverse (such as data model refactoring or public API changes) and require caution and slowness; two-way door decisions can be quickly rolled back (such as feature flags or UI adjustments) and are suitable for rapid experimentation. In the scenario of AI agents automatically merging PRs, Lauren Tan points out that due to the verifiability of software engineering, many operations that were originally one-way doors (such as merging code) become two-way doors through robust verification loops and rollback mechanisms—if a problem is found after merging, it can be immediately reverted. This shift is the prerequisite for the "lights-out factory" model and the fundamental reason it is limited to highly verifiable domains.

Skills Are Language: Everyone Should Have Their Own Knife

At the end of the interview, Lauren and host Gary reached a consensus: skills are essentially the verbalization of processes, Markdown files, with no magic whatsoever. The real value lies in the thinking required to distill abstract processes into clear text.

She encourages developers not to merely copy others' skill libraries, but to look back at their own conversation history, identify where they repeatedly correct agents, and turn those into reusable skills or lint rules. Her own recall skill in PStack originated this way: each time she starts a new conversation, she wants to compress and carry over valuable context from the previous conversation, so she solidified this workflow into a skill.

"Every chef brings their own knife when they start at a new restaurant. Tools follow the person. Trust is essentially trust in your own tools."

As model capabilities improve, skill files can become smaller and more focused on the workflow itself, leaving implementation details to the model's judgment. Lauren predicts that future skills will become increasingly compact, and PStack can be freely mixed and matched with other skill libraries—the key is whether you're willing to spend time sharpening your own knife.

MCP (Model Context Protocol) is an open protocol launched by Anthropic in late 2024, aimed at standardizing how AI assistants connect to external data sources and tools. It defines a client-server architecture: MCP servers expose resources (such as files and databases), tools (executable functions), and prompt templates, while AI applications (clients) invoke these capabilities through a unified interface. In the context of this article, MCP serves as a bridge connecting external systems (Slack, Linear, etc.) with Cursor's coordinator agents, enabling agents to directly subscribe to events, obtain context, and trigger actions without engineers manually ferrying information. This greatly simplifies integration and allows agents to autonomously perceive changes in the outer loop, making it key infrastructure for "agents finding their own work."

One-line Summary

Cursor engineer Lauren Tan built verification skills and a kitchen-style environment to achieve 2,500+ automated PR merges per month, revealing the agent trust ladder and the boundaries of verifiability.

Paragraph Summary

Lauren Tan escaped the trap of micromanaging individual agents and proposed an engineering philosophy of the "trust ladder" and the "Michelin kitchen": humans as head chefs handle environment design, verification tools, and quality control, while agents as sous-chefs execute tasks. She emphasizes that verification is the most important skill, giving agents "hands and eyes" to autonomously close the loop and iterate; by extracting deterministic CLIs and writing lint rules and type constraints, errors become hard to make. Using GrokBot and MCP to connect inner and outer loops, coordinator agents automatically distribute tasks, enabling over 2,500 PR merges per month. She adopts sampling reviews, fuzzing, and fully autonomous mode, but notes that the approach relies on domain verifiability; one-way door operations and domains with difficult verification, such as healthcare and law, still require human oversight. Ultimately, she encourages developers to distill personalized skills from their conversation history and sharpen their own knives.