9. Die Werkzeuge

Die Werkzeuge

Die hier beschriebenen Produkte sind zum Teil erst seit 2024 auf dem Markt, ihre Funktionen ändern sich im Quartalstakt, und es kann sein, dass einige der hier beschriebenen Werkzeuge in einem Jahr nicht mehr existieren.

Beständig sind dagegen die Bauformen, in denen diese Werkzeuge auftreten, und die Auswahlkriterien am Ende des Kapitels. Die Produktbeschreibungen dazwischen sind Beispiele dafür. Wer die Bauformen kennt, ordnet auch ein Werkzeug ein, das hier nicht vorkommt.

Stand Sommer 2026

Alle Angaben in diesem Kapitel sind auf dem Stand Sommer 2026 und ausdrücklich nicht gepflegt. Prüfen Sie Funktionsumfang, Preise und Lizenzbedingungen an der Quelle, bevor Sie darauf eine Entscheidung stützen, und notieren Sie in Ihrer Arbeit das Datum Ihrer Recherche.

Vier Bauformen

Praktisch jedes Werkzeug fällt in eine dieser Kategorien, und die Bauform bestimmt mehr über den Arbeitsalltag als das Modell dahinter.

Bauform	Wo es läuft	Charakter
IDE-Erweiterung	in VS Code, JetBrains, Neovim	integriert, Diffs im Editor, vertraute Umgebung
Terminal (CLI/TUI)	in der Shell	skriptbar, über SSH nutzbar, unabhängig von der IDE
IDE-Fork	eigene Anwendung, meist VS-Code-Abkömmling	tiefere Integration, aber Sie wechseln die IDE
Cloud-Agent	auf fremder Infrastruktur, angestoßen über Issue oder Pull Request	asynchron, arbeitet ohne Sie, Ergebnis kommt als Merge Request

GitHub Copilot

Das älteste Produkt der Gruppe und immer noch das verbreitetste. Es begann 2021 als reine Codevervollständigung im Editor und ist inzwischen ein Bündel, das alle vier Bauformen abdeckt: Vervollständigung, Chat, agentisches Bearbeiten mehrerer Dateien im Editor, ein Terminal-Client und ein Cloud-Agent, dem man ein GitHub-Issue zuweist und der mit einem Pull Request zurückkommt.

Die Integration in VS Code und die JetBrains-Familie ist die beste im Feld, die Einstiegshürde entsprechend niedrig. Die Bindung an GitHub-Issues und Pull Requests passt zu Teams, die dort ohnehin arbeiten, Modelle sind wählbar, und über GitHub Education gibt es für Schülerinnen, Schüler und Lehrende kostenlose Zugänge, was für den Unterricht den Ausschlag gibt.

Schwächer wird es dort, wo es ursprünglich nicht herkommt. Die Vervollständigung ist stark, der Agent ist es weniger; bei Aufgaben, die über mehrere Dateien und viele Schritte laufen, kommt Copilot an Werkzeuge nicht heran, die von Grund auf als Agent gebaut wurden. Dazu hängt der Funktionsumfang vom Abonnement ab, was Vergleiche mühsam macht. Als Standardeinstieg taugt es trotzdem, besonders in Teams mit GitHub-Workflow und in Klassen, in denen der Zugang über GitHub Education läuft.

Claude Code

Der Terminal-Agent von Anthropic, daneben als Desktop-Anwendung, im Browser und als IDE-Erweiterung verfügbar. Konsequent als Agent entworfen und nicht als Vervollständigung mit Zusatzfunktionen.

Bei längeren, mehrschrittigen Aufgaben in gewachsenem Code liegt es im Sommer 2026 vorn. Der Plan Mode (Kapitel 10) ist hier am ausgereiftesten, dazu kommen die Bausteine aus dem vorigen Kapitel: CLAUDE.md als Projektkontext, Subagenten, MCP-Anbindung, Hooks für eigene Prüfungen in der Schleife und ein Berechtigungssystem mit Freigabelisten. Weil es im Terminal läuft, funktioniert es über SSH auf dem Server aus der 4. Klasse genauso wie lokal, und es lässt sich in Skripte und CI-Läufe einbauen.

