Aider + Ollama: Im Terminal programmieren mit einem Agenten, der zu 100 % lokal

#Warum Aider im Terminal?

Während Cline oder Continue in VS Code zu Hause sind, setzt Aider bewusst auf das Terminal. Sie bleiben in Ihrer Shell, im Stammverzeichnis Ihres Git-Repositorys, und sprechen mit dem Modell wie mit einem Kollegen, der Zugriff auf den Code hat. Dieser andere Workflow orientiert sich stärker an der Kommandozeile und gefällt denen, die in tmux zu Hause sind und ungern die Hände von der Tastatur nehmen.

Fokussiert auf git

Jede akzeptierte Änderung wird zu einem sauberen Commit mit einer von Aider verfassten Commit-Nachricht. Ihre Versionshistorie bleibt übersichtlich, und Sie können jede beliebige Änderung mit einem einfachen git revert rückgängig machen.

Automatische Repo-Map

Aider erstellt eine Übersicht Ihres Repositories (Funktionssignaturen, Klassen, Struktur), die es zusätzlich zu den geöffneten Dateien an das Modell sendet. Das Modell versteht den Kontext, ohne dass Sie das gesamte Projekt laden müssen.

Editorunabhängig

Aider verändert die Dateien auf dem Datenträger. Sie verwenden parallel weiterhin Ihren gewohnten Editor: Aider sieht Ihre Änderungen, und Sie sehen die Änderungen von Aider.

100 % lokal mit Ollama

Bei Anbindung an Ollama läuft das Modell auf Ihrer GPU. Ihr Code und Ihre Prompts verlassen niemals Ihren Rechner, was bei proprietärem Code oder Code unter NDA einen entscheidenden Unterschied macht.

#Voraussetzungen und Installation

Drei Bausteine: Python für Aider, Ollama mit einem geladenen Code-Modell und ein Git-Repository. Aider benötigt ein Git-Repository, um seinen vollen Funktionsumfang nutzen zu können – Aider steuert die Commits.

1. 01
   Prüfen Sie Ollama

   Ollama muss auf seinem Standardport lauschen. Führen Sie ollama list aus, um zu bestätigen, dass Ollama antwortet, und die bereits installierten Modelle zu sehen.
2. 02
   Installieren Sie Aider

   Die empfohlene Methode ist die Installation über pipx oder das offizielle Installationsskript, das Aider in einer eigenen Umgebung isoliert, um Konflikte zwischen Python-Abhängigkeiten zu vermeiden.
3. 03
   Wechseln Sie in ein Git-Repository

   Öffnen Sie ein Terminal im Stammverzeichnis eines versionierten Projekts. Falls das Projekt noch nicht mit Git verwaltet wird, führen Sie zunächst git init aus: Aider benötigt dies, um seine Änderungen zu committen.

# Via pipx (isole Aider, n'encombre pas votre Python système)
python -m pip install --user pipx
pipx install aider-chat

# Vérifier l'installation
aider --version

#Aider für Ollama konfigurieren

Aider kommuniziert mit Ollama über dessen OpenAI-kompatiblen Endpunkt. Zwei Dinge müssen eingestellt werden: die Basis-URL von Ollama (Umgebungsvariable) und das zu verwendende Modell. Am saubersten ist es, eine Datei .aider.conf.yml im Stammverzeichnis des Projekts anzulegen (oder für eine globale Einstellung in Ihrem Benutzerverzeichnis), damit Sie die Optionen nicht bei jedem Start erneut eingeben müssen.

# Indique à Aider où trouver l'API Ollama
export OLLAMA_API_BASE=http://127.0.0.1:11434

# Lancer Aider avec un modèle Ollama (préfixe ollama/)
aider --model ollama/qwen3.5:9b

Um nichts mehr erneut eingeben zu müssen, legen Sie diese Einstellungen in einer Konfigurationsdatei ab. Aider liest automatisch eine .aider.conf.yml, die im Stammverzeichnis des Repositories oder in Ihrem persönlichen Ordner gefunden wird.

# Modèle principal servi par Ollama (préfixe ollama/ obligatoire)
model: ollama/devstral:24b

# Modèle léger pour les tâches annexes (messages de commit, résumés)
weak-model: ollama/qwen3.5:9b

# Auto-commit des modifications acceptées (comportement par défaut)
auto-commits: true

# Ne pas committer automatiquement les fichiers que VOUS modifiez
dirty-commits: false

- name: ollama/devstral:24b
  extra_params:
    num_ctx: 8192

#Welches Modell passt zum verfügbaren VRAM?

Aider sendet viel Kontext (hinzugefügte Dateien + Repo-Map) und erwartet einen korrekt formatierten Patch als Antwort. Ein zu kleines Modell erzeugt fehlerhafte Diffs, die Aider nicht anwenden kann. Wählen Sie das größte Coding-Modell, das Ihre Grafikkarte problemlos laden kann, und lassen Sie dabei genügend Speicherreserve für den Kontext.

#Der End-to-End-Workflow

Hier sehen Sie den typischen Ablauf einer Änderung, vom Start von Aider bis zum Commit. Sobald Sie sich an diesen Rhythmus gewöhnt haben, können Sie eine Änderung nach der anderen vornehmen, ohne jemals das Terminal zu verlassen.

