By ByteBot
Cursor 3.5 shipped on May 20 with a feature that sounds like marketing copy until you see the numbers: AI coding agents that run in isolated cloud VMs, write code, run tests, browse your UI, and file pull requests — with or without the IDE open. Cursor CEO Michael Truell put a number on it: 35% of Cursor’s own merged pull requests now come from these autonomous agents. That is not a benchmark. That is production code shipping to millions of users.
The shift from “AI helps you code” to “AI codes while you sleep” is not a roadmap item anymore. It shipped.
What Cloud Agents Actually Do
Each Cursor cloud agent task spins up a dedicated virtual machine: full terminal, browser, and desktop access. The agent clones your repository, installs dependencies, writes code, runs your test suite, and navigates your UI in a headless browser to verify behavior. When it finishes, you get a merge-ready pull request with a video recording of everything the agent did inside the VM attached as an artifact.
You can run ten of these in parallel. Ten different features across ten isolated VMs, while you are in a meeting or asleep. The agent loop is built on Temporal, which means it handles inference blips, pod hibernation, and runs that stretch across days without losing state. Cursor reports 50 million actions per day across 7 million unique workflows.
An independent productivity study found companies using Cursor agents merge 39% more PRs — with the revert rate and bugfix rate holding steady. Volume went up, quality did not go down. That is the metric that matters: faster output that does not create a cleanup bill.
Setting Up Your First Cloud Agent Environment
Cloud agents need a full development environment defined explicitly — unlike local agents, which inherit your laptop setup. The configuration lives in the Dev Environments tab and is Dockerfile-based, which means reproducible, version-controlled, and reviewable.
A minimal Node/Python project setup looks like this:
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y nodejs npm python3-pip git
COPY requirements.txt .
RUN pip install -r requirements.txtAdd your repositories — multi-repo support landed May 13 — set encrypted environment secrets for API keys and database strings, and enable layer caching. Builds that hit the cache run 70% faster, which matters when you are launching agents repeatedly against the same stack.
One thing Cursor’s engineering team flagged in their post-launch writeup: cloud agents need different prompts than local agents. Tell them to proceed without asking for permission. Locally, you notice when an agent has paused. In a cloud VM running unsupervised, it can sit blocked for hours before you check back. Autonomous mode prompts only — if unsure, pick the most reasonable interpretation and proceed.
The Enterprise Option: Your Infrastructure, Your Rules
For teams that cannot let source code and environment variables live on Cursor’s AWS — healthcare, finance, anything touching SOC 2 or GDPR — Cursor launched self-hosted cloud agents on March 31. You run agent workers on your own Kubernetes cluster using Cursor’s Helm chart and operator. Workers use outbound-only HTTPS to Cursor’s control plane — no inbound ports, no VPN tunnels required. Your code stays in your network.
Named customers include Brex, Money Forward, and Notion. The Kubernetes 1.24+ requirement means this fits teams already running containerized workloads. Cursor says setup takes under an hour with the provided Helm charts.
The Limitations Worth Knowing
Cloud agents are not a universal solution, and treating them as one is how you waste credits and generate bad PRs.
The compliance gap is real. Cloud-hosted agents mean Cursor’s infrastructure handles your environment variables, build outputs, and intermediate files. If your security team runs a centralized vault with rotation policies, Cursor’s key-value secrets store is not compatible. Self-hosted solves this, but it requires Enterprise licensing.
The async model assumes task independence. Cloud agents excel at parallelizable work — multiple features, parallel bug fixes, refactoring across separate modules. They are poor at work with tight interdependencies, because you discover conflicts at PR review time rather than mid-execution. If your tasks require constant coordination, this is the wrong tool.
Vague prompts produce bad PRs. And bad PRs cost credits. “Refactor the auth module” is a bad prompt. “Extract the token validation logic from auth.py into a new TokenValidator class with unit tests covering the four error cases in the existing test suite” is a good prompt. The quality of your task specifications is now a first-class engineering concern.
The Bigger Shift
What Cursor 3.5 makes concrete is a change in what developers actually do. The ratio on the platform has already flipped: agent users now outnumber Tab autocomplete users 2-to-1, up from the inverse ratio in early 2025. Agent usage has grown more than 15x over the past year. Writing code is increasingly something agents do. Specifying what gets built, reviewing whether it is correct, and governing what ships — that is the expanding developer surface.
This is not the end of software development as a profession. It is the end of software development as primarily a typing job. The developers who adapt to writing precise task specifications and reviewing agent output at scale will do more. Those who do not will do less.
Cursor 3.5 cloud agents are the clearest production signal yet that the transition is not coming. It already happened. Read the Cursor engineering team’s post-mortem on building cloud agents — it is unusually candid about what they got wrong first.
