Study: Cursor speeds up early development, but later adds to the team's technical debt

Research on Cursor reveals an unpleasant scenario for the AI coding market: initially the tool accelerates code release, but this gain is then consumed by growing complexity and accumulated technical debt. For teams this is bad news not because AI is useless, but because local speed easily masks future costs.

First Boost

The research authors compared 807 open source repositories where they identified signs of Cursor adoption with 1,380 similar projects without such adoption. They used a difference-in-differences approach and looked not at developer perceptions, but at the dynamics of commits, lines of code, and quality metrics before and after adoption. This is important: it's not about a laboratory 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 implementation, the number of commits grew by 55.4%, and the volume of added lines — by 281.3%. In the second month growth still held, but was noticeably weaker: commits grew by 14.5%, and lines — by 48.4%. After this point, researchers no longer observed sustained advantage. That is, Cursor can indeed quickly accelerate output, but this acceleration does not turn into stable development speedup over time.

Cost of Speed

Simultaneously with speed, the research registered growing problems in the codebase. The number of static analysis warnings after Cursor implementation increased by 29.7%, and overall code complexity — by 40.7%. The density of duplicate lines showed no significant spike. The conclusion here is important: it's not only and not so much about copy-paste, but about the system becoming heavier, more convoluted, and more expensive to maintain.

For a team this usually means several things:

• review requires spending more time on large AI-generated changes
• tests and linters start catching more problems already after generation, not before
• architectural decisions are made too cheaply and quickly end up in main branch
• locally convenient code reads worse and is harder to change weeks later

This is precisely why the authors speak of a self-sustaining cycle. Cursor accelerates code release, technical debt grows along with it, and then this debt begins to slow down subsequent changes in practice. If a team has weak review, rare refactoring, and insufficient test coverage, the gains of the first weeks fairly quickly turn into a new source of slowdown. The bottleneck shifts: writing code becomes easier, but understanding, checking, and simplifying it — becomes harder.

Where There Are Caveats

However, the research cannot be read as a final verdict. The authors assumed a repository adopted Cursor if files like .cursorrules or a .cursor folder appeared in the history. This is a useful but crude proxy signal. It doesn't show how actively the team actually used the tool, who exactly used it, and whether Cursor was applied to main development rather than minor fixes or documentation. And this limits the strength of causal inference.

There is a second caveat: quality was assessed using SonarQube metrics, including static analysis warnings and cognitive complexity. These indicators are useful, but they don't measure all engineering reality. They are worse at seeing architectural coupling, spreading domain logic across layers, and the real cost of system maintenance. Therefore, the honest conclusion sounds like this: the research doesn't prove that every AI commit makes code worse, but it confidently shows a troubling pattern at the project level.

What This Means

For business and engineering teams, this is not an argument against AI coding as such, but a signal to restructure the process around it. If you use Cursor only as a generation accelerator, without stricter review, fast refactoring, and reinforced quality gates, short-term speed spikes easily turn into technical debt. The main lesson here is simple: AI removes friction from code writing, but doesn't eliminate the cost of bad decisions and doesn't make maintenance free.