Ein lokaler Programmieragenten-Loop: Aider, Ollama, Git-Worktrees und einfache Rollback-Möglichkeiten.

Fangen Sie mit dem Rückweg an und wählen Sie das Modell später aus. Ein lokaler Programmieragent verdient seinen Platz, wenn er einen kleinen, begrenzten Zyklus abschließen kann: einen Defekt finden, eine bescheidene Änderung vornehmen, die entsprechende Überprüfung durchführen und einen Diff hinterlassen, der entweder kommittiert oder weggeworfen werden kann.

Der konservative Stack für diesen Zyklus setzt voraus, dass bereits ein Repository unter Git vorhanden ist, zusammen mit einem gezielten Testbefehl:

• Agent: Aider
• Modell-Laufzeitumgebung: Ollama, das ein Modell auf dem lokalen Rechner bereitstellt
• Isolement: ein Git-Worktree
• Suche: rg, ausgeführt von der Wurzel des Repositoriums aus
• Validierung: der bereits vorhandene gezielte Testbefehl des Repositoriums
• Wiederherstellung: git diff, gefolgt von einem Commit oder git restore

Nur der Agent und die lokale Ausführumgebung sind neu. Alles andere sind gewöhnliche Repository-Tools, und die Einrichtung sollte nicht zu einer zweiten Entwicklungsplattform werden.

Die Rollen sind einfach. Ollama stellt das Modell bereit. Aider arbeitet innerhalb eines Git-Repositorys. Ein Worktree bietet für die Aufgabe einen eigenen Checkout, meist auf einer dedizierten Branch, und git restore kann unkommitierte Änderungen in benannte Dateien zurückführen. Das Muster ist absichtlich eng gefasst und richtet sich an Repository-Arbeiten, die überprüfbar und rückgängig machbar bleiben müssen. Es handelt sich dabei um keinen Benchmark, und es wird nicht behauptet, dass diese Tools überall bessere Alternativen sind. Befehle, Modellnamen sowie das Genehmigungsverhalten ändern sich außerdem je nach installierter Version und lokaler Konfiguration.

Ein Prozess, den eine Person überprüfen kann

Die Ausgabe des Agents sollte eine kleine Fortschrittsmenge darstellen, die ein Entwickler überprüfen kann. Breiter, unüberwachter Zugriff auf eine Maschine ist das Gegenteil davon.

Die Abfolge:

1. Erstellen Sie einen isolierten Arbeitsbaum.
2. Finden Sie die Implementierung sowie den vorhandenen Test dafür.
3. Definieren Sie ein Ergebnis und dessen Grenzen.
4. Fordern Sie einen Plan an, bevor irgendwelche Änderungen vorgenommen werden.
5. Genehmigen Sie den Plan oder präzisieren Sie ihn.
6. Lesen Sie den Diff.
7. Führen Sie die Projektprüfung durch.
8. Committen oder wiederherstellen Sie die Änderungen.

Die relevanten Kontrollpunkte sind prozedural: Nichts wird geändert, bevor der Plan genehmigt wurde, und keine Änderung bleibt bestehen, bevor der Diff sowie der Test gelesen wurden. Bezeichnen Sie sie nur als technische Kontrollen, wenn der installierte Agent sowie die Host-Konfiguration sie tatsächlich durchsetzen können. Geschwindigkeit ist nur dann von Vorteil, wenn die Ergebnisse leicht überprüfbar und rückgängig machbar bleiben.

Ein Beispiel: leere Anzeigennamen

Stellen Sie sich einen TypeScript-Dienst vor, der leere Anzeigennamen akzeptiert, obwohl die API sie ablehnen sollte. Das Repository enthält eine spezielle Testdatei sowie npm-Skripte zur Validierung.

Die Aufgabe besteht nicht in der Bereinigung der Validierung. Sie lautet wie folgt:

