Cursor’s Third Era: From Writing Code to Operating Agents

Give the agent a working computer

Earlier Cursor Cloud Agents had their own virtual machines, but those machines were typically blank: the repository’s development environment had not been configured. Agents could read and change code without the setup needed to run the application. The upgrade discussed in Cursor’s Third Era, published March 6, 2026, addresses that gap. Agents can onboard themselves, run code, and operate applications through computer use—taking screen pixels as input and producing coordinates for interaction.

In the first demonstration, an agent had worked for roughly half an hour, including starting development servers, testing end to end, and iterating. The intended handoff is a tested pull request ready for human review. Internally, the team reports that configured computers and computer use shifted adoption from small copy edits toward implementing features.

Testing and video production are selective. The model decides, guided by instructions to skip very simple copy changes and test more complex work. Users can disable testing with /notest or supply repository-specific guidance in agents.md, including exceptions for parts of a monorepo where the usual testing workflow will not work.

Review behavior before diving into the diff

Once agents generate larger changes, review becomes a bottleneck. Cursor combines the code change with a demonstration video and access to the running environment. A tooltip example illustrates the approach: an agent can show the component’s behavior, sometimes in a Storybook-style gallery of individual components. The video provides an easier entry into a large change; code review still matters.

Sam describes videos as shared artifacts for resolving intent. A request for a toggle might produce a checkbox; seeing that mismatch early avoids downloading and running the branch just to discover it. Detailed planning reduces underspecification but does not eliminate it. The presenter describes changes that needed two or three follow-ups after the first video established that the implementation was on the right track.

When a recording leaves questions unanswered, the reviewer can control the agent’s desktop, interact with the application, and use its terminal. This makes hands-on evaluation possible without reconstructing the environment locally.

A second example exercises mostly backend error handling: Cloud Agents used its own product to improve the generic failure message shown when saving an oversized secret. Without instructions on how to test it, the agent reportedly opened browser developer tools, used JavaScript to insert 5,000 A characters into the input, and attempted to save. The video cut off before the result, so the presenter referred to a screenshot of the new error. The test procedure combined browser interaction and code execution to reach the failure path.

This design grew out of browser-interaction experiments at Autotab. The aim became a full computer with a development setup comparable to a human’s, removing environmental constraints until model capability becomes the limiting factor. The presenter also reports further gains in autonomous work with Opus 4.5, Opus 4.6, and Codex 5.3, without a quantified comparison.

Establish the bug before showing the fix

Short videos also make candidate implementations easier to compare. The presenter contrasts four 700-line diffs with four 20-second demonstrations: an illustrative review workload in which watching behavior helps select a candidate for further iteration, even if none is finished. Downloaded demos include a Cursor-branded ending; a cloud agent built that feature too.

For debugging, `/repro` creates a more specific handoff: 1. Reproduce the bug in the agent’s virtual machine and record it. 2. Implement a fix. 3. Repeat the same interaction and record the corrected behavior. The presenter reports that this increased confidence in fixes for bugs that were tedious to reproduce locally, describing some merge decisions as taking roughly 90 seconds—an anecdotal estimate.

The concrete example is an image-attachment bug: removing images before submitting a prompt did not actually remove them from the submission. In the narrated reproduction, five images reached the prompt although only one remained in the interface. Repeating the interaction after the fix left only the intended image attached. The agent used the desktop’s native file picker, then prompted another Cursor agent inside its environment. Agents could start and communicate with their own Cloud Agents, but further recursive spawning was disabled.

A participant connects this to red-green test-driven development: establish a failure, then make it pass. That addresses the risk of changing tests until they pass without showing that they exercised the original bug. Automatic reproduction was still imperfectly calibrated, with conservative triggering because it adds runtime. Users could explicitly request /repro when they wanted before-and-after evidence.

Use agents to investigate agents

Bug Bot Auto Fix, described as newly launched, could address review findings through a button or an automatic setting. An internal command, Fix BB—Fix Bug Bot—brought findings back to the original pull-request agent. Its original prompt and conversation could help resolve regressions while preserving the intended change. Discoverability remained a problem: another team participant had never heard of the command.

Cloud Agent Diagnosis takes an instance ID and launches subagents—agents assigned parts of a larger task—to inspect logs through a Datadog integration. The reported benefit is replacing manual log exploration with one agent request. Another internal workflow gives an agent a previous agent’s transcript to debug the run or continue its conversation. It reuses the cloud-agent infrastructure and harness, the system surrounding the model, with additional plumbing to attach the transcript.

Transcript-based debugging was internal, with public versions described as forthcoming. The team was beta testing the Datadog integration and was unsure of its public availability. The discussion raises a strategic tension for observability vendors: expose logs for external coding agents, or own the workflow that diagnoses and fixes problems. That was a participant’s interpretation, not an announced Datadog strategy.

Shared delegation moves the bottleneck to merge

Cursor’s three-era framing moves from Tab autocomplete through interactive task delegation toward longer-running agents. The expected change is in the unit of work: from closely supervising tasks lasting seconds or a few minutes to delegating work lasting half an hour or several hours, then watching demonstrations and trying previews. Those durations describe an anticipated workflow.

