Teil 5 der Serie: Unsere Motorrad-App brauchte eine neue Pass-Datenbank — sauber lizenziert, vollständig aus OpenStreetMap. Zwei KI-Agenten (Gemini und Codex) erhielten denselben schriftlichen Auftrag, Claude orchestrierte und wertete aus. Ein Agent lieferte alle 29 Länder mit 82,6 % Höhenabdeckung, der andere strandete bei 5 Ländern mit 0 % Höhendaten — fand dafür aber die Schwächen, die der Sieger übersehen hatte. Der Artikel rekonstruiert die Muster hinter dem Unterschied und zeigt, warum am Ende keine der beiden Datenbanken direkt in die App kam.
In Teil 2 dieser Serie haben sechs Modelle dieselbe Architekturfrage beantwortet — und die Mehrheit lag daneben. Diesmal ging es nicht um eine Meinung, sondern um ein Werkstück: ein lauffähiges Extraktions-Script plus eine fertige Datenbank. Das macht den Vergleich härter, denn das Ergebnis ist zählbar. Und es zeigte ein Muster, das uns seitdem bei jedem Agenten-Einsatz begleitet.
Die Ausgangslage: einige tausend Pässe, die uns nicht gehörten
Unsere Motorrad-App Kurvenfokus erkennt automatisch, welche Gebirgspässe eine aufgezeichnete Tour überquert hat. Dahinter lag eine mitgelieferte Datenbank mit einigen tausend europäischen Pässen. In der Beta-Phase fiel das nicht weiter auf. Ein Lizenz-Audit vor dem Store-Release brachte dann die unbequeme Erkenntnis: Die verwendete Quelle steht unter keiner offenen Lizenz. Neben dem Urheberrecht schützt in der EU auch das Datenbankherstellerrecht (§§ 87a ff. UrhG) die Investition eines Datenbankherstellers — wesentliche Teile einer fremden Datenbank dürfen ohne Lizenz nicht in ein kommerzielles Produkt übernommen werden, unabhängig davon, wie frei zugänglich die Daten im Netz sind. Für uns war damit klar: Vor dem Store-Release brauchte die App eine eigene, sauber lizenzierte Datenbasis.
Die Alternative lag nahe: OpenStreetMap kennt europaweit Knoten mit dem Tag mountain_pass=yes, samt Name und Höhe, unter der ODbL-Lizenz — nutzbar mit Quellenangabe. Die Frage war nur: Wie kommt man von Roh-OSM zu einer Datenbank, die der bisherigen qualitativ ebenbürtig ist?
Das Experiment: ein Auftrag, wortgleich an zwei Agenten
Statt die Extraktion einem einzigen Modell anzuvertrauen, haben wir denselben schriftlichen Auftrag an zwei CLI-Agenten übergeben: Gemini und Codex (der Kommandozeilen-Agent von OpenAI). Beide bekamen identische Dateien: dieselbe Auftragsbeschreibung, dieselbe Referenz-Datenbank zum Gegenprüfen, dieselben Rahmenbedingungen. Der Auftrag war bewusst präzise formuliert:
- 29 Zielländer per Overpass-API, Abfrage je Land über den ISO-Ländercode — inklusive Sonderfällen wie Kosovo und den Färöern, deren Abfrage bekanntermaßen hakt.
- Kernfrage Befahrbarkeit: Wie filtert man zuverlässig auf Pässe, die mit dem Motorrad erreichbar sind? Mit Zahlen je Land, mit und ohne Filter, plus begründeter Empfehlung.
- Robustheit ausdrücklich gefordert: Pausen zwischen Länder-Abfragen, Timeout mit Wiederholung, Zwischenstände je Land in einen Cache — damit ein Abbruch nicht alles verliert.
- Exaktes Ausgabe-Schema und ein Bericht mit Match-Quote gegen die Referenz, Stichprobe prominenter Pässe und Lizenz-Einordnung.
Und Claude? War bewusst nicht dritter Kandidat, sondern Versuchsleiter: Claude hatte das Lizenzproblem diagnostiziert, formulierte den Auftrag, verteilte ihn an beide Agenten und wertete anschließend die Ergebnisse aus. Diese Rollenteilung — ein Orchestrator, mehrere unabhängige Bearbeiter — ist die praktische Konsequenz aus Teil 3 dieser Serie.
Das Ergebnis: 29 zu 5
Nach den Läufen standen zwei Berichte nebeneinander, die kaum unterschiedlicher sein konnten:
| Gemini | Codex (Hauptlauf) | |
|---|---|---|
| Länder abgeschlossen | 29 von 29 | 5 von 29 (Rest: „nicht gestartet") |
| Extrahierte Kandidaten | 16.540 | 6.739 |
| Einträge mit Höhenangabe | 82,6 % | 0,0 % |
| Match-Quote gegen Referenz (< 500 m) | 54,9 % | 11,1 % |
| Prominente Pässe gefunden (Stichprobe) | 8 von 8 | Bonette, Iseran, Galibier als „nicht gefunden" gelistet |
Die letzte Zeile ist die aufschlussreichste: Codex' Bericht führte den Col de la Bonette (2.802 m), den Col de l'Iseran und den Col du Galibier — drei der berühmtesten Motorradpässe Europas — als in OSM „nicht gefunden". Sie sind selbstverständlich in OpenStreetMap erfasst; Geminis Lauf fand alle drei. Codex' eigener, zu streng eingestellter Befahrbarkeits-Filter hatte sie aussortiert: In Frankreich ließ er von 3.920 Pass-Knoten ganze 58 durch, in Deutschland 4 von 549 — und meldete anschließend für Deutschland eine Match-Quote von 0 %.
Die Muster: Woran der Unterschied wirklich lag
Es wäre bequem, daraus „Gemini ist besser als Codex" zu machen. Das gäbe der Lauf nicht her — und es würde die eigentliche Lektion verdecken. Der Unterschied lag in drei Prozess-Mustern, die mit Modell-Intelligenz wenig zu tun haben:
Muster 1: Langläufer-Disziplin
Der Auftrag war ein Marathon: 29 Länder, Wartezeiten zwischen den Abfragen, große Antwortmengen. Gemini arbeitete die Liste vollständig ab und nutzte den geforderten Länder-Cache, sodass auch ein Abbruch nichts verloren hätte. Codex' Hauptlauf endete nach 5 Ländern — der Bericht weist die übrigen 24 ehrlich als „nicht gestartet" aus, aber der Lauf wurde nicht wieder aufgenommen. Bei Agenten-Aufgaben mit vielen gleichförmigen Schritten ist die Fähigkeit, dranzubleiben und Zwischenstände zu sichern, wichtiger als jede Einzelantwort-Qualität.
Muster 2: Ein Parser-Fehler skaliert auf 100 % Verlust
0,0 % Höhenabdeckung bei Codex gegen 82,6 % bei Gemini — aus derselben Datenquelle. Das ist kein Datenproblem, sondern ein einzelner Extraktions-Fehler beim Auslesen des Höhen-Tags, der sich stillschweigend über den gesamten Bestand multiplizierte. Kein Absturz, keine Fehlermeldung: Das Script lief „erfolgreich" durch und schrieb brav e:0 in jeden Datensatz. Stille Totalausfälle einzelner Felder gehören zu den gefährlichsten Fehlerklassen bei automatisierter Datenextraktion — sie fallen nur auf, wenn jemand die Verteilung der Werte anschaut.
Muster 3: Wer nicht an der Realität prüft, merkt nichts
Der entscheidende Unterschied: Gemini prüfte sein Ergebnis gegen eine Stichprobe prominenter Pässe — Stilfser Joch, Großglockner, Timmelsjoch, Galibier — und fand 8 von 8. Ein eingebauter Realitäts-Anker. Codex meldete 0 % Treffer für Deutschland, ein Land mit Dutzenden bekannten befahrbaren Pässen, ohne dieses offensichtlich unplausible Ergebnis zu hinterfragen. Dieselbe Lektion wie in Teil 4, nur eine Ebene tiefer: Nicht nur Modelle muss man an der realen Aufgabe messen — auch ihre Zwischenergebnisse brauchen einen Abgleich mit dem, was offensichtlich wahr sein muss.
Warum der Verlierer trotzdem unverzichtbar war
Und jetzt die Pointe, die den Lauf zur Multi-Modell-Geschichte macht: Die wertvollsten Einzelbeiträge kamen vom abgebrochenen Lauf. Codex lieferte die präziseste Methodenkritik — etwa den Hinweis, die Distanz zur Straße gegen die tatsächliche Weg-Geometrie zu messen statt nur gegen deren Stützpunkte, und die Warnung, dass Feldwege und Zufahrtsstraßen eine zweite Prüfstufe über Zugangs- und Belag-Attribute brauchen. In einem separaten Nachlauf prüfte Codex zudem alle 29 Länder als reine Kandidatenliste (14.630 Knoten) und verifizierte die Lücken der alten Datenbank auf der Karte. Gemini wiederum lieferte neben der brauchbaren Datenbasis auch ungefragt eine Reihe zusätzlicher Dokumente — von der Zielgruppen-Analyse bis zum Investoren-Pitch. Übererfüllung klingt charmant, ist aber die Kehrseite desselben Phänomens: Agenten brauchen nicht nur Antrieb, sondern auch Scope-Disziplin.
Keine der beiden Datenbanken kam am Ende direkt in die App. Die finale Pipeline baute Claude — mit Geminis Extraktionsansatz als Basis und Codex' Filterkritik als Korrektiv. Der entscheidende Schritt: Das rohe mountain_pass=yes enthält hunderte Hochgebirgs-Sättel, die nur zu Fuß oder mit Steigeisen erreichbar sind; der höchste „Pass" der Rohdaten liegt auf 4.452 Metern mitten im Gletschergebiet des Monte Rosa. Der finale Befahrbarkeits-Filter behält nur Pässe mit asphaltierter öffentlicher Straße in maximal 150 Metern Entfernung — das entfernte 874 nicht befahrbare Sättel. Übrig blieben 4.468 benannte, höhenverifizierte, befahrbare Pässe in 27 Ländern — spürbar mehr als zuvor, vollständig unter ODbL, reproduzierbar per Script.
Was davon bleibt
- Identische Aufträge sind das schärfste Vergleichsinstrument. Erst der wortgleiche Auftrag machte die Unterschiede messbar — jede individuelle Formulierung hätte die Ergebnisse unvergleichbar gemacht.
- Bei Langläufer-Aufgaben Prozess-Anforderungen explizit machen: Cache, Wiederaufnahme, Zwischenberichte. Und trotzdem damit rechnen, dass ein Agent sie ignoriert.
- Jedem Agenten-Ergebnis eine Plausibilitätsprüfung nachschalten: Verteilungen anschauen (82,6 % gegen 0,0 % Höhen hätte jede Stichprobe sofort gezeigt) und gegen bekannte Wahrheiten testen — die Stichprobe prominenter Pässe kostete nichts und fing den größten Fehler.
- Den „Verlierer" nicht wegwerfen. Der abgebrochene Lauf lieferte die Methodenkritik, die die finale Pipeline besser machte. Multi-Modell heißt nicht „der Beste gewinnt alles", sondern „jeder Beitrag wird geprüft und verwertet".
Quellenverzeichnis
- OpenStreetMap Wiki: Tag mountain_pass=yes (abgerufen 2026-08-04; Definition des verwendeten Pass-Tags)
- OpenStreetMap Wiki: Overpass API (abgerufen 2026-08-04; Abfrage-Schnittstelle der Extraktion)
- Open Data Commons: ODbL 1.0 (abgerufen 2026-08-04; Lizenz der OSM-Daten, Attributionspflicht)
- § 87a UrhG (gesetze-im-internet.de) (abgerufen 2026-08-04; Datenbankherstellerrecht)
- Interne Messläufe und Berichte der beiden Agenten-Sessions vom 2026-08-01/02 (eigene Daten: Kandidaten- und Match-Zahlen, Höhenabdeckung, Länder-Status); finale Zahlen aus dem Build-Protokoll der Pipeline. Eigene Auswertungen sind als solche gekennzeichnet.