Como continuação do nosso post original sobre problemas, aqui estão mais alguns dos problemas que consideramos mais importantes para a próxima fase da programação com IA.

#Previsão da próxima ação

Cursor vem com o Copilot++, uma versão mais inteligente do copilot que prevê sua próxima edição. Podemos levar essa ideia ao seu limite natural?

Ao programar, você não faz apenas edições de baixa entropia. Em todo o editor, você realiza toques de tecla, cliques, ações de baixa entropia. Conseguimos criar um modelo para prever cada uma delas com baixa latência?

Para começar, estendemos o Copilot++ para prever sua próxima posição. Combine isso com a previsão da próxima edição e o modelo pode executar uma sequência de mudanças de baixa entropia:

Estamos trabalhando para prever o próximo arquivo para o qual você irá se mover. O próximo comando de terminal que você irá executar. A próxima edição, condicionada aos seus comandos anteriores no terminal! Um modelo de previsão da próxima ação.

Além disso, o modelo deve apresentar a informação no momento em que você precisa dela. Seja o trecho certo de código ou de documentação.

O Cursor deve parecer uma extensão da sua vontade. No momento em que você pensa em uma mudança, o modelo de linguagem requer intenção mínima para executá-la instantaneamente.

#Direções promissoras

• Pesquisa fundamental sobre previsão de ações em toda a base de código.

• Continuação do pré-treinamento e pós-treinamento em modelos de código com ~5–13B de parâmetros ativos (para previsões de baixa latência limitadas pelo prefill).

• Truques adicionais de inferência semelhantes a Speculative Edits

UX inteligente para apresentar “ações” de maneira não intrusiva. (Como sugerir o próximo arquivo para o qual o usuário deve ir? Ou o próximo local fora da área de visualização atual?)

#Edições perfeitas

Podemos aumentar os recursos de computação na etapa de inferência para produzir edições maiores e de maior qualidade? Como compensar o aumento de latência?

Pode ser necessário realizar a edição em segundo plano, iniciando uma tarefa na qual você possa confiar que será executada por modelos inteligentes.

Vamos precisar de modelos com fortes habilidades de uso de ferramentas específicas para edição, contexto mais inteligente em toda a base de código e raciocínio de longo prazo aprimorado.

E como podemos tornar a geração de código assíncrona sem quebrar o fluxo? Isso soa como um oximoro, mas acreditamos que pesquisas engenhosas em capacidades de modelo e UX podem tornar isso possível.

#Pseudocódigo alucinado

Os usuários poderão escrever pseudocódigo que descreve a mudança desejada. Em seguida, podemos confiar no Cursor para transformar esse pseudocódigo em uma mudança completa, em segundo plano.

#Edições em vários arquivos

Cmd-k já é fantástico, mas e se você pudesse pedir uma alteração genérica em todo o seu repositório de código? Em particular, uma que cobrisse com precisão vários arquivos?

#Direções promissoras

• Ampliar a capacidade de computação durante a inferência. Sabemos que modelos de recompensa e rejection sampling trarão melhorias rápidas e fáceis, mas até onde conseguimos chegar?

• Modelos de raciocínio superiores (gpt-5, claude-4, gemini 2.0)

• Executar múltiplas cópias de servidores de linguagem/sistemas de arquivos para um determinado espaço de trabalho de usuário. Isso exigirá uso de ferramentas pelo modelo e reprodução remota de ambientes de execução (runtime).

• Treinar/melhorar o desempenho do modelo em trajetórias de agentes

• Experimentação significativa de UX para edições assíncronas no fluxo

#Contexto ideal

Pode haver milhões de tokens de documentação, dezenas de milhões de tokens de código-fonte, mais dezenas de milhões de tokens de histórico de commits — todos potencialmente úteis para resolver uma única consulta.

Sem falar nos pixels da sua UI, logs em produção e em localhost, mensagens no Slack, etc.

Acreditamos que os melhores sistemas de código vão usar uma combinação de recuperação, recorrência e atenção de longo contexto para ingerir todas essas informações.

