Wie wir Salty Poker bauen: Spec-Driven Development

Die meisten Pokerplattformen werden so gebaut, wie die meisten Pokerhände gespielt werden — schnell, nach Gefühl, im Gehen entschieden. Wir machen das nicht.

Vom ersten Tag an haben wir uns bewusst dafür entschieden, diese Plattform mit Spec-Driven Development zu bauen. Es ist eine Methodik, die in Kreisen der KI-gestützten Entwicklung ernsthaft an Fahrt aufnimmt, und sie ist das Fundament, auf dem alles steht, was wir bauen.

Was Spec-Driven Development bedeutet

Bevor eine einzige Zeile Produktionscode geschrieben wurde, wurde zuerst eine Spezifikation geschrieben. Über 100 Seiten. Dreiundzwanzig Module, die jede Domäne des Systems abdecken — Infrastruktur, Datenbankschema, API-Verträge, Service-Grenzen, Compliance-Kontrollen, CI/CD-Pipelines, operative Runbooks.

Die Methodik gliedert sich in drei Stufen. Spec-first: eine gründliche Spec wird vor jedem Code geschrieben und dann genutzt, um die Entwicklung zu steuern. Spec-anchored: die Spec bleibt lebendig und entwickelt sich neben der Codebasis weiter, während das Projekt reift. Spec-as-source: die Spec ist das Einzige, was der Mensch überhaupt anfasst — der Code wird vollständig aus ihr generiert.

Es gibt auch ein Fehlerschema, das man beim Namen nennen sollte: spec-once — dabei startet eine Spec ein Projekt und wird dann, je tiefer der Build geht, still und leise aufgegeben. Der Bauplan wird zur Reliquie.

Dagegen sind wir ausdrücklich designt. Unsere Spec ist ein lebendes Dokument. Sie wird aktualisiert, sobald Entscheidungen fallen, sobald Edge Cases auftauchen, sobald sich die Architektur weiterentwickelt. Wenn eine Session endet, spiegelt die Spec das wider, was gebaut wurde. Wenn die nächste Session startet, macht sie genau da weiter, wo die letzte aufgehört hat.

Warum das für eine Pokerplattform wichtig ist

Pokerplattformen scheitern auf vorhersehbare Weise — und fast alle diese Fehlerbilder gehen auf dieselbe Grundursache zurück: Abkürzungen, die früh genommen wurden und später zu ernsthaften Problemen anwachsen.

Ein Wallet-System, das ohne ein ordentliches doppelte-Buchführungs-Ledger gebaut wurde. Eine Game Engine, die nie richtig für Edge Cases unter Last getestet wurde. Eine Compliance-Schicht, die im Nachhinein angeschraubt statt von Tag eins an mit eingebacken wurde. Eine Plattform, die mit 50 Spielern gut läuft und bei 500 zusammenbricht.

Spec-Driven Development ist die Disziplin, die genau das verhindert. Jede Service-Grenze wird definiert, bevor sie gebaut wird. Jeder Datenfluss wird dokumentiert, bevor er implementiert wird. Jede Compliance-Anforderung steht in der Spec, bevor eine einzige Migration läuft. Es gibt keine Entscheidungen nach dem Muster "das klären wir später" — denn "später" ist, wenn Spieler bereits an den Tischen sitzen.

Agentic AI als Ausführungs-Engine

Wir nutzen Agentic AI, um diese Plattform zu bauen — und es gibt einen wichtigen Unterschied zwischen dem und den KI-Tools, die die meisten kennen.

Agentic AI beantwortet nicht nur Fragen oder vervollständigt Code. Sie führt mehrstufige Workflows autonom innerhalb definierter Grenzen aus — Code schreiben, Tests laufen lassen, Fehler abfangen, reparieren, committen — ohne dass ein Mensch jede Aktion überwachen muss. Sie arbeitet eine Aufgabe von Anfang bis Ende durch und gibt die Kontrolle zurück, sobald sie auf eine Entscheidung stößt, die einem Menschen vorbehalten ist.

Die Spec ist das, was das Ganze sicher und vorhersehbar macht. Der Agent operiert auf Basis einer definierten, geprüften, versionierten Spezifikation. Jede Session lädt eine fokussierte Teilmenge von Modulen — zwei bis vier auf einmal — und gibt dem Agenten genau den Kontext, den er braucht, und nichts darüber hinaus. Jede Session hat einen definierten Scope. Ein Checkpoint ist das Tor zur nächsten Phase. Nichts rückt weiter, bis die Checkliste sauber ist.

Der Agent entscheidet nicht, was gebaut wird. Das entscheidet die Spec. Der Agent führt aus.

Das Ergebnis

Eine Plattform, die mit der Strenge gebaut wurde, die sie verdient. Jede architektonische Entscheidung dokumentiert. Jede Service-Grenze bewusst. Jede Compliance-Anforderung gelöst, bevor sie zum Problem werden konnte.

Das ist es, was wir bauen. Und ihr werdet den Unterschied spüren, wenn ihr darauf spielt.

Ich schreibe über Spec-Driven Development als Methodik — die Entscheidungen, das Tooling, die Session-Struktur und was es jenseits von Poker bedeutet — auf The Salty Korean. Wenn euch die Engineering-Seite davon interessiert, liegen die tieferen Analysen dort.

Mehr zur Methodik: Using Spec-Driven Development with Claude Code von Heeki Park.

Stay salty.