How a 24/7 agent team takes shape: SpaceXAI engineer Lauren Tan builds engineering judgment into the system

20 PRs auto-merged overnight, after 600+ refactoring PRs

Lauren's main section starts around the six-minute mark. She inherited a GrokBot codebase that was in production but carried the typical risks of a greenfield project: the prototype was built quickly, yet without stable guardrails.

Lauren says she rarely reviews code herself now. One morning she woke up to roughly 20 PRs that agents had merged automatically; in the previous month she submitted about 1,000 PRs, and by day 12 of the current month she was already approaching 800.

These figures come from her own statements during the talk; the public video doesn't include an independently auditable repo or PR list. They indicate delivery scale, but they don't directly prove code value, defect rates, or general productivity.

She also explains why she actively asks agents to split up tasks: a single PR might be a few dozen lines, or it could be hundreds or thousands, with no fixed cap. Her focus is on making each commit as atomic as possible, describing one small change, so that Git history remains a tool for understanding context, rolling back changes, and locating defects—not on maximizing PR count. Even if a forty-thousand-line PR merges successfully, it's nearly impossible to figure out where the problem actually starts.

The relationship between four numbers is what's worth looking at first.

The 20 auto-merged PRs are the output side; the 600+ refactoring PRs are the infrastructure side. In between is a redesigned codebase, and smarter prompts alone can't close that gap.

GrokBot started as a quickly generated greenfield app. It was fast to build, but the architecture naturally evolved into whatever was most convenient for the agent at any given moment. Each task could be completed locally, yet over time, directories, dependencies, processes, and state management started to tangle. The agent might still be able to make changes, but it became increasingly hard for humans to understand and trust the system.

Lauren's choice was to rebuild the working environment for agents. She calls this Electron architecture Dune. The goal is to reduce the number of decisions an agent makes each time, letting the structure embody abstract principles.

Make the right path the shortest path: how Dune constrains agents

Dune makes a strong design judgment: agents like shortcuts, so make the shortest path the correct one.

This is more concrete than "write a more detailed coding standard for AI." A coding standard requires the agent to remember, understand, and obey every time; an architectural constraint directly changes the options it can see.

Shrinking the error spaceTurning 'please remember the conventions' into a path agents can't easily bypass

1. Feature colocationKeep a feature's state, components, and logic in the same area
2. Process boundariesClear separation between main and renderer processes so heavy tasks don't crowd the UI
3. Dependency graph checksCI mechanically blocks cross-layer and cross-process imports
4. Dangerous patterns disabledLint or compile gates target patterns agents repeatedly misuse

The first layer is feature colocation. Most of a feature's code lives in the same directory, so an agent doesn't have to search across multiple shared directories for state, components, or business logic. It only needs to recognize "I'm working on the onboarding flow" to keep most of its work within that feature's directory.

The second layer is process boundaries. The Electron main process and renderer process handle different jobs. If compute or I/O ends up on the renderer side, it competes with UI drawing for time. At 60 FPS, each frame has only about 16 milliseconds, and heavy tasks crossing that line can easily cause jank. Dune uses explicit directory structure and import graph checks to prevent this kind of dependency crossing.

The third layer is banning known-dangerous patterns outright. Lauren gives two aggressive examples: a direct ban on using useEffect, and a ban on ordinary code comments. These aren't always wrong; she's targeting patterns agents repeatedly abuse. With comments especially, models easily turn a temporary opinion from a PR discussion into a permanent rule, leaving historical notes that no longer match the current code.

These rules may not suit every team, but the approach transfers: find the worst shortcuts agents commonly take, then ask whether you can make them impossible through APIs, directories, types, or dependency relationships.

Turn human review comments into CI: how human judgment moves upstream

The same sentence appearing repeatedly in code review is a rule that hasn't been compiled into the system yet.

If engineers comment every week with "this dependency can't be imported from the renderer," "don't read shared state directly here," or "this feature has to go in its own directory," the team is enforcing constraints in the most expensive, slowest way: waiting for errors to happen, then asking a human to spot them.

Lauren's migration path is clear:

That last row matters. Rules, Skills, and BugBot all have value, but they're softer constraints. An agent might miss them, misinterpret them, or forget them in a long task. Architecture, the type system, the compiler, and CI give mechanical results—you can't get around them by saying "I followed the rules."

She uses Rust as a concrete example: a strict compiler and borrow checker eliminate a whole class of errors before code review even happens. This example doesn't require every team to switch to Rust; it shows how the tech stack itself determines how much engineering judgment gets executed mechanically before a human steps in.

So humans haven't left engineering judgment. Their role has shifted: from repeating the same reminders on every PR to designing interfaces, error spaces, and completion criteria up front.

This upfront design costs refactoring time and tokens, but the payoff isn't just for the strongest model. Once boundaries are clear enough, weaker agents, new engineers, and even product and design folks who don't know the full codebase can contribute safely within the same guardrails.

Verification capability sets the parallel limit: agents must run the product themselves

Architecture can make code cleaner, and CI can block known-bad patterns, but neither proves that what the user sees actually works.

Lauren calls verification the most important capability in an agent's toolbox. Here "verification" means far more than running unit tests. The agent needs to be able to start the app, navigate to the UI the user reported, perform actions, reproduce the issue, collect a CPU trace or heap snapshot, make the fix, and then check along the same path whether the problem is gone.

If any part of that loop is missing, a human becomes the dispatcher: the agent writes code, the human opens the dev build, the human finds the button doesn't respond, the human copies the console error, the agent fixes it, the human clicks through again. One agent is tolerable; ten agents will bottleneck the same single human.

A feature map solves the problem of "the agent doesn't know where the product is." Users say "the left sidebar is laggy" or just send a screenshot and three question marks, but there's no file in the codebase called "the left sidebar the user sees." A feature map records entry points, subfeatures, keyboard shortcuts, DOM selectors, and code locations from the user's perspective, turning vague reports into actionable paths.

This approach later made its way into PStack. The public create-verification-skill in the Cursor repo still follows the same principle: identify the UI users actually touch, build a map for the main features, actually launch the product, drive at least one feature, save evidence, and clean up the environment before confirming the evidence still exists. A verification Skill that has never been run for real is just a draft.

Skills need tests too: how PStack grew out of agent failures

Lauren says PStack didn't start with a grand methodology that got packaged into Skills. It started by observing failures.

An agent confidently named a root cause without reading the relevant code, so a Skill was created requiring evidence gathering first. An agent couldn't operate the real app, so Control Glass and verification Skills emerged. An agent couldn't find the feature the user was talking about, so a feature map was added.

Capability regression testingSkills grow from failure samples, and they must be tested against those same samples

Observe a specific failure→Turn it into an executable Skill→Define scoring criteria→Run in isolation across multiple models→Compare regression resultsPass: an agent new to the codebase can complete the task and leave evidence

Writing a Skill isn't the end. She treats evaluation as "unit tests for agents": set scoring criteria for a task, spin up multiple sub-agents in an isolated directory or worktree, have different models run the same task, then have a coordinating agent or another judge model score the results. After modifying a Skill, rerun and see whether it more consistently leads to the intended outcome.

She even gives the evaluation directory a nondescript name so agents don't change their behavior when they realize they're being tested. If a Skill only works when the agent knows it's in an eval, the results aren't trustworthy. Scoring can also be cross-checked by a different model, and the loop continues—modify the Skill, rerun the task—until failure modes truly converge.

This gives teams a very practical bar. A Skill's quality isn't proven by its documentation length. The question is whether an agent encountering the codebase for the first time can complete the task with it, whether it leaves checkable evidence, whether it still works with a different model, and whether failures can be traced to the Skill, the environment, or the task itself.

This loop also changes how team knowledge takes shape. Traditional experience is often scattered across senior engineers' review comments, verbal reminders, and incident memories. An agent team needs to turn that into engineering assets that can be distributed, executed, scored, and regression-tested.

From local observation to auto-merge: trust has to be purchased incrementally

Lauren doesn't advise teams to spin up hundreds of cloud agents on day one. Her sequence is the opposite: start locally, turn on tool calls, watch what the agent reads and doesn't read, see how it fails, then add architecture, verification, and Skills.