1. 01
   Starten Sie Aider aus dem Repository-Root

   Aider startet, liest die Konfiguration, erstellt die Repo-Map und zeigt eine Eingabeaufforderung an. Dabei zeigt Aider das aktive Modell und die Anzahl der erkannten Dateien an.
2. 02
   Fügen Sie die betroffenen Dateien mit /add hinzu

   Fügen Sie nur die Dateien hinzu, die für die Aufgabe geändert werden müssen. Je weniger Dateien im Kontext enthalten sind, desto genauer bleibt das Modell. Die Repo-Map gibt dem Modell bereits einen Überblick über den Rest des Projekts.
3. 03
   Beschreiben Sie die Änderung auf Französisch

   Geben Sie Ihre Anfrage in natürlicher Sprache ein: „Füge die E-Mail-Validierung zum Registrierungsformular hinzu“. Aider denkt nach und schlägt anschließend einen Patch vor.
4. 04
   Prüfen Sie den vorgeschlagenen Diff

   Aider zeigt den Diff an, bevor die Änderungen angewendet werden. Prüfen Sie ihn. Falls etwas nicht stimmt, antworten Sie zur Korrektur: „Nein, verwende eine strengere Regex.“
5. 05
   Lassen Sie Aider committen

   Sobald der Patch angewendet wurde, erstellt Aider automatisch einen Commit mit einer aussagekräftigen Nachricht. Ihre Git-Historie bleibt sauber und jede Änderung ist nachvollziehbar.
6. 06
   Iterieren Sie weiter oder machen Sie die Änderung rückgängig

   Fahren Sie mit der nächsten Änderung fort. Wenn Ihnen ein Commit von Aider nicht zusagt, macht /undo den letzten von Aider erstellten Commit rückgängig, ohne den Rest anzutasten.

$ aider
Aider v0.x — model: ollama/devstral:24b
Repo-map: 42 fichiers

> /add src/auth/register.py
Added src/auth/register.py to the chat

> Ajoute la validation de l'email dans le formulaire d'inscription

[Aider propose un diff, l'applique, puis :]
Commit a1b2c3d  feat: valider le format de l'email à l'inscription

#Wichtige Befehle für den Alltag

Aider wird über Slash-Befehle in seiner Eingabeaufforderung gesteuert. Eine Handvoll reicht aus, um 90 % der Anwendungsfälle abzudecken.

/add fichier

Fügt eine oder mehrere Dateien zum Bearbeitungskontext hinzu. In diese Dateien wird Aider schreiben. Beschränken Sie sich auf das unbedingt Notwendige.

/drop fichier

Entfernt eine Datei aus dem Kontext. Nützlich, wenn Sie die Aufgabe wechseln, um wieder mit einem sauberen Kontext zu beginnen.

/architect

Aktiviert den Modus „erst planen, dann programmieren“: Das Modell durchdenkt zunächst den Ansatz und erzeugt anschließend den Diff. Ideal für nicht triviale Änderungen.

/diff

Zeigt die seit dem letzten Commit vorgenommenen Änderungen an, damit man sehen kann, was Aider geändert hat, bevor man weitermacht.

/undo

Macht den letzten von Aider erstellten Commit rückgängig. Ein sofortiges Sicherheitsnetz, falls bei einer Änderung etwas schiefgeht.

/run commande

Führt einen Shell-Befehl (Tests, Linter) aus und speist die Ausgabe wieder in den Chat ein. Aider kann dann anhand der tatsächlichen Fehler Korrekturen vornehmen.

/ask question

Stellt eine Frage zum Code, OHNE Änderungen oder einen Commit auszulösen. Zum Verstehen, bevor Sie handeln.

#Grenzen des lokalen Betriebs gegenüber der Cloud

Seien wir ehrlich: Ein lokales Modell, das mit 8 bis 16 GB läuft, erreicht nicht das Niveau eines führenden Cloud-Modells. Wer die Grenzen kennt, vermeidet Frust und kann für jede Aufgabe das passende Werkzeug wählen.

Manchmal fehlerhaft formatierte Diffs

Kleine Modelle erzeugen manchmal einen Patch, den Aider nicht anwenden kann (fehlerhaftes Format). Ein größeres Modell zu verwenden oder num_ctx zu erhöhen, verringert dieses Problem deutlich.

Kürzere Kontextlänge

Ein Cloud-Modell kann Dutzende von Dateien verarbeiten. Halten Sie den Kontext bei lokaler Nutzung klein: Fügen Sie mit /add nur wenige Dateien gleichzeitig hinzu und nutzen Sie die repo-map, statt alles zu laden.

Reasoning über mehrere Dateien hinweg

Refactorings, die viele Dateien auf einmal betreffen, bleiben die Schwachstelle lokaler Modelle. Teilen Sie sie in mehrere kleine Aufgaben auf oder wechseln Sie zu /architect, um das Vorgehen zu strukturieren.

Geschwindigkeit abhängig von der GPU

Die Latenz hängt von Ihrer Grafikkarte ab. Ein 32B-Modell ist auf einer wenig leistungsstarken Karte langsam. Wenn die Reaktionsgeschwindigkeit Vorrang hat, ist ein gut eingestelltes 7B- oder 14B-Modell im Alltag angenehmer.

#Häufig gestellte Fragen