In the name of software quality assurance, AI coding assistants need new forms of self-discipline.

Academics from Carnegie Mellon propose this after examining the impact of adopting Cursor on open source projects. Their analysis, conducted in August 2025, was published in a paper in November and has been updated several times since (latest version: January 2026).

This analysis is part of a burgeoning literature. In particular, it follows a study involving Queen’s University (Canada) and the Nara Institute of Science and Technology (Japan). Hundreds of GitHub PRs generated by Claude were analyzed to determine their acceptance rate.

The experiment conducted at Carnegie Mellon went beyond this indicator. It focused on the "longitudinal" effects at the project level, supported by metrics of velocity and quality.

An analysis focused on Cursor and open source projects

The use of Cursor was considered exclusively in agentic mode. To determine if projects had adopted it in this form, researchers relied on the presence of .cursorrules configuration files in GitHub repositories. The date of the first commit affecting these configuration files indicates the probable start of adoption.

This resulted in a sample of 806 repos having adopted agentic Cursor between January 2024 and March 2025. A control group of 1380 repos with similar characteristics before adoption was associated.

In each group, at least 6 months of history before and after adoption is ensured. The number of commits and the number of lines added are collected monthly. Additionally, using a local SonarQube Community server, three quality indicators are collected:

Static analysis alerts (number of reliability, maintainability, and security issues)

Rate of duplicated lines in the codebase (SonarQube estimates this differently depending on the languages; a block is generally considered duplicated if it contains at least 10 consecutive declarations or at least 100 duplicated tokens)

Complexity of the codebase (level of code interpretability)

Gains in velocity... over the first two months

The adoption of Cursor results in, to use the terms employed, a "modestly significant" gain in velocity. At least if one refers to the volume of code produced: about 28.6% more lines. However, there is no net effect on the volume of commits.

In both cases, the gains are significant only in the two months following adoption (+281.3% lines the first month and +48.4% the second; +54.4% commits the first month and +14.5% the second).

Regarding quality, the volume of alerts increases on average by 30.3%. The complexity of the code, by 41.6%. There is no significant effect on duplicate lines. Unlike the velocity gains, these increases persist beyond the initial adoption period.

With an AI assistant, a more complex codebase

Across all the analyzed repositories, all other things being equal, an increase in development velocity does not produce a significant effect on the volume of alerts and code complexity.

The adoption of Cursor does not have a significant effect on the volume of alerts. When it increases, the size of the codebase is a major determinant. However, even when controlling for this dimension, the effect of Cursor on code complexity remains significant (+9% on average compared to similar projects not using the assistant).

On average, again all other things being equal, a doubling of code complexity is correlated with a 64.5% decrease in the number of lines. While a doubling of alerts is associated with a 50.3% reduction in the number of lines.

The adoption of Cursor leading to an average increase of 84% in lines added, the gain in velocity would be completely canceled by a tripling of complexity or a quintupling of alerts.

In summary, the adoption of Cursor results in an intrinsically more complex codebase, while the accumulation of alerts and complexity reduces velocity.

Results largely independent of the level of Cursor usage

The methodology adopted allows for detecting traces of Cursor, but not how projects use it. To verify if their findings applied equally to repos using Cursor actively as to those where engagement is minimal, the researchers devised a test. They identified, on each repo, the contributors who modified the .cursorrules files. And calculated their share of commits. The repos where this share was 80% or more were considered as "high adoption" of Cursor. A second set was formed by isolating the commits that modified these files post-adoption.

The results on the two sets support the general conclusions. On the repos where Cursor usage is higher, the accumulation of alerts and complexity is more significant. On these same repos, there is also an increase in velocity. This seems to indicate that abandoning Cursor after adoption cancels at least part of the velocity gains.

The analysis has another limitation: it does not account for the potential use of other AIs. Including tools that would not leave traces in the repos, such as the web version of ChatGPT. To identify these repos, the researchers examined the presence of certain elements; for example, .vscode folders. Among the 806 repos in the main group, 382 are concerned (345 with GitHub Copilot, 63 with Claude Code, 37 with Windsurf, etc.).

Between these repos and those likely only using Cursor, the main results persist. They are even amplified on the repos where prior use of AI tools is less probable.

