Lauren Tan's agent kitchen: how she scaled to 2,500 PRs

Lauren traces pstack back to a side project after leaving Meta's React team. In January or February, she found herself spending hours micromanaging one agent. She started writing skills and a brain directory to transfer parts of her own working method into the agent. She could iterate quickly, but she had little evidence that a skill improved the result.

She joined Cursor in March and soon worked on performance problems in its agent window. The early work was manual. She read flame graphs, inspected heap snapshots, and passed information between the agent and Chrome DevTools. Her own labor connected the model to the evidence it needed.

That bottleneck shaped the rest of her method. A capable model still reaches for shortcuts. The useful intervention is to redesign the process so that the quick path also produces the desired result.

Lauren argues that domain expertise gains value when the model can carry out more of the implementation. The limiting step moves toward the human's ability to define the goal, recognize a good result, and explain the constraints. A doctor, lawyer, or engineer with enough technical fluency can use an agent to build around knowledge the model does not own.

Matt connects this to language. A term such as test-driven development changes which evidence the agent seeks. His grilling method asks questions until hidden requirements become explicit. Lauren adds tautological tests as an example of a precise label. Such a test restates the implementation and can pass without increasing confidence in behavior.

Vocabulary compresses a working concept into a phrase the agent can reuse. That compression helps communication, but it does not prove the agent understood the requirement or implemented it correctly. Verification still has to supply that evidence.

Lauren accepts that software factory describes high-volume production, but she prefers a Michelin kitchen. A factory can suggest interchangeable work and indifferent quality. A serious kitchen still produces at scale, yet its organization exists to protect craft, user experience, and the finished dish.

A solo cook prepares ingredients, cooks, and cleans. Adding more people without stations, tools, or shared methods creates congestion. The chef's work changes as the kitchen grows. She chooses ingredients, prepares stations, defines methods, and owns the result even when other people do most of the cooking.

Lauren maps that role to engineering. The codebase, tools, skills, and verification system become the kitchen. Agents do more implementation, while the engineer designs the conditions in which implementation happens. The engineer's name and reputation still attach to the outcome.

Lauren's first high-value skill at Cursor let the agent operate the application and observe the result. For interface work, that can mean running the app, interacting with it as a user, inspecting traces, reading browser state, and taking snapshots. Without those abilities, the agent has to ask a person what happened.

Planning and explanation skills can improve the proposed change, but they do not close the feedback loop. The agent must compare observed behavior with an explicit goal and revise. Lauren calls this foundation more important than any particular pstack command.

She connects the loop to hill climbing. If a performance goal has a reliable score or rubric, the agent can try a change, measure it, and keep improvements. She relates the idea to Andrej Karpathy's autoresearch. The interview gives no measured performance result, so this is a method, not a benchmark claim.

Lauren reports that each application in her organization has a shared, automatically maintained verification skill. A custom command-line tool handles browser interaction through Playwright and the Chrome DevTools Protocol. She is careful about its novelty. It is glue around existing APIs, not a new verification engine.

Concern in the agent community that compaction weakened results first motivated the tool, because a small command preserved context space. The longer-lasting benefit is consistency. Without the tool, every agent rebuilt a browser driver, debugged it, and discarded it. The next agent repeated the same work with a different result.

Her general rule is to separate judgment from mechanics. An agent can decide what evidence matters or how to respond to a failure. A script should handle steps whose correct execution is known in advance. She extends the same idea to migrations, where codemods and abstract syntax tree transforms can perform mechanical changes before an agent handles ambiguous cases.

A low-trust setup traps the engineer in supervision. Each agent needs correction, so deadlines consume all available attention. The team then has no time to build better tools, which keeps trust low. Lauren compares the cycle to working with a dull knife because sharpening feels too slow during dinner service.

Her remedy is an explicit investment in the environment. That includes fast tests, useful types, focused modules, lint rules, stable tool interfaces, and application-level verification. The interview does not prescribe a percentage of engineering time or a fixed setup period. The work depends on observed failure modes.

A good environment helps human engineers too. It reduces the number of local conventions someone must remember and makes a safe change easier to recognize. Agent readiness and maintainability point in the same direction here.

Lauren uses TypeScript narrowing as the conceptual model. A broad string type permits many invalid states. Runtime checks and type guards can narrow it to a specific valid form. She applies the same move to repository design by reducing the number of places and patterns an agent can choose.

Dune is her internal framework for Electron applications. She describes it as similar to Next.js in the way it supplies conventions. It is not open source. Features live in dedicated directories, a registry discovers them, and restrictive lint rules reject patterns the team has decided against.

The framework grew from concrete failure. Lauren says early Grok Bot versions accumulated about eight huge files, each at least 10,000 lines. Feature directories prevent the easy move of appending more code to a central file. Every recurring mistake becomes a design question: can a type, directory convention, linter, or API make that mistake impossible?

Once the implementation environment works, the next human bottleneck is context transfer. Lauren calls engineering agents working against a captured goal the inner loop. That goal is only a snapshot. New bug reports, product decisions, infrastructure limits, and user feedback arrive elsewhere and can make the snapshot stale.

The outer loop is the set of systems where that information appears. She names Slack, Linear, X, and email. Grok Bot routines can subscribe to relevant sources and pass reports into an engineering project. The key value is not the number of connectors. It is removing the person who repeatedly copies information between systems.

A report still needs investigation. The engineering agent should reproduce the problem on the current main branch and distinguish a product bug from account data, local setup, or a missing dependency. Context ingestion should supply real evidence, not permission to guess.