Enfatizamos sistemas porque, no curto prazo, isso pode ser um conjunto de modelos e infraestrutura que formam um mecanismo de contexto infinito para código. No longo prazo, esperamos que isso esteja embutido na arquitetura.

Estamos especialmente animados ao pensar de forma criativa sobre o futuro da recuperação. Indo além de embeddings, qual é o melhor desempenho possível dada a primitiva de uma etapa cara de indexação e uma etapa barata de consulta (sublinear no tamanho do corpus)?

Talvez isso se pareça com alguma variante de transformer memory as a differentiable search index. Talvez seja algo completamente diferente. É uma direção de pesquisa ainda pouco explorada.

#Contexto multi-hop

Na minha codebase, quero calcular um diff entre duas strings. Com embeddings, eu obtenho o seguinte chunk:

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel,
): string {
  //...
}

Para atender à consulta original, preciso determinar como criar um ITextModel a partir de uma string. Esta é uma consulta que exige dois saltos para ser resolvida.

As perguntas e consultas mais difíceis em uma base de código exigem vários saltos. A recuperação básica só funciona para um único salto.

#Caminhos promissores

• Embeddings e rerankers especializados/otimizados para codebases.

• Treinar embedders multi-hop. Dada uma consulta e o código relevante encontrado até agora, determinar qual é o próximo trecho de código para o qual devemos avançar.

• Estratégias inteligentes de prefix-caching e, talvez, máscaras de atenção personalizadas mais adequadas para codebases.

• Pesquisa inédita sobre recuperação em nível de codebase.

• Ensinar um modelo a aprender uma codebase em seus próprios pesos, de forma semelhante a transformers usados como índice de busca.

#Detecção de bugs e depuração

Os sistemas atuais de detecção de bugs têm dificuldade de calibração e de entendimento suficiente da base de código.

Os modelos são inteligentes o bastante para identificar bugs corretamente, mas sofrem com muitos falsos positivos. Identificar os bugs mais difíceis exige um entendimento mais profundo da base de código. E um código que parece problemático pode ser inofensivo quando se enxerga o quadro maior.

Uma forma de isso se manifestar é uma experiência de revisão de código muito melhor usando modelos de linguagem:

#Detectando bugs na revisão por IA

O benefício da “revisão por IA” é que o usuário é mais tolerante a falsos positivos, já que está solicitando uma revisão. A desvantagem é que isso requer mudar o comportamento do usuário.

#Linting com IA

A melhor forma de detectar bugs é ter um linter sempre ativo que encontra seus bugs em segundo plano. Ele precisa usar um modelo mais barato e mais rápido do que o da revisão com IA, já que teria que rodar várias vezes por minuto. Também precisa ser ajustado para ter uma taxa de falsos positivos mais baixa.

#Depuração mais inteligente

Talvez ainda mais impressionante do que a detecção de bugs seja a depuração de problemas difíceis.

Precisaremos ir além da análise estática baseada em LLMs. Por exemplo, criamos um pacote cursor/debug. Quando injetado no seu código, ele monitora informações de tempo de execução.

Em segundo plano, podemos até usá‑lo para monitorar estados adicionais de variáveis (semelhante à depuração com prints, com saídas relevantes encaminhadas para o contexto do Cursor).

#Caminhos promissores

• Curadoria inteligente de conjuntos de dados (provavelmente dados sintéticos) e RL em modelos de código de ponta para melhorar a calibração.

• Rastrear informações relevantes de outras superfícies (como o navegador ou um terminal não integrado ao Cursor).

• Melhorar o desempenho de modelos de ponta no uso de ferramentas específicas de depuração e encadeamentos de ferramentas.

• Contexto infinito e compreensão quase perfeita da base de código.

• Expandir o escopo da nossa biblioteca cursor/debug para rastrear todas as informações úteis de estado do programa.

Se você se interessar por qualquer um desses desafios, entre em contato em hiring@cursor.com