Die Werkzeuge

Eine Liste der Werkzeuge wäre nach drei Monaten falsch. Was länger hält, sind die Bauformen. Es gibt drei davon, alle drei sind in Gebrauch, und die Nummern hier ordnen sie danach, wie weit sie ins Projekt greifen. Entstanden sind sie in einer anderen Reihenfolge, die Jahreszahlen stehen jeweils dabei.

Bauform 1: Code-Completion beim Tippen

Sie schreiben, und im Editor erscheint grau ein Vorschlag für den Rest der Zeile oder der Funktion. Tab übernimmt ihn, weitertippen verwirft ihn.

GitHub Copilot zeigte das im Juni 2021 (externe Seite, github.blog), siebzehn Monate vor ChatGPT. Benutzen konnten es damals wenige, und die Ankündigung sagt es im letzten Satz selbst:

The number of spots for the technical preview is limited, so sign up today! (externe Seite, github.blog)

Für alle offen stand Copilot ein Jahr später (externe Seite, github.blog), zu zehn Dollar im Monat. Das ist die älteste Bauform und heute die unauffälligste: Sie läuft in fast jedem Editor mit, oft ohne dass jemand sie eigens eingerichtet hat.

Was sie sieht, ist eng begrenzt: die offene Datei, ein paar benachbarte, den Namen dessen, was Sie gerade tippen. Was sie tut, ebenso: Sie schlägt vor. Ausgeführt wird nichts, und was Sie übernehmen, steht danach im Editor wie selbst getippt.

Bauform 2: Der Agent in der Entwicklungsumgebung

Hier verschwindet die Zeile, an der Sie stehen, als Bezugspunkt. Sie beschreiben ein Vorhaben in einem Feld daneben, und das Werkzeug arbeitet über mehrere Dateien.

Cursor hat das im November 2024 (externe Seite, cursor.com) mit dem Composer vorgeführt. Der Änderungseintrag nennt schon damals beides, was diese Bauform ausmacht:

Early version of an agent in composer that can pick its own context and use the terminal (externe Seite, cursor.com)

Der Gewinn gegenüber Bauform 1 ist der Blick über die einzelne Datei hinaus. Der Gewinn gegenüber Bauform 3 ist die Ansicht: Jede Änderung steht markiert im Editor und lässt sich einzeln behalten oder verwerfen.

Wann sie dort steht, ist die feinere Frage, und derselbe Hersteller beantwortet sie drei Wochen später:

Agent auto-saves changes to disk (externe Seite, cursor.com)

Die Datei ist also geschrieben, wenn die Markierung erscheint. Wer verwirft, nimmt zurück. Im selben Eintrag steht der Satz, der die zweite Grenze verschiebt:

With Yolo Mode, the agent can auto-run terminal commands (externe Seite, cursor.com)

Damit kann diese Bauform beides, was der nächste Abschnitt Bauform 3 zuschreibt. Aus einem Unterschied der Bauart ist eine Einstellung geworden, und das ist der Grund, warum die drei Fragen weiter unten nach Rechten fragen statt nach Fenstern.

Bauform 3: Der Agent auf der Kommandozeile

Kein Editor, kein Fenster. Sie starten ein Programm im Projektverzeichnis und schreiben hinein, was geschehen soll. Es liest Dateien, ändert sie, führt Befehle aus und liest deren Ausgabe.

Diese Bauform ist älter, als die meisten annehmen. Aider gab es bereits 2023 (externe Seite, aider.chat), zwanzig Monate bevor Claude Code im Februar 2025 (externe Seite, anthropic.com) erschien und der Sache zu ihrer heutigen Bekanntheit verhalf.

Was in der Kommandozeile läuft, kann im Ausgangszustand alles, was Sie dort auch könnten. Tests starten, Abhängigkeiten nachziehen, ein Verzeichnis durchsuchen, sich mit einem anderen Rechner verbinden. Der Unterschied zu Bauform 2 ist damit die Voreinstellung: Hier ist die weite Reichweite der Ausgangspunkt, dort ein Schalter.