The hypothesis of the "excitement-frustration-abandonment" cycle

The collapse of velocity gains after the first two months contrasts with productivity improvements that some studies report at the task level.

As seen, the increase in velocity is correlated with the increase in the size of the codebase... and therefore potentially technical debt. However, the negative effect of this debt likely does not fully explain the collapse in question, the researchers suggest. Indeed, as mentioned, complexity would need to triple—or alerts quintuple—to completely cancel the velocity gain, which seems unlikely.

Another plausible explanation lies in the "excitement-frustration-abandonment" cycle. The "new and shiny" effect of Cursor and Co. would encourage experimentation on tasks where AI excels, thus contributing to the increase in velocity. But when reaching scenarios where AI is more limited, frustration can occur. Associated with the cognitive load induced by verifying what the AI produces, it is likely to reduce the use of coding assistants, or even lead to their abandonment. At least within open source projects, which are the focal point of the analysis.

The researchers are clear on this point: their conclusions should be interpreted in the context of these projects. Which, compared to enterprise projects, have their specificities. Notably variable levels of collaboration that potentially reduce code reviews. And resource constraints that can limit testing and quality assurance regardless of development speed. Factors that likely amplify the excitement-frustration-abandonment cycle.

With or without AI, aligning quality assurance with velocity

The analysis reveals a nuanced relationship between code production velocity and its quality. If the absolute levels of alerts increase after the adoption of Cursor, the effect is largely attributable to the increase in velocity, which itself increases the size of the codebase, which itself increases technical debt.

If AI coding assistants allow for faster code production, they do not necessarily introduce more quality issues than within "non-AI" projects with the same velocity. Such a relationship advocates for scaling quality assurance according to velocity.

Code complexity deserves particular attention, as it is distinct from quality issues. It increases even when accounting for velocity dynamics. This tends to prove that the code generated by Cursor is intrinsically more complex than that written by humans*. The debt created can be all the more burdensome. Another potential reason for the very ephemeral velocity gain.

Considering a throttling mechanism

If the adoption of Cursor does not result in significant changes in line duplication, the phenomenon is somewhat more noticeable among "heavy" users of the assistant.

For scaling quality assurance, the researchers suggest, among other things, refactoring sprints triggered by reaching thresholds. They believe these thresholds could also guide the behavior of assistants. Which could, for example, start producing less once the codebase crosses a level of complexity and/or debt, forcing developers to optimize before continuing. In a less "aggressive" manner, they could also suggest tests and recommend refactoring paths.

* This discrepancy may be due to the training objectives of the underlying models. Specifically, a prioritization of passing tests over satisfying non-functional requirements like code readability.

Main illustration generated by AI

The post Software Quality: The Cumulative Effects of Coding Agents appeared first on Silicon.fr.

Au nom de l’assurance qualité logicielle, les assistants de codage IA ont besoin de nouvelles formes d’autodiscipline.

Des universitaires de Carnegie Mellon le postulent après avoir examiné l’impact de l’adoption de Cursor sur des projets open source. Leur analyse, conduite en août 2025, a fait l’objet d’un article publié en novembre et actualisé plusieurs fois depuis (dernière version : janvier 2026).

Cette analyse s’inscrit dans une littérature foisonnante. En particulier, dans la lignée d’une étude ayant associé l’Université Queen’s (Canada) et le Collège doctoral de sciences et techniques de Nara (Japon). Des centaines de PR GitHub générés par Claude avaient été analysés pour déteminer leur taux d’acceptation.

L’expérience menée à Carnegie Mellon est allée au-delà de cet indicateur. Elle a porté sur les effets « longitudinaux » au niveau des projets, à l’appui de métriques de vélocité et de qualité.

Une analyse centrée sur Cursor et les projets open source

L’usage de Cursor a été considéré exclusivement en mode agentique. Pour déterminer si des projets l’avaient adopté sous cette forme, les chercheurs se sont basés sur la présence de fichiers de configuration .cursorrules dans les dépôts GitHub. La date du premier commit touchant ces fichiers de configuration indique le début probable de l’adoption.

Il en a résulté un échantillon de 806 repos ayant adopté Cursor « agentique » entre janvier 2024 et mars 2025. Y a été associé un groupe de contrôle de 1380 repos qui présentaient des caractéristiques similaires avant adoption.

