Im zweiten Teil ging es darum, was die App kann. Jetzt der unangenehmere Teil: was dabei kaputtging, wer daran schuld war und was davon sich auf einen Kanzleischreibtisch übertragen lässt.

Die Arbeitsteilung

Fangen wir mit dem Begriff an, der gerade durch jede Diskussion geistert: „Vibe Coding“: Man beschreibt, was man haben will, übernimmt das Ergebnis und schaut nicht hin.

So lief es hier nicht. Die Anforderungen kamen von mir, die Entscheidungen auch: Was ist ein eigener Datensatz? Wie hängen Erweiterungen am Grundspiel? Welche Reihenfolge hat der Redaktionsexport? Code und Struktur kamen von Claude. Und dann wurde jede Datei eingebaut, gestartet, ausprobiert und wenn es klemmte, gemeinsam diagnostiziert.

Das ist ein wichtiger Unterschied. Nicht weil ich den Code Zeile für Zeile geprüft hätte, das kann ich in Swift schlicht nicht. Sondern weil ich jederzeit wusste, was die App tun sollte, und deshalb sofort merkte, wenn sie etwas anderes tat. Fachliche Kontrolle ersetzt keine technische Prüfung, aber sie fängt erstaunlich viel ab.

Was das Modell falsch gemacht hat

Drei Fehler haben mich echte Zeit gekostet, und alle drei waren lehrreich.

Der erste war der teuerste, weil er „leise“ war. Mehrfach wurden neue Datenfelder angelegt, ohne sie als optional zu kennzeichnen. Die Folge: Beim Start scheiterte das Laden der alten Sicherungs- bzw. Exportdaten, die kannte das neue Feld ja nicht, und die App zeigte nur ihre alten Beispieldaten an. Kein Fehler, keine Meldung, nur plötzlich falsche Spiele in meinem Regal. Wer nicht weiß, dass es Beispieldaten gibt, denkt an dieser Stelle, seine Sammlung sei weg.

Der zweite war handwerklich. Einmal wurden vier Dateien gleichzeitig umgebaut, ohne die davon abhängigen mitzuziehen. Das Ergebnis war eine Fehlerkaskade, deren Ursprung sich erst nach längerem Suchen zurückverfolgen ließ.

Der dritte war ein Ratschlag. „Dupliziere das Projekt als Sicherung, bevor du das umbaust.“ Klingt vernünftig. In Swift Playground führte es dazu, dass der Datencontainer beim Kopieren nicht mitkam. Die Sicherung war also genau das Problem. Ein gut gemeinter Rat, der die Lage verschlechtert hat.

Das ist der Punkt, den ich für die wichtigste Erkenntnis der zehn Tage halte: Die gefährlichen Fehler sind nicht die, bei denen etwas rot aufleuchtet. Es sind die, bei denen alles normal aussieht.

Was das Werkzeug falsch gemacht hat

Um fair zu bleiben: Der größere Teil des Ärgers ging nicht auf das Modell zurück, sondern auf die Umgebung.

Swift Playground ist für Lernprojekte mit drei Dateien gebaut. Meine App hat inzwischen dreißig. In dieser Größenordnung traten immer dieselben Symptome auf: Dateien, die sich partout nicht registrieren ließen. Umbenennungen, die nach einem Neustart wieder zurücksprangen. Und eben jene Datencontainer, die beim Kopieren verlorengingen.

Der Tiefpunkt: Ein verrutschtes Einfügen löschte zwei Dateien. Kein Papierkorb, keine Historie, keine Rücknahme. Drei Stunden Wiederherstellung, für einen Fehlgriff von einer Sekunde.

Die wichtigste Lehre

Nach drei Tagen hatte sich eine Regel herausgeschält, die den Rest des Projekts getragen hat: immer komplette Dateien, nie Teiländerungen.

„Ersetze in Zeile 47 den Ausdruck durch…“ klingt effizient und ist die häufigste Fehlerquelle überhaupt. Man fügt an der falschen Stelle ein, übersieht eine Klammer, oder die Beschreibung passt nicht mehr, weil sich die Datei zwischenzeitlich geändert hat. Eine vollständige Datei dagegen ist eindeutig: markieren, ersetzen, starten. Sie kostet mehr Zeichen und spart Stunden.

