Wir haben salty.poker mit KI gebaut. Hier ist der Teil, den niemand gesehen hat.

Zweiundzwanzig Build-Sitzungen in zehn Tagen.

Jede Sitzung: ein Claude Code-Agent, der nach einer 100-seitigen Spezifikation arbeitet — liest den aktuellen Zustand der Codebasis, nimmt das zugewiesene Spezifikationsmodul, schreibt Code, verbindet Dienste, führt Migrationen aus, macht Commits. Keine Schätzungsmeetings. Keine Umfangsgespräche. Keine Jira-Tickets, die in einem Konferenzraum debattiert werden.

Das Ergebnis dieser Sitzungen waren 20 Microservices, eine Echtzeit-Tisch-Engine, Turnierverwaltung, ein doppeltes Buchführungssystem, KYC-Überprüfung, Betrugserkennung und ein in PixiJS gerenderter Pokertisch mit animierten Karten und Chip-Stacks.

Das Changelog deckt ab, was geliefert wurde. Dieser Post handelt von dem, was danach passierte.

Was Wirklich Passiert, Nachdem der Code Geschrieben Ist

Richtigen Code zu schreiben und ein funktionierendes System zu haben sind zwei verschiedene Dinge. Der Code besteht seine Unit-Tests. Die Dienste verhalten sich in Isolation korrekt. Aber wenn man alles verbindet — Web-App, Tisch-Engine, Echtzeitverbindungen, Authentifizierung, Datenbank — wächst die Angriffsfläche für Fehler schneller, als jede Test-Suite vollständig antizipieren kann.

Die vergangene Woche war diese Phase. End-to-End-Tests. Echte Logins, echtes Lobby, echte Tische, echte Spieler, die Platz nehmen.

Die Tischansicht lud und zeigte eine leere Leinwand, wo Sitze sein sollten. Kein Kauf-Dialog. Keine Möglichkeit, zum Lobby zurückzukehren. Ein leerer Bildschirm, wo ein Pokerspiel sein sollte.

Das Lobby hatte eine Tischkarte, die sich auf die gesamte Seitenhöhe ausdehnte. Ein CSS-Standard — so verhält sich CSS Grid eben, wenn es nur ein Element in der Zeile gibt und man das Stretch-Verhalten nicht überschrieben hat.

Keiner dieser Bugs wurde von einem Menschen geschrieben. Eine KI-Sitzung schrieb die Tischansicht. Eine KI-Sitzung schrieb das Lobby. Es waren trotzdem Bugs. Sie mussten trotzdem gefunden, bis zur Ursache zurückverfolgt und behoben werden.

Warum Dies Trotzdem der Bessere Weg Ist

Bevor die Wie-es-kaputt-gegangen-Geschichte: die Tatsache, dass wir in zehn Tagen bei End-to-End-Tests sind, ist die Geschichte.

Zwei frühere Unternehmen haben mir gelehrt, wie lange das auf traditionelle Weise dauert. Monate des Gerüstbaus, bevor man etwas zum Testen hat. Weitere Monate, bevor man etwas testet, das dem Endprodukt ähnelt.

Wir haben diese Lücke in zehn Tagen geschlossen. Die Testphase ist der schwierige Teil. Wir sind drin.

Was in Dieser Serie Kommt

Dies ist Post eins von vier. In der nächsten Woche werden wir durchgehen, was wir beim Testen wirklich gefunden haben — ein Routing-Bug, der unsichtbar war, bis der vollständige Stack lief, eine Entwicklungsumgebung, die Code-Änderungen still ignorierte, und ein Auth-Guard, der jeden Navigationsversuch in eine Redirect-Schleife schickte.

Für die tiefere Methodik schreibe ich darüber auf The Salty Korean.

Stay salty.