Cursor 3 turns the IDE into an agent control tower
Contents
Cursor announced its major update, “Cursor 3,” on the official blog. It threw away the old VS Code-based UI and rebuilt the interface around agent management. Hacker News pushed it to 302 points and 257 comments.
In the previous Composer 2 post, the buzz came from outsiders discovering that the base model was Moonshot AI’s Kimi K2.5. This time the focus is not the model, but the product architecture itself. Cursor 3 goes straight at the assumption that has defined IDEs for decades: that developers are the ones who write the code.
What Traditional IDEs Assume
VS Code, JetBrains, and Xcode all start from the same premise: developers read code, understand it, and modify it with their own hands.
Under that assumption, IDE features have always existed to make manual work faster.
| Feature | Role |
|---|---|
| File tree and editor tabs | Let developers navigate the codebase as a physical file hierarchy and open the files they need manually |
| Go to Definition / Find References | Deterministic AST-based navigation. The developer decides what to read next |
| Refactoring tools | Rename Symbol, Extract Method, Inline Variable. All AST transformations with fully predictable results |
| Integrated terminal and debugger | Passive tools that the developer launches and drives explicitly |
| Single workspace | Designed around focusing on one project at a time |
That is a good design, and for many developers it is still the right workflow. Cursor 3 is trying to change the premise itself.
What Changed
Cursor 3 is built around the idea that “the agent is the main actor, the human is the supervisor.” The old Cursor was basically a VS Code fork with a chat panel. Cursor 3 makes the agent dashboard the center of the screen.
The main new features are:
| Feature | What it does |
|---|---|
| Multi-workspace | Run agents across multiple repos at once |
| Cloud agents | Run in isolated cloud VMs with a terminal, browser, and full desktop environment |
| Local/cloud switching | Move work from local to cloud and back without friction |
| Agent Tabs | Show multiple agent chats in parallel, side-by-side or in a grid |
| Design Mode | Annotate UI elements in the browser and point the agent at them directly |
| Cursor Marketplace | Distribute MCP, skills, and subagents as plugins, including private team publishing |
If you line those up against a traditional IDE, the structural change becomes obvious.
| Traditional IDE | Cursor 3 | What changed |
|---|---|---|
| File tree + editor tabs | Agent Tabs | The unit of work shifts from files to agent sessions |
| Single workspace | Multi-workspace | Work across multiple repos at once |
| Local execution only | Cloud agents + local | The execution environment is no longer tied to your machine |
| Deterministic refactors | LLM-based changes | Predictable but limited -> flexible but non-deterministic |
| DevTools + manual CSS edits | Design Mode | Point at the UI and let the agent patch the code |
| Manual test runs and result checks | Agent runs tests and fixes issues | Developer does not “run tests” anymore; the agent does |
The cloud agent is the boldest part. It spins up a sandbox VM in the cloud, clones the repo, and handles everything from environment setup to code changes, testing, and PR creation. It keeps running even if you go offline, and when it finishes it generates a demo with screenshots. Each user can run up to 10 workers in parallel.
With traditional IDEs, CI handled the post-commit testing. Cursor 3 pushes automation earlier and makes the coding loop itself autonomous.
How the Development Loop Changes
The developer’s place in the loop is completely different between the old IDE model and Cursor 3.
In the traditional IDE model, the developer sits in the center of the loop:
graph TD
A1[Developer opens a file] --> A2[Reads and understands code]
A2 --> A3[Manually edits code]
A3 --> A4[Runs tests in terminal]
A4 --> A5{Tests pass?}
A5 -- No --> A3
A5 -- Yes --> A6[Commit]In Cursor 3, the agent moves to the center:
graph TD
B1[Developer writes a task] --> B2[Agent analyzes the codebase]
B2 --> B3[Agent changes code]
B3 --> B4[Agent runs tests]
B4 --> B5{Tests pass?}
B5 -- No --> B3
B5 -- Yes --> B6[Developer reviews and approves]The old model is “the developer writes, tests, and fixes.” The IDE helps make that loop faster.
The Cursor 3 model is “the developer supervises while the agent does the loop.” The IDE becomes a control tower rather than a writing tool.
The difference becomes clear if you compare JetBrains’ Rename Symbol with Cursor 3’s agent-based change flow. Rename Symbol uses AST analysis to rewrite every reference deterministically. It is 100% predictable and never makes surprise edits. Cursor 3, by contrast, accepts vague prompts like “rename this function and update all the related tests and docs.” It can catch string literals and comments, but because the LLM output is non-deterministic, it can also introduce unintended changes.
Do you want a limited but safe deterministic refactor, or a flexible but heavily verified agent-driven change? Cursor 3 bets on the latter.
Comparison With Copilot CLI /fleet
In terms of parallel agents, GitHub Copilot CLI’s /fleet command had already implemented a similar idea. But the approaches are different.
/fleet takes one prompt, splits it internally, and runs the waves automatically. Cursor 3 is more of a “manual orchestration” model, where the developer opens several agent tabs and gives each one separate instructions. One side optimizes for automatic decomposition; the other lets the human control the granularity.
The other difference is cloud execution. Copilot’s & key sends a task to the cloud, but it stays at the repo level. Cursor’s cloud agent gives you a whole VM, so it can handle browser UI verification and desktop-level work.
Neither of those ideas existed in traditional IDEs. VS Code and JetBrains did not have a concept of “multiple autonomous processes rewriting code at once.” At most, linters and formatters ran on save. The developer was still the sole author of changes.
Can Design Mode Replace DevTools?
Inside Cursor 3’s integrated browser, you can inspect the rendered result of a local server directly. With Design Mode enabled, you can click UI components and add annotations, then tell the agent things like “change this button color” or “tighten this spacing.”
The traditional flow for the same thing looked like this:
- Open DevTools in the browser and inspect the element
- Identify the CSS selector or component name
- Go back to the IDE and find the file
- Manually edit CSS or JSX
- Reload the browser and check the result
- Repeat steps 3-5 until it looks right
Design Mode shortcuts that loop. You point to the UI in the browser, and the agent aligns the DOM with the source code and changes the code accordingly. No more jumping between DevTools and the editor just to find the right file.
That said, Design Mode does not replace DevTools’ network analysis, performance profiling, or memory-leak detection. It is specifically for visual change requests. Debugging still needs DevTools.
Where Composer 2 Fits
Cursor is still pushing Composer 2 on the model side. As I explained in the previous article, the model is based on Moonshot AI’s Kimi K2.5 with coding-focused reinforcement learning, and it was already close to GPT-5.4 Thinking on CursorBench. In Cursor 3, Composer 2 is positioned as especially good for agent tasks, and you can still switch to external models like Claude.
Cursor also added a shortcut to send the same prompt to multiple LLMs and compare the outputs. Traditional IDEs had no concept of model selection, but in AI coding tools the model choice directly affects code quality, so comparison mode is genuinely useful.
How Hacker News Reacted
The Hacker News comments were split.
Supportive comments focused on the fast navigation provided by Cursor’s remote indexing and the good UX for tagging files and code in chat.
The criticism fell into a few buckets.
One group simply does not want to give up the traditional IDE experience. Comments like “I have zero interest in the new agent swarm. Please stop forcing it on us” came up more than once. The concern is that managing many parallel agents adds cognitive overhead and that letting multiple agents rewrite code without human review is risky for quality. For this group, plain IDE + Copilot completions are enough. They want to write the code themselves, and they value understanding the codebase deeply. To them, delegation to agents feels less like productivity and more like giving up comprehension.
Cost complaints were also common. One user said they had been spending $2,000 a week on premium models before switching to Claude Code Max, which cut the cost to one tenth. Because Cursor’s business model depends on reselling API tokens, it gets more expensive the more you use it.
VS Code extension compatibility was another recurring complaint. Cursor is a VS Code fork, but some plugins, such as Python IntelliSense, do not work properly because of the fork and its licensing differences. Cursor 3’s redesign makes it even more distinct from VS Code. Cursor’s original advantage was that it inherited the VS Code ecosystem. Agent-first design now risks eroding that advantage.
Claude Code got its own comparison. Terminal-based Claude Code is cheaper and more flexible but takes more setup. Cursor is smoother because the whole experience is integrated, but it is more expensive. Claude Code users can also keep their existing IDE and add agent features through extensions, preserving file navigation and refactoring tools. Cursor went the other direction: it discarded the traditional IDE experience and focused on the agent experience. Same AI coding category, different route.
The Competitive Picture for AI Coding Editors
The AI coding market has moved from “add a chat panel to the IDE” to “build a dashboard that manages agents.” Copilot CLI’s /fleet, OpenAI Codex’s cloud sandboxes, and Claude Code’s multi-agent coordination all point in the same direction: parallel agents. But the market is splitting into two camps. One keeps the strengths of traditional IDEs, while the other redefines what an IDE even is.
Traditional file trees and deterministic refactoring are optimized for helping developers understand a codebase deeply. Delegating to agents can be faster, but it can also lower the developer’s understanding. That speed-versus-understanding tradeoff is where the current tools are diverging.
Anysphere, the company behind Cursor, has already raised more than 29.3 billion valuation holds up depends on whether people keep using Cursor 3.