Als Fortsetzung unseres ursprünglichen Beitrags zu Problemen sind hier einige weitere Probleme, die unserer Meinung nach für die nächste Phase der KI-Programmierung am wichtigsten sind.

#Vorhersage der nächsten Aktion

Cursor wird mit Copilot++ ausgeliefert, einer intelligenteren Version von Copilot, die deine nächste Bearbeitung vorhersagt. Können wir diese Idee konsequent zu Ende denken?

Beim Programmieren nimmst du nicht nur stark vorhersehbare Bearbeitungen vor. Im gesamten Editor führst du stark vorhersehbare Tastendrücke, Klicks, Aktionen aus. Können wir ein Modell bauen, das all das mit geringer Latenz vorhersagt?

Als ersten Schritt haben wir Copilot++ erweitert, um deine nächste Position im Code vorherzusagen. Kombinierst du das mit der Vorhersage der nächsten Bearbeitung, kann das Modell eine Sequenz stark vorhersehbarer Änderungen durchspielen:

Wir arbeiten daran, die nächste Datei vorherzusagen, zu der du wechselst. Den nächsten Terminalbefehl, den du ausführst. Die nächste Bearbeitung, konditioniert auf deine vorherigen Terminalbefehle! Ein Modell zur Vorhersage deiner nächsten Aktion.

Außerdem sollte das Modell Informationen genau in dem Moment einblenden, in dem du sie brauchst – sei es das richtige Stück Code oder die passende Dokumentation.

Cursor sollte sich wie eine Erweiterung deines Willens anfühlen. In dem Moment, in dem du an eine Änderung denkst, benötigt das Sprachmodell nur ein Minimum an Intent, um sie sofort auszuführen.

#Vielversprechende Ansätze

• Grundlagenforschung zu Action Prediction über eine gesamte Codebasis hinweg.

• Fortgesetztes Pre-Training und Post-Training auf Code-Modellen mit ~5–13B aktiven Parametern (für prefill-gebundene Vorhersagen mit niedriger Latenz).

• Zusätzliche Inferenztricks, ähnlich wie Speculative Edits

Cleveres UX-Design, um „Actions“ auf unaufdringliche Weise einzublenden. (Wie schlägst du vor, zu welcher Datei ein User als Nächstes wechseln sollte? Oder zur nächsten relevanten Stelle außerhalb des aktuellen Viewports?)

#Perfekte Edits

Können wir den für die Inferenz eingesetzten Rechenaufwand hochskalieren, um hochwertigere, umfangreichere Edits zu erzeugen? Wie gleichen wir die dadurch erhöhte Latenz aus?

Es kann nötig sein, den Edit im Hintergrund auszuführen – also eine Arbeitseinheit abzuspalten, die man intelligenten Modellen anvertrauen kann.

Wir werden Modelle mit starken, editorspezifischen Fähigkeiten zur Tool-Nutzung, smarterem Kontext über den gesamten Codebestand und verbessertem langfristigem Reasoning benötigen.

Und wie können wir asynchrone Code-Generierung flussbewahrend machen? Das klingt wie ein Widerspruch in sich, aber wir glauben, dass clevere Forschung zu Modellfähigkeiten und UX dies möglich machen könnte.

#Halluzinierter Pseudocode

Nutzer schreiben Pseudocode, der die gewünschte Änderung beschreibt. Dann können wir uns darauf verlassen, dass Cursor den Pseudocode im Hintergrund automatisch in die vollständige Änderung umsetzt.

#Bearbeitungen in mehreren Dateien

Cmd-k ist bereits großartig, aber was wäre, wenn Sie eine globale Änderung in Ihrer gesamten Codebasis anfordern könnten? Vor allem eine, die sich korrekt über mehrere Dateien erstreckt?

#Vielversprechende Richtungen

• Skalierung der Rechenleistung während der Inferenz. Wir wissen, dass Reward-Modelle und Rejection Sampling schnelle und einfache Verbesserungen bringen werden, aber wie viel weiter können wir gehen?

• Bessere Reasoning-Modelle (GPT-5, Claude-4, Gemini 2.0)

• Ausführen mehrerer Language-Server-/Dateisystem-Instanzen für einen bestimmten Benutzer-Workspace. Dies erfordert Tool-Nutzung durch das Modell und die Remote-Reproduktion von Laufzeitumgebungen.

• Training/Verbesserung der Modellleistung auf Basis von Agent-Trajektorien

• Umfangreiche UX-Experimente für asynchrone Edits im laufenden Arbeitsfluss

#Optimaler Kontext

Es kann Millionen von Token an Dokumentation geben, Dutzende Millionen Token an Quellcode, noch einmal Dutzende Millionen Token an Commit-Historie – alles potenziell nützliche Token, um eine einzelne Abfrage zu beantworten.

Ganz zu schweigen von den Pixeln in deiner UI, Logs in Produktion und auf localhost, Nachrichten in Slack usw. ...