Das ist zugleich der Grund, warum diese Bauform am meisten Vorkehrungen verlangt. Die Kapitel danach handeln überwiegend davon.

Wie man das eine vom anderen unterscheidet

Drei Fragen genügen.

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Wer bestimmt, was gelesen wird? Bei Bauform 1 der Ort des Cursors. Bei 2 und 3 das Werkzeug selbst.

Kann es etwas ausführen? Bei Bauform 1 nein. Bei 2 so viel, wie in den Einstellungen steht, bei 3 alles.

Wann sehen Sie eine Änderung? Bei 1, bevor sie gilt. Bei 2 und 3, nachdem sie geschrieben ist, und bei 3 nur, wenn Sie danach sehen.

Alle drei nebeneinander ist der Normalfall

Es gibt keine Entscheidung zu treffen, bei der eine Bauform gewinnt. In der Praxis benutzt man alle drei am selben Tag: die Code-Completion beim Schreiben von Hand, den Agenten in der Entwicklungsumgebung für eine überschaubare Änderung mit Blick darauf, die Kommandozeile für alles, was lange läuft oder viele Dateien anfasst.

Wer heute anfängt, fängt trotzdem am besten mit Bauform 3 an. Der Grund ist nicht ihre Güte: Dort wird sichtbar, was in den anderen verborgen abläuft.

Was bei der Auswahl wirklich zählt

Weniger, als man denkt, hängt am Modell dahinter, und Tiefe 2 sagt, warum. Eher diese vier Dinge:

• Wo die Daten hingehen. Läuft das Modell beim Anbieter oder bei Ihnen? Bei fremdem Code ist das keine Geschmacksfrage.
• Was es kostet und wie abgerechnet wird. Pauschale je Monat oder Abrechnung nach Verbrauch. Bei Bauform 3 kann derselbe Auftrag je nach Vorgehen ein Vielfaches kosten.
• Ob Sie eigene Regeln hinterlegen können. Gegenstand von Kapitel 03.
• Ob es sich einbauen lässt. Ein Werkzeug, das nur mit einem Menschen davor läuft, taugt nicht für alles, was regelmäßig geschehen soll.

Der sichtbare Unterschied zwischen den Bauformen ist die Oberfläche. Der wirksame ist, was das Werkzeug lesen und ausführen darf, und beides hängt weniger am Hersteller als an einer Handvoll Entscheidungen, die man selbst trifft.

Was der Agent zu Beginn sieht

Ein verbreiteter Irrtum: Ein Agent im Projektverzeichnis kenne das Projekt. Er kennt es nicht. Er sieht zu Beginn dasselbe wie jemand, der das Verzeichnis zum ersten Mal öffnet, und muss sich alles Weitere holen.

Wie er das tut, unterscheidet sich, und der Unterschied ist spürbar.

Über eine Übersicht. Aider baut eine Karte des Projekts auf, in der die wichtigsten Namen und Zusammenhänge stehen, und legt sie in den Kontext. Vorteil: Der Agent weiß von Anfang an, was es gibt. Nachteil: Die Karte kostet Platz, bei jedem Aufruf.

Über Suche bei Bedarf. Andere Werkzeuge starten ohne Übersicht und suchen sich, was sie brauchen, wenn sie es brauchen. Vorteil: Der Kontext bleibt frei. Nachteil: Der Agent findet nur, wonach er sucht, und wonach er sucht, rät er.

Praktisch heißt das: Etwas, das an einer unerwarteten Stelle steht oder anders heißt als vermutet, findet ein suchender Agent oft nicht. Er baut es dann ein zweites Mal. Das ist eine der Arten, wie doppelter Code aus Agentenarbeit entsteht. Wie oft sie gegenüber den anderen vorkommt, ist nirgends erhoben. Sie steht hier, weil der Aufbau sie erzeugt: Ein besseres Modell sucht an derselben falschen Stelle.

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Der Kontext ist die knappe Größe

