Unsere Probleme

Update: Wir haben über einige weitere Problemegeschrieben.

Eine ungeordnete Liste kurzer, konkreter Probleme:

Besserer Kontext: In einem Code-Editor gibt es viele Informationsquellen: offene Dateien, semantisch ähnliche Code-Snippets, symbolisch verbundene Klassen, Lint-Ausgaben, Ausführungstraces, Git-Historie, Tipp-Historie, externe Dokumentation und mehr. Wir möchten, dass das Modell sofort versteht, was für die Frage der Nutzerin bzw. des Nutzers am relevantesten ist, und trainieren aktuell ein eigenes, schnelles Reranker-Modell, um dieses Problem zu lösen. Für jede Anfrage sammeln wir 500k Tokens aus all diesen Quellen und verwenden unseren Reranker, um sie auf die relevantesten 8k Tokens zu filtern. Das ist sowohl ein Modellproblem als auch zunehmend ein Infrastrukturproblem.
Ein „Copilot für Änderungen“: GitHub Copilot ist unglaublich hilfreich, um Low-Entropy-Tastendrücke beim Schreiben von neuem Code zu eliminieren, hilft dir aber nicht, Low-Entropy-Tastendrücke zu sparen, wenn du kleine, einfache Änderungen an bestehenden Codeblöcken vornehmen musst. Denk an die Navigations-, Lösch- und Eingabetastendrücke, die du für ein Rename brauchst, das nur geringfügig komplizierter ist, als es ein symbolisches F2-Rename leisten kann. Wir werden Innovationen sowohl im UX-Bereich benötigen (unaufdringliche Diffs, die dir beim Coden angezeigt werden) als auch auf Modellseite (Prompting reicht hier nicht aus – wegen Kosten-, Latenz- und Intelligenzproblemen).
Begrenzte, im Flow arbeitende Agents: Stell dir den Code Interpreter von OpenAI vor, aber für Engineering in großen Codebases. Du sagst einem begrenzten, wenige Schritte umfassenden Agent, was er tun soll, und er durchsucht, schreibt und führt Code für dich aus und holt dabei immer wieder dein Feedback ein. Der erste Schritt dahin, an dem wir gerade arbeiten, ist ein solcher Agent, der mit Ordnern von ein paar Hunderttausend Tokens umgehen kann. Wenn das gelingt, skalieren wir ihn auf ganze Codebases hoch.
Bug-Finding: Es gibt hier zwei Modi: (1) Im Hintergrund scannt Cursor deine Dateien stets passiv, um potenzielle Bugs für dich zu finden, und (2) wenn du tief in einer Debugging-Session bist, sucht Cursor mit deiner Hilfe aktiv nach dem Bug. Hier gibt es eine Menge interessanter Datenerhebung zu tun.
Größere Änderungen: Cursor sollte in der Lage sein, für dich ganze Dateien und sogar komplette Verzeichnisse zu ändern. Das ist eine Herausforderung sowohl in Bezug auf Fähigkeiten als auch auf UX. Für Geschwindigkeit muss das Modell smart genug sein, die zu ändernden Teile herauszupicken, ohne alles neu zu schreiben. Damit die Erfahrung gut ist, müssen die Änderungen in einer gut auswertbaren Echtzeit-Form dargestellt werden.
Scale: Wir haben 1,4 Milliarden Vektoren und 150 Tausend Codebases indiziert (Stand: 12. Oktober 2023). Das wird sich bis zum Jahresende vermutlich verzehnfachen. Wir haben bereits eine sehr schnelle, auf Merkle-Bäumen basierende Codebase-Sync-Engine in Rust gebaut und werden wahrscheinlich bald ein eigenes Indizierungssystem entwickeln müssen.

Zukünftige Ideen:

Time Warp: Sage die dateiübergreifenden Codeänderungen voraus, die du in den nächsten 15 Minuten machen wirst, und zeige sie an. Ein Tastenkürzel, um alle Einfügungen/Löschungen zu übernehmen.
Verständnis: Unsere Modelle sollten alle Konzepte in jeder Codebase tiefgreifend verstehen – in den Gewichten.
Lesemodus: Mache das Verstehen von Code mühelos – mit Dokumentation auf jedem gewünschten Detailgrad und einem Bot, der dich durch die relevanten Codepfade führt und bei Bedarf erklärt.
Pseudo-Code-Modus: Bearbeite eine grobe „Outline“-Darstellung deines Codes und lass die Änderungen automatisch auf Quellcode-Ebene anwenden.
Nie wieder über Stack Traces nachdenken müssen: Die IDE sollte sie einfach verstehen und den Code automatisch für dich beheben.

