Aider nutzen: Schritt-für-Schritt-Anleitung

Um Aider zu nutzen, installierst du es mit aider-install oder dem Einzeiler-Skript, wechselst mit cd in ein Git-Repository, startest es mit aider --model sonnet --api-key anthropic=<key> (oder einem anderen Anbieter), fügst die Dateien, die sich ändern sollen, mit /add hinzu und beschreibst die Änderung in normaler Sprache. Aider bearbeitet die Dateien und committet jede Änderung in Git, /undo nimmt sie also wieder zurück.

Das ist der ganze Ablauf. Diese Anleitung deckt die Teile ab, die Aider angenehm machen: API-Keys und Modelle, welche Dateien du hinzufügst, Ask-, Code- und Architect-Modus, Edit-Formate, das Git-Verhalten, .aider.conf.yml, Lint- und Test-Integration und eine Konventionsdatei. Jeder Befehl und jedes Flag hier stammt aus der offiziellen Aider-Dokumentation auf aider.chat mit Stand Oktober 2026.

Was Aider ist

Aider ist ein KI-Pair-Programmer für das Terminal. Es ist ein Coding-Agent, der mit fast jedem LLM arbeitet: Claude, GPT, Gemini, DeepSeek oder einem lokalen Modell. Zwei Dinge unterscheiden ihn von den meisten CLI-Agenten. Erstens ist er um Git herum gebaut: Jede Änderung wird ein Commit. Zweitens ist er beim Kontext explizit: Du entscheidest, welche Dateien im Chat sind, und eine Repository-Map gibt dem Modell eine Zusammenfassung vom Rest.

Wenn du ihn mit anderen Terminal-Agenten vergleichst, folgen opencode nutzen und GitHub Copilot CLI nutzen demselben Schritt-für-Schritt-Aufbau.

Schritt 1: Aider installieren

Die Aider-Doku nennt mehrere Installationswege. Nimm einen davon.

aider-install richtet Aider in einer eigenen Python-Umgebung ein, damit es sich nicht mit den Paketen deines Projekts beißt. Installierst du mit einfachem pip, dann in einer virtuellen Umgebung. Wird der Befehl aider nach einer pip-Installation nicht gefunden, macht python -m aider dasselbe.

Schritt 2: API-Keys und Modelle

Aider spricht mit deinen eigenen Keys mit den Modellanbietern. Am schnellsten startest du, indem du Modell und Key auf der Kommandozeile übergibst:

cd /to/your/project

# Anthropic
aider --model sonnet --api-key anthropic=<key>

# OpenAI
aider --model o3-mini --api-key openai=<key>

# DeepSeek
aider --model deepseek --api-key deepseek=<key>

Jedes Mal einen Key einzutippen nervt auf Dauer. Aider liest auch die üblichen Umgebungsvariablen (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, DEEPSEEK_API_KEY und so weiter) und eine .env-Datei in deinem Projekt. --api-key provider=<key> funktioniert für jeden Anbieter: --api-key gemini=xxx setzt GEMINI_API_KEY.

Kurznamen wie sonnet sind eingebaute Aliase. Mit Stand Oktober 2026 ordnet die Doku sonnet, opus und haiku aktuellen Claude-Modellen zu, gemini und flash Gemini-Modellen, deepseek und r1 DeepSeek Chat und Reasoner und 4o GPT-4o. Du kannst eigene definieren:

aider --alias "fast:gpt-4o-mini" --model fast

In einer Session wechselt /model <name> das Hauptmodell, /models <search> listet verfügbare Modelle und /reasoning-effort setzt den Effort für Modelle, die das unterstützen. Für Commit-Nachrichten und Chat-Zusammenfassungen nutzt Aider außerdem ein günstigeres „Weak Model“; --weak-model ändert es. Du willst auf eigener Hardware arbeiten? Die Anleitung Coding-Agent mit lokalem LLM beschreibt dieses Setup.

Schritt 3: Dateien zum Chat hinzufügen

Aider bearbeitet nur Dateien, die im Chat sind. Du kannst sie beim Start nennen:

aider src/api/users.py tests/test_users.py

oder später hinzufügen:

/add src/api/users.py tests/test_users.py