Internally, Slack has become a shared development workspace. Mentioning Cursor in an issue or product-discussion channel starts a cloud agent. With team follow-ups enabled, colleagues can contribute context to an agent someone else started. One workflow asks the agent to investigate an issue, consult code blame, and tag people who may understand the relevant code. The thread then gathers their context and the agent’s artifacts around a proposed pull request.

Another participant describes collaboration across technical marketing, design, and sales, each contributing domain knowledge and correcting agents. Participants report that human discussion increasingly centers on whether to ship, whether the user experience is right, and how to make behavior clearer. Cursor responds only to an explicit @mention while retaining access to intermediate messages, leaving room for humans to discuss the task.

Generating a pull request is easier than establishing that it is ready to merge. The recurring internal joke is that almost any proposed feature already has a pull request somewhere. Cursor identifies the first-draft-to-merge pipeline as a place to apply more compute, with Graphite described as a major part of that effort. A completed integration was not announced.

Review remains layered: videos help assess features, while code review examines implementations. Participants report strong internal adoption of Bug Bot and expect its comments to be addressed. They anticipate further agent-assisted reviews for performance, security, and other effects on the codebase.

The broader prediction is that parallel agents will give small teams delivery problems previously associated with much larger organizations. Proposed practices include waiting for Bug Bot before merging, releasing frequently but gradually, adding rollout checkpoints, and detecting regressions automatically. The comparison between a 10-person startup and a 10,000-person company concerns infrastructure needs, not measured output equivalence.

The environment and interface shape delegation

Cursor attributes part of its early growth to developers adopting it for side projects and bringing it to work. Team setup now receives more attention: the recently launched Marketplace distributes plugins containing skills and integrations so later adopters inherit useful configuration. Administrators can configure services with team authentication; integrations requiring individual authorization still need each user’s approval.

Early cloud-agent adoption was reportedly strong among smaller teams with simpler environments. Agents could install dependencies for straightforward frontend/backend projects, while complex infrastructure—such as Docker layer caching needed to avoid two-hour builds—required further support. Users could not yet choose virtual-machine size; that control was planned.

Two kinds of persistence serve different purposes: - Environment templates: run installation commands, snapshot roughly the filesystem state, and use the snapshot to start new virtual machines. Dockerfile-based setup is also supported. - Hibernation and rehydration: capture memory too, allowing restoration of a browser with the same page open. The desired experience is a desktop users can return to after several days while continuing work on a feature.

The web interface became smaller during development. Cursor removed a preview that forwarded the virtual machine’s local web application into an iframe in the user’s browser. The team judged remote desktop sufficiently responsive and more general: it supports desktop applications and native file interactions as well as web pages. The remaining design emphasizes shared controls—both human and agent can operate the desktop and run terminal commands.

Removing the built-in file editor was more contentious. Cursor wanted to encourage delegation; another participant argued that occasional manual edits still matter and opening an external editor creates friction. The response distinguished the overall product from individual interfaces: Cursor should support high-level delegation and low-level inspection, while surfaces such as Slack can expose fewer controls. The removed features could be reconsidered.

A hosting proposal raises a similar boundary question. Platforms such as Lovable and Bolt combine app creation and deployment; owning the live site and logs could tighten the debugging loop. Cursor’s response was that hosting was not its best immediate way to help customers ship. Its focus on existing software makes moving customers to a new deployment platform a different problem from hosting a new app. Integrations such as Datadog offer another route to operational context.

Parallel candidates, synthesis, and subagents

Model choice introduces another layer of delegation. One participant describes personally switching from Opus 4.5 to Codex 5.3 as preferences changed. Cursor’s desktop editor already offered Auto routing, which selects a model for a request; equivalent routing for Cloud Agents remained an ambition. The product needed to support both explicit model choice and users who wanted Cursor to choose.

Best of N runs several agents on the same prompt. It existed in both the desktop editor and web interface, and the demonstration launched five models from a multi-model picker. Each cloud agent had its own virtual machine. Compared with local Git worktrees, the consequential advantage is runtime isolation: agents can start servers and run commands without interfering with one another’s ports.

An unshipped experiment from the previous year went beyond choosing a winner. Multiple candidates fed an agentic judge that could write code, synthesizing a new diff from their solutions. A speaker reports better outputs when the base models came from different providers, suggesting complementary strengths, but gives no evaluation procedure or effect size. The proposed interface would hide generation and judging behind a simple user choice.

Subagents let a parent delegate bounded work through a generic task interface. The parent might assign codebase exploration to one worker or divide it among several. In a desktop demonstration, an exploration subagent uses Composer while its parent uses Opus: exploration involves reading many things, so a faster model can return an answer sooner. Users can inspect the subagent’s activity, though the precise customization interface was not explained.

Cloud Agents use a built-in computer-use subagent for testing and verification, where long runs accumulate many images. That boundary supports both task-specific model routing and context compression: the subagent summarizes its execution and testing history in a final message to the parent. The parent does not need to carry every screenshot and intermediate step, reducing the need to compact the entire conversation.

Longer runs demand clearer intent and more capacity

