Sperrobjekt Weblog

Die Umsetzung

Im Januar 2025 kam dann die Meldung, dass GitHub Copilot auch LLMs von Anthropoic, Google und OpenAI untestützt. Zuvor hatte ich nur zaghaft mit "Vibe Coding" experimentiert, und die Antworten der AI-Modelle waren auch oft enttäuschend geblieben. Aber nach vermehrt positiven Berichten gab ich den Coding-Assistenten eine neue Chance. Und es hat erstaunlich gut funktioniert!

Nach wenigen Prompts hatte mit Copilot ich eine SPARQL-Query erzeugt, die mir das gewünschte Ergebnis liefert. Beinahe gleichzeitig entdecke ich auch Spinach Wikidata, einen

experimental assistant designed to help users converse data stored in Wikidata using natural language.

Spinach schlug folgende Abfrage vor:

SELECT ?community ?communityLabel ?twin ?twinLabel WHERE {
  ?community wdt:P190 ?twin.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
LIMIT 50

und erklärte sie auf Wunsch auch:

• WHERE { ?community wdt:P190 ?twin. }:
  • wdt:P190 is the property for "twinned administrative body."
  • The query retrieves all pairs of entities where a community (?community) is linked to its twin (?twin) via this property.
• SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }:
  • This ensures that the labels (?communityLabel and ?twinLabel) are retrieved in the user's preferred language (or English as a fallback).

Das war schon ziemlich gut als Grundlage. Weitere Verfeinerungen nahm ich dann im Wechsel manuell und mithilfe von Copilot und Spinach vor. Aufgrund der Menge der Daten kann der Wikidata-Endpoint schon einmal überlastet werden oder in einem Timeout laufen. Daher musste ich die Daten in mehrere Abfragen unterteilen.

Und schließlich galt es auch noch die Kartenanzeige im Frontend zu verbessern. Auch hier nutzte ich meine AI-Assistanten zum Ausbauen meines rudimentären Code-Gerüsts, später auch zum Refaktorieren und Aufteilen des Codes in separate Funktionen.

Das Ergebnis

Nach einigen Feierabend-Sitzungen und weiteren, diesmal manuellen Überarbeitungen war ich mit dem Prototypen erst einmal zufrieden. Die Daten werden jetzt in mehreren Abfragen von Wikidata ausgelesen, umgeformt und in der Datenbank gespeichert. Die Anzeige auf der Karte erfolgt bei geringen Zoomstufen als Cluster, beim Reinzoomen dann genauer. Nach dem Klick auf eine Gemeinde wird wieder so weit herausgezoomt, dass alle Partnerkommunen angezeigt werden.

Ich habe noch ein paar Ideen für Features und Verbesserungen, aber die Anwendung funktioniert erstmal und ist live unter jumelages.gutjahr.dev zu sehen. Der Quellcode liegt auf Codeberg im Repository mattsches/jumelages.

Was noch fehlt

In Wikidata sind offenbar noch deutlich mehr "twinned administrative bodies" eingetragen, aber mir ist es bisher nicht gelungen, sie abzufragen. Denn es scheint für Gemeinden/Städte keine übergreifende Eigenschaft oder Hierarchie zu geben, mit der ich die entsprechenden Einträge zurückbekommen könnte. Manche deutschen Gemeinden sind als "Q116457956 non-urban municipality in Germany" klassifiziert, was wiederum eine Unterklasse von "Q262166 municipality in Germany" darstellt, die wiederum auf "Q15284 municipality" basiert. Und so weiter. Da reichen meine Wikidata-/SPARQL-Kenntnisse nicht weit genug, und auch die KI konnte mir bisher nicht weiterhelfen. Vielleicht findet sich ja eine human intelligence, die dafür eine Lösung kennt.

Ich würde außerdem die geraden Linien zwischen den Partnerkommunen durch gebogene Kurven ersetzen. Es gibt für diesen Zweck ein Leaflet-Plugin, aber damit habe ich mich noch nicht weiter beschäftigt. Mein erster Eindruck ist jedoch positiv, das Feature sollte sich umsetzen lassen.

Für weitere Ideen und Feature Requests bin ich offen (habe auch selbst noch ein paar weitere), aber die Umsetzung hängt natürlich stark von zeitlichen Ressourcen ab. Vielleicht sollte ich auch mal messen, ob Jumelages überhaupt genutzt wird - Tracking habe ich noch gar nicht eingebaut.

Fazit

Allgemein

Aus einem Gedankenexperiment und persönlichem Interesse wurde eine konkrete Idee, und diese ließ sich erfolgreich umsetzen. Die Anwendung ist live und funktioniert als Prototyp. Die Entwicklung hat mir Spaß gemacht, ich konnte mich mit Technologien (z. B. SPARQL) intensiver beschäftigen und Projekte, die ich sehr mag (Openstreetmap, Wikidata), sinnvoll nutzen. Von daher bin ich sehr zufrieden.

Vibe-Coding

Zum Anderen habe ich viele Erfahrungen mit KI-Coding-Assistenten sammeln können und bin eigentlich ganz angetan von den Resultaten. Gerade für solche kleinen Tools und Prototypen eignet sich Vide-Coding recht gut - wie auch die Story von Rene Turcios zeigt, der mit diese Methode erfolgreich an zahlreichen Hackathons teilgenommen hat. Die Sorge um Code-Qualität einerseits, aber auch um die Zukunft unseres "Handwerks" schwingt natürlich mit. Aber ich kann dennoch jeder Software-Entwicklerin und jedem Software-Entwickler raten, sich mit KI, LLMs und dem sich rasend schnell entwickelnden Ökosystem drum herum auseinanderzusetzen. Und sei es nur, um fundiert mitreden und die Zukunft mitgestalten zu können.