Ich muss mir etwas von der Seele reden. Vor meinem Vorstellungsgespräch bei @cursor_ai hatte ich Cursor noch nie wirklich benutzt.
Bei Meta war Claude Code explosionsartig im Kommen. Ich habe sogar 200 Dollar im Monat für einen persönlichen Account für meine Nebenprojekte bezahlt. Ich liebte die Einfachheit und wie schnell ich mich produktiv fühlen konnte. Der Knackpunkt für mich war, meine eigenen Fähigkeiten zu entwickeln, um cc in fast alles zu verwandeln, was ich wollte. Ich habe sogar angefangen, mein eigenes Agenten-Orchestrierungstool darauf aufzubauen.
Während meines Vor-Ort-Gesprächs habe ich Cursor zwei Tage lang benutzt, um das Interviewprojekt zu erstellen. Das war vor der Veröffentlichung von Cursor 3, also habe ich das Editor-Fenster verwendet. Ich benutze VSCode seit so vielen Jahren, dass die meisten Tastenkombinationen noch in meinem Kontextfenster waren, daher war die Rückkehr zur IDE nicht allzu schwierig. Ich kann aber nicht lügen. In den ersten ein oder zwei Stunden habe ich die CLI definitiv vermisst. Auf Dinge zu klicken, fühlte sich fast barbarisch an. Aber es gab ein paar Dinge, die mir wirklich aufgefallen sind.
Erstens fühlten sich die Modelle, die ich damals gewohnt war – Opus und Codex – irgendwie schlauer an. Und es war großartig, die Modelle spontan wechseln und beide gleichzeitig an verschiedenen Teilen meines Projekts verwenden zu können (Opus für das Frontend, Codex für Systeme). Vor meinem Vorstellungsgespräch habe ich bereits von Multi-Modell-Adversarial Review geschwärmt, daher fühlte es sich sehr natürlich an, dies nativ in der Benutzeroberfläche tun zu können. Noch besser war die Möglichkeit, Unteragenten verschiedener Modelle zu spawnen, sodass ich das Beste aus beiden Welten in einem Gespräch haben konnte.
Zweitens war die Komprimierung unglaublich schnell. Als cc-Benutzer war ich es gewohnt, dass die Komprimierung viele Minuten dauerte, und ich war daher ständig in Alarmbereitschaft, was meinen Kontext- und Planverbrauch anging. Ich war also völlig schockiert, wie schnell es in Cursor war. So sehr, dass ich praktisch nie darauf achten musste, wie viel Kontext ich verbrauchte. Es funktionierte einfach, während ich bei cc oft das Gefühl hatte, dass das Modell nach der Komprimierung super dumm wurde.
Und das dritte, was mir auffiel, war, wie viel GUIs gegenüber TUIs bieten können. Die Möglichkeit, deine App direkt im Cursor-Browser zu öffnen und mit dem Design-Modus Designänderungen vorzunehmen, fühlte sich intuitiv an und brachte mich zum Nachdenken, wie sehr zweckgebundene Benutzeroberflächen agentisches Programmieren effektiver machen könnten.
Cursor mit Cursor bauen
Seit meinem Eintritt Ende März arbeite ich hauptsächlich am Agentenfenster von Cursor 3 und benutze es als mein tägliches Werkzeug. Obwohl ich cc immer noch für ein cooles Produkt mit einem großartigen Team halte, habe ich festgestellt, dass seine Einfachheit die Leute dazu treibt, ihre eigenen Abstraktionen darum herum zu bauen. In meinem letzten Job hatte ich das Gefühl, dass jede Woche ein neues internes Orchestrierungstool auf Basis von cc angekündigt wurde.
@bcherny spricht viel über diese Idee der "latenten Nachfrage":
"Es gibt diese wirklich alte Idee im Produktbereich, die latente Nachfrage genannt wird... du baust ein Produkt so, dass es hackbar ist, dass es offen genug ist, damit Leute es für andere Anwendungsfälle missbrauchen können. Dann siehst du, wie die Leute es missbrauchen, und dann baust du dafür."
Genau das war es! Leute, die sich auf Orchestrierungstools konzentrieren, offenbaren die latente Nachfrage, dass die Verwendung einer CLI dich, den Menschen, zum Orchestrator macht.
Aber jeder Agenten-Workflow, den ich verwendet hatte, konzentrierte sich auf das Falsche. Mehrere CLIs in einer GUI auszuführen, verfehlte den Punkt völlig. Der Ansatz, der mich interessierte, war, Vertrauen in Agenten aufzubauen.
Als ehemaliger Engineering Manager wurde mir schnell klar, dass die Verwaltung von Agenten dem Aufbau eines menschlichen Engineering-Teams ähnelt. Neue Mitarbeiter müssen eingearbeitet werden, damit sie die Codebasis verstehen, aber auch, wie Arbeit erledigt wird. Sie kommen bereits mit Fähigkeiten, die sie aus ihren bisherigen Erfahrungen mitbringen: wie man debuggt, wie man qualitativ hochwertigen Code und Tests schreibt und wie man kommuniziert, um nur einige zu nennen.
Agenten sind wie Neueinstellungen in einem ständigen Zustand von Amnesie und Idiotie. Sie erinnern sich nicht an das, was du ihnen sagst, und sie lernen nie wirklich etwas Neues. Aber wir können sie mit Regeln, Fähigkeiten, Werkzeugen und einem Langzeitgedächtnis ausstatten, die das annähern können. Sie sind fähig, aber dumm und sehr lernfähig. Und ich sah ihre Fehlermodi als Gelegenheit, ihnen alles beizubringen, was ich über tiefgehendes, rigoroses Engineering weiß.
Denn wenn es keine Strenge gibt, werden Agenten unterwürfig alles tun, um den Code zu schreiben, den du verlangt hast. Und Junge, können und werden sie eine Menge davon schreiben. Naive Parallelisierung lässt sie nur schneller Mist schreiben.
Wenn du schnell vorankommen willst, geh zuerst in die Tiefe
Ich glaube, dass Agenten-Orchestrierung produktiv sein kann. Aber wir müssen zuerst in die Tiefe gehen.
Ich mache pstack als Open Source verfügbar, meine persönliche Sammlung von Fähigkeiten und Engineering-Prinzipien, die ich täglich verwende, um @cursor_ai zu bauen. Ich habe mit frühen Iterationen dieser Fähigkeiten in meinen Nebenprojekten begonnen und sie seitdem verfeinert.
Hol es dir hier: https://cursor.com/marketplace/cursor/pstack
Diese Fähigkeiten gehören zu den am häufigsten genutzten Fähigkeiten des Cursor-Teams, daher freue ich mich, sie mit euch allen zu teilen.
pstack lehrt Agenten, mit mehreren Modellen rigoroser zu sein. Ich habe alle Fehlermodi, die ich beobachtet habe, genommen und in Fähigkeiten umgewandelt. Das Herzstück des Plugins ist /poteto-mode, eine übergeordnete Fähigkeit, die Agenten das richtige Playbook für eine bestimmte Aufgabe gibt. Das Ziel ist nicht maximale LOC, sondern das Gegenteil: maximale Wirkung mit der geringsten Menge an Code.
Die Strenge wird angewendet, indem Probleme auf die gleiche Weise angegangen werden wie erfahrene Ingenieure. Ein großartiger Weg zum Debuggen ist zum Beispiel die binäre Suche des Problemraums. Du beginnst mit einigen Hypothesen, was los sein könnte, und versuchst dann, sie systematisch auszuschließen, bis du der wahren Ursache näher kommen kannst. Wenn es schwer zu reproduzieren ist, könntest du versuchen, den Fehler synthetisch zu erzwingen. Oder du könntest versuchen, Instrumentierung oder Konsolenprotokollierung hinzuzufügen, um den Programmstatus während der Ausführung zu überprüfen.
Diese Schritte bilden ein Playbook, das von Agenten verwendet werden kann, um Probleme gründlich zu debuggen, anstatt zu raten, was sie gerne tun, wenn du sie lässt. pstack wird mit vielen Fähigkeiten und Playbooks ausgeliefert, die es dir ermöglichen, Softwareentwicklung mit dem gleichen Maß an Strenge anzugehen. Ich habe derzeit Playbooks für:
- Erstellung von Fähigkeiten und Evaluierungen
- Autonomes Arbeiten
- Fehlerbehebungen und Laufzeitforensik
- Feature-Entwicklung
- Visuelle Gleichheit und Prototyping
- Und mehr
Wann immer du Strenge brauchst, stelle deinem Prompt /poteto-mode voran. Zum Beispiel:
Du kannst auch optional die anderen Fähigkeiten bei Bedarf aufrufen:
- /how: du möchtest eine Erklärung, wie ein Subsystem tatsächlich funktioniert.
- /why: du möchtest wissen, warum etwas auf diese Weise gebaut wurde. Verwendet deine verfügbaren MCPs, um jede Beweiskategorie parallel abzufragen (Quellcodeverwaltung, Issue-Tracker, Langzeitdokumentation, Echtzeit-Chat, Infrastruktur-Beobachtbarkeit, Fehlerverfolgung, Analyse-Warehouse).
- /architect: du bist dabei, Code zu schreiben, der eine Funktionsgrenze überschreitet, und möchtest zuerst die Typen und Datenstrukturen festlegen.
- /arena: du möchtest N parallele Versuche für dasselbe, um dann die besten Teile von jedem zu nehmen.
- /interrogate: du möchtest, dass verschiedene Modelle etwas adversariell überprüfen.
- /tdd: du behebst einen Fehler. Schreibe zuerst den fehlschlagenden Test, dann die Behebung.
- /unslop: du räumst jede Art von KI-Schreibarbeit auf. Bringt sie dazu, klar zu sprechen.
- /reflect: du möchtest deine Fähigkeiten nach langen Gesprächen kontinuierlich verbessern.
- /figure-it-out: machst du etwas Ungewöhnliches? Entwirft ein rigoroses, überprüfbares Playbook für die Aufgabe.
- /show-me-your-work: du möchtest einen überprüfbaren Entscheidungsweg. Protokolliert Entscheidungen in einer TSV-Datei, die du committen kannst.
Und schließlich kannst du deine eigene Modus-Fähigkeit mit /automate-me erstellen. Es durchsucht deine letzten Transkripte, entwirft eine deine-Modus-Fähigkeit basierend auf deiner Arbeitsweise und leitet sie unter der Haube durch pstack.
pstack funktioniert mit jedem agentischen Codierungstool, aber besonders gut in Multi-Modell-Tools wie Cursor. Viele der Fähigkeiten nutzen Multi-Modell-Workflows, um die einzigartigen Stärken und Schwächen jedes Modells auszunutzen. Es ist Agenten-Orchestrierung, aber in die Tiefe statt in die Breite angewendet.
Der Engpass bei Agenten ist die Verifikation. Agenten können schnell große Mengen an Code schreiben. Sicherzustellen, dass alles korrekt ist, ist äußerst schwierig. Wenn man das erreichen kann, könnte echte Agenten-Parallelität, wie in einer dunklen Fabrik für Software, möglich sein.
Aber zuerst müssen wir in die Tiefe gehen und rigoros sein. Ich denke, wir kommen dorthin, indem wir das Vertrauen erhöhen.
Probier pstack aus und lass mich wissen, was du denkst.
Zen und die Kunst der Software-Wartung
Diese Fähigkeiten helfen mir, beim Schreiben von Code mit mehr Selbstvertrauen zu agieren. Aber die Wartung von Code ist jetzt ein Albtraum, da Agenten den ganzen Code schreiben. Fehler, Leistungsprobleme und Feature-Anfragen brauchen immer noch Zeit, um bearbeitet zu werden. Und jetzt gibt es so viel mehr davon!
Ich mache bei Cursor ausgiebig Gebrauch von Cursor-Automationen. Das sind Cloud-Agenten, die zeitgesteuert oder als Reaktion auf Ereignisse wie neue Nachrichten in einem Slack-Kanal ausgeführt werden können. Ein solches Beispiel ist mein Bot Benny. Ich habe ihm die gleichen Fähigkeiten gegeben, die ich in pstack habe.
Benny ist noch in Arbeit, aber meine Vision ist es, so viel wie möglich vom Software-Wartungsprozess zu automatisieren. Die Idee ist folgende: Wenn wir jetzt das Vertrauen haben, Probleme mit pstack meistens "auf einen Schlag" zu lösen, mit einer guten Sicherheit, dass die PR-Qualität hoch ist, dann können wir sicherlich auch Feedback automatisieren.
Diese Fabrik beginnt ihr Leben mit der Triage: dem Sammeln von Informationen von Mitarbeitern über Fehlerberichte. Wir dogfooden Cursor viel und bekommen daher viel Feedback von Mitarbeitern zu unseren Release Candidates. Benny versteht Bild- und Videoanhänge, erkundet die Codebasis mit pstack-Fähigkeiten und unterhält sich mit dem Melder, um Informationen zu Reproduktionsschritten zu erhalten, falls diese nicht klar sind.
Dies ist ein wichtiger Teil des Fehlerberichtsprozesses. Ohne klare Reproduktionsschritte und ein Verständnis dafür, was kaputt ist, können Agenten nur raten, was die Lösung ist. Wir müssen ihnen ein klares Verständnis davon geben, wo und wie genau es kaputt geht.
Nach der Triage erstellt Benny ein Ticket mit seinen Erkenntnissen aus der Codeanalyse, der Git-Historie für kürzliche Regressionen, Slack für andere Nachrichten über denselben Fehler und sogar Notion für Design- und Produktentscheidungen darüber, wie eine Funktion funktionieren soll: Ist es ein Fehler oder wurde es so entworfen?
Nachdem das Ticket erstellt wurde, nimmt sich ein anderer Benny-Bot seiner mit einer weiteren Fähigkeit an, die ich erstellt habe, namens /orchestrate.
Zuerst versucht er, das Problem durch Computernutzung zu reproduzieren. Cursor Cloud Agents können Cursor selbst in der Cloud ausführen, wo sie mit dem Desktop interagieren, auf Dinge klicken und Tastatureingaben senden. Intern verwendet dies weitere Fähigkeiten, die ich gemacht habe, um unsere Produkte programmgesteuert mit Protokollen wie CDP oder Äquivalenten zu steuern.
Dies ermöglicht es uns zu zeigen, ob der Fehlerbericht reproduziert werden kann. Wenn er den Fehler konsistent reproduziert, versucht er dann, ihn zu beheben. Wenn es ein Leistungsproblem ist, kann Benny Vorher-Nachher-CPU-Traces und Heap-Snapshots erstellen. Unterplaner spawnen mehr Arbeiter, um die Behebung mit pstack-Fähigkeiten zu verifizieren und die Arbeit gegen das Ticket zu prüfen, falls es behoben wurde.
Zusätzliche Arbeiter werden in diesem Durchlauf gespawnt, um ein Video des Vorher und Nachher aufzunehmen, und schließlich öffnet ein Arbeiter die PR zur Überprüfung mit dem Video in der Beschreibung.
Das ist alles noch in Arbeit und es gibt noch eine Menge zu tun, aber ich freue mich darauf, ein Team von Agenten zu haben, die mir helfen, Fehler mit Zuversicht zu beheben, während ich schlafe oder andere Dinge tue. Code-Reviews skalierbar zu machen, ist ein weiterer großer Bereich, und ich denke, Cursor wird einige coole neue Funktionen haben, um dabei zu helfen.
Aber der Schlüssel zum Bau deiner eigenen Software-Fabrik ist Vertrauen. Wenn du einem Agenten nicht vertrauen kannst, ein Problem von Anfang bis Ende zu besitzen, einschließlich der Verifikation, kannst du deine Prozesse nicht automatisieren. Wenn du das Vertrauen mit Plugins wie pstack erhöhst, die deinen Agenten mehr technische Tiefe geben, kannst du beginnen, ehrgeizigere Probleme anzugehen. Zu versuchen, Agenten zu parallelisieren, denen du noch nicht vertraust, ist eine riesige Verschwendung von Tokens und bringt mehr Schrott in deine Codebasis.
Danke fürs Lesen!