Dafür ist es an Anthropic-Modelle gebunden, die Bedienung im Terminal ist gewöhnungsbedürftig für alle, die aus der IDE kommen, und bei intensiver Nutzung ist es das teuerste Werkzeug der Gruppe: Lange autonome Läufe mit hoher Denkstufe kosten Tokens, was unmittelbar aus Kapitel 4 und 5 folgt. Es lohnt sich bei größeren Umbauten und bei Fehlersuche in unbekanntem Code, also überall dort, wo eine Aufgabe über eine Datei hinausgeht, und für alle, die ohnehin im Terminal leben.

OpenCode

Ein quelloffener Terminal-Agent, der bewusst modellagnostisch gebaut ist: Sie bringen Ihren eigenen Zugang mit, zu welchem Anbieter auch immer, oder Sie hängen ein lokales Modell aus Kapitel 6 daran.

Keine Anbieterbindung, weder beim Modell noch beim Werkzeug selbst. Der Quellcode ist einsehbar, was für den Unterricht ein eigener Wert ist: Man kann nachlesen, wie die Agentenschleife tatsächlich implementiert ist, statt sie sich vorzustellen. Die Anbindung an Language Server bringt dem Agenten dieselben Typinformationen, die Ihre IDE hat, und Sitzungen lassen sich fortsetzen und teilen. Die Bausteine aus Kapitel 8 sind vorhanden: AGENTS.md als Regeldatei, Skills als SKILL.md, MCP-Anbindung und Subagenten. Skills und Rules werden dabei auch aus den Verzeichnissen der anderen Werkzeuge gelesen, also aus .claude/skills/ und ersatzweise CLAUDE.md, was einen Wechsel ohne Umschreiben erlaubt.

Es ist weniger poliert als die kommerziellen Produkte, braucht mehr Einrichtungsaufwand, und die Qualität hängt vollständig davon ab, welches Modell Sie dahinterhängen. Als quelloffenes Projekt bewegt es sich schnell, was Vor- und Nachteil zugleich ist. Die passende Wahl, wenn Sie mehrere Modelle vergleichen wollen, wenn lokale Modelle eine Rolle spielen, wenn Anbieterunabhängigkeit eine Anforderung ist, oder wenn Sie verstehen wollen, was in der Schleife passiert.

Aider

Einer der ältesten Vertreter der Gattung, quelloffen und im Terminal zu Hause. Der Entwurf dreht sich um zwei Ideen, die beide unmittelbar aus früheren Kapiteln bekannt sind.

Die erste ist Git als Sicherheitsnetz: Aider legt für jede Änderung einen eigenen Commit an, mit passender Nachricht. Was in Kapitel 8 als Betriebsregel steht („ein Agent arbeitet nie auf uncommitteten Änderungen”), ist hier in das Werkzeug eingebaut. Jeder Schritt lässt sich einzeln zurücknehmen, und die Historie zeigt, was der Agent getan hat, statt eines gewachsenen Diffs am Ende.

Die zweite ist ausdrückliche Kontextsteuerung: Sie bestimmen mit /add und /drop, welche Dateien im Kontext liegen. Für alles übrige erzeugt Aider eine Repo-Map, eine verdichtete Übersicht der Struktur, statt ganze Dateien mitzuschicken. Das ist Retrieval ohne Vektorindex (Kapitel 7) und Kontext-Engineering aus Kapitel 4 als Bedienkonzept, und deshalb eignet sich Aider gut zum Lernen: Man sieht, was im Kontext liegt, weil man es selbst hineingelegt hat.

Aider ist modellagnostisch, arbeitet also auch mit lokalen Modellen aus Kapitel 6, und kennt einen Architect-Modus, in dem ein Modell plant und ein zweites die Änderungen schreibt. Dafür ist es weniger autonom als die neueren Agenten: Es arbeitet enger am einzelnen Schritt und nimmt Ihnen die Führung nicht ab. Für kleine bis mittlere Änderungen ist das ein Vorteil, für einen Umbau über zwanzig Dateien ein Nachteil.

Plandex

Ebenfalls quelloffen und im Terminal, aber auf die Aufgaben zugeschnitten, an denen die anderen Werkzeuge scheitern: lange Läufe über viele Dateien.

