Estudio: Cursor acelera el arranque del desarrollo, pero después aumenta la deuda técnica del equipo

Un estudio sobre Cursor apunta a un escenario incómodo para el mercado del AI coding: primero la herramienta acelera la producción de código, pero luego la complejidad creciente y la deuda técnica acumulada se comen esa ventaja. Para los equipos es una mala noticia no porque la IA sea inútil, sino porque la velocidad local oculta con facilidad los costes futuros.

El impulso inicial

Los autores compararon 807 repositorios de código abierto con señales de adopción de Cursor con 1380 proyectos similares sin ella. Usaron un enfoque de diferencias en diferencias (difference-in-differences) y no miraron las sensaciones de los desarrolladores, sino la evolución de los commits, las líneas de código y las métricas de calidad antes y después de la adopción. Es un detalle importante: no se trata de una prueba de laboratorio con una sola tarea, sino de un intento de entender cómo se comporta un asistente de IA en bases de código reales.

Al principio, el efecto resulta convincente. En el primer mes tras la adopción, el número de commits aumentó un 55,4 % y el volumen de líneas añadidas, un 281,3 %. En el segundo mes el incremento se mantuvo, pero bastante más débil: los commits crecieron un 14,5 % y las líneas, un 48,4 %. Después, los investigadores ya no vieron una ventaja sostenida. Es decir, Cursor puede disparar rápidamente la producción, pero ese impulso no se traduce en una aceleración estable del desarrollo a largo plazo.

El precio de la velocidad

Junto con la velocidad, el estudio registró un aumento de los problemas en la base de código. Las advertencias del análisis estático subieron un 29,7 % tras la adopción de Cursor, y la complejidad general del código, un 40,7 %. La densidad de líneas duplicadas, en cambio, no mostró un salto significativo. La conclusión es importante: no se trata solo ni principalmente de copiar y pegar, sino de que el sistema se vuelve más pesado, más enrevesado y más caro de mantener.

Para un equipo, esto suele implicar varias cosas:

• la revisión exige más tiempo con cambios grandes generados por IA
• las pruebas y los linters detectan más problemas después de la generación, no antes
• las decisiones de arquitectura se toman con demasiada ligereza y llegan antes a la rama principal
• el código cómodo a nivel local se lee peor y cuesta más de cambiar pasadas unas semanas

Por eso los autores hablan de un ciclo que se retroalimenta. Cursor acelera la producción de código, la deuda técnica crece con él y luego esa deuda empieza a frenar en la práctica los cambios siguientes. Si un equipo tiene revisiones débiles, refactorizaciones poco frecuentes y una cobertura de pruebas insuficiente, la ganancia de las primeras semanas se convierte bastante rápido en una nueva fuente de lentitud. El cuello de botella se desplaza: escribir código es más fácil, pero entenderlo, verificarlo y simplificarlo es más difícil.

Dónde están las salvedades

El estudio no debe leerse como un veredicto definitivo. Los autores consideraron que un repositorio había adoptado Cursor si en su historial aparecían archivos como .cursorrules o una carpeta .cursor. Es un indicador indirecto útil, pero tosco. No muestra con qué intensidad usó realmente el equipo la herramienta, quién la usó ni si Cursor se empleó para el desarrollo principal y no para retoques menores o documentación. Esto limita la solidez de la conclusión causal.

Hay una segunda salvedad: la calidad se evaluó con métricas de SonarQube, incluidas las advertencias del análisis estático y la complejidad cognitiva. Son indicadores útiles, pero no miden toda la realidad de la ingeniería. Ven peor el acoplamiento arquitectónico, la dispersión de la lógica de dominio entre capas y el coste real de mantener el sistema. Por eso, la conclusión honesta es esta: el estudio no demuestra que cada commit de IA empeore el código, pero sí muestra con claridad un patrón preocupante a nivel de proyecto.

Qué significa

Para las empresas y los equipos de ingeniería, esto no es un argumento contra el AI coding en sí, sino una señal para reorganizar el proceso a su alrededor. Si Cursor se usa solo como acelerador de la generación, sin revisiones más estrictas, refactorizaciones rápidas y quality gates más fuertes, un breve estallido de velocidad se convierte fácilmente en deuda técnica. La lección principal es sencilla: la IA elimina fricción al escribir código, pero no anula el coste de las malas decisiones ni hace gratuito el mantenimiento.