A human stuck reviewing every agent step can't scale to more tasks

When Lauren first joined Cursor, she was tasked with helping optimize the performance of the agent window. The app is built with React, the release deadline was near, and the codebase was unfamiliar to both her and the agents. Her initial workflow involved opening developer tools, recording performance traces, and handing screenshots or files to the agent for analysis. The agent would often point confidently at a suspected cause, yet the problem would persist after the fix.

In this workflow, writing code could be delegated, but observing the app remained a human responsibility. The agent says it's done; the human opens the dev build, spots the problem, then copies screenshots and error messages back. Each round-trip's speed depends on how quickly the human can check. Spinning up more agents just means they all end up waiting on the same reviewer.

So Lauren's first priority was to build verification capability into the agent: it should be able to launch the app, interact with the UI, capture CPU profiles and memory snapshots, and run a simulator when necessary. The agent needs to operate at the layer the user actually touches and observe what changes before and after a fix, rather than judging success solely from the code it wrote.

That answers whether a specific issue is resolved, but good architecture, maintainability, and product judgment call for other constraints. A single passing run only covers the behavior that was actually exercised.

Lauren sketched this process as a hand-drawn curve. During the talk, she noted that she had woken up to roughly 20 pull requests auto-merged at once. A PR is a set of changes submitted for review and merging into the codebase. She also mentioned merging around 1,000 PRs last month, and, by day 12 of the current month, reaching nearly 800. These figures illustrate how frequently she handled changes; each PR varies in content and size, so they don't translate into a productivity multiplier.

Give the agent a feature map so it can locate and verify issues

Once agents could operate the app, a new problem surfaced quickly: they could open windows but had no idea where product features actually lived.

When a user says "the left sidebar is laggy" or "the PR tab on the right doesn't work," a human can usually map that to a location. A fresh agent lacks that context and can only dig through code while clicking around. If a bug report is just a screenshot and some question marks, the agent may not even be sure which feature is implicated.

Lauren added a Feature Map to her verification skills. This document links what users see to the actual paths for reaching it: entry points, sub-features, operations, keyboard shortcuts, and which element attributes are available for programmatic UI interaction. The agent can therefore turn a vague bug report into an executable navigation sequence. The map explains how the product is used; when deeper implementation understanding is needed, the agent still goes back to the code.

The following questions can help check whether your own map is useful:

This table is a starting point for putting together a feature map; the specific paths and elements must be filled in for your own product. Copying navigation docs from another app won't help an agent understand the current one.

Lauren stores the methods for creating and maintaining verification skills in pstack. Maintenance matters as much as creation: when entry points, shortcuts, or interactions change, an outdated map will steer agents to the wrong places. The verification tooling enables the agent to operate the app; the feature map tells it where the thing to verify actually is.

Turn recurring pitfalls into reusable working methods

pstack started as a set of skills Lauren accumulated during regular work. A skill is a task description and operating guide for agents, often saved as Markdown and paired with execution tools. Its value comes from concrete experience: when the same failure keeps showing up, you write down the correct way to handle it.

For example, when an agent confidently insisted on a root cause, Lauren looked at the actual tool calls and saw that it never read the code relevant to the issue. Just adding a note to "be more careful" hardly changes behavior. The requirement had to be explicit: search and read the related implementation first, split up investigation when needed, and only then explain the cause based on evidence.

This also makes the case that early-stage observation can't stop at the final answer. A response can sound perfectly reasonable while the actions behind it don't back it up. Watching what was read, what was executed, and what was verified reveals which capability actually needs to be added.

Evaluate with real tasks to check whether skills are helping

Writing a skill doesn't guarantee the agent will follow it consistently. Lauren uses evals, meaning evaluations targeted at agent behavior, to check whether skill changes produce the intended results. Her approach: first define the task and the rubric, then run multiple agents in separate working directories to see if they can complete it correctly; run the same eval across the different models she commonly uses; and where useful, use another model as a judge to cross-check the assessment.

She also deliberately avoids giving away that an eval is in progress, such as through directory naming conventions, because she has observed agents changing their behavior once they recognize an evaluation scenario. The concern here is reliability during normal usage, not just whether a demo looks good once.

She also described a loop where a coordinating agent iteratively refines a skill, runs the eval, and works to improve the score; the verification skills themselves were developed through this same process. A perfect eval score means the skill satisfies that task set and grading rubric. It doesn't guarantee that all new tasks will be handled correctly. Whether an eval can expose real failures in the wild still requires people to keep observing and exercising judgment.