Wir haben versucht, alle Probleme zu sammeln, über die wir im Moment nachdenken, aber – und das ist eines der wunderbaren Dinge daran, ein Produkt zu bauen, das man selbst 12 Stunden pro Tag nutzt – wir haben ständig neue Ideen und priorisieren um. Daher sollte dies nicht als ultimativer, vollständiger Fahrplan verstanden werden. Nichtsdestotrotz hoffen wir, dass es ein Gefühl dafür vermittelt, womit wir jeden Tag unsere geistige Energie verbringen.

Außerdem bist du ziemlich weit gekommen mit dem Lesen, daher ist es wohl wahrscheinlich, dass du ein gewisses Interesse an den Problemen hast, die uns interessieren :). Falls das so ist, solltest du in Betracht ziehen, dich uns anzuschließen! Hier sind noch ein paar andere Gründe, warum wir denken, dass du es lieben würdest, mit uns zu arbeiten:

Die Leute verwenden Cursor gerne. Wir sind mit unserem bisherigen Wachstum sehr zufrieden.
Du wirst hier mit wirklich klugen Leuten zusammenarbeiten. Wir glauben fest an Talentdichte. Alle, mit denen du hier arbeitest, werden wirklich, wirklich gut sein.
KI-gestütztes Programmieren ist ein riesiger Markt. Und wir können ihn gewinnen.
Es macht Spaß. Das ist uns sehr wichtig! Es macht Spaß, mit Leuten zu arbeiten, die man mag, es macht Spaß, ein Produkt zu bauen, bei dem man Cmd-Shift-R drückt und sofort Feedback von Nutzer:innen bekommt, weil man selbst beim Programmieren die Zielgruppe ist, und es macht Spaß, jeden Tag ein kleines Stück voranzukommen, um alle langweiligen Teile der Programmierung zu automatisieren.
Wir arbeiten hart. Wir schätzen es sehr, an diesen Problemen zu arbeiten, und wir genießen es, all unsere Energie in ihre Lösung zu stecken.

Update: Wir haben über einige weitere Problemegeschrieben.

Eine ungeordnete Liste kurzer, konkreter Probleme:

Besserer Kontext: In einem Code-Editor gibt es viele Informationsquellen: offene Dateien, semantisch ähnliche Code-Snippets, symbolisch verbundene Klassen, Lint-Ausgaben, Ausführungstraces, Git-Historie, Tipp-Historie, externe Dokumentation und mehr. Wir möchten, dass das Modell sofort versteht, was für die Frage der Nutzerin bzw. des Nutzers am relevantesten ist, und trainieren aktuell ein eigenes, schnelles Reranker-Modell, um dieses Problem zu lösen. Für jede Anfrage sammeln wir 500k Tokens aus all diesen Quellen und verwenden unseren Reranker, um sie auf die relevantesten 8k Tokens zu filtern. Das ist sowohl ein Modellproblem als auch zunehmend ein Infrastrukturproblem.
Ein „Copilot für Änderungen“: GitHub Copilot ist unglaublich hilfreich, um Low-Entropy-Tastendrücke beim Schreiben von neuem Code zu eliminieren, hilft dir aber nicht, Low-Entropy-Tastendrücke zu sparen, wenn du kleine, einfache Änderungen an bestehenden Codeblöcken vornehmen musst. Denk an die Navigations-, Lösch- und Eingabetastendrücke, die du für ein Rename brauchst, das nur geringfügig komplizierter ist, als es ein symbolisches F2-Rename leisten kann. Wir werden Innovationen sowohl im UX-Bereich benötigen (unaufdringliche Diffs, die dir beim Coden angezeigt werden) als auch auf Modellseite (Prompting reicht hier nicht aus – wegen Kosten-, Latenz- und Intelligenzproblemen).
Begrenzte, im Flow arbeitende Agents: Stell dir den Code Interpreter von OpenAI vor, aber für Engineering in großen Codebases. Du sagst einem begrenzten, wenige Schritte umfassenden Agent, was er tun soll, und er durchsucht, schreibt und führt Code für dich aus und holt dabei immer wieder dein Feedback ein. Der erste Schritt dahin, an dem wir gerade arbeiten, ist ein solcher Agent, der mit Ordnern von ein paar Hunderttausend Tokens umgehen kann. Wenn das gelingt, skalieren wir ihn auf ganze Codebases hoch.
Bug-Finding: Es gibt hier zwei Modi: (1) Im Hintergrund scannt Cursor deine Dateien stets passiv, um potenzielle Bugs für dich zu finden, und (2) wenn du tief in einer Debugging-Session bist, sucht Cursor mit deiner Hilfe aktiv nach dem Bug. Hier gibt es eine Menge interessanter Datenerhebung zu tun.
Größere Änderungen: Cursor sollte in der Lage sein, für dich ganze Dateien und sogar komplette Verzeichnisse zu ändern. Das ist eine Herausforderung sowohl in Bezug auf Fähigkeiten als auch auf UX. Für Geschwindigkeit muss das Modell smart genug sein, die zu ändernden Teile herauszupicken, ohne alles neu zu schreiben. Damit die Erfahrung gut ist, müssen die Änderungen in einer gut auswertbaren Echtzeit-Form dargestellt werden.
Scale: Wir haben 1,4 Milliarden Vektoren und 150 Tausend Codebases indiziert (Stand: 12. Oktober 2023). Das wird sich bis zum Jahresende vermutlich verzehnfachen. Wir haben bereits eine sehr schnelle, auf Merkle-Bäumen basierende Codebase-Sync-Engine in Rust gebaut und werden wahrscheinlich bald ein eigenes Indizierungssystem entwickeln müssen.

