Eine Funktion ergänzen oder einen Fehler beheben folgt meist derselben Route: Editor öffnen, Datei finden, ändern, Tests laufen lassen. Für jemanden, der den ganzen Tag im Terminal arbeitet, hat diese Route eine unangenehme Naht in der Mitte. Das Gespräch mit dem Assistenten findet in einem Fenster statt, der Code liegt in einem anderen, und das Wechseln kostet mehr Aufmerksamkeit, als beide Aufgaben verdienen.

Aider verlegt das Gespräch ins Terminal. Man geht ins Projektverzeichnis, startet das Werkzeug und beschreibt dann, was man will, so wie man es einer Kollegin beschreiben würde: dieser Funktion eine Prüfung der Parameter geben, die gemeinsame Logik aus diesen drei Klassen herausziehen. Es liest den Code, ändert die Dateien, lässt die Tests laufen und wird fertig, ohne dass der Editor je erscheint. Zehntausende von Beobachtenden und Millionen Installationen sprechen dafür, dass sich das Entfernen dieser Naht gelohnt hat.

Jede Änderung wird eingecheckt, Rücknahme kostet einen Befehl

Die Entwurfsentscheidung, an der viele hängen bleiben, ist einfach: Jede Änderung, die das Werkzeug an der Codebasis vornimmt, wird mit einer geschriebenen Nachricht in die Versionsverwaltung eingecheckt. Wie der Code vorher aussah und wie danach – beides liegt in der Geschichte. Es gibt also immer einen sauberen Weg zurück. Ist eine Änderung falsch, zeigen die üblichen Werkzeuge den Unterschied und nehmen sie zurück, und es gibt keinen Streit darüber, welche Dateien berührt wurden.

Der Autor hat dieses Prinzip durch das ganze Projekt getragen, was ein großer Teil des guten Rufs in der Entwicklergemeinde erklärt. Es ist außerdem ein kleines Stück Disziplin, das die Psychologie der Arbeit verändert: Einem Agenten eine Aufgabe zu übergeben fühlt sich nicht mehr wie ein Wagnis an, sondern wie ein Zweig.

Erst eine Karte, dann Änderungen

Bei einer großen Codebasis zerlegt das Werkzeug zuerst das gesamte Projekt mit einem Satzanalysator und erzeugt eine Karte davon: welche Dateien, welche Klassen, welche Funktionen und wie sie einander aufrufen. Der ganze Quelltext wird dem Modell nicht übergeben. Das Modell sieht zuerst das Gerüst des Projekts und wählt dann gezielt die Dateien, die es braucht.

Das macht große Projekte praktisch statt theoretisch. Ein zweiter Modus trennt Denken von Tun: ein stärkeres Modell plant die Änderung, ein schnelleres führt den Plan aus. Qualität, wo Urteil nötig ist, Tempo, wo nicht, und Kosten, die im Verhältnis zur Schwierigkeit bleiben.

Jedes Modell und hundert Sprachen

Kein Anbieter wird bevorzugt. Kommerzielle Modelle lassen sich anbinden, ebenso ein Modell auf dem eigenen Rechner, wobei der Code diesen dann nie verlässt. Die Empfehlungen der Betreuenden schließen Kombinationen ein, die nach Preis und Leistung gewählt sind statt nach Ansehen – eine Haltung, die selbstverständlich sein sollte und selten ist.

Bei den Sprachen reicht die Abdeckung über hundert, von den offensichtlichen Skript- und Systemsprachen bis zu denen, die in Web-Hintergründen und älteren Unternehmenssystemen verwendet werden. Prüfen und Testen gehören zur selben Schleife: Das Werkzeug lässt Prüfer und Testreihe selbst laufen und repariert, was es findet, bevor es die Arbeit zurückgibt. Man kann den Wunsch sogar aussprechen und ihn aufschreiben lassen – was wie eine Spielerei klingt, bis man es zum dritten Mal benutzt.

Mit sich selbst gebaut

Das Detail, das Zweifelnde überzeugt, ist die Arbeitsweise: Das Projekt entwickelt sich selbst mit. Der Autor hat rund achtundachtzig Prozent des Werkzeugs mit dem Werkzeug geschrieben, und mehr als dreitausend Einträge der Geschichte tragen eine Mitautorenzeile, die darauf verweist. Ein Werkzeug, das so stark an sich selbst benutzt wird, liefert ein Qualitätsargument, an das keine Messung heranreicht, und wer es bezweifelt, kann die Geschichte lesen.

Das Projekt ist unter einer freizügigen Lizenz vollständig offen und verlangt für sich nichts; bezahlt wird nur, was an Modellaufrufen tatsächlich anfällt. Es behandelt auch den Fall eines Modells, das nur in einem Browserfenster existiert, und erspart das Kopieren und Einfügen, das diese Anordnung früher verlangte.

Für wen es gedacht ist

Entwickler, die ohnehin im Terminal leben und den Wechsel in den Editor als störend empfinden, holen am meisten heraus – doch die Anziehung reicht weiter. Was Aider wirklich anbietet, ist ein Arbeitsstil, in dem jedes Experiment festgehalten und jeder Fehler umkehrbar ist und in dem das Modell ein Teilnehmender im Projekt ist statt ein Chatfenster daneben. Das ist ein erstaunlich großer Unterschied für eine so kleine Ortsveränderung.