Agents can also help build these foundational pieces. Lauren had agents contribute to writing command-line tools for controlling the app, improving the verification skills, and then used evals to see what worked. Humans choose the problems to solve and define the success criteria; agents handle parts of the implementation and iteration. This way, engineering tooling once skipped because of limited headcount can gradually get built.

This improvement path can start narrow: pick a task that fails often, note which step the agent skipped, add one specific instruction, and then run a task that triggers the problem to see whether behavior changed. Once that class of issue has stabilized, broaden the scope of the skills.

Make recurring errors into automated checks

Verification capabilities address whether a running app meets its goal, but the codebase also needs to handle a different problem: as more features pile up, does the whole system get worse?

Lauren argues this is similar to what large engineering teams face. When many people are committing code, you can't rely on everyone simply remembering every principle. You need frameworks, conventions, permissions, and automated checks. When an agent can submit changes much faster, even a small team starts running into the same coordination pressures.

That means older codebases with mature constraints may actually be a better fit for agents. The higher risk sits with hastily assembled new prototypes: each task gets solved in whatever way is easiest at the moment, and over time dependencies between features become tangled, so fixing one thing can break another.

To keep every feature from going its own way, she restructured Grokbot, an agent application, around a shared set of engineering conventions called Dune. Dune defines how code is organized, which dependencies are forbidden, and enforces these limits with automated checks. Lauren described it as a set of principles and designs, without making any commitment to open-sourcing it as a general-purpose framework.

The most concrete Dune example involves restricting what code can enter the UI rendering side. Electron, the technology used to build the desktop app, needs a reasonable division of labor between drawing the interface and doing other work. Lauren said the agent window used to suffer from poor isolation, letting heavy computation or large I/O accidentally land on the render path and compete with UI updates for time.

At 60 FPS, the display draws 60 frames per second, giving each frame a budget of around 16.7 milliseconds, approximated as 16 ms during the talk. If other work eats into that time budget, the UI can drop frames or stutter. Just reminding reviewers to "avoid jank" isn't enough when changes get merged this quickly.

In Dune, she moved the relevant code into clearly separated directories and then set up CI checks on the dependency graph to block imports that cross boundaries. CI refers to a set of checks that run automatically after code is committed; if a detectable constraint is violated, the check fails. This way, errors don't wait until a human reads a pull request.

Bugbot, meanwhile, is a tool that assists with code review. These different constraints each handle distinct work:

Lauren also gave the example of a project constraint that bans code comments. She observed that agents would turn a piece of local review feedback into a comment that looked like a permanent rule, leading later executors to treat it as a global directive. Dune also disables React's useEffect, an interface commonly used to sync components with external systems, because she considers it too easy to misuse. These are choices she made for that codebase, and they don't generalize automatically into rules for every React project or every team.

When she mentions Rust, the emphasis is similarly on how the compiler can enforce some constraints for you. Compile checks have value in catching the errors they can recognize early. Whether the business logic is correct or the interface runs smoothly still depends on separate verification approaches.

A more useful move for a team: when the same review comment keeps showing up, check whether it can become a lint rule (an automated check for code patterns), a CI check, or an architectural change that removes the wrong path entirely. In that way, human judgment gets baked into every future commit.

Make the right way the path of least resistance

Could all those hard constraints make development more tedious? The other half of Lauren's design is about making the correct path clear, local, and easy to follow.

For example, code related to one feature lives together in a single directory, and new features follow the same organizational structure. When an agent works on onboarding, it can stay mostly within the corresponding feature directory instead of hunting for fragments across the codebase. Framework concepts like features, entry points, and chat cards also have agreed-upon creation methods.

Dune also requires that each state value that needs to persist over time has a single clear writer. New product features should prefer adding separate files rather than continually adding branches to a shared entry point. When an exception is truly needed, it should be limited in scope, have an explicit purpose, and go through review as an architecture change. These conventions make it clear who mutates state, where features extend, and how boundaries get adjusted.

This takes advantage of the fact that agents like following existing patterns. A good pattern is easy to find and following it automatically satisfies the constraints. Bad paths are blocked by automated checks. The architecture thus offers both a positive model and clear error boundaries, letting agents make fewer arbitrary choices and keeping them more likely to use established conventions correctly.