In einem Punkt ist die Aider-Doku eindeutig: Füge nur die Dateien hinzu, die für die Aufgabe bearbeitet werden müssen. Jede hinzugefügte Datei kostet Tokens, und zu viele Dateien können das Modell überfordern. Aider baut eine Repository-Map des ganzen Repos, das Modell weiß also schon, wo verwandte Funktionen und Klassen liegen, ohne dass du sie hinzufügst. Fügst du gar nichts hinzu, versucht Aider selbst herauszufinden, welche Dateien bearbeitet werden müssen.

Die Befehle, mit denen du den Kontext steuerst:

• /add <files> fügt Dateien hinzu, die Aider bearbeiten darf.
• /read-only <files> fügt Referenzdateien hinzu, die es lesen, aber nicht ändern kann (Doku, ein Beispielmodul).
• /drop <files> entfernt Dateien, um Kontext freizumachen; /drop allein leert alle.
• /ls listet die Dateien im Chat und im Repo.
• /tokens zeigt, wie viele Tokens der aktuelle Kontext belegt.
• /map gibt die Repository-Map aus, /map-refresh baut sie neu.

Dann beschreibst du die Änderung:

Füge dem Endpoint list_users eine Paginierung hinzu: Er soll die
Query-Parameter page und page_size akzeptieren, standardmäßig 20 pro
Seite liefern, und aktualisiere die Tests.

Schritt 4: Ask-, Code- und Architect-Modus

Aider hat Chat-Modi, und den richtigen zu wählen ist schon der größte Teil der Kunst.

/ask, /code und /architect gefolgt von einer Nachricht gelten nur für diese eine Nachricht. Allein getippt wechseln sie den Modus, bis du ihn wieder änderst; /chat-mode <mode> macht dasselbe. --chat-mode <mode> wählt den Modus beim Start, und --architect ist eine Abkürzung dafür.

Die Doku empfiehlt, abzuwechseln: erst fragen, den Plan verfeinern, dann coden lassen.

/ask Wie sollte ich Rate Limiting für die Login-Route einbauen, ohne
die anderen Endpoints anzufassen? Ändere noch nichts.

Wenn der Plan passt, tippst du /ok. Das ist die Kurzform für „/code Ok, please go ahead and make those changes.“ (sinngemäß: „Ok, setz die Änderungen bitte um.“)

Der Architect-Modus verteilt die Arbeit auf zwei Modelle. Das Hauptmodell beschreibt, wie das Problem zu lösen ist, und ein Editor-Modell, das du mit --editor-model festlegst, macht daraus Datei-Edits. Wenn du keins angibst, wählt Aider zu jedem Hauptmodell ein passendes Editor-Modell. Das hilft oft bei Reasoning-Modellen, die gut planen, aber weniger zuverlässig exakte Edits erzeugen. Der Preis dafür: Der Architect-Modus schickt zwei Anfragen pro Änderung, ist also langsamer und teurer.

Schritt 5: Edit-Formate

Ein Edit-Format ist die Art, wie das Modell Aider mitteilt, was geändert werden soll. Selten musst du daran drehen, weil Aider für jedes Modell das beste Format wählt, aber es hilft zu wissen, was du siehst:

Überschreiben kannst du das mit --edit-format <format>, das Format des Editor-Modells setzt du mit --editor-edit-format. Erzeugt ein Modell immer wieder Edits, die sich nicht anwenden lassen, ist ein Wechsel auf whole bei kleinen Dateien ein sinnvoller Test.

Schritt 6: Git, Auto-Commits und /undo

Aider funktioniert am besten in einem Git-Repo. Standardmäßig gilt:

• Jede Änderung von Aider wird mit einer aussagekräftigen Nachricht committet, die das Weak Model im Conventional-Commits-Stil schreibt.
• Hattest du in Dateien nicht committete Änderungen, bevor Aider sie bearbeitet, committet es diese zuerst, damit deine Arbeit und seine in getrennten Commits landen.
• An Autor- und Committer-Namen seiner Commits wird „(aider)“ angehängt.

Damit ist das Sicherheitsnetz einfach:

• /diff zeigt die Änderungen seit deiner letzten Nachricht.
• /undo macht den letzten Commit rückgängig, wenn Aider ihn erstellt hat.
• /commit committet Änderungen, die du selbst außerhalb gemacht hast.
• /git <command> führt einen beliebigen Git-Befehl aus, ohne den Chat zu verlassen.

Teile davon kannst du abschalten: --no-auto-commits lässt Edits zum Prüfen uncommittet, --no-dirty-commits überspringt den Commit vor dem Bearbeiten, und --no-git schaltet Git ganz ab (davon rät die Doku ab). Aider committet standardmäßig mit --no-verify, deine Pre-Commit-Hooks laufen also nicht; nimm --git-commit-verify, wenn sie laufen sollen. Willst du Aiders Änderungen lieber von deinem Haupt-Checkout fernhalten, lass es in einem eigenen Git-Worktree laufen.

Schritt 7: .aider.conf.yml konfigurieren

Flags, die du jedes Mal nutzt, gehören in eine YAML-Datei. Aider lädt .aider.conf.yml aus deinem Home-Ordner, dann aus dem Root des Git-Repos, dann aus dem aktuellen Ordner; spätere Dateien haben Vorrang. --config <file> lädt nur diese eine Datei.

# .aider.conf.yml
model: sonnet
weak-model: haiku
auto-commits: true
dirty-commits: true
lint-cmd: "python: ruff check --fix"
test-cmd: pytest -q
auto-test: false
read: [CONVENTIONS.md]

Die Schlüssel in der Datei entsprechen den langen Flag-Namen ohne die Bindestriche davor. API-Keys können auch hier stehen (anthropic-api-key:, openai-api-key: oder eine api-key:-Liste wie - gemini=xxx), dann gehört die Datei aber nicht in Git. Standardmäßig fügt Aider .aider* zur .gitignore hinzu, damit seine Verlaufsdateien nicht in Commits landen.

Schritt 8: Lint- und Test-Integration

Aider lintet die Dateien, die es bearbeitet, direkt nach jeder Änderung, mit eingebauten Lintern für die meisten verbreiteten Sprachen. Meldet der Linter Probleme, versucht Aider sie zu beheben. Du kannst auch deinen eigenen Linter mitbringen:

aider --lint-cmd "python: ruff check --fix" --lint-cmd "javascript: npx eslint --fix"

Der Befehl muss Fehler ausgeben und mit einem Exit-Code ungleich null enden, wenn er Probleme findet. --no-auto-lint schaltet das Linten ab.

Tests funktionieren genauso, sind aber standardmäßig aus. Setze einen Befehl mit --test-cmd und schalte --auto-test ein, dann führt Aider nach jeder Änderung die Tests aus und versucht, Fehlschläge (jeden Exit-Code ungleich null) zu beheben. Im Chat:

• /lint lintet und repariert die Dateien im Chat oder, wenn keine hinzugefügt sind, alle geänderten Dateien.
• /test <command> führt einen Befehl aus und fügt bei einem Fehlschlag die Ausgabe zum Chat hinzu.
• /run <command> (oder !<command>) führt einen Shell-Befehl aus und lässt dich seine Ausgabe teilen.

Schritt 9: eine Konventionsdatei

Aider hat keine eingebaute Projekt-Anweisungsdatei, die es von selbst lädt. Der dokumentierte Weg ist eine einfache Markdown-Datei, die du schreibgeschützt lädst:

# CONVENTIONS.md
- Prefer httpx over requests for making http requests.
- Use types everywhere possible.
- Every new endpoint needs a test in tests/api/.

aider --read CONVENTIONS.md

oder /read-only CONVENTIONS.md während einer Session, oder read: CONVENTIONS.md in der .aider.conf.yml, damit sie jedes Mal geladen wird. Schreibgeschützte Dateien werden gecacht, wenn Prompt-Caching aktiv ist, die Kosten bleiben also niedrig. Pflegst du schon eine AGENTS.md für andere Agenten, kannst du stattdessen die laden; CLAUDE.md und AGENTS.md gibt Tipps, wie du Regeln schreibst, an die sich Agenten wirklich halten.

Zwei weitere Funktionen, die du kennen solltest

Skripte. --message (oder -m) schickt eine einzelne Anweisung, wendet die Edits an und beendet sich. So lässt sich Aider leicht in einer Schleife über Dateien laufen lassen:

for FILE in *.py ; do
  aider --message "add descriptive docstrings to all the functions" $FILE
done

Mit --yes-always werden Rückfragen automatisch bestätigt, mit --message-file liest Aider die Anweisung aus einer Datei.

Watch-Modus. Starte Aider mit --watch-files und arbeite in deinem Editor weiter. Schreib einen Kommentar, der auf AI! endet, und Aider setzt die Änderung um; endet er auf AI?, beantwortet Aider die Frage. Das funktioniert mit #-, //- und ---Kommentaren.

Häufige Stolperfallen

• Das ganze Repo hinzufügen. Mehr Dateien bedeuten höhere Kosten und schlechtere Edits. Füge hinzu, was sich ändert, nimm /read-only für Referenzen und verlass dich auf die Repo-Map.
• Das Dirty-Commit-Verhalten vergessen. Aider committet deine offenen Änderungen, bevor es eine Datei anfasst. Überrascht dich das, committe oder stashe vorher, oder nimm --no-dirty-commits.
• Erwarten, dass Hooks laufen. Commits überspringen Pre-Commit-Hooks, außer du übergibst --git-commit-verify.
• Architect-Modus für alles. Er verdoppelt die Anfragen. Nutze ihn für knifflige Änderungen; für kleine Edits reicht der normale Code-Modus.
• Keys in einer committeten Konfiguration. Enthält die .aider.conf.yml API-Keys, behalte sie in deinem Home-Ordner oder außerhalb von Git.
• Lange Chats. Alte Nachrichten kosten bei jeder Anfrage Tokens. /clear löscht den Chatverlauf, /reset entfernt zusätzlich die Dateien.

Aider in AgentVera ausführen

AgentVera ist eine Desktop-App für macOS, Windows und Linux, die CLI-Agenten nebeneinander in echten Terminals ausführt, mit deinen eigenen Installationen und Keys. Aider ist einer der unterstützten Agenten; die Seite Aider in AgentVera listet die Details:

• Deine Keys, deine Konfiguration. Aider liest Anbieter-Keys wie gewohnt aus Umgebungsvariablen oder der .aider.conf.yml. Ein Modell, das du in AgentVera wählst, wird mit --model übergeben, niedriger, mittlerer oder hoher Effort mit --reasoning-effort.
• Eigener Verlauf pro Agent. Jeder Aider-Agent hat seine eigene Chatverlaufsdatei unter ~/.aider/agentvera/ und setzt sie mit --restore-chat-history fort, wenn die App wieder geöffnet wird. So vermischen mehrere Aider-Agenten ihre Verläufe nie.
• Rollen als schreibgeschützte Datei. Aider erlaubt keine Erweiterung seines System-Prompts, deshalb wird die Rolle des Agenten mit --read übergeben, über denselben Mechanismus wie eine Konventionsdatei.
• Panels neben anderen Agenten. Lass Aider im Raster des Workspace neben Claude Code oder Codex laufen und starte Agenten aus dem Git-Panel in eigenen Worktrees.
• Review und Flows. Aider-Agenten bekommen am Ende eines Turns ein automatisches Code-Review und funktionieren in Flows (Pro und Team), Broadcasts und geplanten Aufgaben.

Eine Grenze solltest du kennen: Die MCP-Server, die du in AgentVera einrichtest, werden nicht an Aider übergeben. Raster, Worktrees und Code-Review gehören zum Free-Tarif. Lade AgentVera herunter und probiere es aus.

Fazit

Installiere Aider, wechsle in ein Git-Repo, starte es mit Modell und Key und füge nur die Dateien hinzu, die die Änderung braucht. Plane mit /ask und setze mit /ok oder /code um, probiere /architect bei schwierigeren Problemen und verlass dich auf /diff und /undo, weil jede Änderung ein Commit ist. Leg deine Standards in der .aider.conf.yml ab, deine Regeln in der CONVENTIONS.md, und lass --lint-cmd und --test-cmd Fehler finden, bevor du es tust. Wenn du auch den Agenten von GitHub nutzt, ist GitHub Copilot CLI nutzen dieselbe Anleitung für dieses Tool.