🤖 AI

Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects

This study employs a difference-in-differences design to demonstrate that while adopting the Cursor AI assistant significantly boosts short-term development velocity in open-source projects, it simultaneously induces a persistent rise in code complexity and static analysis warnings that ultimately drives long-term velocity slowdowns.

Original authors: Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner, Bogdan Vasilescu

Published 2026-01-27

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner, Bogdan Vasilescu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a team of builders constructing a massive, complex city (your software project). For years, they've been laying bricks by hand, one by one. Then, a new machine arrives called Cursor. It's a super-powered robot assistant that can not only lay bricks but also design entire neighborhoods, order materials, and even fix mistakes while the builders watch.

The builders are thrilled. They claim the robot makes them 10 times faster. But this paper asks a critical question: Is the city actually better, or are we just building it faster and making a bigger mess?

Here is what the researchers found, using a "time-travel" style comparison of software projects that started using Cursor versus those that didn't.

1. The Initial Rush: The "Sugar High"

When the builders first turned on the robot, the city exploded with activity.

The Result: In the first month, the team added 28% more code (bricks) than usual. It felt like a miracle.
The Catch: This speed boost was a sugar high. It lasted only about two months. After that, the building speed slowed back down to normal. The robot didn't make them permanently faster; it just gave them a short burst of energy.

2. The Hidden Cost: The "Messy Basement"

While the builders were rushing to lay bricks, they weren't paying attention to the quality of the work. The robot was great at speed, but it was messy.