Dans chaque groupe, on s’assure de disposer d’au moins 6 mois d’historique avant et après adoption. On collecte, à intervalle mensuel, le nombre de commits et le nombre de lignes ajoutées. Ainsi que, à l’aide d’un serveur SonarQube Community local, trois indicateurs de qualité :

Alertes d’analyse statique (nombre de problèmes de fiabilité, de « maintenabilité » et de sécurité)

Taux de lignes dupliquées dans la codebase (SonarQube l’estime différemment selon les langages ; un bloc est généralement jugé ainsi s’il contient au moins 10 déclarations consécutives ou au moins 100 tokens doublonnés)

Complexité de la codebase (niveau d’interprétabilité du code)

Des gains en vélocité… sur les deux premiers mois

L’adoption de Cursor engendre, pour reprendre les termes employés, un gain de vélocité « modestement important ». En tout cas si on se réfère au volume de code produit : environ 28,6 % de lignes en plus. Il n’y a en revanche pas d’effet net sur le volume de commits.

Dans l’un et l’autre cas, les gains ne sont significatifs que dans les deux mois suivant l’adoption (+ 281,3 % de lignes le premier mois et + 48,4 % le second ; + 54,4 % de commits le premier mois et + 14,5 % le second).

Sur l’aspect qualité, le volume d’alertes augmente en moyenne de 30,3 %. La complexité du code, de 41,6 %. Il n’y a pas d’effet significatif sur les lignes en double. Au contraire des gains de vélocité, ces hausses persistent au-delà de la période initiale d’adoption.

À assistant IA, codebase plus complexe

Sur l’ensemble des dépôts analysés, toutes choses étant égales par ailleurs, une augmentation de la vélocité de développement ne produit pas un effet significatif sur le volume d’alertes et la complexité du code.

L’adoption de Cursor n’a pas un effet significatif sur le volume d’alertes. Lorsque celui-ci augmente, la taille de la codebase en est un déterminant majeur. Cependant, même en contrôlant cette dimension, l’effet de Cursor sur la complexité du code demeure important (+ 9 % en moyenne par rapport à des projets aux caractéristiques similaires qui n’utilisent pas l’assistant).

En moyenne, là aussi toutes choses étant égales par ailleurs, un doublement de la complexité du code est corrélé à une baisse de 64,5 % du nombre de lignes. Tandis qu’un doublement des alertes est associé à une réduction de 50,3 % du nombre de lignes.

L’adoption de Cursor entraînant une augmentation moyenne de 84 % des lignes ajoutées, le gain en vélocité serait complètement annulé par un triplement de la complexité ou par un quintuplement des alertes.

Pour résumer, l’adoption de Cursor engendre une codebase intrinsèquement plus complexe, tandis que l’accumulation d’alertes et de complexité réduit la vélocité.

Des résultats globalement indépendants du niveau d’utilisation de Cursor

La méthodologie adoptée permet de détecter les traces de Cursor, mais pas la manière dont les projets s’en servent. Pour vérifier si leurs constats s’appliquaient autant aux repos utilisant Cursor de manière active qu’à ceux où l’engagement est minimal, les chercheurs ont élaboré un test. Ils ont identifié, sur chaque repo, les contributeurs ayant modifié les fichiers .cursorrules. Et calculé leur part de commits. Les repos où cette part était supérieure ou égale à 80 % ont été considérés comme « à forte adoption » de Cursor. Un deuxième ensemble a été constitué en isolant les commits ayant modifié ces fichiers post-adoption.

Les résultats sur les deux ensembles accréditent les conclusions générales. Sur les repos où l’usage de Cursor est plus élevé, l’accumulation des alertes et de la complexité est plus importante. Sur ces mêmes repos apparaît également une augmentation de vélocité. Ce qui semble indiquer que l’abandon de Cursor après adoption annule au moins une partie des gains de vélocité.

L’analyse a une autre limite : ellle ne tient pas compte de l’éventuel usage d’autres IA. Y compris des outils qui ne laisseraient pas de traces dans les repos, comme la version web de ChatGPT. Pour identifier ces repos, les chercheurs ont examiné la présence de certains éléments ; par exemple de dossiers .vscode. Sur les 806 repos du groupe principal, 382 sont concernés (345 avec GitHub Copilot, 63 avec Claude Code, 37 avec Windsurf, etc.).