Das kennzeichnende Merkmal ist ein Sandkasten. Änderungen landen nicht in Ihren Dateien, sondern in einem geschützten Bereich, den Sie danach mit plandex diff ansehen und mit plandex apply übernehmen oder verwerfen. Bis zu diesem Moment ist Ihr Arbeitsbaum unberührt. Dazu kommen versionierte Pläne mit Verzweigungen und einer Rücksetzfunktion.

Damit ist Plandex die Trennung aus Kapitel 10 als Produkteigenschaft: Was dort ein Vorgehen ist, das Disziplin verlangt, erzwingt dieses Werkzeug durch seine Bauweise. Wer sich das Prüfen vor der Übernahme angewöhnen will, bekommt hier die Umgebung dazu.

Der Preis ist ein eigener Arbeitsablauf, den man lernen muss, und mehr Einarbeitung als bei einem Werkzeug, das einfach im Projektverzeichnis losläuft. Für eine einzelne kleine Änderung ist der Aufwand zu groß.

Aide

Ein quelloffener VS-Code-Abkömmling mit eingebautem agentischem Bearbeiten. Der Ansatz ist das Gegenteil von Claude Code und OpenCode: Statt die IDE zu verlassen, wird der Agent in die IDE hineingebaut, mit Diffs, Vorschau und Zurücknehmen an der gewohnten Stelle.

Vertraute Oberfläche für alle, die aus VS Code kommen; Erweiterungen und Einstellungen lassen sich übernehmen. Änderungen sind sichtbar, bevor sie übernommen werden, was den Prüfschritt aus Kapitel 8 an die Stelle rückt, an der man ihn tatsächlich macht. Der Quellcode ist offen.

Der Preis dafür ist die Bauform. Ein IDE-Fork hinkt der Basis hinterher, Sie wechseln die Anwendung, in der Sie den ganzen Tag arbeiten, und das Feld der VS-Code-Forks ist eng besetzt und volatil; man wettet dabei auch auf den Fortbestand des Projekts. Interessant, wenn agentisches Arbeiten stattfinden soll, ohne dass Sie die IDE verlassen, und wenn quelloffen ein Kriterium ist.

Aide und Aider sind zwei verschiedene Werkzeuge

Die Namen unterscheiden sich um einen Buchstaben und die Werkzeuge in fast allem: Aider ist ein Terminal-Agent mit Git-Anbindung, Aide ein VS-Code-Abkömmling mit Agent in der Oberfläche. Achten Sie beim Recherchieren und beim Zitieren in Ihrer Arbeit darauf, welches der beiden Sie meinen.

Weitere Namen, die Sie hören werden

Ohne Anspruch auf Vollständigkeit, damit die Begriffe einzuordnen sind: Cursor und Windsurf sind kommerzielle VS-Code-Forks derselben Kategorie wie Aide, mit größerer Verbreitung. Continue und Cline sind quelloffene VS-Code-Erweiterungen, modellagnostisch. Zed ist ein neu gebauter Editor mit eingebauten Agentenfunktionen. Gemini CLI und Codex CLI sind Terminal-Agenten von Google und OpenAI, direkte Gegenstücke zu Claude Code. Dazu kommen die Cloud-Varianten der großen Anbieter, denen man eine Aufgabe zuweist und die asynchron mit einem Merge Request antworten.

Werkzeuge daneben, die keine Coding-Agenten sind

Im selben Umfeld tauchen Namen auf, die in eine andere Kategorie gehören. Sie schreiben keinen Code, sondern bedienen die Schichten darüber und darunter, und wer sie mit den Agenten in einen Topf wirft, vergleicht Dinge, die nichts miteinander zu tun haben.

Open WebUI ist eine selbst gehostete Weboberfläche für Sprachmodelle, im Stil der bekannten Chatdienste und meist als Container betrieben. Sie führt selbst kein Modell aus, sondern spricht Ollama und jede OpenAI-kompatible Schnittstelle an, passt also genau auf die Architektur aus Kapitel 6. Ihr eigentlicher Wert im Betrieb ist das, was den Arbeitsplatzwerkzeugen dort fehlt: Mehrbenutzerbetrieb mit Anmeldung, Rollen und Rechten, dazu Modellverwaltung, eine Sammlung geteilter Prompts und Dokumenten-Upload mit Rückgriff auf die eigenen Unterlagen, also RAG nach Kapitel 7, fertig eingebaut. In einer Schule oder einem Betrieb ist sie die Oberfläche für alle, die nicht im Terminal arbeiten, und damit die dritte Schicht über Gateway und Inference-Server.

