Como a Cursor melhora seu agente de IA: de guardrails a contexto dinâmico

A Cursor publicou um estudo detalhado sobre como desenvolve e aprimora continuamente seu agente de IA para programação. A conclusão principal: um único modelo de linguagem poderoso não basta. Mesmo os modelos mais avançados precisam de um bom "arcabouço" (harness): um sistema de prompts, ferramentas, gerenciamento de contexto e métricas de avaliação. O artigo não trata apenas de resultados, mas de metodologia: como a Cursor testa hipóteses, mede a qualidade e adapta a arquitetura às novas capacidades dos modelos.

A evolução da janela de contexto

Quando a Cursor desenvolveu seu primeiro agente de programação, no fim de 2024, os modelos de linguagem ainda não eram muito bons em escolher sozinhos o que incluir no contexto. Por isso, a equipe passou meses desenvolvendo guardrails: restrições e regras rígidas que encaminhavam o agente na direção certa.

A abordagem antiga era assim:

• Após cada edição, repassava ao agente os erros do linter e do type-checker
• Reescrevia os pedidos de arquivos se o agente solicitasse poucas linhas de código
• Limitava a quantidade de ferramentas que o agente podia chamar em um ciclo
• Fornecia muito contexto estático: estrutura de pastas, trechos e versões compactadas de arquivos

Era primitivo, mas funcionava. O modelo era fraco e precisava de direcionamento. Porém, com o rápido avanço das capacidades dos modelos, a Cursor foi abandonando os guardrails aos poucos.

A abordagem atual é bem diferente: o agente recebe o mínimo de contexto estático, basicamente informações do sistema operacional, o status do git e os arquivos atuais e vistos recentemente. Todo o resto ele solicita dinamicamente, conforme a necessidade. Ele mesmo procura os arquivos de que precisa na base de código, consulta a documentação e analisa erros em tempo real. É isso que significa um modelo amadurecer.

Como a qualidade real é medida

Determinar se uma melhoria realmente funciona é um problema nada trivial para um produto. A Cursor usa uma abordagem em dois níveis, combinando testes sintéticos e dados reais de usuários.

O primeiro nível são benchmarks públicos (como o CursorBench), que dão um retrato rápido da qualidade e permitem comparar resultados ao longo do tempo. Mas mesmo bons benchmarks refletem o uso real apenas de forma aproximada. Um agente pode ir muito bem em um teste de laboratório e falhar no trabalho de verdade.

Por isso, no segundo nível, a Cursor roda testes A/B com usuários reais, comparando várias variantes do harness ao mesmo tempo. É aqui que surgem as métricas que realmente importam:

• Latency: a rapidez com que o agente dá a primeira resposta
• Token efficiency: quantos tokens gastou em uma única solicitação
• Tool call count: quantas vezes recorreu a ferramentas
• Cache hit rate: com que frequência reaproveitou contexto em cache

Mas a métrica mais importante é o Keep Rate. Ele é a fatia do código que permanece na base de código uma semana ou um mês após a conclusão da tarefa. Se o usuário refaz com frequência o código gerado ou precisa corrigir erros manualmente, o Keep Rate cai. É um sinal: o agente não deu conta.

O que isso significa

A abordagem da Cursor mostra uma verdade importante: a qualidade de um agente de IA depende não só do modelo, mas da arquitetura em torno dele. Guardrails rígidos ajudam modelos fracos, mas os engessam. O contexto dinâmico libera o potencial dos melhores modelos, permitindo que explorem o problema por conta própria.

A principal conclusão: não fique esperando o modelo perfeito. Dedique tempo à arquitetura do harness e à capacidade de testar hipóteses rapidamente. Porque a qualidade de um agente não é definida pela velocidade de resposta nem pelo volume de tokens, e sim por o resultado do seu trabalho continuar no código com o passar do tempo.