Was ein Agent liest, steht danach in seinem Kontextfenster und geht bei jedem weiteren Schritt erneut mit. Die Mechanik dazu steht in Grundkurs, Kapitel 05 und Grundkurs, Kapitel 08, die Folgen für diese Arbeitsweise sind eigen.

Eine Sitzung, die lange läuft, füllt sich. Am Anfang stehen die Anweisungen, dann die gelesenen Dateien, dann jede Tool-Ausgabe, dann die eigenen Zwischenschritte. Bevor das Fenster überläuft, greift das Werkzeug ein und ersetzt das Bisherige durch eine Zusammenfassung. Genau dann bemerkt man es an der Arbeit: Der Agent vergisst, was zu Beginn vereinbart war, oder wiederholt etwas, das schon erledigt ist. Wer die Zusammenfassung schreibt, entscheidet damit über das Überleben jeder Einzelheit, und das ist der Gegenstand von Kapitel 05.

Die Gegenmittel sind unspektakulär und wirksam. Eine Sitzung je Thema statt einer langen. Große Ausgaben in eine Datei umleiten und daraus nur das Nötige lesen. Und die Sachen, die immer gelten, dorthin schreiben, wo sie bei jedem Start wieder dastehen, statt sie im Gespräch zu wiederholen.

Berechtigungen, und warum sie schnell aufweichen

Werkzeuge der Bauform 3 fragen, bevor sie etwas ausführen. Am ersten Tag findet man das richtig, am dritten lästig. Dann setzt man eine Allowlist, damit die harmlosen Befehle ohne Rückfrage durchlaufen, und irgendwann steht darauf mehr, als man noch überblickt.

Zwei Dinge, die dabei regelmäßig übersehen werden.

Eine Rückfrage, die niemand beantwortet, ist ein Ausschalter. Läuft ein Agent nachts oder in einem automatischen Ablauf, hält ihn jede Rückfrage an, bis eine Frist abläuft. Wer das nicht bedenkt, baut eine Sicherung, die zuverlässig verhindert, dass überhaupt etwas passiert.

Eine Allowlist beschreibt Befehle. Was daraus folgt, steht nicht darauf. Ein erlaubtes Werkzeug kann fremde Inhalte lesen, und in fremden Inhalten kann eine Anweisung stehen. Bis hierher ist das eine Überlegung. Der größte Vorfall des Jahres (externe Seite, huggingface.co) belegt sie nicht: Dort war der Agent der Angreifer, und er lief in einer Auswertung, für die der Betreiber die Schutzschichten eigens abgeschaltet hatte. Was er zeigt, ist die Reichweite eines Modells ohne Bremsen. Was eine Tool-Liste leisten kann und wo die Umgebung einspringen muss, steht in Grundkurs, Kapitel 09.

Der praktische Schluss daraus ist nicht, auf Agenten zu verzichten. Er lautet: Was ein Agent anrichten kann, ergibt sich aus dem, worauf er Zugriff hat, und das ist eine Entscheidung beim Einrichten. Ein Agent in einem Wegwerf-Baum mit eigenen Zugangsdaten ist ein anderes Risiko als einer im Hauptverzeichnis mit den Schlüsseln des Benutzers.

Das Modell ist austauschbar geworden, in Grenzen

Vor zwei Jahren war die Wahl des Werkzeugs zugleich die Wahl des Modells. Heute steht bei vielen eine Liste zur Auswahl, und Aider treibt es am weitesten:

Aider can work also with local models, for example using Ollama (externe Seite, aider.chat)

Auf derselben Seite steht der Preis, ein paar Zeilen tiefer:

Be aware that aider may not work well with less capable models. (externe Seite, aider.chat)

