Study: Cursor speeds up the start of development, then piles technical debt onto teams

A study of Cursor points to an uncomfortable scenario for the AI coding market: the tool first speeds up code output, but then growing complexity and accumulated technical debt eat the gain. For teams, this is bad news not because AI is useless, but because local speed easily masks future costs.

The initial boost

The authors compared 807 open source repositories showing signs of Cursor adoption with 1,380 similar projects without it. They used a difference-in-differences approach and looked not at developers' impressions but at the dynamics of commits, lines of code and quality metrics before and after adoption. This matters: it is not a lab test on a single task, but an attempt to understand how an AI assistant behaves in live codebases.

At the start, the effect looks convincing. In the first month after adoption, the number of commits rose by 55.4% and the volume of added lines by 281.3%. In the second month the gain persisted but was noticeably weaker: commits grew by 14.5% and lines by 48.4%. After that, the researchers found no lasting advantage. In other words, Cursor can indeed quickly boost output, but that boost does not turn into a stable speedup of development over the long run.

The price of speed

Alongside the speed, the study recorded growing problems in the codebase. The number of static analysis warnings after Cursor adoption increased by 29.7%, and overall code complexity by 40.7%. Code duplication density, however, showed no significant jump. The conclusion here is important: it is not only, or even mainly, about copy-paste, but about the system becoming heavier, more tangled and more expensive to maintain.

For a team, this usually means several things:

• review takes more time on large AI-generated changes
• tests and linters catch more problems after generation rather than before it
• architectural decisions are made too cheaply and reach the main branch faster
• code that is locally convenient is harder to read and harder to change a few weeks later

This is why the authors describe a self-reinforcing cycle. Cursor speeds up code output, technical debt grows with it, and then that debt starts slowing down subsequent changes in practice. If a team has weak reviews, infrequent refactoring and insufficient test coverage, the gain of the first weeks fairly quickly becomes a new source of slowdown. The bottleneck shifts: writing code gets easier, while understanding, verifying and simplifying it gets harder.

Where the caveats lie

The study should not be read as a final verdict. The authors counted a repository as having adopted Cursor if files such as .cursorrules or a .cursor folder appeared in its history. This is a useful but crude proxy signal. It does not show how actively the team really used the tool, who exactly used it, or whether Cursor was used for core development rather than minor edits or documentation. That limits the strength of any causal conclusion.

There is a second caveat: quality was assessed with SonarQube metrics, including static analysis warnings and cognitive complexity. These indicators are useful, but they do not capture all of engineering reality. They are worse at seeing architectural coupling, domain logic spreading across layers, and the real cost of maintaining a system. So the honest conclusion is this: the study does not prove that every AI commit makes code worse, but it confidently shows a worrying pattern at the project level.

What this means

For businesses and engineering teams, this is not an argument against AI coding as such, but a signal to rebuild the process around it. If Cursor is used only as a generation accelerator, without stricter review, fast refactoring and stronger quality gates, a short burst of speed easily turns into technical debt. The main lesson is simple: AI removes friction from writing code, but it does not cancel the cost of bad decisions and does not make maintenance free.