Aider: ein Entwicklungsagent in CLI

#Was Aider ist und was es in Ihrem Repository tut

Aider ist ein quelloffener Programmierassistent für die Kommandozeile, der sich selbst als Pair Programming mit einer KI im Terminal beschreibt. Sie führen den Befehl aider in einem Git-Repository aus und beschreiben eine Änderung in natürlicher Sprache. Aider schlägt daraufhin Dateiänderungen vor, wendet sie an und speichert sie anschließend in einem Commit. Er funktioniert sowohl mit gehosteten Modellen (Claude, GPT, DeepSeek) als auch mit lokalen Modellen, die über Ollama oder LM Studio bereitgestellt werden. Damit ist er einer der wenigen Code-Agenten, die sich nutzen lassen, ohne dass eine Zeile Ihres Projekts den Rechner verlässt. Das offizielle Repository hat mehr als 49.000 Sterne auf GitHub.

Drei Dinge unterscheiden ihn von einem einfachen Chat. Erstens führt er eine Übersicht des Repositorys: Bei jeder Anfrage sendet er dem Modell eine Liste der Dateien mit ihren Klassen, Funktionen und wichtigsten Signaturen, sodass das Modell weiß, wo es suchen soll, ohne dass Sie ihm alles zeigen müssen. Zweitens ist er in Git integriert: Jede Änderung wird zu einem Commit, der sich rückgängig machen lässt. Schließlich führt er die von Ihnen vorgegebenen Befehle für Linter und Tests wiederholt aus und versucht, Fehler zu beheben. Er ist kein autonomer Agent, der das Web durchsucht oder Server startet, sondern ein über die Unterhaltung gesteuerter Code-Editor.

#Aider installieren

Der kürzeste offizielle Installationsweg führt über das Paket aider-install, das Aider in einer eigenen, isolierten Python-Umgebung installiert und bei Bedarf eine kompatible Python-Version herunterlädt. Voraussetzung für diesen Weg ist eine Python-Version zwischen 3.8 und 3.13. Für macOS, Linux und Windows gibt es auf uv basierende Installationsbefehle, die jeweils nur eine Zeile benötigen. Die frühere Methode mit pipx funktioniert weiterhin, doch die aktuelle Dokumentation empfiehlt aider-install.

python -m pip install aider-install
aider-install

# Vérifier
aider --version

Wechseln Sie anschließend in das Stammverzeichnis Ihres Projekts. Wenn der Ordner kein Git-Repository ist, bietet Aider an, eines zu erstellen. Es ist jedoch besser, das Repository selbst zu initialisieren: Das gesamte weiter unten beschriebene Sicherheitsnetz beruht auf Git.

#An Ollama anbinden, ohne in die Kontextfalle zu tappen