Ablehnen Sie Anzeigennamen, die nur aus Leerzeichen bestehen, aktualisieren Sie die vorhandene Testdatei, lassen Sie die öffentliche API unverändert und führen Sie den ausgewählten Test aus.

Dadurch erhält der Agent ein Verhalten, eine Grenze und eine Überprüfung.

Geben Sie der Änderung einen eigenen Checkout

Vom primären Checkout:

git worktree add -b fix/display-name-validation ../service-display-name-fix
cd ../service-display-name-fix

Ein Worktree ist ein zweiter Arbeitsverzeichnis, das demselben Repository zugeordnet ist. Der obige Befehl erstellt ../service-display-name-fix auf der Branch fix/display-name-validation und lässt das Hauptverzeichnis weiterhin für andere Arbeiten frei.

Von nun an bleiben Änderungen, Testergebnisse sowie der ausstehende Diff vom primären Verzeichnis getrennt. Sollte das Experiment als sinnlos erweisen, können seine Dateien wiederhergestellt oder der Worktree nach Überprüfung seines Status entfernt werden.

Zuerst den Code und die Tests finden

Verwenden Sie das eigene Vokabular des Repositories, um den Umfang festzulegen:

rg -n "displayName|display name" src test

Nehmen wir an, die Suche liefert Folgendes:

src/users/validateProfile.ts
test/users/validateProfile.test.ts

Die Grenzen sind nun klar definiert. Der Agent benötigt diese beiden Dateien sowie den Befehl zur Überprüfung derselben, und eine vage Einladung, den gesamten Repository zu durchsuchen, bringt nichts.

Aider mit dem lokalen Ollama-Modell starten

Vor diesem Schritt sollten Sie sicherstellen, dass Git, Aider, Ollama sowie rg installiert sind und dass die Ollama-Laufzeitumgebung auf diesem Rechner verfügbar ist. Das ausgewählte Modell muss außerdem mit den installierten Versionen von Aider und Ollama kompatibel sein. Aider dokumentiert die verfügbaren Ollama-Anbieter – stellen Sie sicher, dass das gewünschte Modell in Ollama vorhanden ist, und starten Sie anschließend Aider aus dem Arbeitsverzeichnis unter Verwendung des Präfixes ollama_chat/ vor dem Modellnamen.

ollama pull <installed-model>
aider --model ollama_chat/<installed-model>

Ersetzen Sie <installed-model> durch den Tag, den Ollama tatsächlich verwendet. Derselbe Tag kommt in beiden Befehlen vor, da Ollama dieses Modell bereitstellt und Aider es nach Namen auswählt.

Aider kann seine Änderungen über Git verfolgen. Starten Sie es im Arbeitstree, lesen Sie nach jeder Änderung den Diff und überlassen Sie die Entscheidung zum Commit menschlichen Entscheidungsträgern.

Zusätzlich sind In-Chat-Befehle, eine Karte der Repositorys, Konfigurationsoptionen sowie Einstellungen zur Kontextbegrenzung enthalten. Sie helfen bei der Navigation, doch keines davon legt den Umfang fest oder beweist die Richtigkeit eines Patches.

Machen Sie den ersten Schritt zu einem Plan

Beschränken Sie den Kontext des Agents auf die relevanten Dateien, indem Sie den für die installierte Aider-Version dokumentierten Workflow zur Hinzufügung von Dateien verwenden – nicht das Git Staging. Geben Sie anschließend eine Anweisung mit dem gewünschten Ergebnis, den zulässigen Pfaden sowie einem Validierungsbefehl an:

Task: Fix whitespace-only display names being accepted.

Files in scope:
- src/users/validateProfile.ts
- test/users/validateProfile.test.tsConstraints:
- Preserve the public API.
- Do not edit generated files, lockfiles, deployment configuration, or unrelated tests.
- First, explain the current behavior, name the files you would change, and propose the smallest fix.
- Do not edit files until I approve the plan. Treat this as a required review step, and use any available approval controls in your local agent configuration to enforce it where possible.Validation:
- Run: npm test -- validateProfile
- Report the exact command run, files changed, test result, and any unresolved assumption.