Grind Mode, the internal name for the available long-running agent mode, grew out of experiments attributed to Wilson. It begins with alignment and planning; execution waits until the agent judges the plan acceptable to both itself and the user. Underspecification becomes more expensive as runs lengthen. A speaker argues that three days of autonomous work may justify hours spent communicating the desired outcome beforehand.

Three-day runs were reported, without task details or success criteria. The available long-running agent was described as one worker node. The browser-building experiment instead used collaborating workers, planners, and other agents after a single worker’s throughput proved insufficient for the project’s scale.

This motivates the distinction between latency and throughput: how long one task takes versus how much work the system completes in a given time. Parallel agents can increase aggregate output without shortening each task. A speaker describes concurrent agents generating thousands of tokens per second as a glimpse of future development, while acknowledging that the browser had no real-world users and substantial shortcomings. Production readiness at that scale remained a prediction.

Downstream capacity was already a practical constraint: a speaker reports that agent-generated pushes overloaded Cursor’s GitHub Actions build and delivery pipeline. Another compares agent coordination to reinforcement-learning infrastructure, where parallel runs must be scheduled for throughput. The discussion predicts sharply rising inference demand per developer, but supplies neither measured personal token consumption nor a quantitative capacity forecast.

The spending argument invokes Jevons paradox: better tools can stimulate enough additional use to increase total consumption. A speaker sketches monthly spending rising from roughly $20 for autocomplete to hundreds for interactive coding and thousands for long-running parallel agents, then speculates about tens of thousands per person. These are broad spending and value claims, not a price list. Another participant reports becoming busier and more ambitious, while limiting the employment implications to personal experience.

Engineering judgment remains central to hiring. Familiarity with the latest agent techniques signals curiosity but is not an absolute prerequisite. The speakers value systems experience, sound abstractions, and good decisions made quickly. Their reason is concrete: models running for long periods without cleanup and refactoring can produce sloppy code and poor abstractions that humans must recognize and redirect.

A working day becomes a series of check-ins

A late demonstration shows the daily workflow. The presenter describes starting roughly ten agents in the morning, then checking each as it finishes: watch its video, perhaps try the desktop, and send feedback or begin the merge process. A check-in might take 90–120 seconds before attention moves to another agent while automated checks or follow-up work continue. Those timings are personal workflow estimates.

One follow-up asks an agent to show a button in the actual application rather than only in a gallery. The reviewer decides whether the demonstration answers the product question. Separate desktops reduce the friction of finding branches and worktree diffs or waiting for local rebuilds. Another participant checks progress, watches videos, and unblocks agents through the mobile web interface during commutes and overnight, without leaving a computer open.

As check-ins, task tracking, and completion notifications become central, coding tools may overlap with productivity tools; Vibe Kanban is cited as an open-source example. The discussion also points to OpenClaw as an example of broader capabilities built on a coding-agent foundation. More generalist roles and similar changes in other industries are predictions, with much more evidence still to come.

Manual writing persists where it helps formulate intent. One participant estimates that manual coding accounts for about 1% of their work and predicts writing no code personally during December of the interview year. Prompt editing remains a meaningful exception: composing the text can be part of thinking through the request. Internal prompt-optimization tools still leave substantial human work in deciding which concepts the model needs.

Voice offers another way to transfer context, including tangents and unfinished thoughts. At Autotab, users taught tasks through screen recordings with audio, often adopting stilted sentences and exaggerated enunciation learned from older voice assistants. Participants favor more natural context dumps, while identifying a persistent difficulty for coding: exact technical spelling and capitalization matter.

Operational memory is the unfinished foundation

One participant predicts that cloud agents will surpass local agents before the end of the interview year and exceed twice their volume by year-end, without defining the volume metric. The remaining obstacles begin with onboarding. Users select a repository, add secrets, and grant access before the agent installs dependencies, but setup is still too slow. It also needs continuing maintenance as dependencies change, new systems require access, and databases move.

Autonomy exposes missing operational memory. To operate a repository, an agent needs its specific backend startup procedure, health checks, and development quirks. It also needs the architecture and design trade-offs that explain how to make a good change. Familiarity with conventional commands cannot supply that local knowledge.

One proposed direction is filesystem-based memory, influenced by Cursor’s work on dynamic file context: give agents pointers and annotations to relevant information. An agent encountering a recurring gap could propose a memory file, link, or annotation for future use. This could extend into auditing its own operation—finding conflicting instructions, skills, or rules and fixing development-environment problems.

The closing discussion calls this agent self-awareness: understanding the surrounding system, available capabilities, and constraints, rather than consciousness. An agent must know environment-specific details such as how secrets work. A further prediction is that models will manage their own context, potentially editing their system prompts; how to make such edits safely remains unresolved.

A recollection from Dot makes the requirement concrete. At launch, the product could perform certain tasks yet sometimes told users it could not. The capability existed, but the agent lacked adequate knowledge of its own boundaries. Being able to perform a task and knowing that the capability is available are separate product requirements, potentially requiring different parts of the prompt. A speaker argues that users often perceive greater intelligence when a system understands its environment well enough to act effectively within it.