Entre ces repos et ceux n’ayant vraisemblablement eu recours qu’à Cursor, les principaux résultats persistent. Il sont même amplifiés sur les repos où l’usage antérieur d’outils IA est moins probable.

L’hypothèse du cycle « excitation-frustration-abandon »

L’effondrement des gains de vélocité après les deux premiers mois contraste avec les améliorations de productivité dont certaines études témoignent au niveau des tâches.

Comme on l’a vu, l’accroissement de la vélocité est corrélé à l’accroissement de la taille de la codebase… et donc potentiellement de la dette technique. L’effet négatif de cette dette ne suffit toutefois sans doute pas à expliquer l’effondrement en question, suggèrent les chercheurs. Il faudrait effectivement, comme susmentionné, que la complexité triple – ou que les alertes quintuplent – pour annuler complètement le gain de vélocité, ce qui semble peu probable.

Une autre explication plausible réside dans le cycle « excitation-frustration-abandon ». L’effet « tout beau, tout neuf » de Cursor et Cie pousserait à expérimenter sur les tâches où l’IA excelle, contribuant ainsi à la hausse de la vélocité. Mais lorsqu’on arrive sur des scénarios où l’IA est plus limitée, peut survenir de la frustration. Associée à la charge cognitive qu’induit la vérification de ce que produit l’IA, elle est susceptible de réduire l’usage des assistants de codage, voire d’en entraîner l’abandon. En tout cas au sein des projets open source, qui sont le point focal de l’analyse.

Les chercheurs sont formels à ce sujet : il faut interpréter leurs conclusions dans le contexte de ces projets. Qui, par rapport aux projets d’entreprise, ont leurs spécificités. Notamment des niveaux de collaboration variables qui réduisent potentiellement les revues de code. Et des contraintes de ressources qui peuvent limiter les tests et l’assurance qualité indépendamment de la vitesse de développement. Des facteurs qui amplifient probablement le cycle excitation-frustration-abandon.

Avec ou sans IA, aligner l’assurance qualité sur la vélocité

L’analyse révèle une relation nuancée la vélocité de production du code et sa qualité. Si les niveaux absolus d’alertes augmentent après l’adoption de Cursor, l’effet est en grande partie attribuable à l’accroissement de la vélocité, qui elle-même accroît la taille de la codebase, qui elle-même accroît la dette technique.

Si les assistants IA de codage permettent de produire du code plus rapidement, ils n’introduisent pas forcément davantage de problèmes de qualité qu’au sein des projets « sans IA » ayant la même vélocité. Une telle relation plaide pour un passage à l’échelle de l’assurance qualité en fonction de la vélocité.

La complexité du code mérite une attention particulière, en ce qu’elle est distincte des problèmes de qualité. Elle augmente même en tenant compte des dynamiques de vélocité. Ce qui tend à prouver que le code que génère Cursor est intrinsèquement plus complexe que celui qu’écrit l’humain*. La dette créée peut en être d’autant plus lourde. Une autre raison potentielle du gain très éphémère de vélocité.

Envisager un mécanisme de bridage

Si l’adoption de Cursor n’engendre pas de changements importants sur la duplication des lignes, le phénomène est un peu plus net chez les « gros » utilisateurs de l’assistant.

Pour le passage à l’échelle de l’assurance qualité, les chercheurs suggèrent notamment des sprints de refactoring déclenchés par l’atteinte de seuils. Ils estiment que ces seuils pourraient aussi guider le comportement des assistants. Lesquels pourraient, par exemple, se mettre à produire moins dès lors que la codebase franchirait un niveau de complexité et/ou de dette, forçant les développeurs à optimiser avant de continuer. De manière moins « agressive », ils pourraient aussi suggérer des tests et recommander des pistes de refactoring.

* Cet écart tient peut-être aux objectifs d’entraînement des modèles sous-jacents. En l’occurrence, une priorisation de la réussite aux tests par rapport à la satisfaction des exigences non fonctionnelles comme la lisibilité du code.

Illustration principale générée par IA

The post Qualité logicielle : les effets cumulés des agents de codage appeared first on Silicon.fr.