Der Grund ist derselbe, aus dem ein Werkzeug überhaupt etwas ändern kann: Es erwartet die Änderung in einer bestimmten Form und bucht ein, was es wiedererkennt. Ein Modell, das diese Form verfehlt, kann guten Code schreiben, ohne dass sich eine einzige Datei ändert. Austauschbar heißt also gegen ein Modell, das dazu in der Lage ist, und wie lang die Liste dieser Modelle ist, unterscheidet die Werkzeuge mehr als ihre Oberfläche.

Damit verschiebt sich, worauf es bei der Auswahl ankommt. Die Frage nach dem besten Modell tritt zurück, und diese vier treten vor:

• Wie geht das Werkzeug mit Fehlern um? Merkt es, dass ein Befehl fehlschlug, und was macht es dann?
• Wie viel vom Kontext verbraucht es selbst, bevor Sie ein Wort geschrieben haben? Angebundene Tools kosten Platz, auch ungenutzt.
• Lässt sich etwas dranbauen? Eigene Abläufe, eigene Prüfungen, eigene Auslöser.
• Läuft es ohne Menschen davor?

Die letzten beiden Punkte trennen ein Werkzeug, mit dem man arbeitet, von einem, auf dem man etwas aufbaut. Für Bauform 1 und 2 sind sie unwichtig, für 3 sind sie der Grund, sie zu wählen.

Wo die Bauformen sich überschneiden

Die Grenzen sind unscharf geworden. Entwicklungsumgebungen haben eine eingebaute Kommandozeile, Kommandozeilen-Agenten bekommen Oberflächen, und Anbieter bieten beides an.

Das ändert an der Ordnung nichts, weil sie an drei Fragen hängt statt an Produktnamen: Wer entscheidet, was gelesen wird? Was darf ausgeführt werden? Wann sehen Sie die Änderung?

Ein Werkzeug, das alle drei Antworten dem Werkzeug überlässt, ist Bauform 3, auch wenn es ein Fenster hat.

Was nach zwei Jahren übrig geblieben ist

Von den Werkzeugen, die 2024 als führend galten, sind einige verschwunden, gekauft oder eingestellt. Das ist bei einem Gebiet in dieser Geschwindigkeit normal und der Grund, warum dieses Kapitel keine Rangliste enthält.

Was geblieben ist, sind die Bauformen. Die Code-Completion von 2021 gibt es unverändert, und die Kommandozeile ist seit Aider dieselbe Idee. Der Agent in der Entwicklungsumgebung hat in derselben Zeit an Rechten gewonnen, wie der Yolo-Modus in Tiefe 1 zeigt: Geblieben ist die Bauform, gewandert sind ihre Voreinstellungen. Wer eine davon verstanden hat, kommt mit einem neuen Werkzeug derselben Bauform binnen einer Stunde zurecht, und die Einstellungen sieht er sich trotzdem an.

Ab einer gewissen Nutzungsdauer entscheidet über die Tool-Wahl nichts von dem, was in Vergleichstabellen steht. Es entscheiden drei Dinge: was der Sockel im Kontext kostet, ob mehrere Läufe nebeneinander möglich sind, und ob sich das Werkzeug ohne Menschen davor betreiben lässt.

Der Sockel

Bevor Sie ein Wort geschrieben haben, steht im Kontext bereits eine beträchtliche Menge Text: die Systemanweisung des Werkzeugs, die Beschreibung jedes angebundenen Tools, die Projektanweisungen, oft eine Verzeichnis- oder Projektübersicht.

Das ist der Sockel, und er ist keine Kleinigkeit. Er wird bei jedem einzelnen Schritt mitgeschickt, also bei jedem Tool Call innerhalb einer Aufgabe. Wer zwanzig Tools anbindet, weil sie einmal nützlich sein könnten, zahlt deren Beschreibungen bei jedem Schritt mit.

Zwei Folgerungen, beide unbequem:

Weniger angebundene Tools sind oft besser, und der zweite Grund neben den Kosten steht in den Empfehlungen des Protokolls, über das solche Tools meistens angebunden werden. Alle Beschreibungen vorab zu laden, kostet dreifach:

wastes tokens, increases latency, and degrades model performance (externe Seite, modelcontextprotocol.io)

Wo die Grenze liegt, sagt dieselbe Seite, und sie liegt höher, als eine Faustzahl vermuten lässt:

For a handful of tools, this is perfectly reasonable. (externe Seite, modelcontextprotocol.io)

Zum Problem wird es bei Dutzenden angebundenen Servern mit Hunderten von Tools, und als Schwelle für das Nachladen bei Bedarf nennt die Seite einen Anteil am Kontextfenster von einem bis fünf Prozent. Wer fünf Tools angebunden hat und sich um die Auswahlgüte sorgt, sorgt sich damit an der falschen Stelle. Das Thema steht in Grundkurs, Kapitel 09: Angebunden heißt nicht benutzt, und was gewählt wird, entscheidet die Beschreibung.

Der Sockel ist nicht konstant. Er ändert sich mit jedem Update des Werkzeugs, ohne dass jemand etwas tut. Wer seine Kosten je Aufgabe kennt, sollte sie gelegentlich neu messen.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Nebenläufigkeit

Der Punkt, der in Vergleichen fehlt und in der Praxis am meisten ausmacht: Können mehrere Läufe gleichzeitig arbeiten, ohne sich zu behindern?

Bei Bauform 1 und 2 stellt sich die Frage nicht, dort sitzt ein Mensch davor. Bei Bauform 3 ist sie zentral, denn dort will man irgendwann drei Aufgaben parallel laufen lassen.

Das geht nur, wenn jeder Lauf seinen eigenen Worktree hat. Zwei Agenten im selben Verzeichnis erzeugen genau die Sorte Fehler, die hinterher niemand zuordnen kann: Der eine committet, was der andere gerade schreibt. Wie getrennte Bäume daraus eine Eigenschaft des Aufbaus machen, steht in Kapitel 04.

Getrennt sind dabei die Dateien im Baum. Alles andere teilen die Läufe weiter, und darüber stolpert man beim ersten Mal: dieselbe Datenbank, derselbe Port, dieselben Cache, dieselben Zugangsdaten. Auf dieser Seite hier war es eine Verknüpfung. Ein Aufräumbefehl im zweiten Baum löschte den Bau-Cache des ersten mit, weil beide auf dasselbe Verzeichnis zeigten. Ein Baum trennt, was in der Versionsverwaltung liegt.

Ein Werkzeug, das das nicht zulässt, weil es einen festen Zustand im Projektverzeichnis hält, deckelt damit, wie viel man mit ihm tun kann.

Was Abrechnung nach Verbrauch praktisch heißt

Bei Pauschale je Monat ist die Rechnung vorhersehbar und die Nutzung gedeckelt. Bei Abrechnung nach Verbrauch ist es umgekehrt, und die Streuung ist größer, als die Preistabelle vermuten lässt.

Derselbe Auftrag kostet je nach Vorgehen ein Vielfaches. Die Treiber:

• Wie oft der Kontext neu geschickt wird. Eine Aufgabe mit dreißig Tool-Schritten schickt den Sockel dreißigmal.
• Ob ein Cache greift. Bei gleichbleibendem Anfang des Kontexts wird der günstiger abgerechnet. Wer die Anweisungen ständig ändert, verliert das.
• Wie viel gedacht wird. Was ein Modell vor der Antwort denkt, wird als Ausgabe abgerechnet, und Ausgabe ist die teure Spalte. Der Beleg dafür steht in Grundkurs, Kapitel 10.
• Wie viele Läufe scheitern. Ein abgebrochener Lauf kostet alles, was bis dahin verbraucht wurde, und liefert dafür nichts.

