How a Cursor engineer puts agents to work

10x Developer Productivity with AI Agents: Practical Lessons from Cursor Engineer Lauren Tan

AI, Study  · 

Sometimes I hand a task to an AI agent and try to work on something else, only to find myself back at the terminal watching its progress.

The code comes together quickly. But once I start checking whether it is heading in the right direction, inspecting the results, and explaining requirements it missed, stepping away turns out to be harder than expected.

If I spend less time writing code, why am I still so busy?

Perhaps it is because the speed at which an agent works is different from the scope of work we can confidently delegate to it. To improve productivity further, we need a way to close that gap.

A presentation by Cursor engineer Lauren Tan addresses exactly this problem. Lauren introduces herself as an engineer at Cursor at the time of the talk, having previously worked on React Compiler at Meta and served as a tech lead and engineering manager at Netflix.

In this post, I will look at the verification skills and automation examples in her presentation and discuss the environment we need to prepare before we can confidently delegate work to agents.

1. Why It Is Hard to Delegate Work to Agents

Why We Keep Watching the Agent Work

When I ask AI to fix an error, I often get a response like this:

I found the cause and fixed it.

But when I run the application again, the same error appears. The AI changes something else, and now a feature that used to work no longer does.

After this happens repeatedly, it is natural to start checking everything the AI does.

Checking the work is necessary. The problem is when every task moves forward only while I am watching.

After Code Generation Comes Verification

Even if I run several agents, if I am the only person checking their results, eventually the work waiting for review just piles up.

I think this calls for a slightly different way of measuring productivity.

How quickly code is produced matters, but we also need to look at how far the work can progress without my constant intervention.

That does not mean we can suddenly trust AI and hand everything over. First, we need a basis for that trust.

2. Verification Skills as a Foundation for Trust

“Test It” Is Not Enough

Suppose I make the following request:

When a user saves their settings, the changes are not reflected on screen immediately.
Find the cause, fix it, and test the fix.

The agent modifies the relevant code and runs the unit tests. They all pass.

Can we call the task done now?

Whether it actually clicked the Save button in the UI, whether the changes appear only after a refresh, and whether they persist after navigating away and returning are separate questions.

The verification we expect may cover a different scope from what the agent actually performed.

That is why verification also needs a concrete procedure. For a bug fix, we should first check whether the issue can be reproduced before making changes. Tests that already passed before the fix do not tell us much about whether the problem has been resolved.

1. Prepare a test account and data in the development environment.
2. Reproduce the issue on the settings screen before the fix and record the conditions.
3. After modifying the code, change and save the settings under the same conditions.
4. Check that the changes appear on screen without a refresh.
5. Reload the page and verify that the read API also returns the saved values.
6. Run a regression test that reproduces the issue, along with relevant existing tests.
7. Report the commands run, expected and actual results, and anything that could not be checked.

I put together this example for practical use. If the issue cannot be reproduced, the agent should distinguish suspected causes from confirmed facts and explicitly state that it could not verify the effect of the fix.

It is better to define the completion criteria before implementation. We should also check that the agent has not changed expected results to match its own code or deleted existing tests just to make the checks pass.

The key is to make sure the agent knows what to run and what state to check. If it cannot access the execution environment, it must explain why. It must not mark something as passed when it has not verified it.

Control-Glass: Tools for Running and Checking the Application

Control-Glass, introduced in the presentation, is a verification skill that helps with running and interacting with the application, collecting traces, and more. I am discussing it here as an example of the speaker’s implementation, not as a publicly available tool you can simply install and use.

It is easier to understand if we imagine applying the same idea to our own project.

If an agent can only read code, it may be limited to inferring what will happen. If it can actually run the application and observe it, it can investigate again when the results differ from its expectations.

To repeat this process, we need more than execution commands. We also need the necessary environment configuration, test data, and ways to inspect the results.

Feature Map: Explaining How to Access Each Feature

Lauren adds a Feature Map to tell the agent how to access each feature.

Connecting a tool that can operate a browser does not mean the agent understands our service. When it receives a report that “reservation cancellation is not working,” it first needs to know which menu to open and how to prepare a reservation that can be canceled.

For each feature, we can document the following:

For a backend, the equivalent might be the sequence of API calls, authentication, data preparation, and ways to inspect responses and persisted results.

Pointing to the code is not enough. We also need to explain how users use the feature and how developers verify the results.

3. Turning Repeated Verification into Automation

Getting Verification Procedures Out of Your Head

At this point, you might be thinking:

Isn’t writing all these verification procedures more trouble than it is worth?

For a task you perform only once, perhaps it is. But if you open the same screen, enter the same data, and check the same results every time you modify a feature, the situation is different.

You are already repeating that process. It just lives in the developer’s head rather than in documentation or tools.

I think this is a good place to start with automation.

Rather than delegating the entire development process from the beginning, document one small task you check every time. Have the agent perform it, see what it missed, and improve the procedure.

For example, if it stops after confirming a successful save, add a case where the request returns a failure response. If it keeps getting stuck on accounts with no data, add instructions for preparing test data.

What matters is making sure you do not have to give the same explanation again after solving the current task.

As this accumulates, some of your judgment and verification procedures become part of how the agent works.

Benny: Delegating Bug Investigation Too

