Wenn eine Änderung durch ein Dutzend Dateien läuft, hilft Vervollständigung nicht mehr

Echte Änderungen landen selten an einer Stelle. Ein Feld kommt dazu, und man fasst Datenmodell, Schnittstellenschicht, das Formular davor und die Prüfungen an - verteilt über ein Dutzend Dateien. Die klassische Vervollständigung ist gut darin, die halbe Zeile zu erraten, die man schreiben wollte, und hier nahezu nutzlos: Man trägt die Liste im Kopf und geht sie Punkt für Punkt ab, in der Hoffnung, keine Ecke zu übersehen. Cursor dreht die Aufgabe um und übergibt das Ganze einem Vertreter. Man beschreibt das gewünschte Ergebnis, und nachdem er das gesamte Verzeichnis gelesen hat, arbeitet er allein weiter - ändert Dateien, führt Befehle aus, sieht einen Fehler und geht zurück, bis es läuft.

Cursor ist kein Gesprächsfenster, das an einen Editor geschraubt wurde; er tritt als Handwerker auf, der fertige Arbeit übergibt.

Erst zerlegen, dann ausbreiten

Lässt man einen einzigen Vertreter auf ein Dutzend Dateien starren, verliert er den Faden. Cursor zerlegt in zwei Schichten. Die innere ist der Untervertreter. Jeder läuft in seinem eigenen Zusammenhangsfenster, übernimmt eine Art Arbeit und gibt seine Schlussfolgerung an den Vater zurück, sodass das Suchen dazwischen nicht das Hauptgespräch frisst. Sie dürfen gleichzeitig an verschiedenen Teilen des Verzeichnisses beginnen, statt hintereinander in der Schlange zu stehen. Drei sind mitgeliefert: einer durchsucht und untersucht den Code, einer führt Befehle der Hülle aus, einer steuert über MCP-Werkzeuge ein Browsergesicht - und alle drei antworten im Editor, auf der Befehlszeile und in einem Vertreter in der Ferne gleichermaßen. Eigene lassen sich mit Anweisung, Werkzeugsatz und Modell definieren und über mehrere Vorhaben hinweg verwenden.

Projects: ein Koordinator, der keinen Code schreibt

Wird die Aufgabe zu groß für eine Sitzung, übernimmt die Schicht Projects, und die Arbeitsteilung darin ist das Interessante: Der Koordinator setzt nichts um. Die offizielle Beschreibung sagt, er schreibe keinen Code direkt - er plane die Arbeit, verteile die Umsetzungsaufgaben und bringe das fertige Ergebnis zur Prüfung zurück. Er öffnet so viele Vertreter, wie die Arbeit braucht, und lässt sie nebeneinander laufen. Jedes Vorhaben läuft auf einer eigenen Maschine in der Ferne, das Zuklappen des Notebooks unterbricht also nichts; muss etwas auf echter Hardware geprüft werden, startet der Koordinator einen örtlichen Vertreter, der übernimmt.

Bemerkenswerter ist, dass diese Vertreter nicht jeder für sich alles vergessen. Ein Vorhaben pflegt einen Satz Dateien, der über alle fernen und örtlichen Maschinen abgeglichen wird, und die Vertreter hängen an, was sie gefunden haben, welche Gepflogenheiten im Vorhaben gelten und welche Art du bevorzugst. Findet einer heraus, wie ein Dienst zu prüfen ist, können alle späteren diese Schlussfolgerung direkt nutzen - der Koordinator wird mit dem Vorhaben besser. Er darf auch eine Rückmeldungsspur abonnieren, nach Zeitplan laufen oder allen deinen Änderungsanträgen folgen, ohne dass du etwas sagst.

Wo die Arbeit tatsächlich läuft

Vertreter, die nebeneinander arbeiten, brauchen Platz. Ferne Vertreter sitzen in abgeschotteten virtuellen Maschinen, das Verzeichnis ist bereits kopiert, die Abhängigkeiten sind eingerichtet, Schlüssel und Netzzugang stehen bereit, sodass sie wirklich bauen, prüfen und mit der Software umgehen, die sie gerade ändern, und das Ergebnis schließlich als Änderungsantrag einreichen. Sie abonnieren auch die Anträge, die sie selbst geöffnet haben, und arbeiten Fehler der fortlaufenden Prüfung und Kommentare von Maschinen ab, bis zusammengeführt ist.

Teams, deren Code nicht in eine öffentliche Ferne darf, können eigene Maschinen betreiben: Die Ausführung von Werkzeugen bleibt im eigenen Netz, Verzeichnis, Bauergebnis und Schlüssel liegen auf inneren Maschinen der eigenen Grundlage, und die Aufrufe werden örtlich abgewickelt. Ein gemeinsamer Vorrat für ein Team wächst und schrumpft mit der Zahl der Anfragen, schläft im Leerlauf und kommt bei der nächsten Anfrage innerhalb eines Wiederverbindungsfensters zurück - keine Maschine, die für die nächste Eingabe weiterbrennt.

Wie weit man loslässt, ist einstellbar

Alles abzugeben ist kein einzelner Schalter. Die leichteste Stufe ist die Vervollständigung auf Tastendruck, getrieben von einem eigens dafür trainierten Modell, das nur die nächste Änderung vorhersagt, fast ohne dass man etwas sagt. In der Mitte steht das gezielte Umschreiben für eine klar umrissene Stelle. Erst darüber kommt der Vertretermode, der die ganze Aufgabe übernimmt. Jede Änderung hinterlässt einen Prüfpunkt, sodass der Weg des Codes sichtbar bleibt und ein früherer Stand einen Schritt entfernt ist. Beim Fehlersuchen setzt er Messpunkte in den Code und nutzt echte Ausführungsdaten, statt zu raten.

Der Einstieg ist günstig: Die freie Stufe braucht keine Karte, sie bringt nur eine begrenzte Zahl von Vertreteranfragen mit. Mehr Umfang und stärkere Modelle kosten: 20 Dollar im Monat für eine Person, 40 Dollar je Nutzer für ein Team, die genauen Mengen stehen auf der offiziellen Preisseite.

Ein Modell dazu zu bringen, ein anständiges Stück Code zu schreiben, ist nicht die Kunst. Die Kunst ist, eine große Aufgabe in kleine zu zerlegen, die nebeneinander laufen können, und die Teile wieder zusammenzusetzen - genau das leisten diese zwei Schichten der Teilung.