Werkstattbericht · KI & Entwicklung
Ein Spiel. Zwei KI-Systeme. Weniger als 24 Stunden.
Wie wir Fakturus Puzzle mit Claude und Codex entwickelten – und welche Arbeit trotz des hohen Tempos blieb.
Fakturus Puzzle begann mit einer einfachen Idee: ein Spiel mit frei beweglichen Teilen, Platz neben dem Brett und eigenen Fotos. Ohne Werbung, mit einem kostenlosen Einstieg und einer geplanten Vollversion als Einmalkauf.
Mit Claude und Codex wurde daraus nach unserer Projekterfahrung in weniger als 24 Stunden ein spielbarer Entwicklungsstand. Die Systeme übernahmen die Umsetzung innerhalb vorgegebener Aufgaben. Hier zeigen wir, wie die Arbeit organisiert war, welcher Fehler dabei auffiel und was vor einer Veröffentlichung noch zu tun blieb.
Am Anfang stand ein Produktgedanke.
Im Projekt wurden früh Wünsche aus Nutzerbewertungen in konkrete Aufgaben übersetzt: Teile drehen können. Platz außerhalb des Bretts haben. Ein begonnenes Puzzle zuverlässig fortsetzen. Eigene Bilder verwenden. Das Spielgefühl bewahren, wenn neue Funktionen dazukommen.
Die technische Grundlage bildeten SwiftUI und SpriteKit. Eine Roadmap zerlegte die Arbeit in kleine, prüfbare Schritte. Die Systeme bauten auf vorhandenen Frameworks auf und mussten festgelegte Spielregeln umsetzen.
Vom Prototyp zu den Store-Aufnahmen.
Die Versionsgeschichte macht das Tempo greifbar. Am 14. Oktober 2026 um 19:11 Uhr wurde der erste Prototyp eingecheckt. Am 15. Oktober um 11:53 Uhr folgten überarbeitete Store-Aufnahmen. Dazwischen liegen knapp 17 Stunden – und zahlreiche Schritte von der Spiellogik bis zur Präsentation.
- Der Prototyp ist da.Ein natives Puzzle mit SwiftUI und SpriteKit bildet den Ausgangspunkt.
- Die Spielregeln werden testbar.Die PuzzleEngine trennt Logik von Darstellung und Eingabe.
- Fortschritt bleibt erhalten.Automatisches Speichern und mehrere angefangene Puzzles kommen hinzu.
- Gemeinsam puzzeln.Der Duo-Modus bringt zwei Personen an einem Gerät zusammen.
- Das Ergebnis wird sichtbar.Store-Aufnahmen für iPhone und iPad zeigen Spiel, Galerie und Kaufansicht.
Wie Claude und Codex im Projekt arbeiteten.
Beide Systeme kamen im Entwicklungsprozess zum Einsatz. Entscheidend war der gemeinsame Arbeitsstand: Code, Roadmap und Tests lagen im Projekt. Eine Aufgabe sollte klein genug sein, um sie umzusetzen, zu prüfen und als eigenen Commit nachvollziehbar festzuhalten.
Der vorgegebene Ablauf: einen Test für das gewünschte Verhalten schreiben, die Funktion implementieren, aufräumen und erneut prüfen. So ließ sich nach jedem Schritt kontrollieren, ob die Aufgabe erfüllt war.
Mit „voll autonom“ meinen wir die eigenständige Implementierung innerhalb dieser Aufgaben. Produktidee und Prioritäten kamen von Menschen. Die Arbeitsregeln verlangten Feedback an Meilensteinen und Prüfungen auf dem iPhone; ein späterer Fehlerfix stützte sich auf den Spielstand eines Testers. Wie viel menschliche Betreuung und Prüfzeit insgesamt nötig war, lässt sich aus dem Git-Verlauf nicht rekonstruieren.
Warum ein Puzzle bei 97 Prozent hängen blieb.
Ein dokumentierter Fehler zeigt, warum Nacharbeit nötig war: Ein Puzzle sah fertig aus, blieb aber bei 97 Prozent stehen. Das letzte Teil verdeckte die Lücke, lag jedoch außerhalb der Fangdistanz und rastete nicht ein. Der Fix vom 15. Oktober stützte sich auf einen echten Tester-Spielstand. Die Korrektur passte die Fangdistanz an den Zoom an und ergänzte einen Regressionstest.
Weitere Änderungen betrafen Fehlgriffe, die Brettgröße, eine Lupe über dem Hinweis-Button und schmale Fenster. Ob sich ein Teil unter dem Finger richtig anfühlt, wird durch eine korrekte Spiellogik allein nicht beantwortet.
Die vorhandenen Tests prüfen unter anderem verlorene Teile, Gruppenzustände und das Wiederherstellen gespeicherter Partien. Auch vollständige Lösungsabläufe werden simuliert. Für diesen Bericht haben wir den Testcode und die Änderungshistorie gelesen; die Spieltests wurden dafür nicht erneut ausgeführt.
Wie sich die Entwicklungsarbeit verändert.
Der Vergleich mit Softwareentwicklung vor zwei Jahren führt für uns zu einer Frage: Wie beschreiben wir Aufgaben so, dass Systeme mehrere Schritte selbstständig bearbeiten und prüfen können? Bei Puzzle musste genau dieser Ablauf organisiert werden.
Wir mussten festlegen, was das Spiel können soll, Aufgaben eingrenzen und Ergebnisse prüfen. Technisches Verständnis blieb wichtig, um falsche Annahmen in Code und Tests zu erkennen.
Für uns gehört KI damit zur weiteren Entwicklungsarbeit. Dieser Ablauf verändert, welche Ideen wir überhaupt ausprobieren. Was sich aus dem Puzzle-Projekt auf andere Aufgaben übertragen lässt, müssen weitere Projekte zeigen.
Neue Chancen. Und neue Wege, sich zu täuschen.
Die Chance liegt besonders bei kleinen, klar umrissenen Produkten. Ein Spezialwerkzeug für einen Betrieb, eine bislang zu kleine Zielgruppe oder ein ungewöhnlicher Spielmodus werden leichter ausprobierbar. Frühes Feedback kann an etwas Nutzbarem stattfinden.
Mit dem Tempo wächst allerdings auch die Menge dessen, was geprüft werden muss. Zwei KI-Systeme können dieselbe falsche Annahme teilen. Tests können die Implementierung bestätigen und dabei eine unvollständige Anforderung übersehen. Gut aussehende Oberflächen können darüber hinwegtäuschen, dass Wiederherstellung, Fehlerfälle oder Datenschutz noch offen sind.
Auch Berechtigungen werden zur Produktentscheidung: Welche Dateien darf ein Agent ändern? Welche Zugangsdaten benötigt er? Welche Handlung erreicht schon echte Nutzer? Ein schneller Entwicklungsprozess braucht klare Grenzen und einen Weg zurück, wenn eine Änderung fehlschlägt.
Und Inhalte haben eine Herkunft. Die Puzzlemotive im Projekt sind Fotos und Gemälde mit dokumentierten Quellen und Lizenzen. Das App-Icon wurde generiert. Für diesen Artikel sind die beiden silbernen Symbolbilder ebenfalls KI-generiert; die Spielaufnahmen stammen aus dem Projekt. Diese Unterscheidung gehört für uns zur Qualität.
Welche Funktion gehört wirklich ins Spiel?
Ein kurzer Entwicklungszyklus kann verführen, immer mehr Funktionen anzuhängen. Mit dem Duo-Modus lässt sich Puzzle zu zweit an einem Gerät spielen.
Die nächsten Entscheidungen verlangen trotzdem ein Urteil: Ist das verständlich? Wird es gebraucht? Ist der zusätzliche Aufwand für Pflege und Support gerechtfertigt? Eine autonom geschriebene Funktion beantwortet diese Fragen noch nicht.
Am betrachteten Projektstand waren in der Roadmap noch Barrierefreiheit, zusätzliche Geräteprüfungen, die Einrichtung des In-App-Kaufs, Datenschutz- und Rechtsprüfung sowie Beta und App-Store-Veröffentlichung offen. Eine Roadmap kann dem tatsächlichen Stand hinterherlaufen; sie belegt hier keinen Abschluss dieser Arbeiten.
Claude und Codex brachten dieses Projekt schnell zu einem spielbaren Stand. Ob sich der Ablauf für andere Produkte bewährt und wie viel Aufwand die Pflege erfordert, wird sich erst im weiteren Einsatz zeigen.