Cursor AI: what it ships and what it misses

Every developer has that moment when they wonder if their coding tools are truly working for them or just adding noise to their workflow. Cursor AI has sparked that conversation across engineering teams worldwide, promising to reshape how developers write, debug, and ship code. But does it deliver on that promise, or does the hype outpace the reality?

In this analysis, we take a close look at Cursor AI from the perspective of developers who already understand the fundamentals and want honest, practical insight. We will break down what the tool genuinely gets right, from its context-aware completions to its conversational code editing features. We will also examine where it falls short, the rough edges and limitations that do not always make it into the marketing materials.

Whether you are evaluating Cursor AI for your own workflow or considering rolling it out across a team, this post will give you a grounded view of its strengths and gaps. No breathless enthusiasm, no unfair dismissal; just a clear-eyed look at what you are actually getting.

What Cursor AI actually is

Cursor is an AI-native code editor built on a forked version of VS Code, but that origin story undersells what it has become. Where VS Code treats AI as an extension layer bolted on top, Cursor bakes it into the architecture from the ground up, giving the AI access to the full editing context rather than a narrow slice of the current file. Developers can import existing VS Code extensions, themes, and keybindings with minimal friction, which lowers the switching cost considerably without sacrificing the AI-first design.

The core differentiator is context at repository scale. Cursor's context window reaches 272,000 tokens, and rather than operating line by line, it loads context dynamically across an entire codebase to inform suggestions, refactors, and new file generation simultaneously. A developer asking it to extract a utility function gets suggestions that account for how that function is called elsewhere in the project. That cross-file awareness is what separates it from earlier autocomplete tools, and it works best in single-repository workflows with fewer than 50,000 files.

Agent Mode is now the default workflow for many teams. The agent reads the codebase, edits files, executes terminal commands, monitors output, and iterates until a task completes, without the developer issuing each individual instruction. Background Agents extend this further, spinning up sandboxed cloud environments where multiple agents work in parallel and return a pull request when finished. Cursor now powers development at over half of Fortune 500 companies, with more than 90% of Salesforce engineers using it daily, a signal that this is enterprise infrastructure, not a developer experiment. For a full comparison of how Cursor handles large codebases against alternative architectures, the file-count ceiling is worth examining before committing to it at scale.

Market position, by the numbers

The market context here is worth reading carefully, because the numbers reveal where Cursor sits relative to the category it helped create.

The AI coding assistant market is valued at approximately $12.8B in 2026, projected to reach $30.1B by 2032 at a 27% CAGR. Within that category, Cursor holds roughly 25% market share today, with projections placing it at 45% by 2036 as multi-file editing and deep codebase context shift from differentiators into baseline expectations. That trajectory implies compounding rather than a near-term jump: the tool that owns the editing layer now is well-positioned as the category matures around it.

Developer adoption data reinforces the scale. Roughly 85% of developers now use AI coding tools, and 70% run two to four tools simultaneously, with Cursor handling editing while other tools take on complex reasoning tasks. That tool-stacking behaviour is significant: it means Cursor is not competing to be the only tool in a workflow, but to be the one developers open first. On code volume, 42% of committed code is now AI-contributed, which makes Cursor-generated output a material share of what enters production repositories across the industry.

The shift driving Cursor's position forward is agentic execution. Autonomous, multi-step task handling now dominates developer attention in 2026, displacing the autocomplete model that defined the previous generation of tools. Adoption is rising while trust in AI output accuracy is falling, with only 33% of developers saying they trust AI-generated code, down from 43% the previous year. A 51-point gap between adoption and trust is the structural condition Cursor operates inside. The numbers confirm the category is large and growing fast. They also confirm the quality problem is real.

Cursor against the field

Claude Code sits at the top of the satisfaction table: a 46% developer love score, $8B ARR as of May 2026, and an 80.8% score on SWE-bench Verified, the benchmark most teams now treat as the standard measure of autonomous coding performance. Those three numbers together describe a tool that developers not only adopt but actively prefer. Cursor's equivalent satisfaction score is 19%. The gap is not marginal. A product that holds the largest share of the AI-native IDE market and generates $4B in annualised revenue still trails its nearest competitor by 27 percentage points on the one metric that predicts long-term retention.