Reducing unnecessary decision-making may also lower the model capability required for a task. Lauren said that once this kind of environment is in place, agents using less capable models can still produce solid code work. She did not claim a uniform cost reduction, but it indicates a testable direction: first lay out the task path and engineering boundaries clearly, then run your own evals to see whether you still need a stronger model.

Work decomposition serves the same purpose. Lauren encourages splitting changes into self-contained PRs, each explaining what that slice of work does. Git history then retains understandable context, and it is easier to locate and revert issues when something goes wrong.

She does not impose a single line-count cap on PRs. The sizes she describes range from roughly 50 lines to over a thousand, and sometimes a PR may be primarily deletions. The point of a 'small PR' is that the change can stand alone — explainable, reviewable, and revertible — not that every commit fits under one uniform number.

Validate locally first, then scale to the cloud and the team

Lauren recommends starting the validation process locally, because being in the environment lets you see whether the agent lands on the right interface, what tools it calls, and whether it actually completes the check. Once that capability is trustworthy, moving it to the cloud makes it easy for multiple people to reuse.

Benny, the agent she demonstrates, handles feedback. When it receives a bug report, it launches Cursor in its cloud desktop environment and attempts to reproduce the issue using the same set of control skills. One specific result: it reproduced the problem on an older commit but found that main, the trunk code, already had the fix.

The value of this kind of report is immediate: the team knows the fix already exists, so the next step is shipping a new build that includes it. There is no need to spend an hour going back and forth with the agent, nor to redo changes that are already resolved.

What cloud reuse amplifies is precisely this kind of established capability. Validation tools, feature maps, and environment configuration stop helping only Lauren and start helping colleagues who receive feedback. Conversely, if a single agent's operations are not reliable, scaling it to many cloud instances only scales idle spinning and mistakes together.

Bringing more colleagues into the loop also requires the right entry point. Lauren notes that IDEs and command line interfaces are built for developers, not necessarily for product managers or designers; Grokbot uses a more conversational interface, closer to everyday chat, so they can raise tasks, see progress, and join the editing process. An easy-to-use entry point gets people in the door; the validation and engineering constraints behind it hold up the quality of changes.

Auto-merge also belongs later in this progression. Lauren's practice can help illustrate what it needs in terms of support, but there is no one-size-fits-all set of conditions for auto-merging across projects. Each team still has to determine, based on its own engineering standards, which results are sufficient to move to the next step.

Whether the rebuild pays off depends on whether the whole team keeps benefiting

To refactor Grokbot into this architecture, Lauren put in more than 600 PRs and a significant amount of token spend. She is upfront that she works at an AI lab with very generous token resources, and other teams should not assume they have the same budget.

So the cost of this approach has to be weighed alongside the ongoing gains. The upfront work includes building control tools, organizing feature maps, iterating on evals, migrating the architecture, and filling in checks; the payoff is less repeated manual validation downstream, and more contributors able to do work under the same set of constraints. She also describes product managers and designers using agents to fix issues and submit features, with engineering colleagues reviewing those contributions.

The frameworks, checks, and validation environment turn part of her expertise into conditions other colleagues can use. She does not offer a universal payback period; whether the investment is worth it should come down to whether those facilities are reused consistently and whether they genuinely cut down on repeated human intervention.

If you want to start, scope can be very small: pick a recurring failure you can observe locally, let the agent run the full reproduction and validation path on its own, fill in the feature map for that route, and turn one common rule violation into an executable check. Once tasks in that category stop needing humans to fill in steps, expand the capability to other features and to the cloud.

The engineer's job shifts too: beyond solving the immediate problem, you leave behind the knowledge, actions, and boundaries that made the solution possible. The next executor can build on those directly, and reliable autonomous work has room to keep growing.

Source

Lauren Tan, How Cursor Turned AI Agents Into Better Engineers, Maven, August 12, 2026. Video chapters include validation and feature maps (08:35), skill evals (20:04), cloud agents (26:34), refactoring and constraints (32:34), the Dune architecture (41:00), and cost (50:38).

Watch the original talk

Company attribution: on August 14, 2026, Cursor officially announced it had been acquired by SpaceX, with the team stating in the public announcement that it is joining SpaceXAI. The Cursor name in the original talk and product remains as it was at the time. Acquisition announcement · Team statement