Agentlytics beantwortet eine Frage, die kein Agent über sich selbst beantwortet: Was ist hier eigentlich passiert? Gestartet mit bunx agentlytics, liest es die Sitzungsdaten ein, die die installierten Werkzeuge ohnehin lokal ablegen, und bereitet sie unter http://localhost:4637 im Browser auf. Es schickt nichts an einen Dienst; ausgewertet wird, was auf der eigenen Platte liegt.

Abb. 9.1: Agentlytics wertet die lokal gespeicherten Sitzungen der installierten Coding-Agenten aus. Im Beispiel verteilen sich 321 Sitzungen auf zwei Werkzeuge; daneben stehen Tokens, Cache-Trefferquote, geschätzte Kosten und der Anteil selbst geschriebenen Codes.

Screenshot, Sommer 2026

Für den Unterricht ist das Werkzeug aus einem anderen Grund brauchbar als für den Betrieb: Es macht die Größen sichtbar, die in diesem Anhang nur als Begriffe vorkommen. Die Cache-Trefferquote steht als Zahl da, statt als Erklärung in Kapitel 4. Der Anteil an Tokens, den das Modell erzeugt hat, lässt sich dem gegenüberstellen, den Sie selbst getippt haben, was die Selbsteinschätzung aus Kapitel 12 von einer Vermutung in eine Messung verwandelt. Und die geschätzten Kosten je Sitzung beantworten die Frage, ob eine Arbeitsweise tragfähig ist, bevor die Monatsrechnung sie beantwortet.

Im Betrieb liegt der Nutzen woanders: Sobald mehrere Teams mit mehreren Werkzeugen arbeiten, ist die Frage, wofür die Tokens aufgewendet werden und wo ein Werkzeug nur beschäftigt wirkt, sonst nicht zu beantworten.

Der Vergleich

Werkzeug	Bauform	Quelloffen	Modelle	Stärke	Schwäche
Copilot	Erweiterung, CLI, Cloud	nein	mehrere, wählbar	Vervollständigung, GitHub-Integration	schwächer bei langen Läufen
Claude Code	Terminal, Desktop, Web, IDE	nein	Anthropic	lange agentische Läufe	Anbieterbindung, Kosten
OpenCode	Terminal	ja	beliebig, auch lokal	Unabhängigkeit, Transparenz	Politur, Einrichtung
Aider	Terminal	ja	beliebig, auch lokal	Commit je Änderung, sichtbarer Kontext	weniger autonom bei großen Umbauten
Plandex	Terminal	ja	beliebig, auch lokal	Sandkasten vor der Übernahme	eigener Arbeitsablauf, Einarbeitung
Aide	IDE-Fork	ja	mehrere	Agent in gewohnter IDE	Fork-Pflege, IDE-Wechsel

Kontextmechanismen aus Kapitel 8, Abrechnung und Einsatz im Unterricht:

Werkzeug	Rules	Skills	Abrechnung	Im Unterricht
Copilot	.github/copilot-instructions.md, AGENTS.md	ja, .github/skills/	Abo je Nutzer	über GitHub Education zugänglich
Claude Code	CLAUDE.md, .claude/rules/	ja, .claude/skills/	Abo oder pro Token	für die Projektarbeit
OpenCode	AGENTS.md, ersatzweise CLAUDE.md	ja, .opencode/skills/	reine Modellkosten	für Vergleiche und Analyse
Aider	CONVENTIONS.md, über --read geladen	nein, nur von Hand als Kontextdatei	reine Modellkosten	für Git-Workflow und Kontextsteuerung
Plandex	Kontextdateien im Plan	nein	Modellkosten, Cloud optional	für Plan und Build aus Kapitel 10
Aide	Regeldateien	nein	Modellkosten	für IDE-orientiertes Arbeiten

Wonach man auswählt

