¿Cómo Cursor superó los límites de Git a gran escala

Cursor, el editor de código con IA, tuvo que resolver un verdadero problema de escalabilidad de Git para funcionar correctamente en bases de código muy grandes. Esto es lo que hicieron —y por qué interesa a todo desarrollador senior.

El caso concreto

Imaginen una base de código de varios millones de líneas: el tipo que se encuentra en grandes grupos tecnológicos, proyectos de código abierto maduros o monorepos de startups que han crecido rápidamente. Git comienza a tener problemas: git status tarda segundos, las operaciones cotidianas se vuelven frustrantes. Ahora añadan una herramienta de IA (Cursor) que debe entender el estado del repositorio en tiempo real para contextualizar sus sugerencias. El problema se vuelve crítico.

Es exactamente lo que Cursor se encontró — y The Register detalla cómo superaron los límites de escalabilidad de Git.

El problema de fondo: Git no está diseñado para la IA

Git fue creado por Linus Torvalds en 2005 para gestionar el núcleo de Linux: una base de código grande pero con un modelo de uso humano: desarrolladores que hacen commits, ramas y fusiones. Git no fue pensado para una herramienta de IA que lee el estado del repositorio docenas o cientos de veces por minuto para alimentar sus sugerencias en tiempo real.

Los cuellos de botella son conocidos:

• Índice de Git: el archivo .git/index se lee por completo en cada operación de estado, incluso para un solo archivo modificado.
• Almacén de objetos: la recuperación de objetos por hash no está optimizada para lecturas masivas y repetidas.
• Ganchos del sistema de archivos: en Windows y macOS, los observadores del sistema de archivos añaden latencia.

Lo que hizo Cursor: S3 como fuente de verdad, NVMe local para la latencia

El enfoque de Cursor, revelado por The Register, se basa en una arquitectura de dos niveles: S3 (almacenamiento de objetos en la nube) como fuente de verdad para el repositorio, y repositorios locales en NVMe (SSD de alto rendimiento) para el trabajo sensible a la latencia.

En concreto, en lugar de hacer que la IA trabaje directamente sobre el repositorio Git local con sus limitaciones de escalabilidad, Cursor mantiene una copia canónica en S3 y utiliza cachés locales en NVMe para las operaciones que requieren una respuesta rápida. La sincronización entre ambos niveles está optimizada para minimizar las lecturas completas del índice de Git.

Es el tipo de problema que los desarrolladores senior conocen bien: las abstracciones estándar funcionan hasta cierto punto, y luego hay que bajar al nivel inferior — aquí, replantearse por completo el modelo de almacenamiento en lugar de optimizar marginalmente las llamadas a git.

Por qué le interesa a todo el mundo

La solución de Cursor tiene implicaciones más allá de su herramienta:

• Monorepos: cualquier equipo que trabaje en un monorepo de tamaño significativo se enfrenta a estos problemas. La arquitectura S3 + NVMe local es transferible.
• Git LFS: resuelve el problema de los archivos binarios grandes, pero no la escalabilidad del índice. Es un problema abierto que Cursor ha sorteado de otra manera.
• Herramientas de IA sobre bases de código: todas las herramientas de análisis estático, revisión de código asistida o generación de código se encontrarán con este problema al crecer.