Zukünftige Ideen:

Time Warp: Sage die dateiübergreifenden Codeänderungen voraus, die du in den nächsten 15 Minuten machen wirst, und zeige sie an. Ein Tastenkürzel, um alle Einfügungen/Löschungen zu übernehmen.
Verständnis: Unsere Modelle sollten alle Konzepte in jeder Codebase tiefgreifend verstehen – in den Gewichten.
Lesemodus: Mache das Verstehen von Code mühelos – mit Dokumentation auf jedem gewünschten Detailgrad und einem Bot, der dich durch die relevanten Codepfade führt und bei Bedarf erklärt.
Pseudo-Code-Modus: Bearbeite eine grobe „Outline“-Darstellung deines Codes und lass die Änderungen automatisch auf Quellcode-Ebene anwenden.
Nie wieder über Stack Traces nachdenken müssen: Die IDE sollte sie einfach verstehen und den Code automatisch für dich beheben.

Die Leute verwenden Cursor gerne. Wir sind mit unserem bisherigen Wachstum sehr zufrieden.
Du wirst hier mit wirklich klugen Leuten zusammenarbeiten. Wir glauben fest an Talentdichte. Alle, mit denen du hier arbeitest, werden wirklich, wirklich gut sein.
KI-gestütztes Programmieren ist ein riesiger Markt. Und wir können ihn gewinnen.
Es macht Spaß. Das ist uns sehr wichtig! Es macht Spaß, mit Leuten zu arbeiten, die man mag, es macht Spaß, ein Produkt zu bauen, bei dem man Cmd-Shift-R drückt und sofort Feedback von Nutzer:innen bekommt, weil man selbst beim Programmieren die Zielgruppe ist, und es macht Spaß, jeden Tag ein kleines Stück voranzukommen, um alle langweiligen Teile der Programmierung zu automatisieren.
Wir arbeiten hart. Wir schätzen es sehr, an diesen Problemen zu arbeiten, und wir genießen es, all unsere Energie in ihre Lösung zu stecken.

Update: Wir haben über einige weitere Problemegeschrieben.

Eine ungeordnete Liste kurzer, konkreter Probleme:

Besserer Kontext: In einem Code-Editor gibt es viele Informationsquellen: offene Dateien, semantisch ähnliche Code-Snippets, symbolisch verbundene Klassen, Lint-Ausgaben, Ausführungstraces, Git-Historie, Tipp-Historie, externe Dokumentation und mehr. Wir möchten, dass das Modell sofort versteht, was für die Frage der Nutzerin bzw. des Nutzers am relevantesten ist, und trainieren aktuell ein eigenes, schnelles Reranker-Modell, um dieses Problem zu lösen. Für jede Anfrage sammeln wir 500k Tokens aus all diesen Quellen und verwenden unseren Reranker, um sie auf die relevantesten 8k Tokens zu filtern. Das ist sowohl ein Modellproblem als auch zunehmend ein Infrastrukturproblem.
Ein „Copilot für Änderungen“: GitHub Copilot ist unglaublich hilfreich, um Low-Entropy-Tastendrücke beim Schreiben von neuem Code zu eliminieren, hilft dir aber nicht, Low-Entropy-Tastendrücke zu sparen, wenn du kleine, einfache Änderungen an bestehenden Codeblöcken vornehmen musst. Denk an die Navigations-, Lösch- und Eingabetastendrücke, die du für ein Rename brauchst, das nur geringfügig komplizierter ist, als es ein symbolisches F2-Rename leisten kann. Wir werden Innovationen sowohl im UX-Bereich benötigen (unaufdringliche Diffs, die dir beim Coden angezeigt werden) als auch auf Modellseite (Prompting reicht hier nicht aus – wegen Kosten-, Latenz- und Intelligenzproblemen).
Begrenzte, im Flow arbeitende Agents: Stell dir den Code Interpreter von OpenAI vor, aber für Engineering in großen Codebases. Du sagst einem begrenzten, wenige Schritte umfassenden Agent, was er tun soll, und er durchsucht, schreibt und führt Code für dich aus und holt dabei immer wieder dein Feedback ein. Der erste Schritt dahin, an dem wir gerade arbeiten, ist ein solcher Agent, der mit Ordnern von ein paar Hunderttausend Tokens umgehen kann. Wenn das gelingt, skalieren wir ihn auf ganze Codebases hoch.
Bug-Finding: Es gibt hier zwei Modi: (1) Im Hintergrund scannt Cursor deine Dateien stets passiv, um potenzielle Bugs für dich zu finden, und (2) wenn du tief in einer Debugging-Session bist, sucht Cursor mit deiner Hilfe aktiv nach dem Bug. Hier gibt es eine Menge interessanter Datenerhebung zu tun.
Größere Änderungen: Cursor sollte in der Lage sein, für dich ganze Dateien und sogar komplette Verzeichnisse zu ändern. Das ist eine Herausforderung sowohl in Bezug auf Fähigkeiten als auch auf UX. Für Geschwindigkeit muss das Modell smart genug sein, die zu ändernden Teile herauszupicken, ohne alles neu zu schreiben. Damit die Erfahrung gut ist, müssen die Änderungen in einer gut auswertbaren Echtzeit-Form dargestellt werden.
Scale: Wir haben 1,4 Milliarden Vektoren und 150 Tausend Codebases indiziert (Stand: 12. Oktober 2023). Das wird sich bis zum Jahresende vermutlich verzehnfachen. Wir haben bereits eine sehr schnelle, auf Merkle-Bäumen basierende Codebase-Sync-Engine in Rust gebaut und werden wahrscheinlich bald ein eigenes Indizierungssystem entwickeln müssen.

Zukünftige Ideen:

Time Warp: Sage die dateiübergreifenden Codeänderungen voraus, die du in den nächsten 15 Minuten machen wirst, und zeige sie an. Ein Tastenkürzel, um alle Einfügungen/Löschungen zu übernehmen.
Verständnis: Unsere Modelle sollten alle Konzepte in jeder Codebase tiefgreifend verstehen – in den Gewichten.
Lesemodus: Mache das Verstehen von Code mühelos – mit Dokumentation auf jedem gewünschten Detailgrad und einem Bot, der dich durch die relevanten Codepfade führt und bei Bedarf erklärt.
Pseudo-Code-Modus: Bearbeite eine grobe „Outline“-Darstellung deines Codes und lass die Änderungen automatisch auf Quellcode-Ebene anwenden.
Nie wieder über Stack Traces nachdenken müssen: Die IDE sollte sie einfach verstehen und den Code automatisch für dich beheben.

Die Leute verwenden Cursor gerne. Wir sind mit unserem bisherigen Wachstum sehr zufrieden.
Du wirst hier mit wirklich klugen Leuten zusammenarbeiten. Wir glauben fest an Talentdichte. Alle, mit denen du hier arbeitest, werden wirklich, wirklich gut sein.
KI-gestütztes Programmieren ist ein riesiger Markt. Und wir können ihn gewinnen.
Es macht Spaß. Das ist uns sehr wichtig! Es macht Spaß, mit Leuten zu arbeiten, die man mag, es macht Spaß, ein Produkt zu bauen, bei dem man Cmd-Shift-R drückt und sofort Feedback von Nutzer:innen bekommt, weil man selbst beim Programmieren die Zielgruppe ist, und es macht Spaß, jeden Tag ein kleines Stück voranzukommen, um alle langweiligen Teile der Programmierung zu automatisieren.
Wir arbeiten hart. Wir schätzen es sehr, an diesen Problemen zu arbeiten, und wir genießen es, all unsere Energie in ihre Lösung zu stecken.