The Result: The researchers found that after adopting the robot, the projects had 30% more "warnings" (like a mechanic's check engine light) and 41% more complexity (the blueprints became confusing and tangled).
The Analogy: Imagine the robot is so eager to build that it puts bricks in weird places, forgets to seal the windows, and builds staircases that lead nowhere. The building goes up fast, but the basement is a disaster zone full of tripping hazards and leaks.

3. The Vicious Cycle: Speed Kills Future Speed

This is the most important part of the story. The mess created by the robot didn't just sit there; it started to slow the builders down later on.

The Mechanism: Because the code became so complex and full of errors (the "technical debt"), the human builders had to spend all their time fixing the robot's mistakes instead of building new things.
The Math: The researchers calculated that the speed boost from the robot was completely wiped out by the time it took to clean up the mess. To cancel out the robot's speed boost, you'd need a massive amount of errors (about 5 times more warnings or 3 times more complexity). Since the robot did create that much mess, the net result was no long-term speed gain.

4. Why Did the Builders Stop Using It?

The researchers noticed a pattern: The builders got excited, then frustrated, and then stopped using the robot as much.

The Cycle:
1. Excitement: "Wow, look how fast we are!"
2. Frustration: "Wait, why is this code so confusing? Why did the robot break this feature?"
3. Abandonment: "This robot is more trouble than it's worth."
Because the builders were working on open-source projects (voluntary, like a community garden), they could easily quit using the robot when it got annoying. In a corporate job, they might be forced to keep using it, but the mess would still be there.

The Bottom Line

The paper concludes that Cursor is a speed trap.

It gives you a massive, temporary boost in how much you can produce, but it leaves behind a trail of complexity and errors that eventually slows you down even more than if you hadn't used it at all.

The Lesson: If you want to use these AI robots, you can't just let them run wild. You need to build a "quality control" team that grows alongside the robot. You can't just measure success by how many bricks are laid; you have to measure how many of those bricks are actually holding the building together. Without that, you are just building a skyscraper on a foundation of quicksand.

Technical Summary: Speed at the Cost of Quality

Problem Statement

While Large Language Models (LLMs) and LLM agent assistants (e.g., Cursor) are widely reported to significantly increase developer productivity, empirical evidence regarding their long-term impact on software quality and sustained development velocity is lacking. Prior research has largely focused on code completion tools (like early GitHub Copilot) or controlled experiments, which may not generalize to modern agentic tools that autonomously navigate codebases, perform multi-file refactorings, and execute commands. There is a critical gap in understanding whether the initial velocity gains from adopting agentic AI tools are sustainable or if they lead to long-term degradation in code quality and subsequent velocity slowdowns due to accumulated technical debt.

Methodology

The authors employ a rigorous quasi-experimental design to estimate the causal effects of adopting the LLM agent assistant Cursor on open-source GitHub projects.

Data Collection and Identification

Treatment Group: The study identifies 806 repositories that adopted the modern Cursor client. Adoption is proxied by the first commit introducing .cursorrules configuration files or .cursor folders, which signal the use of Cursor's multi-file editing and agentic capabilities. The adoption period spans from August 2024 to March 2025.
Control Group: A matched control group of 1,380 repositories that never adopted Cursor during the observation period was constructed using propensity score matching. The matching model accounts for dynamic repository characteristics (activity levels, contributor counts, development patterns) over the six months preceding potential adoption, ensuring comparable trajectories between treated and control groups.
Observation Period: Monthly data was collected from January 2024 to August 2025.

Causal Inference Strategy

Difference-in-Differences (DiD): The study utilizes a staggered adoption DiD design with the Borusyak et al. [29] imputation estimator. This modern estimator is chosen to avoid biases associated with traditional two-way fixed effects (TWFE) models in staggered settings. It compares outcome changes in the treatment group against the control group while controlling for repository-specific and time-specific fixed effects.
Dynamic Panel GMM: To investigate temporal interactions between velocity and quality, the authors use Generalized Method of Moments (GMM) models (specifically Arellano-Bond). This allows for the testing of bidirectional causality and endogeneity, examining how changes in code quality affect future velocity and vice versa.

Metrics

Development Velocity: Measured by the number of commits and lines added per month.
Code Quality (Technical Debt): Measured via static analysis tools (SonarQube) focusing on:
- Static Analysis Warnings: Reliability, maintainability, and security issues.
- Code Complexity: Cognitive complexity.
- Duplicate Line Density: Percentage of duplicated code.

Key Results

1. Transient Velocity Gains

The adoption of Cursor leads to a statistically significant but transient increase in development velocity.

Magnitude: In the first month post-adoption, lines added increased by approximately 281.3%, and commits increased by 55.4%.
Duration: These gains are short-lived. By the third month, the velocity increase dissipates, returning to baseline levels. The average treatment effect (ATT) across the entire post-adoption period shows a modest 28.6% increase in lines added, but this is driven entirely by the initial spike.

2. Persistent Quality Degradation

In contrast to the transient velocity gains, the adoption of Cursor results in sustained and persistent increases in technical debt.

Static Analysis Warnings: Increased by 30.3% post-adoption.
Code Complexity: Increased by 41.6% post-adoption.
Persistence: Unlike velocity, these negative quality metrics do not revert to baseline; they remain elevated throughout the observation period.
Duplicate Lines: No statistically significant change was observed in the aggregate sample, though robustness checks suggest potential increases in high-adoption subsets.

3. Velocity-Quality Feedback Loop

The GMM analysis reveals a self-reinforcing cycle:

Velocity $\to$ Debt: While increased velocity initially drives codebase size (which correlates with debt), the GMM models show that accumulated technical debt (warnings and complexity) significantly reduces future development velocity.
Quantitative Impact: The models suggest that the initial velocity gain from Cursor adoption would be completely cancelled out by a roughly 5x increase in static analysis warnings or a 3x increase in code complexity.
Inherent Complexity: Even when controlling for velocity dynamics, Cursor adoption independently leads to a 9% baseline increase in code complexity, suggesting that AI-generated code in this context is inherently more complex than human-written code.

4. Robustness Checks

The findings hold across various robustness checks:

High-Confidence Adoption: Effects are amplified in repositories where contributors actively modified Cursor configuration files, suggesting the results are not spurious correlations.
Activity Levels: The persistence of quality degradation holds even in very active repositories.
Alternative AI Tools: Controlling for the potential use of other AI tools (e.g., Copilot, Claude Code) weakens the estimated effect size slightly but does not alter the main conclusions.

Significance and Contributions

The paper claims the following significance:

First Large-Scale Causal Evidence: This is the first study to use rigorous causal inference (DiD and GMM) to evaluate the impact of LLM agent assistants (specifically Cursor) on real-world, project-level development velocity and code quality.
Challenging the Optimism-Pessimism Binary: The results challenge both unbridled optimism (that AI tools permanently boost productivity) and categorical pessimism (that AI tools immediately degrade quality). Instead, the study identifies a complex temporal dynamic: a short-term velocity surge followed by a long-term quality decline that eventually erodes the initial productivity gains.
Identification of a Bottleneck: The study identifies quality assurance as a major bottleneck for early adopters. The "speed at the cost of quality" phenomenon creates a ratchet effect where technical debt accumulation dampens future velocity.
Design Implications: The authors argue that current AI coding tools are "generation-first," treating quality as an afterthought. They call for a shift in tool design where quality assurance is a "first-class citizen," potentially requiring tools that self-throttle or proactively manage complexity to ensure long-term project sustainability.
Contextual Nuance: The findings highlight that the observed patterns (excitement-abandonment cycles, lack of systematic review) may be specific to open-source contexts and may differ in enterprise settings with mandatory quality processes.

The paper concludes that realizing the promise of AI-assisted development requires not just adopting new tools, but fundamentally adapting development workflows to scale quality assurance with AI-driven velocity.