Multi-Agenten-Power im Eigenheim: Wie ich mit OpenCode & AI mein Outdoor-Projekt „GeoTour“ aufgebaut habe

Eines vorweg: Ich war faul und habe alles mit KI gemacht. Auch diesen Blogbeitrag inklusive der reißerischen Überschrift. Für mich zählt das Ergebnis von einem Sonntag Nachmittag, mit dem ich zukünftig meine Wochenenden besser planen kann.

Kennst du das Gefühl, wenn du gerne wanderst oder Rad fährst, aber auf Karten schlicht den Überblick verlierst, wo du eigentlich schon überall unterwegs warst? Eine einfache Route anzuzeigen ist kein Problem – aber eine persönliche Abdeckungs-Heatmap („Wo war ich schon, wo fehlen noch weiße Flecken auf meiner Karte?“) ist oft gar nicht so leicht umzusetzen.

Genau dafür habe ich mein neues Projekt GeoTour ins Leben gerufen: Eine schlanke, lokale Webanwendung, die Komoot-Touren und GPX-Importe auf einer interaktiven Karte zusammenführt und visuell aufbereitet.

Das Besondere an diesem Projekt ist allerdings nicht nur das Ergebnis, sondern wie es entstanden ist: Ich habe GeoTour mithilfe eines Multi-Agenten-Systems auf Basis von OpenCode entwickelt.

In diesem Artikel nehme ich dich mit durch die Architektur, die Arbeitsweise des KI-Teams und die wichtigsten Erkenntnisse aus dem Projekt!

Das Ziel: Schlank, lokal & „Der Überblick muss sofort da sein“

Von Anfang an hatte das Projekt eine klare Leitlinie: Maximaler Nutzen bei minimaler Komplexität.

• Direkter Fokus: „Der Überblick muss sofort da sein.“ – Fokus auf die Desktop-Nutzung, die mobile Ansicht liefert das Nötigste.
• Kein Frontend-Build-Overhead: Keine Lust auf stundenlange npm build-Orgien oder komplizierte Toolchains. Als Frontend-Stack reichen Jinja2-Templates, Vanilla JS und Leaflet. Keine externen CDNs, keine unnötigen Node-Abhängigkeiten im Produktivcode.
• Open Source & Kostenkontrolle: Das Multi-Agenten-System läuft in OpenCode ausschließlich mit freien KI-Modellen.
• Lokal & Zukunftsfähig: Gestartet als lokales Tool, mit dem Ziel, später auf einen eigenen 1blu VPS umzuziehen.

Wie das Multi-Agenten-Team gearbeitet hat

Statt der KI einfach nur unstrukturierte Prompts zuzuwerfen, habe ich ein rollenbasiertes System in OpenCode aufgesetzt. Jede Rolle hatte klare Aufgaben und Befugnisse:

• Der Architekt (@architect): Planer und Entscheider. Er hielt das „Produktgedächtnis“ sauber, traf Systementscheidungen und führte Architectural Decision Records (ADRs).
• Die Coder (@coder): Zuständig für das Backend (FastAPI, Python) und Frontend (Leaflet, JS). Max. 2 Coder arbeiteten gleichzeitig, um Merge-Konflikte in Dateien zu vermeiden.
• Der Protokollant (@scribe): Dokumentations-Guru für ADRs und Spezifikationen.
• Der Tester (@reviewer-tester): Prüfte Code, deckte Kantenfälle auf und stellte sicher, dass die Testsuite grün blieb.

Disziplin ist alles: Klare Regeln für das KI-Team

Damit ein solches Multi-Agenten-System nicht im Chaos versinkt, gab es harte Projekt-Konventionen:

1. Verbindliche ADRs: Keine relevante technische Entscheidung blieb ungeklärt im Raum stehen. Jede Entscheidung wurde formell festgehalten.
2. Kompakte Feedback-Loops: Maximal zwei Nacharbeitsrunden pro Aufgabe.
3. Feste Arbeitsgrenzen: Der Coder durfte nur an App-Dateien arbeiten, der Architekt/Scribe nur an der Dokumentation.