GitHub Copilot tells a different story about scale. With 4.7 million paid subscribers, it occupies the enterprise incumbent position, and its June 2026 shift to usage-based billing signals something specific: flat subscription pricing is no longer the right model when consumption patterns vary this widely across teams. That billing change is less a product update than an admission of monetisation maturity. Enterprises do not buy Copilot because it leads on benchmarks; they buy it because it lives inside the GitHub and Microsoft contracts they already run.

The February 2026 Composer 2 and parallel agents update from Cursor reads, in this context, as a direct response to Claude Code's lead on agentic execution. The competitive axis has moved. Autocomplete speed no longer differentiates; autonomous multi-step task quality does. Testing nine tools against the SWE-bench standard confirms that open-source BYOK tools such as Cline, pointed at the same underlying models, now match paid tools on the benchmark that matters.

Niche tools occupy a narrow but real segment of this market: developers who want granular control over model selection and execution cost, not a managed GUI. That segment is growing.

The structural issue underneath all of this: 70% of developers run two to four AI tools simultaneously. Cursor for editing, Claude Code for complex refactors, Copilot for inline completions on legacy codebases. Each tool adds capability. Each tool also adds a seam where output crosses from one context into another, unverified. Adoption scale and quality confidence are moving in opposite directions, and the gap between them is where problems compound.

The adoption-trust paradox

The numbers here are running in opposite directions, and that gap is the story.

92% of US developers use AI coding tools daily, yet trust in AI output accuracy sits at 33%, down from 43% the prior year. A 10-point collapse in 12 months, while adoption continues to climb. These two trendlines are not converging. They are running in parallel through 2026, and the gap between them is where production risk accumulates.

The volume figure makes this concrete. 42% of all committed code is now AI-contributed, and a significant portion of that code reaches production without thorough human review. Cursor's own Spring 2026 Developer Habits Report describes developers deploying AI-generated code without review as a signal of "growing confidence." Observers read the same behaviour differently: confidence is rising precisely as trust falls. That is not confidence. That is automation without verification, and the two are not the same thing.

The frustration developers name most often is not compilation failures or obvious runtime errors. It is code that looks correct while containing subtle defects, the kind a passing code review does not intercept. CodeRabbit's analysis of 470 open-source pull requests found AI-generated code carries 1.7 times more defects than human-written code. Copy-pasted code has nearly doubled since 2022, a pattern directly linked to AI-assisted workflows. Subtle errors in plausible-looking code are categorically harder to catch than obvious failures, and they are what teams are shipping.

The productivity calculus is also less favourable than headline adoption numbers suggest. METR's study of 16 experienced developers across 246 tasks found AI tools increased completion time by 19%, while those same developers predicted a 24% saving beforehand. Code churn has doubled, from 3.3% pre-AI to 7.1% in 2025. Time savings from generation are offset by debugging, verification, and rework. The net gain is real for routine tasks, but smaller and more variable than the adoption story implies.

Cursor's 19% developer love score against Claude Code's 46% sits inside this context. High output volume and high output quality are not equivalent, and that gap in satisfaction scores reflects exactly that distinction.

Gartner projects 40% of enterprise applications will embed AI agents by end of 2026, expanding the surface area where unverified, AI-generated behaviour reaches real users at scale. 92% of firms currently lack governance frameworks capable of controlling their own AI-generated code. The adoption curve has outpaced the oversight infrastructure built to manage it.

Cursor builds it. Who tests it?

Cursor's own documentation puts it plainly: "AI-generated code can look correct but be subtly wrong. It might follow existing patterns, compile, and pass tests you wrote, but still miss edge cases." The review process Cursor describes is entirely developer-facing: diffs, commit hygiene, peer review. What happens to the person, or the agent, navigating the shipped product is outside scope by design.

That boundary is not a criticism. It is a structural fact. Cursor's workflow ends at the commit. The browser is someone else's problem.

The question is whose.

Product, design, and growth teams are the teams who inherit AI-built flows after the commit lands. They have no native visibility into whether a registration form drops people at the address field, whether a task completion path resolves, or whether an information retrieval flow returns anything useful. Those are not code questions by the time they surface. They are experience questions, and they arrive as support tickets, drop-off rates, and delegated-access failures rather than as readable diffs.