Wir glauben, dass die besten Coding-Systeme eine Mischung aus Retrieval, Rekurrenz und Long-Context-Attention nutzen werden, um all diese Informationen zu verarbeiten.

Wir betonen Systeme, denn kurzfristig kann dies ein Ensemble aus Modellen und Infrastruktur sein, das gemeinsam eine unendliche Kontext-Engine fürs Programmieren bildet. Langfristig erwarten wir, dass es direkt in die Architektur eingebettet sein wird.

Wir sind besonders begeistert, wenn wir kreativ über die Zukunft von Retrieval nachdenken. Über Embeddings hinausgehend: Welche maximale Performance ist möglich, gegeben das Primitiv eines teuren Indizierungsschritts und eines günstigen Abfrage-Schritts (sublinear in der Größe des Korpus)?

Vielleicht sieht es aus wie eine Variante von Transformer-Speicher als differenzierbarer Suchindex. Vielleicht etwas völlig anderes. Es ist ein noch wenig erforschtes Gebiet.

#Multi-Hop-Kontext

In meiner Codebasis möchte ich ein Diff zwischen zwei Strings berechnen. Mit Embeddings erhalte ich den Chunk:

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

Um die ursprüngliche Frage zu beantworten, muss ich herausfinden, wie ich aus einem String ein ITextModel erstellen kann. Dies ist eine Frage, die zwei Schritte zur Beantwortung erfordert.

Die schwierigsten Fragen und Abfragen in einer Codebasis erfordern mehrere Schritte. Einfaches Retrieval funktioniert nur für einen Schritt.

#Vielversprechende Ansätze

• Spezialisierte/verbesserte Embeddings und Reranker für Codebasen.

• Training von Multi-Hop-Embedding-Modellen: Ausgehend von einer Anfrage und dem relevanten Code, den wir bisher gefunden haben, das nächste Code-Stück bestimmen, zu dem gesprungen werden soll.

• Cleveres Prefix-Caching und eventuell benutzerdefinierte Attention-Masken, die besser für Codebasen geeignet sind.

• Neuartige Forschung zu Retrieval auf Codebase-Ebene.

• Ein Modell so trainieren, dass es eine Codebase in seinen Gewichten lernt – ähnlich wie Transformer-Modelle als Suchindex.

#Fehlererkennung und Debugging

Bestehende Systeme zur Fehlererkennung haben Schwierigkeiten mit der richtigen Kalibrierung und einem ausreichenden Verständnis der Codebasis.

Modelle sind intelligent genug, um Fehler korrekt zu identifizieren, leiden jedoch unter vielen Fehlalarmen (False Positives). Die kniffligsten Bugs zu finden erfordert ein tieferes Verständnis der Codebasis. Und Code, der fehlerhaft aussieht, kann sich als unbedenklich herausstellen, wenn man das größere Ganze betrachtet.

Eine Möglichkeit, wie sich das zeigen kann, ist ein deutlich besseres Erlebnis bei Code-Reviews mit Sprachmodellen:

#Erkennen von Fehlern in der KI-Review

Der Vorteil einer „KI-Review“ ist, dass Nutzer gegenüber False Positives toleranter sind, da sie explizit eine Review anfordern. Der Nachteil ist, dass dafür ein geändertes Nutzerverhalten erforderlich ist.

#KI-Linting

Die beste Variante der Fehlererkennung ist ein dauerhaft aktiver Linter, der deine Bugs im Hintergrund findet. Dafür brauchen wir ein günstigeres und schnelleres Modell als für KI-Reviews, da wir es mehrmals pro Minute ausführen würden. Außerdem muss es auf eine niedrigere Rate an Fehlalarmen abgestimmt sein.

#Intelligenteres Debugging

Noch beeindruckender als die reine Fehlererkennung ist das Debuggen schwieriger Probleme.

Wir müssen über LLM-basierte statische Analyse hinausgehen. Zum Beispiel haben wir ein cursor/debug-Paket entwickelt. Wenn du es in deinen Code einbindest, erfasst es Laufzeitinformationen.

Im Hintergrund können wir es sogar verwenden, um zusätzliche Zustände von Variablen nachzuverfolgen (vergleichbar mit Print-Debugging, bei dem relevante Ausgaben in den Kontext von Cursor geleitet werden).

#Vielversprechende Ansätze

• Clevere Kuratierung von Datensätzen (voraussichtlich synthetische Daten) und RL auf Frontier-Code-Modellen, um die Kalibrierung zu verbessern.

• Relevante Informationen von anderen Oberflächen (dem Browser oder einem nicht integrierten Terminal) erfassen.

• Leistung von Frontier-Modellen beim debugger­spezifischen Tool-Einsatz und bei Tool-Chains verbessern.

• Unendlicher Kontext und nahezu perfektes Verständnis der Codebasis.

• Den Umfang unserer cursor/debug-Bibliothek erweitern, um alle nützlichen Informationen zum Programmzustand zu erfassen.

Wenn eines dieser Themen für dich interessant ist, melde dich bitte unter hiring@cursor.com