Eine solche Anweisung verhindert mehrere häufige Fehler: Aufgaben, die außer Kontrolle geraten, Änderungen außerhalb der vorgesehenen Pfade sowie Patches, für die keine angegebene Methode zur Überprüfung vorhanden ist.

Weisen Sie umfassende Pläne frühzeitig ab

Eine gute erste Antwort sieht wie folgender Plan aus:

1. Inspect src/users/validateProfile.ts to confirm how displayName is validated.
2. Inspect test/users/validateProfile.test.ts for the existing validation-test pattern.
3. Add a failing test for a whitespace-only displayName.
4. Make the smallest validation change required to reject that input.
5. Run npm test -- validateProfile.

Vor der Freigabe jeder Änderung fragen Sie Folgendes:

• Nennt der Plan die vorgesehene Implementierung und Tests?
• Beschränkt er sich auf ein einziges Verhalten?
• Gibt er an, welche Validierungsänderung vorgeschlagen wird?

Stoppen Sie, wenn davon die Rede ist, dass eine Schema-Migration, ein Installieren von Abhängigkeiten, ein Update eines Lockfiles oder unverwandte Endpunktbereinigungen stattfinden sollen. Beschränken Sie die Aufgabe stattdessen, anstatt eine Erweiterung zu genehmigen, die nur plausibel klingt.

Der Diff und das Testergebnis sind das Endergebnis

Sobald der Plan freigegeben wurde, wiederholen Sie jedes Mal denselben Überprüfungsablauf.

Betrachten Sie ausschließlich die vereinbarten Dateien

git diff -- src/users/validateProfile.ts test/users/validateProfile.test.ts

Hier ist das erwartete Ergebnis ein einziger neuer Test für leere Eingaben zusammen mit einer Implementierungsanpassung, die dies erfüllt. Wie diese Anpassung aussieht, hängt vom bestehenden Validierungsvertrag des Repositoriums ab; überprüfen Sie daher, dass nur Eingaben, die nach Trimmen leer sind, abgelehnt werden und gültige Anzeigennamen unverändert durchkommen.

Achten Sie darauf, was eine Sitzungszusammenfassung verbergen kann:

• die öffentliche API wurde geändert, obwohl dies ausdrücklich verboten war
• Dateien wurden außerhalb der vereinbarten Liste bearbeitet
• Umformate, die nichts mit dem Fehler zu tun haben
• ein neuer Test, der ohne Berücksichtigung des Zielverhaltens bestanden wird
• eine Validierungsanpassung, die auch gültige Namen ablehnt

Der Diff sowie das Testergebnis sind die zu liefernden Ergebnisse. Die eigene Zusammenfassung des Agents dient lediglich als Leitfaden zum Lesen und beweist nichts bezüglich der Richtigkeit.

Führen Sie die gezielte Überprüfung durch

<repository-focused-test-command>

Ersetzen Sie den Platzhalter durch die tatsächlich von dem Repository verwendete Befehls- und Dateiauswahl-Syntax.

Aider kann nach Codeänderungen automatisch Fehler überprüfen und Tests durchführen. Dadurch können die Feedbackzyklen verkürzt werden, doch der eigene Befehl des Repositories bleibt die offizielle Methode.

Die Änderung absichtlich beibehalten oder entfernen

Falls der Diff sowie das Testergebnis in Ordnung aussehen:

git status
git add src/users/validateProfile.ts test/users/validateProfile.test.ts
git commit -m "Reject whitespace-only display names"

Falls sie es nicht tun:

git restore src/users/validateProfile.ts test/users/validateProfile.test.ts

Da keine Quelle angegeben ist, ruft git restore die beiden benannten Dateien aus HEAD zurück und ignoriert dabei nur die noch nicht committen Änderungen an diesen Dateien. Überprüfen Sie mit git status die in den Staging-Bereich gebrachten Änderungen, die nicht verfolgten Dateien oder andere Modifikationen, bevor Sie das Experiment als verworfen betrachten.