The problem compounds when the actor navigating the product is not a human. Gartner projects 40% of enterprise apps will embed AI agents by end of 2026. Those agents are delegated to complete tasks: book, retrieve, submit, confirm. A human encountering a broken address form will read around it, try a different input, or abandon and return. An AI agent stops. There is no fallback instinct. The same broken path that a human navigates with mild frustration becomes a hard failure for an agent with a task to complete and no tolerance for ambiguity.

Current coverage of Cursor does not address this. Practitioner QA guides and tool comparisons frame the conversation around output velocity: how fast can a team generate test plans, write automation scripts, ship fixes. The question of whether Cursor-generated flows are actually navigable, by a real user or a delegated agent, in a live product, does not appear in any source in the market.

This is the gap Stunt Double addresses. The platform sends AI agents through products to simulate how real users and AI agents experience them, across discovery, task completion, information retrieval, and delegated access. Broken flows surface before they reach production. The commit is not the finish line.

What testing a Cursor-built product looks like in practice

A Stunt Double agent runs through the same flows a real user runs: discovery, information retrieval, task completion, and delegated access scenarios in sequence. This is not unit testing or static code review. It is a cast of AI agents moving through the product as actors would, surface by surface, input by input, and recording what actually happens at each step.

Predictive user behaviour analysis changes what product and growth teams receive at the end of a test cycle. Instead of an error log that documents what broke after a real user encountered the problem, the output surfaces where actors abandon or fail before that moment arrives. An actor stalls at the address form. An actor cannot retrieve a pricing figure from the information page. An actor completes three of four steps in a checkout flow and stops. These are concrete findings, not stack traces: a product team can locate the scene, examine the take, and act on it without translating from engineering output into product language.

Delegated access testing is the category that most existing QA frameworks have not caught up with. As AI agents complete tasks on behalf of users inside products, those products need to be tested by AI agents operating in delegated roles, not only by human testers clicking through a browser. A human tester cannot reliably simulate how an agent navigates ambiguous form states, handles unexpected permission prompts, or responds to flows that assume a human reading context. The agentic era requires agentic testing.

The findings Stunt Double produces are framed around what the actor did. Not what users think, not what users feel: what the actor did, recorded as a behavioural artefact the team can examine, prioritise, and fix. That framing matters because it removes speculation from the conversation between product, design, and engineering.

For enterprise teams building on Cursor, where 60% of Cursor's revenue already comes from enterprise buyers, the testing surface expands with every agentic commit. Coding speed has doubled year-over-year according to the Cursor Developer Habits Report, PRs are growing larger, and AI-generated code is surviving review at higher rates. At that velocity, automated experience testing is not a phase that happens before launch. It becomes part of the deployment cycle itself.

The short version

Cursor is real infrastructure. At $4B ARR, 25% market share, and the default IDE for multi-file agentic development, it sits at the centre of how software gets built in 2026. The adoption-trust gap is equally real: 42% of committed code is AI-contributed and often unverified, and Cursor's developer love score sits at 19% against Claude Code's 46%. Developers now spend 11.4 hours a week reviewing AI-generated code and only 9.8 hours writing new code. The competitive battle has shifted from code completion to autonomous agentic execution, and the data on what that shift costs in rework and verification is starting to accumulate. The velocity of what gets committed has outpaced the quality layer underneath it.

What follows from that gap is a practical problem for product, design, and growth teams: the IDE stops at commit. It cannot evaluate what the code does once it reaches real users, or what happens when delegated AI agents encounter the flows it built. That is a different surface, and it requires a different instrument.

Stunt Double runs AI agents through products to find what Cursor-built code does in practice, before real users or delegated agents encounter it. The evaluation happens from the user's side, not the developer's.

Conclusion

Cursor AI is a genuinely capable tool that raises the bar for AI-assisted development, but it is not a silver bullet. Its context-aware completions and conversational editing features can meaningfully accelerate your workflow. At the same time, its limitations around large codebases, occasional hallucinations, and team collaboration gaps deserve honest consideration before committing. The right question is not whether Cursor AI is impressive; it is whether it fits your specific context and working style.

Start with a focused trial on a real project, not a toy example. Pay attention to where it saves you time and where it creates friction. That hands-on experience will tell you more than any benchmark.

The best developers do not adopt every new tool. They adopt the right ones. Use this analysis as your starting point and let your own workflow guide the final verdict.