Lauren is not manually opening 2,500 conversations. She describes Cursor Projects as persistent coordinators. A coordinator supervises a task list, creates worker agents, carries context between them, and tracks the work. Its main job is management rather than implementation.

She worked backward from a concrete target: what conditions would let an agent merge its own code? That question forces attention onto verification, repository constraints, context freshness, and failure recovery. The PR count is an effect of those systems, not the first control to turn.

Lauren's concrete setup combines Grok Bot routines with Cursor Projects. Grok Bot watches selected external sources and sends relevant work to a project. The project runs in the cloud with a coordinator and its own computer. The coordinator can choose worker arrangements, delegate tasks, and pass findings between them.

She connects the design to a management lesson from Netflix: give context that enables self-sufficiency. A burst of 30 reports is Matt's hypothetical example, not Lauren's measured workload. The useful point is that a coordinator can group related reports before assigning work.

If several users report similar performance failures, one worker per report may duplicate the same investigation or produce competing fixes. A coordinator can compare the reports, identify the common layer, and send workers after distinct parts of one root problem.

Lauren explicitly corrects an easy misreading of the headline. The monthly total is not 2,500 features. Much of the work is codebase gardening: small maintenance changes, cleanup, refactoring, and improvements to the environment.

That work benefits every engineer. A new hire inherits clearer structure and better defaults. Existing engineers spend less time navigating old shortcuts. Agents also encounter fewer ambiguous choices. The same PR can therefore raise future throughput without adding visible product behavior.

PR count remains a volume measure. It does not reveal size, risk, user value, defect rate, or review quality. Lauren's interview explains the operating system behind the count, but it does not supply an independent outcome audit.

One recurring agent scans React code for problematic patterns. It does not open a fix for every finding. It appends observations to a document. Every few days, Lauren reviews the accumulated items and asks whether they are instances of the same underlying problem.

The delay is deliberate. Immediate execution optimizes each item in isolation. A buffer creates material for comparison and gives a human or coordinator time to choose one systemic change, such as a lint rule, shared abstraction, codemod, or repository constraint.

Lauren does not claim to read every PR. She samples code and pull requests, reportedly every day, and inspects them closely. The object of review is both the change and the system that produced it.

A one-off error may need a local correction. Several agents taking the same shortcut point to an environmental defect. She then changes a skill, lint rule, type, constraint, or shared abstraction so the next worker does not repeat it.

This resembles statistical quality control, but the interview gives no sampling rate or defect threshold. The practical requirement is enough scrutiny to notice recurring failure. Lauren also warns that reaching this state takes substantial effort. Installing pstack does not transfer her trust or her codebase conditions to another team.

Lauren says her agents run around the clock and that she has more than ten coordinator agents. They cover areas such as desktop performance, user-reported bugs, and an exploratory native rewrite that she calls a toy. These are separate work areas with separate management context.

Full autopilot can start several verifier agents for one PR. They run the application, interact with it, look for regressions, report problems, and trigger another repair cycle. Lauren loosely calls this fuzzing. In this context, it includes exploratory application interaction, so readers should not assume it means only a formal coverage-guided fuzzer.

The process consumes many tokens and can be tuned. Lauren gives ten verifiers, one verifier, or self-verification as examples. Some PRs merge before her review. In the morning she samples commit history and can modify, revert, or add rules after seeing a problem.

This is post-merge human review backed by pre-merge machine checks. Lauren grounds her confidence in the constrained codebase and verification system she described earlier.

Lauren says the answer depends on the quality of available verification. She regards much software work as verifiable and gives mathematical proofs as another example, while acknowledging that neither field is entirely verifiable. Other domains are much harder to evaluate programmatically. She says she does not have a universal answer.

She suggests that better formal methods and agent-oriented languages may expand what can be checked. She mentions Bend, Lean, and TLA+ while discussing code and proofs. Her direction is toward stronger machine-checkable evidence, not a claim that current tools make all changes safe.

Explainer clarification. Verification and reversibility are distinct. A test may lower the probability of a harmful change, but it does not restore deleted data or reverse an external action. A proof establishes the properties encoded in the proof under its assumptions. It does not cover a requirement that nobody wrote down.

Matt asks how people should combine his skills with pstack. Lauren rejects the idea that the libraries compete as complete systems. A skill is a process written down. Users can combine Matt's questioning or Wayfinder work with pstack execution, or take only the pieces that fit their environment.

Trust here means understanding the tool well enough to predict its behavior and correct it. A chef carries familiar knives between jobs. In the same way, an engineer should adapt a personal set of prompts, scripts, rules, and verification methods rather than copy a library unchanged.

Past agent chats are evidence for that library. Repeated corrections reveal missing instructions. Repeated workarounds may belong in a lint rule or tool. A good skill begins with a real intervention that the person no longer wants to repeat manually.

Lauren's recall skill came from debugging virtualization in Cursor. Each new chat needed context from earlier attempts, and manually explaining where to look became repetitive. Recall compresses that instruction into a reusable workflow that finds and carries forward relevant history.

She expects stronger models to need fewer low-level command recipes and more concise process descriptions. That does not cancel her earlier argument for deterministic tools. Commands still belong in scripts when exact execution matters. The skill can become shorter because it points to stable tools and states the decision process around them.

The conversation ends with a permissive model of skill design. Combine Wayfinder and poteto-mode, rewrite them, or extract a smaller method. The durable asset is the tested process behind the words.