Wem gehören eigentlich die Daten?

Ein Exkurs, der über das Projekt hinausgeht und der euch als Spielerinnen und Spieler direkt betrifft.

BoardGameGeek verlangt seit dem letzten Jahr eine Registrierung für seine Schnittstelle. Das ist verständlich und für nicht-kommerzielle Zwecke kostenlos; die Auflage ist im Wesentlichen das „Powered by BGG“-Logo. Nur: Die Schnittstelle liest. Sie schreibt nicht. Meine 150 Spiele kann ich aus BGG in meine App holen. Meine eigene Sammlung dort zu pflegen bleibt Klickarbeit, Titel für Titel.

Bei Kickstarter und Gamefound ist es schlichter: Dort gibt es gar keine offene Schnittstelle. Alles, was ich über meine unterstützten Projekte weiß, habe ich selbst zusammengetragen: aus Mails, Screenshots und einer über Jahre gepflegten Tabelle. Deshalb betreiben wir hier auf dem Blog überhaupt Crowdfunding-Archäologie: Was die Plattformen nicht herausgeben, verschwindet mit ihnen.

Man merkt es beim Bauen deutlicher als beim Benutzen. Die eigenen Daten liegen in fremden Häusern, und die Tür geht nur in eine Richtung auf.

Was ich für die Kanzlei mitnehme

Vier Dinge, und keines davon hat mit Swift zu tun.

Das Datenmodell schlägt die Syntax. Wer weiß, wie ein Sachverhalt strukturiert ist, kommt mit einem Modell weit, auch ohne die Sprache zu beherrschen. Wer es nicht weiß, bekommt sehr schnell sehr viel Code, der das Falsche tut.

Die Prüfpflicht wandert, sie verschwindet nicht. Ich musste den Code nicht schreiben. Aber ich musste wissen, was herauskommen sollte, und das Ergebnis dagegen halten. Genau so wird es bei jedem KI-Einsatz im Beruf sein.

Stille Fehler sind das eigentliche Risiko. Eine Fehlermeldung ist harmlos, sie zwingt zum Hinsehen. Ein plausibles falsches Ergebnis ist es nicht. Das gilt für Beispieldaten in einer Spiele-App genauso wie für alles, was in einer Kanzlei plausibel aussieht.

Sicherung und Versionierung sind keine Kür. Die drei Stunden Reparatur wären mit einer ordentlichen Versionsverwaltung ein einziger Befehl gewesen. Ich habe das dreißig Jahre lang für ein Entwicklerthema gehalten. Es ist eine Arbeitstechnik.

Wie es weitergeht

Der Mac mini ist bestellt. Damit wird aus Swift Playground Xcode, aus „bloß nichts kaputtmachen“ eine Versionsverwaltung mit Git, und aus einer App auf einem iPad eine App auf mehreren Geräten, über CloudKit für die gemeinsamen Daten und TestFlight für die Verteilung an Familie und Redaktion.

Denn das ist die eigentliche Lücke im jetzigen Stand: Die App liegt auf einem iPad. Josef und Maja können ihre Ranglisten nicht pflegen, ohne dass ich ihnen das Gerät reiche. Für ein Werkzeug, dessen ganzer Witz die verschiedenen Perspektiven auf dieselbe Sammlung sind, ist das ein Konstruktionsfehler.

Und dahinter wartet das Thema aus dem ersten Teil: ein lokal betriebenes Sprachmodell. Wer erst einmal gesehen hat, wie viel Arbeit ein Modell abnehmen kann, versteht besser, warum die Frage, wo es läuft und was mit den Eingaben passiert, keine technische Randnotiz ist.

Und die Karteikarten?

Die liegen noch irgendwo zu Hause in einer Schachtel. Ich werde sie suchen, wenn wir aus dem Urlaub zurück sind – nicht nur aus Nostalgie, sondern weil die alten Spiele auch noch in die App müssen. Und weil die Idee damals bereits richtig war, aber so ist es nun einfacher.

Heute fragt uns die App, wer mitspielt und wie viel Zeit wir haben. Herauskommt dasselbe wie damals: ein Spiel, das neutral vorgeschlagen wird und deshalb keine Diskussion auslöst.

Manchmal braucht eine gute Idee eben dreißig Jahre Technikgeschichte, um richtig zu funktionieren.