Once local verification is stable, tasks move to the cloud. She cites an agent named Benny: when a bug report comes in, Benny boots a cloud desktop, runs Cursor, uses the same control Skills to try to reproduce, then determines whether the main branch already has a fix. In the live demo, it confirmed the issue was already fixed on main, and the only remaining step was to ship a new build. It returned the reproduction results, environment state, and next steps—not just a guess like "might be here."

Trust, purchased in incrementsModel capability is only part of the story; permissions depend on evidence and reversibility

1. Local observationSee what the agent reads and how it fails
2. Controlled changesRestrict directories, permissions, and task scope
3. Independent verificationCan run the real product and leave evidence
4. Cloud executionIsolated environment, separate branch, auditable
5. Error triageReproduce, assess state, and hand off to the next step
6. Auto-mergeMechanical gates, short rollbacks, and production monitoring in place

The public version of Cursor Cloud Agents is already much more product-like. The official docs say each agent runs in its own VM, clones an authorized repo, works on a separate branch, and hands off its work as a draft PR; network egress, secrets, auditing, and repo permissions still need to be configured by the team. Cursor's security notes also explicitly put human review into the default handoff flow.

Auto-merge is a bigger step than running in the cloud. The former is just about where the agent executes; the latter decides whether an agent can change the main branch. To open that permission, a team should at least demonstrate: clear task boundaries, architecture that mechanically blocks high-risk errors, agents that run the real product, traceable failure evidence, short rollback paths, and monitoring that catches post-launch anomalies.

The reason product managers and designers can commit code directly stems from the same condition. The system first narrows the acceptable range of changes clearly enough—so both people unfamiliar with the full codebase and agents have a hard time stepping outside it—and the barrier to participation genuinely drops.

PR count is not productivity: what to learn, what not to copy

This talk could easily be misread as a high-output playbook: spend more tokens, rewrite the codebase, let agents auto-merge, then use PR count to prove efficiency.

PR count only records how many pieces a change was split into. A large task can be split into ten PRs, but ten PRs can also just be small fixes. It doesn't automatically include defect rate, rework, rollbacks, user value, delivery time, or maintenance cost.

METR's 2026 update to its developer productivity experiments draws a telling boundary: raw data from late 2025 tools shows signs of speedup, but participant selection bias, lower pay, and timing difficulties caused by multiple agents running concurrently made the research team conclude the data only provides weak evidence of the magnitude. The research update even explicitly notes that parallel agents make it harder to measure "how much human time did a task take."

A single productive engineer's PR numbers don't replace productivity research. A more reasonable team metric set would look at: time from requirement to verifiable result, number of human interventions, defects and rollbacks, completeness of verification evidence, reversibility of changes, and ultimately, business outcomes.

Greenfield and brownfield projects can't follow the same playbook. Brand-new applications are the quickest to spin up, but they're also the easiest to let run off the rails without guardrails in place, which makes them ideal candidates for designing agent-friendly boundaries from day one. Mature codebases, on the other hand, may already be better suited for agents if they come with strict typing, thorough tests, permissions, and large-scale engineering conventions. A full rewrite is only worth considering when the existing structure can't provide mechanical boundaries and the migration can be validated in stages.

Lauren also pointed out that the frameworks, conventions, permission limits, and safeguards that big tech companies build for human engineers across a wide range of skills and experience levels happen to work well for agents too. Agent engineering isn't a brand-new discipline that appeared from nowhere. Much of the effective infrastructure simply repurposes the guardrails originally designed for human organizations and applies them to models.

The cost of model calls and overnight runs also needs to be tracked separately. The token investment shown in the video doesn't come with a reusable cost table, and the live discussion about specific models, pricing, and capabilities at the end will become outdated as products evolve. So it can't be used to promise a certain budget or output for another team.

So the truly replicable outcome isn't "1,000 PRs per month." It's a method for gradually reducing the cost of human coordination: first tighten the agent's error space, then let the agent verify its own results, turn repeated failures into evaluated capabilities, and finally grant more permissions based on evidence.

A 24/7 agent team doesn't eliminate human judgment. It just moves that judgment from late-night line-by-line code reviews to daytime work on system design, defining what done means, and checking the evidence.