Estudio: Cursor acelera el inicio del desarrollo, pero luego aumenta la deuda técnica del equipo

Investigación sobre Cursor revela un escenario desagradable para el mercado de codificación con IA: inicialmente la herramienta acelera el lanzamiento de código, pero esta ganancia es luego consumida por el crecimiento de la complejidad y la deuda técnica acumulada. Para los equipos esto es mala noticia no porque la IA sea inútil, sino porque la velocidad local fácilmente enmascara costos futuros.

Primer Impulso

Los autores de la investigación compararon 807 repositorios de código abierto donde identificaron signos de adopción de Cursor con 1.380 proyectos similares sin tal adopción. Utilizaron un enfoque de diferencias-en-diferencias y analizaron no las percepciones de los desarrolladores, sino la dinámica de commits, líneas de código y métricas de calidad antes y después de la adopción. Esto es importante: no se trata de una prueba de laboratorio en una única tarea, sino de un intento por entender cómo se comporta un asistente de IA en bases de código reales.

Al inicio el efecto se ve convincente. En el primer mes después de la implementación, el número de commits creció 55,4%, y el volumen de líneas añadidas — 281,3%. En el segundo mes el crecimiento se mantenía, pero era notablemente más débil: commits crecieron 14,5%, y líneas — 48,4%. Después de este punto, los investigadores ya no observaron ventaja sostenida. Es decir, Cursor realmente puede acelerar rápidamente la producción, pero esta aceleración no se convierte en una velocidad de desarrollo estable a distancia.

Costo de la Velocidad

Simultáneamente con la velocidad, la investigación registró crecimiento de problemas en la base de código. El número de advertencias de análisis estático después de la implementación de Cursor aumentó 29,7%, y la complejidad general del código — 40,7%. La densidad de líneas duplicadas no mostró un aumento significativo. La conclusión aquí es importante: no se trata solo ni principalmente de copiar-pegar, sino de que el sistema se vuelve más pesado, más enmarañado y más costoso de mantener.

Para un equipo esto normalmente significa varias cosas:

• revisión requiere pasar más tiempo en cambios grandes generados por IA
• pruebas y linters comienzan a detectar más problemas ya después de la generación, no antes
• decisiones arquitectónicas se toman demasiado económicamente y terminan rápidamente en main branch
• código localmente conveniente se lee peor y es más difícil de cambiar semanas después

Precisamente por eso los autores hablan de un ciclo automantenible. Cursor acelera el lanzamiento de código, la deuda técnica crece junto con él, y luego esta deuda comienza a ralentizar los cambios subsecuentes en la práctica. Si un equipo tiene revisión débil, refactorización rara y cobertura de pruebas insuficiente, las ganancias de las primeras semanas se transforman bastante rápido en una nueva fuente de ralentización. El cuello de botella se desplaza: escribir código se vuelve más fácil, pero entenderlo, verificarlo y simplificarlo — se vuelve más difícil.

Donde Hay Aclaraciones

Sin embargo, la investigación no puede leerse como un veredicto final. Los autores asumieron que un repositorio adoptó Cursor si archivos como .cursorrules o una carpeta .cursor aparecían en el historial. Esta es una señal proxy útil pero tosca. No muestra qué tan activamente el equipo realmente utilizó la herramienta, quién exactamente la usó, y si Cursor fue aplicado al desarrollo principal en lugar de arreglos menores o documentación. Y esto limita la fortaleza de la inferencia causal.

Hay una segunda aclaración: la calidad fue evaluada usando métricas de SonarQube, incluyendo advertencias de análisis estático y complejidad cognitiva. Estos indicadores son útiles, pero no miden toda la realidad de la ingeniería. Son peores para ver acoplamiento arquitectónico, propagación de lógica de dominio entre capas, y el costo real del mantenimiento del sistema. Por lo tanto, la conclusión honesta suena así: la investigación no prueba que cada commit de IA empeore el código, pero muestra con confianza un patrón inquietante a nivel de proyecto.

Qué Significa Esto

Para negocios y equipos de ingeniería, esto no es un argumento en contra de la codificación con IA como tal, sino una señal para reestructurar el proceso alrededor de ella. Si usa Cursor solo como un acelerador de generación, sin revisión más estricta, refactorización rápida y quality gates reforzadas, picos de velocidad a corto plazo se convierten fácilmente en deuda técnica. La lección principal aquí es simple: IA elimina fricción en la escritura de código, pero no elimina el costo de decisiones malas y no hace que el mantenimiento sea gratuito.