Die praktische Regel lautet deshalb, den Aufwand zur Aufgabe zu wählen. Eine mechanische Umbenennung über vierzig Dateien braucht kein Nachdenken, eine Architekturfrage keine dreißig Tool-Schritte.

Die Kante zwischen Werkzeug und Bausatz

An einem Punkt hört die Tool-Wahl auf und etwas anderes fängt an: wenn man mit dem Agenten aufhört zu arbeiten und beginnt, etwas zu bauen, das selbst arbeitet.

Der Übergang ist erkennbar an einer einzigen Frage: Läuft es, wenn niemand zusieht?

Alles daran hängt:

• Es braucht eine Anmeldung, die ohne Browserfenster funktioniert.
• Es braucht ein Zeitlimit, sonst hängt es bis zum nächsten Neustart.
• Es braucht eine Aussage darüber, was ein Fehlschlag ist, und einen Weg, ihn zu melden. Ein Lauf, der still nichts tut, sieht von außen aus wie einer, der nichts zu tun fand.
• Es braucht einen definierten Ausgangszustand, sonst arbeitet es auf dem, was gerade herumliegt.

Das ist der Punkt, an dem aus Vibe-Coding Betrieb wird, und ab dort gelten die Regeln des Betriebs. Wer einen nächtlichen Lauf einrichtet und ihn nicht überwacht, hat sich einen Dienst gebaut, dessen Ausfall er zufällig bemerkt.

Die Angriffsfläche wächst mit den Rechten

Ein Agent mit Netzzugang und Ausführungsrecht liest Inhalte, die andere geschrieben haben, und handelt danach. Damit ist jeder gelesene Text eine mögliche Anweisung.

An dieser Stelle laufen zwei Risiken zusammen, die gern verwechselt werden. Das eine ist die untergeschobene Anweisung: Der Agent tut, was in einer fremden Datei steht. Das andere ist der Ausbruch: Der Agent oder der von ihm ausgeführte Code findet einen technischen Fehler und verlässt seine Umgebung. Die beiden dokumentierten Fälle des Jahres 2026 gehören zur zweiten Sorte.

Der Angriff auf Hugging Face (externe Seite, huggingface.co) im Juli will dabei mit Vorsicht gelesen werden: Der Agent lief in einer Auswertung, für die der Betreiber die Schutzschichten eigens abgeschaltet hatte. Der zweite Fall zeigt die Grenze an der Sandbox selbst. Ein Sicherheitsforscher legt Schritt für Schritt offen (externe Seite, accomplish.ai), wie ein Agent aus seiner virtuellen Maschine ausbricht, und hält fest, dass der dafür genutzte Fehler der austauschbare Teil der Kette ist. Er arbeitet an einem konkurrierenden Entwurf und schreibt das in seinem Schlussabschnitt dazu.

Was daraus folgt, ist eine Frage der Auslegung statt einer Liste von Verboten: Was hat der Agent überhaupt in Reichweite? Ein Lauf mit eigenen, eng geschnittenen Zugangsdaten in einem eigenen Verzeichnis richtet im schlimmsten Fall dort Schaden an. Ein Lauf mit den Rechten des Benutzers richtet ihn überall an.

Woran man ein Werkzeug nach einer Woche beurteilt

Nicht daran, wie gut das erste Ergebnis war. Sondern:

Wie oft musste eine Änderung zurückgenommen werden? Wie oft hat es behauptet, etwas getan zu haben, das es nicht getan hat? Wie lange dauert es von der Beschreibung bis zu dem Punkt, an dem Sie das Ergebnis verantworten würden?

Die dritte Zahl schließt die beiden anderen ein, denn Rücknahmen und falsche Erfolgsmeldungen kosten genau die Zeit, die sie misst. Bei einem schnellen Werkzeug mit schlechter Rückmeldung fällt sie deshalb schlechter aus als bei einem langsamen mit guter.