Diese sieben Fragen überleben jedes einzelne Produkt in der Tabelle.

1. Wo liegt der Code, und was darf ihn verlassen? Die Frage aus Kapitel 6, hier noch einmal. Bei einem Betrieb mit Vertraulichkeitsvereinbarung entscheidet sie allein und schließt die meisten Optionen aus.

2. Welche Modelle sind erreichbar? Anbieterbindung ist ein Risiko und manchmal eine bewusste Entscheidung für Qualität. Beides ist vertretbar, unbewusst sollte es nicht sein.

3. Passt die Bauform zur Arbeitsweise? Wer den ganzen Tag in der IDE ist, wird mit einem Terminal-Agenten unglücklich, und umgekehrt. Das entscheidet mehr über die tatsächliche Nutzung als jede Funktionsliste.

4. Wie funktioniert die Freigabe? Welche Rückfragen kommen, wie fein lässt sich das einstellen, lässt sich der Agent einsperren (Kapitel 8)?

5. Was kostet es unter Last? Nicht der Listenpreis, sondern die Rechnung nach einem Monat echter Arbeit. Bei Abrechnung pro Token gehört ein Budget dazu.

6. Wie gut fügt es sich in den Team-Workflow? Merge Requests, CI, Review. Ein Werkzeug, das dabei quer liegt, wird umgangen.

7. Wie kommt man wieder heraus? Was bleibt, wenn Sie das Werkzeug wechseln? Eine AGENTS.md und ein Repository mit Tests bleiben. Eine Sammlung werkzeugspezifischer Konfiguration bleibt nicht.

Eine Empfehlung

Allgemein: Lernen Sie zwei Werkzeuge aus verschiedenen Bauformen, nicht fünf. Eine IDE-Integration für den Alltag und einen Terminal-Agenten für die größeren Aufgaben deckt das Spektrum ab und macht die Unterschiede sichtbar. Wer nur eines kennt, hält dessen Eigenheiten für Naturgesetze.

Und unabhängig vom Werkzeug: Die Zeit, die Sie in Tests, Typen und eine gute Projektdokumentation stecken, wirkt bei jedem Werkzeug und überlebt jeden Produktwechsel. Die Zeit, die Sie in werkzeugspezifische Kniffe stecken, ist mit dem nächsten Wechsel weg. Das ist keine Nebenbemerkung, sondern die brauchbarste Investitionsregel in diesem Feld.

Häufige Stolperfallen

1. Das Werkzeug nach einem Demo-Video auswählen. Demos zeigen grüne Wiesen; Ihre Arbeit ist gewachsener Code.
2. Nur ein Werkzeug kennen. Dessen Eigenheiten erscheinen dann als Eigenschaften der Technologie.
3. Die Datenschutzfrage zuletzt stellen. Sie schließt Optionen aus und gehört an den Anfang.
4. Bei Abrechnung pro Token ohne Budget starten. Die erste Monatsrechnung ist regelmäßig eine Überraschung.
5. Alles werkzeugspezifisch konfigurieren. Beim nächsten Wechsel fängt man von vorne an.
6. Ein Werkzeug nehmen, das quer zum Team-Workflow liegt. Es wird umgangen, und dann hilft es niemandem.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

• Nennen: die vier Bauformen benennen und ein aktuelles Werkzeug jeweils zuordnen.
• Erklären: Stärken und Schwächen von GitHub Copilot, Claude Code, OpenCode, Aider, Plandex und Aide gegenüberstellen.
• Erklären: an Aider und Plandex zeigen, wie sich die Konzepte aus den Kapiteln 4, 7 und 9 in Produkteigenschaften niederschlagen.
• Beurteilen: anhand der sieben Kriterien für einen konkreten Anwendungsfall ein Werkzeug auswählen und die Wahl begründen.
• Beurteilen: die Datenschutz- und Anbieterbindungsfrage vor der Funktionsfrage stellen und die Folgen für die Auswahl darstellen.
• Beurteilen: unterscheiden, welche Investitionen werkzeugunabhängig wirken und welche mit einem Wechsel verloren gehen.
• Anwenden: ein neues, hier nicht beschriebenes Werkzeug selbstständig einordnen und bewerten.