Benny, introduced in the presentation, is an agent that takes a bug report, runs Cursor in the cloud, and attempts to reproduce the issue. The talk also includes an example in which it confirms that the issue has already been resolved on the main branch.

I think this kind of automation is quite practical.

Fixing the code is not always the part of bug handling that takes time.

When someone reports that “saving is not working,” we first need to identify the screen. Then we need to determine which account and data are involved and check whether the issue still occurs in the current version.

Investigation may reveal that the fix already exists but has not been deployed yet. Or the problem may occur only under specific conditions.

Even automating the process of gathering this information changes the developer’s starting point.

Instead of receiving a vague bug report and investigating from scratch, we can decide what to do next based on reproduction conditions and verified results.

Automation does not have to fix every bug automatically to be valuable. Reducing repetitive investigation and preparing the information needed for a decision is already meaningful.

4. The Development Environment Behind Auto-Merging

Dune’s Constraints

The presentation also introduces an architecture called Dune and strict CI rules. Examples include banning useEffect and code comments.

Of course, there is no need to copy those rules directly. Nor should we interpret them as saying that useEffect or comments are the wrong choice in every project.

What I find important is that recurring problems in the project were turned into rules and reflected in actual checks.

For our own project, rules like these might be more appropriate:

- Domain modules must not depend directly on external API clients.
- Data access must go through the designated layer.
- Type checks and core scenario tests must pass.
- Sensitive information must not be written to logs.

Turning Documented Rules into Actual Checks

If we stop at writing these rules in a context file, we are still relying on the agent to remember and follow them.

Rules that can be checked automatically are better connected to linters, dependency checks, tests, and similar tools. A violation should fail CI, allowing the agent to see the result and make corrections.

Of course, automated checks cannot judge every design issue. We need to distinguish conditions that can be checked from those that require human judgment.

Auto-Merging Is What Comes Last

Lauren explains that she reached the point of automatically merging PRs.

Looking only at that outcome, it may seem that we should also configure our setup to merge agent-written PRs immediately.

But there are questions to answer first:

Passing CI means the conditions checked by CI were satisfied. If a condition we care about is missing from those checks, a green status alone is not enough.

So if auto-merging is the goal, we first need to make the completion criteria and verification scope concrete. Then we can connect the merge and deployment procedures on top of that.

Auto-merging is an option to choose based on the risk of the changes and how the team operates. Automating verification while keeping human approval for merging can also deliver substantial benefits. The conditions for allowing a merge and those for allowing an actual deployment should be defined separately as well.

5. How to Tell Whether Automation Is Working

Doing It Yourself May Be Faster at First

The productivity curve in the video is an illustration of Lauren’s personal experience, not a set of measured statistics.

I see it as an explanation of when an investment in automation begins to pay off.

At first, you need to keep checking what the agent does. You prepare the execution environment, write verification procedures, and correct things when the results are wrong. Looking only at the task immediately in front of you, doing it yourself may be faster.

But if the tools and rules you create in that process can be reused for the next task, the cost changes.

There is less to explain from scratch each time, and the agent starts checking some of the things a person previously had to check. That frees up time to focus on other problems.

Look for Less Intervention and Rework, Not Just More Output

The amount of code generated is not enough to measure this. It is useful to compare similar types of tasks before and after automation.

What to observe What to record
Human effort Time spent giving instructions, intervening, reviewing, and reworking
Time to completion Elapsed time from the task request to completed verification
Quality of the result Whether rework was needed and defects discovered after deployment
Automation maintenance cost Time spent on initial setup and improving skills and tests

There is no need to build an elaborate dashboard from the start. You can begin by keeping simple records for a few recurring tasks. However, you should not compare tasks with very different difficulty levels or interpret figures that exclude initial setup time as the overall productivity gain.

If more PRs are being created but review and rework are also increasing, that is far from the productivity improvement we were hoping for.

6. The Developer’s Role When Working with Agents

From Cooking Every Dish to Being the Executive Chef

Lauren compares a developer working with agents to an executive chef leading a team of cooks. Rather than making every dish personally, the role is to organize the kitchen and distribute the work.

Applying that analogy to development makes our responsibilities clearer.

We need to decide which problems to solve, break down the work, and prepare the necessary context. We need to provide tools that let agents check their results and make the important decisions ourselves.

Engineering Judgment Still Matters

That does not mean we no longer need to understand the implementation.

To judge whether verification criteria are sufficient, we need to understand the features and architecture. We also need to recognize cases where the tests pass but the design is wrong.

I think this shift broadens the scope of engineering expected of developers.

Alongside thinking about how to write code, we also need to consider how to build an environment in which agents can work correctly.

Closing Thoughts: Delegate One Small Task from Start to Finish

To me, the core of development automation is getting AI agents to approach engineering with a thought process similar to my own. In practical terms, that means having them reproduce a problem, fix it, and verify the agreed completion criteria.

A recurring error or a screen you repeatedly check is a good place to start. Document your verification procedure, delegate it to the agent, and see whether your intervention and rework decrease while the quality of the result is maintained.

If it works, expand the scope. If it falls short, improve whatever judgment criteria or information were missing.

If we want to improve productivity significantly, I think we should start by looking at what remains after the code has been generated.

Build an environment where you can genuinely delegate one small task all the way through.

That is where I would start.

References

Feedback is always welcome!