Como o Cursor contornou as limitações do Git em grande escala

Cursor, o editor de código com IA, teve que resolver um verdadeiro problema de escalabilidade do Git para funcionar corretamente em bases de código muito grandes. Veja o que eles fizeram — e por que isso interessa a todo dev sênior.

O caso concreto

Imagine uma base de código com milhões de linhas - do tipo que encontramos em grandes grupos de tecnologia, projetos open source maduros ou mono-repos de startups que cresceram rapidamente. O Git começa a apresentar dificuldades: git status leva segundos, operações comuns tornam-se frustrantes. Agora, adicione uma ferramenta de IA (Cursor) que precisa entender o estado do repositório em tempo real para contextualizar suas sugestões. O problema torna-se crítico.

É exatamente isso que o Cursor enfrentou - e o The Register detalha como eles contornaram os limites de escalabilidade do Git.

O problema de fundo: o Git não foi feito para IA

O Git foi criado por Linus Torvalds em 2005 para gerenciar o núcleo do Linux - uma base de código grande, mas com um modelo de uso humano: desenvolvedores que fazem commits, criam branches, fazem merge. O Git não foi projetado para uma ferramenta de IA que lê o estado do repositório dezenas ou centenas de vezes por minuto para alimentar suas sugestões em tempo real.

Os gargalos são conhecidos:

• Índice do Git: o arquivo .git/index é lido inteiramente a cada operação de status, mesmo para um único arquivo modificado.
• Armazenamento de objetos: a recuperação de objetos por hash não é otimizada para leituras massivas e repetidas.
• Hooks do sistema de arquivos: no Windows e macOS, os watchers do sistema de arquivos adicionam latência.

O que o Cursor fez: S3 como fonte de verdade, NVMe local para latência

A abordagem do Cursor revelada pelo The Register baseia-se em uma arquitetura de dois níveis: S3 (armazenamento de objetos na nuvem) como fonte de verdade para o repositório, e repositórios locais em NVMe (SSDs de alta performance) para o trabalho sensível à latência.

Concretamente, em vez de fazer a IA trabalhar diretamente no repositório Git local com suas limitações de escalabilidade, o Cursor mantém uma cópia canônica no S3 e usa caches NVMe locais para as operações que exigem resposta rápida. A sincronização entre os dois níveis é otimizada para minimizar as leituras completas do índice do Git.

Esse é o tipo de problema que desenvolvedores seniores conhecem bem: as abstrações padrão funcionam até certo ponto, depois é necessário descer ao nível inferior - aqui, repensar completamente o modelo de armazenamento em vez de otimizar marginalmente as chamadas git.

Por que isso interessa a todos

A solução do Cursor tem implicações além de sua ferramenta:

• Mono-repos: qualquer equipe que trabalha em um mono-repo de tamanho significativo enfrenta esses problemas. A arquitetura S3 + NVMe local é transponível.
• Git LFS: resolve o problema de arquivos binários grandes, mas não a escalabilidade do índice. É um problema em aberto que o Cursor contornou de outra forma.
• Ferramentas de IA em bases de código: todas as ferramentas de análise estática, revisão de código assistida ou geração de código enfrentarão esse problema ao crescer.