Falls der gesamte Branch weggeworfen werden kann, entfernen Sie den Worktree, nachdem dessen Status überprüft und alles, was aufbewahrt werden sollte, gespeichert wurde:

git worktree remove ../service-display-name-fix

Git verwaltet verknüpfte Arbeitsverzeichnisse über seine worktree-Befehle. Die Wiederherstellung ist ein normaler Ablauf und sorgt dafür, dass Experimente mit einem kleinen Agenten sicher wiederholt werden können.

Grenzen: Dateisystem, Berechtigungen, Kontext

Starten vom Repository-Root aus

Führen Sie den Agenten im Projektverzeichnis oder in seinem speziellen worktree aus. Wenn man von einem Heimverzeichnis aus startet und darauf hofft, dass eine Eingabeaufforderung eine Grenze vorgibt, funktioniert das nicht.

Das Arbeitsverzeichnis bietet einen Standardumfang, erzwingt jedoch nichts. Was der Agent tatsächlich erreichen kann, wird durch die OS-Berechtigungen, Einstellungen der Tools sowie die vorhandene Sandbox bestimmt.

Nebenwirkungen absichtlich zulassen

Die Schreibzugriffe auf Dateien, die Installation von Abhängigkeiten, der Zugriff auf Anmeldeinformationen, die Netzwerknutzung sowie Änderungen an der Infrastruktur sollten alle einer bewussten Genehmigung bedürfen. Wenn der Agent oder der Host dies nicht durchsetzen kann, sollte dies als manuelle Überprüfungsstufe behandelt werden und nicht als technische Kontrolle dargestellt werden. Überprüfen Sie vor der Nutzung, welche Kontrollen vorhanden sind.

OWASP listet die promptbasierte Einleitung als Risiko auf, das eine mit LLMs ausgestattete Anwendung zu unerwünschten Aktionen oder zur Offenlegung von Informationen veranlassen kann.

Eine praktische Grundlage:

• Erlauben Sie das Lesen von Dateien im vorgesehenen Repository.
• Fordern Sie eine Genehmigung vor Schreibvorgängen ein.
• Fordern Sie eine Genehmigung vor Shell-Befehlen mit Nebeneffekten ein.
• Machen Sie den Netzwerzzugriff optional.
• Halten Sie Geheimnisse außerhalb des normalen Kontexts des Agents.

Dadurch wird der Ausmaß der Auswirkungen begrenzt. Es wird dabei keine Beurteilung darüber abgegeben, ob der Agent vertrauenswürdig ist.

Halten Sie die Konfiguration klein und sichtbar

Aider liest YAML-Konfigurationen, Umgebungsdateien sowie API-Schlüssel-Einstellungen. Die gemeinsame Projektkonfiguration sollte sichtbar, minimal sein und von Geheimnissen getrennt aufbewahrt werden; Zertifizierungsdaten gehören niemals in eine Anweisungsdatei im Repository. Stapel von globalen Standardwerten, die später niemand überprüfen oder erklären kann, sollten unbedingt vermieden werden.

Geben Sie den Kontext bereit, den die Aufgabe benötigt

Die Karte des Repositories hilft Aider, die Struktur der Codebasis zu verstehen, während der Kontext begrenzt, wie viel pro Anfrage verarbeitet werden kann. Für eine gezielte Korrektur sollten die Aufgabe, die relevanten Dateien, der Validierungs-Befehl sowie alle projektbezogenen Regeln, die sich auf die Änderung beziehen, bereitgestellt werden. Das Hinzufügen generierter Dateien, jeder Dokumentation oder alter, nicht verwandter Commits führt meist nur zu Unordnung.

Ein Projektvertrag für wiederkehrende Arbeiten

Falls derselbe Arbeitsablauf immer wieder auftaucht, speichern Sie eine eingereichte Anweisungsdatei, einen wiederverwendbaren Prompt oder ein Aufgabenvorlage neben dem Code:

Project contract

Goal:
- [Describe one bounded outcome.]Scope:
- You may edit: [paths]
- Do not edit: [paths, generated files, secrets, deployment configuration]Conventions:
- Follow: [formatter, naming, architecture rules]
- Preserve: [public APIs, compatibility constraints]Validation:
- Run: [exact test, lint, type-check, or build command]
- Report: commands run, files changed, failures, and unresolved assumptionsDefinition of done:
- The requested behavior is implemented.
- Relevant checks have run, or the reason they could not run is stated.
- The final response summarizes the diff and any follow-up work.

Die Formatierung ist unerheblich. Entscheidend ist, dass die Einschränkungen sichtbar sind.

Fehlermöglichkeiten und kleinere nächste Schritte

Zu breites Suchen. Stoppen Sie, kürzen Sie die Dateiliste und starten Sie erneut mit Pfaden oder Symbolen, die aus einer manuellen Suche stammen.

Ein umfangreicher Refactoring-Vorschlag. Teilen Sie die Anfrage an einer testbaren Grenze auf. Ein fehlerhafter Test, ein Verhalten oder eine Refactoring-Grenze sind besser als architektonische Vorgaben.

Änderungen außerhalb des Umfangs. Lehnen Sie den Patch ab, stellen Sie die nicht relevanten Dateien wieder her und nennen Sie die verbotenen Pfade in der nächsten Anfrage.

Eine unsichere Befehlanfrage. Fragen Sie nach den Änderungen und dem Grund für deren Notwendigkeit, bevor Sie zustimmen.

Ein fehlerhafter Check. Fordern Sie eine Diagnose an, bevor weitere Änderungen erlaubt werden, und verlangen Sie Angaben zum Fehler, seiner wahrscheinlichen Ursache sowie dem kleinsten nächsten Experiment.

Schlechte lokale Inferenzgeschwindigkeit. Verkleinern Sie zunächst die Aufgabe und den Kontext. Beurteilen Sie erst danach ein anderes Modell oder Einstellungen zur Ausführung. Es wird hier keine Leistungsvergleiche durchgeführt, und jeder spätere Vergleich sollte die gemessene Latenzzeit, das Modell, die Ausführungszeit sowie die Hardware aufzeichnen.

Ein schnellerer Agent, der größere, schwieriger zu prüfende Unterschiede erzeugt, hat den Arbeitsablauf nicht verbessert.

Stellen Sie jeweils nur eine Einstellung ein

Sobald Suchvorgänge, Planungen, Vergleiche, Tests und Wiederherstellungsprozesse vorhersagbar ablaufen, passen Sie in jeder Runde nur eine Variable an. Ändern Sie das Modell, wenn die Ausgabequalität das Engpassproblem darstellt. Ändern Sie die Kontextstrategie, wenn relevanter Code ständig übersehen wird. Erleichtern Sie die Standardfreigabeverfahren erst dann, nachdem mehrere kleine, begrenzte Aufgaben gezeigt haben, dass der Prompt hier nichts schützt – und behalten Sie auch in diesem Fall Unterschiede, Tests sowie Möglichkeiten zur Rücksetzung bereit. Fügen Sie die Automatisierung zuletzt hinzu, sobald dem Validierungsbefehl vertraut werden kann.

Aiders Einrichtung ist versionssensitiv, daher lohnt es sich, vor erneuter Verwendung die Konfigurations- und Versionshistorie-Seiten zu überprüfen. Vergleichen Sie jeden Befehl, jedes Modellidentifikator sowie jede Konfigurationsoption mit den tatsächlich auf dem Gerät installierten Aider- und Ollama-Versionen.

Die Entscheidungsregel ist einfach: Behalten Sie ein Tool oder eine Einstellung nur bei, wenn es die Erledigung von Aufgaben, die Überprüfbarkeit oder die Wiederherstellung verbessert.