Die Meilensteine & Iterationen

Die Entwicklung verlief in knackigen, fokussierten Iterationen:

1. M1 – Karte & GPX-Import: Basispfad aufbauen. GPX-Dateien hochladen, parsen und als farbige Linien auf der Leaflet-Karte darstellen.
2. M2 – Inkrementeller Komoot-Abgleich: Ein Anbindungs-Modul holt Touren direkt von Komoot. Dabei gab es spannende Erkenntnisse: Der Login-Schritt erwies sich bei genauer Analyse als GET mit Basic-Auth (statt des ursprünglich vermuteten POSTs), und bei REST-Anfragen verlangte die Schnittstelle präzise Accept-Header (application/hal+json).
3. M3 – Die Abdeckungs-Heatmap: Ein serverseitiges Raster unterteilt die Karte in Kacheln (Standard: 1 km²). Die Anwendung zählt, wie viele Touren eine Kachel kreuzen, und zieht eine sanfte, petrolfarbene Heatmap-Ebene drüber.

Technische Highlights & Features

Über die Zeit ist aus dem initialen Prototyp ein richtig runder Kartendienst geworden:

• Smarte Heatmap: Eine transparente Petrol-Färbung (#0a5a69), die bewusst nicht mit der feurig-roten Auswahllinie kollidiert. Bereits ab 10 Touren pro Kachel erreicht die Farbe ihre volle Intensität.
• Koppelung von Liste & Karte: Die Tourenliste in der Seitenleiste passt sich dynamisch dem sichtbaren Kartenausschnitt an. Ein Klick auf eine Tour zentriert die Karte mit passendem Zoom.
• Volle Kontrolle über die Optik: Schieberegler für die Deckkraft von Touren und Heatmap sowie anpassbare Kachelgrößen direkt in der Oberfläche.
• Robuste Löschfunktion: Touren werden „weich“ gelöscht (deleted_at). So bleibt ein Fingerprint erhalten, damit gelöschte Touren bei einem erneuten Komoot-Import nicht plötzlich wieder auftauchen.
• Eigener UI-Verhaltensprüfstand: Ein extrem schneller JS-Harness testet die Leaflet-Oberfläche headless über Node-vm – ganz ohne schwerfälliges Browser-Automation-Tooling.

Meine wichtigsten Learnings

1. Klare Agenten-Rollen verhindern Verwirrung: KI-Modelle arbeiten um ein Vielfaches effizienter, wenn sie in engen Rollengrenzen agieren. Wenn der Architekt plant und der Coder nur baut, bleibt die Codebase sauber.
2. ADRs sparen KI-Kontext: Indem Architektentscheidungen in knappen Markdown-ADRs festgehalten werden, „vergisst“ das KI-System nie, warum eine Entscheidung so getroffen wurde.
3. Echte API-Recherche schlägt Annahmen: Schnittstellen wie Komoot verhalten sich manchmal anders als gedacht (z. B. HAL+JSON Header oder Basic-Auth Verhalten). Isolierte Tests vor der Anbindung sparen Frust.
4. Fehlende Node-Build-Tools sind eine Wohltat: Pure HTML/Jinja2-Templates mit nativem JavaScript und Leaflet machen das Projekt extrem leichtgewichtig, blitzschnell ausführbar und wartungsarm.

Stand & Ausblick

Der aktuelle Zwischenstand kann sich sehen lassen: 487 Backend-Tests grün, 31 Frontend-Harness-Szenarien bestanden und eine voll funktionsfähige Karte inklusive Heatmap und Komoot-Abgleich.

Als nächstes steht die visuelle Filter-Oberfläche (Filtern nach Status, Sportart und Zeitraum) auf dem Plan, bevor das Ganze für den Dauerbetrieb auf meinen 1blu VPS wandert.

Hast du Fragen zum Aufbau des Multi-Agenten-Systems oder zur Umsetzung mit OpenCode? Lass es mich gerne in den Kommentaren wissen!