Die offizielle Dokumentation von Aider für Ollama beschreibt vier Schritte: die Variable OLLAMA_API_BASE setzen (die übliche Adresse ist http://127.0.0.1:11434), das Modell mit ollama pull herunterladen, den Server starten und anschließend aider mit dem Präfix ollama_chat/ vor dem Modellnamen aufrufen. Das Präfix ollama_chat/ wird ausdrücklich anstelle von ollama/ empfohlen.

export OLLAMA_API_BASE=http://127.0.0.1:11434
ollama pull devstral:24b
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# Dans un autre terminal, à la racine du projet
aider --model ollama_chat/devstral:24b

Die kostspieligste Falle ist das Kontextfenster. Ollama verwendet standardmäßig 2.000 Token Kontext, was für einen Code-Agenten winzig ist. Entscheidend ist dabei, dass es alles, was darüber hinausgeht, stillschweigend verwirft. Ohne es zu wissen, können Sie also mit einem Modell sprechen, das nur den Anfang Ihrer Dateien erhalten hat. Aider begrenzt das Problem: Standardmäßig stellt es das Kontextfenster von Ollama selbst auf die Größe jeder Anfrage plus 8.000 Token für die Antwort ein. Wenn Sie eine feste Größe bevorzugen, müssen Sie dafür eine Datei mit Modelleinstellungen verwenden, nicht die Hauptkonfigurationsdatei.

- name: ollama_chat/devstral:24b
  extra_params:
    num_ctx: 32768

Der Kontext benötigt Speicher: Der KV-Cache wächst mit dem Kontextfenster, und ein Modell mit 24 Milliarden Parametern, das in Q4 bereits etwa 14 GB belegt, lässt auf einer Karte mit 16 GB wenig Spielraum. Die Leitfäden zum Kontextfenster und zur Quantisierung des KV-Caches geben Anhaltspunkte zu den Größenordnungen.

#Welches lokale Modell für Aider

Aider ist so gut wie das Modell, das es steuert, und die Herausforderung ist zweifach: Das Modell muss über den Code nachdenken und ein striktes Format für Änderungen einhalten. Ein Modell, das dieses Format nicht befolgt, erzeugt Änderungen, die das Tool nicht anwenden kann. Die öffentliche Rangliste von Aider basiert auf 225 Exercism-Übungen in sechs Programmiersprachen und misst genau diese doppelte Fähigkeit. Sie wird von sehr großen gehosteten Modellen dominiert, während Modelle, die auf einem privaten Rechner Platz finden, deutlich schlechter abschneiden. Sehen Sie sich die Rangliste an, bevor Sie Ergebnisse auf Cloud-Niveau erwarten.

Für einen lokalen Rechner ist Devstral 24B, veröffentlicht von Mistral AI und All Hands AI, ein sinnvoller Ausgangspunkt: Es ist für Code-Agenten konzipiert, belegt in der Ollama-Bibliothek 14 GB und gibt ein Kontextfenster von 128.000 Tokens an. Bei einer GPU mit 12 GB oder weniger müssen Sie auf ein kleineres Modell wechseln und mehr Formatfehler in Kauf nehmen. Der Leitfaden „Bestes lokales LLM zum Programmieren“ vergleicht die aktuellen Kandidaten; dieser Leitfaden legt keine feste Rangliste fest, da sie sich zu schnell ändert.

#Eine erste Änderung, vom Prompt zum Commit

1. 01
   Die richtigen Dateien hinzufügen

   Starten Sie aider und übergeben Sie die zu bearbeitenden Dateien, beispielsweise aider src/api.py src/models.py. Die hinzugefügten Dateien sind diejenigen, die aider bearbeiten kann; der Rest des Repositorys ist dem Tool über die Repository-Karte bekannt.
2. 02
   Die Änderung präzise beschreiben

   Schreiben Sie eine vollständige Anfrage: „Füge einen GET-Endpoint /users/:id hinzu, der den Benutzer zurückgibt oder einen 404-Fehler, wenn der Benutzer nicht existiert.“ Eine unklare Anfrage erzeugt einen unklaren Diff.
3. 03
   Den Diff überprüfen

   Aider zeigt die Änderungen an und wendet sie an. Prüfen Sie sie mit /diff, bevor Sie fortfahren: Jetzt ist der richtige Zeitpunkt, sie abzulehnen, nicht erst nach drei weiteren Anfragen.
4. 04
   Commit prüfen

   Jede Bearbeitung wird mit einer beschreibenden Nachricht gespeichert. Wenn das Ergebnis schlecht ist, macht /undo den letzten von Aider erstellten Commit rückgängig.
5. 05
   Schritt für Schritt voranschreiten

   Fordern Sie anschließend Tests, die Behandlung des Grenzfalls und die Protokollierung an – jeweils einen Schritt nach dem anderen. Kleine Schritte halten den Kontext kurz und den Diff gut lesbar.

#Die relevanten Chat-Befehle

Aider bietet Dutzende Befehle, die mit einem Schrägstrich beginnen; eine Handvoll reicht zum Arbeiten aus. Die allgemeine Regel: Was Sie dem Chat nicht hinzugefügt haben, kann nicht geändert werden. Die Repository-Karte zeigt dem Modell jedoch, dass weitere Dateien existieren.

/add et /drop

Fügen dem Chat Dateien hinzu oder entfernen sie daraus. Das Entfernen von Dateien, die nicht mehr benötigt werden, schafft Platz im Kontext, was bei einem lokalen Modell besonders wichtig ist.

/read-only

Fügt eine Datei nur als Referenz hinzu: Das Modell liest sie, kann sie aber nicht bearbeiten. Nützlich für eine Datei mit Konventionen oder einen Schnittstellenvertrag.

/ask, /code, /architect

Ändern den Chatmodus für eine einzelne Nachricht oder dauerhaft mit /chat-mode.

/run et /test

/run lance une commande shell et peut en verser la sortie dans le chat ; /test lance la commande de test et ajoute la sortie au chat si elle échoue, ce qui déclenche une correction.

/diff et /undo

/diff montre les changements depuis votre dernier message ; /undo annule le dernier commit s'il a été fait par Aider.

/tokens

Zeigt die Anzahl der Tokens an, die der aktuelle Kontext belegt: Diese Prüfung sollte zur Gewohnheit werden, um zu verstehen, warum ein lokales Modell „vergisst“.

/map

Zeigt die Karte des Repositorys, die dem Modell gesendet wurde.

#Die Chat-Modi: code, ask, architect

Aider unterscheidet vier Chat-Modi. Der standardmäßig aktive Modus code ändert Ihre Dateien. Der Modus ask bespricht den Code, ohne ihn jemals zu verändern. Der Modus architect lässt zwei Modelle zusammenarbeiten: Ein Architektenmodell schlägt die Lösung vor, anschließend setzt ein Editormodell sie in präzise Dateiänderungen um. Der Modus help beantwortet Fragen zu Aider selbst. Es gibt keinen Zwischenmodus namens „paired“; die Kombination eines leistungsstarken und eines schnellen Modells wird über die Optionen --model und --editor-model eingestellt.

Der von der Dokumentation empfohlene Arbeitsablauf besteht darin, zwischen /ask und /code zu wechseln: Im Modus ask besprechen Sie die Vorgehensweise, dann wechseln Sie in den Modus code, in dem ein einfaches „go ahead“ genügt, um den vereinbarten Plan auszuführen. Das ist eine flüssigere Variante des Modus architect mit nur einem Modell. Für ein mittelgroßes lokales Modell ist das oft der beste Kompromiss: Sie vermeiden es, zwei Modelle in den Arbeitsspeicher zu laden, und behalten die Kontrolle über den Plan.

Der Architect-Modus ist sinnvoll für Modelle, die gut schlussfolgern, aber Code schlecht bearbeiten. Er kostet zwei Anfragen statt einer: Aktivieren Sie ihn nur dann, wenn der Code-Modus regelmäßig ungültige Diffs erzeugt.

#Git, Ihr Sicherheitsnetz

Aider nutzt Git, um jeden Fehler rückgängig machen zu können. Bei jeder Bearbeitung erstellt es einen Commit der Änderungen mit einer beschreibenden Nachricht, die das schwache Modell anhand des Diffs und der Unterhaltung im Stil von Conventional Commits generiert. Bevor es eine Datei mit noch nicht committeten Änderungen bearbeitet, erstellt es zunächst einen Commit des bisherigen Stands: Ihre Arbeit und die der KI bleiben im Verlauf getrennt. Die von Aider erstellten Commits tragen den Zusatz „(aider)“ im Autorennamen, sodass sie sich wiederfinden lassen.

Die Folge sind viele kleine Commits. Bewährt hat sich, Aider auf einem eigenen Branch arbeiten zu lassen, die Änderungen zu prüfen und die Commits vor dem Merge zusammenzufassen (Squash). Zwei Optionen sollten Sie kennen: --no-auto-commits deaktiviert das automatische Committen, und --git-commit-verify aktiviert die Pre-Commit-Hooks wieder, die das Tool standardmäßig mit --no-verify umgeht. Wenn Ihr Team auf diese Hooks setzt, macht diese Option den entscheidenden Unterschied.

git switch -c ai/endpoint-users
aider src/api.py
# ... relire, tester, puis :
git rebase -i main

#Ihre Tests in der Schleife ausführen

Diese Einstellung macht Aider von einem Codegenerator zu einem Werkzeug, das sich selbst korrigiert. Mit --test-cmd und --auto-test führt Aider Ihre Testsuite nach jeder Änderung aus; wenn der Befehl einen Exit-Code ungleich null zurückgibt, liest Aider die Ausgabe und versucht, die Fehler zu beheben. Für den Linter gilt mit --lint-cmd dasselbe Prinzip, und Aider führt standardmäßig Lint-Prüfungen für die Dateien aus, die es bearbeitet.

aider --test-cmd "pytest -x -q" --auto-test --lint-cmd "ruff check"

Zwei Vorsichtsmaßnahmen. Der Testbefehl muss schnell ausgeführt werden: Bei einem lokalen Modell benötigt jeder Zyklus bereits mehrere Dutzend Sekunden für die Generierung. Außerdem muss er Fehler anzeigen und dabei einen Exit-Code ungleich null zurückgeben, sonst glaubt Aider, dass alles in Ordnung ist.

#Was mit einem lokalen Modell schiefgeht und wie man es umgeht

Fehler im Bearbeitungsformat

Das Modell gibt eine Änderung zurück, die das Tool nicht anwenden kann. Wechseln Sie zu einem größeren Modell oder testen Sie den architect-Modus. Die Aider-Dokumentation widmet diesen Fehlern eine Seite zur Fehlerbehebung.

Verlust des Kontexts

Symptom: Das Modell ignoriert eine Datei, die Sie gerade hinzugefügt haben. Wahrscheinliche Ursache: zu kleines Kontextfenster oder voller Kontext. Abhilfe: /tokens, unnötige Dateien mit /drop entfernen, dann das Kontextfenster vergrößern.

Zu lange Dateien

Eine Datei mit Tausenden von Zeilen überlastet den lokalen Kontext. Teilen Sie sie auf oder fordern Sie eine Änderung einer spezifischen Funktion an.

Vage Anfragen

„Verbessere diesen Code“ erzeugt unvorhersehbare Diffs. Geben Sie die Datei, die Funktion und das erwartete Verhalten an.

Fehler wegen des Token-Limits

Aider weist darauf hin, wenn ein Modell seine Grenzen überschreitet, und schlägt Maßnahmen vor: kleinere Änderungen anfordern, Dateien aufteilen, das Modell wechseln.

#Aider oder ein Agent im Editor

Aider richtet sich an diejenigen, die im Terminal arbeiten und einen sauberen Git-Verlauf möchten. Wenn Sie lieber in VS Code bleiben möchten, bietet Cline eine vergleichbare Erfahrung mit schrittweiser Überprüfung; wenn Sie einen autonomeren Terminal-Agenten möchten, ist OpenCode eine Option. Die Wahl hängt nicht von der Modellqualität ab, die gleich ist, sondern davon, wo Sie die Diffs überprüfen möchten.

• Aider + Ollama: der vollständige Workflow im Terminal
• Das beste lokale LLM zum Programmieren
• Das Kontextfenster verstehen
• Cline + Ollama in VS Code
• OpenCode + Ollama im Terminal
• Code vor Commit mit einem lokalen LLM überprüfen

• Quelle: Aider-Dokumentation für Ollama
• Quelle: die Chat-Modi von Aider
• Quelle: Git-Integration von Aider
• Quelle: Linting und Tests in Aider
• Quelle: Devstral in der Ollama-Bibliothek