Die Preview ist nicht das Produkt
Sieh dir die Demo irgendeines KI-App-Builders an — unsere eingeschlossen — und du siehst denselben Bogen: ein Prompt, ein Fortschritts-Feed und dann ein iframe mit einer funktionierenden App darin. Applaus. Das iframe ist echt, der Code ist echt, und der scheinbar schwere Teil — eine KI hat eine vollständige Full-Stack-Anwendung geschrieben — ist tatsächlich passiert.
Aber das iframe ist eine Preview, und eine Preview verspricht so gut wie nichts. Sie verspricht nicht, morgen noch da zu sein. Sie verspricht nicht, dass die nächste Iteration ihre Daten nicht löscht. Sie verspricht dem zweiten Nutzer überhaupt nichts, weil es meist keinen zweiten Nutzer gibt. Die Generierung ist einfach geworden; die Demo sind die leichten 80 %. Das Produkt ist der andere Teil — der, der genau in dem Moment beginnt, in dem ein Fremder eine URL eintippt und deiner App eine Zeile seiner Daten anvertraut.
Dieser Beitrag ist die Inventur genau dieser Lücke. Und zugleich die Design-Haltung, auf der die gesamte Plattform aufsetzt, einmal klar ausgesprochen:
Der Agent darf sich irren. Die Plattform nicht.
Jeder Mechanismus weiter unten existiert, um irgendein Versagen des Agenten — oder der Infrastruktur darunter — überlebbar zu machen: kraft Systeminvariante, nicht kraft Modellverhalten.
Was „Produktion“ wirklich verlangt
Daten, die den nächsten Deploy überleben
Die Datenbank der Preview ist ein Notizzettel; die Datenbank der Produktion ist ein Versprechen. In dem Moment, in dem echte Nutzer Zeilen schreiben, hört „Deploy“ auf, alles ersetzen zu bedeuten, und fängt an, den Code ändern, die Migrationen anwenden, sonst nichts anrühren zu bedeuten. Auf dieser Plattform ist das strukturell: Prod hat eine eigene Daten-Timeline ab dem ersten Release, Deploys wenden die ausstehenden Migrationen darauf an, und Prod-Daten mit denen von dev zu überschreiben ist ein separater, expliziter, per Snapshot abgesicherter Akt. Es gibt keinen Codepfad, auf dem das als Nebeneffekt geschieht.
Ein Rollback, das die Daten einschließt
Ein Release, das etwas kaputtmacht, ist nicht vollständig rückgängig gemacht, indem man nur den Code zurücknimmt — die Migration ist ja schon gelaufen. Jedes Release hier setzt vor dem ersten Eingriff einen Pre-Deploy-Checkpoint auf die Prod-Timeline, damit der Rollback Code und Daten auf denselben kohärenten Moment zurücksetzen kann, unter expliziten Regeln darüber, was er löschen darf.
Eine Verifikation, die sich nicht beschwatzen lässt
Eine Preview muss nur einmal richtig aussehen. Ein Produkt muss nach jeder Iteration richtig sein — auch nach Iteration vierzig, Monate später erstellt von einem Agenten ohne jede Erinnerung an Iteration eins. Deshalb wird „fertig“ von Compilern, Live-Contract-Probes und den eigenen Tests der App entschieden, niemals von der Selbsteinschätzung des Modells. Das interessante Detail: Der Contract ist die Deklaration des Architekten, also fällt ein Feature, das der Producer stillschweigend übersprungen hat, durch die Verifikation — selbst wenn der gesamte Code, den er tatsächlich geschrieben hat, einwandfrei ist.
Secrets, die niemand eingefügt hat
Die Preview kann Credentials faken; die Produktion nicht. Jedes Credential hier — Datenbank-URLs, Service-Passwörter, API-Keys — wird zur Provisioning-Zeit erzeugt, in Vault abgelegt und über einen einzigen verbindlichen Pfad als Kubernetes Secrets in den Namespace injiziert. Der Agent komponiert gegen Umgebungsvariablen, deren Werte er nie zu Gesicht bekommt. Es gibt nichts, das in einen Prompt lecken könnte, weil der Prompt es nie enthalten hat.
Leerlaufkosten von null
Eine Plattform, die jede Wochenend-Idee hostet, funktioniert nur, wenn eine untätige Idee nichts kostet. Eingefrorene Container und Postgres-Compute, das auf null skaliert und mitten in der Verbindung aufwacht machen „lass es einfach laufen, man weiß ja nie“ zum Standard statt zur monatlichen Rechnung. Der umgekehrte Fall — eine App, deren Nutzer keinen Kaltstart dulden — ist eine bewusste, bepreiste Entscheidung (Keep-Warm) und kein Zufall der Architektur.
Das Überleben des eigenen Baus
Die meistunterschätzte Produktionsanforderung: Die Fabrik selbst stürzt ab. Builds sind lang; Pods werden evakuiert; Prozesse werden mitten im Schreiben per OOM gekillt. Ein Reconciliation-Lauf behandelt „der Build ist gestorben“ als ganz normalen Input — jeder unterbrochene Run wird erkannt, und jedes Stück Zustand, das er hielt, wird in ein konsistentes, fortsetzbares Bild zurückgeführt. Eine Plattform, die ihre eigene halbfertige Arbeit nicht wieder einfangen kann, würde früher oder später das Projekt eines Kunden in einem Zustand stranden lassen, den kein Button mehr reparieren kann.
Warum das ein Plattform-Problem ist, kein Modell-Problem
Jeder Punkt oben hat dieselbe Form: Er muss für jedes Projekt, bei jeder Iteration, unabhängig davon, was das Modell ausgibt, gelten. Das ist die Definition einer Invariante, und Invarianten leben nicht in Prompts. Sie leben in Namespaces, Branch-Topologien, Append-only-Ledgern, Verifikations-Gates und Reconciliation-Loops — den Kästen aus dem Anatomie-Beitrag.
Bessere Modelle kommen ständig, und wir tauschen sie an dem Tag ein, an dem sie erscheinen — die Engine behandelt Modelle als Konfiguration. Was sich mit dem Modell nicht ändert, ist die Frage, die die Plattform beantwortet: Was muss wahr bleiben, egal was der Agent tut? Die Preview ist das, was der Agent gemacht hat. Das Produkt ist alles, was drumherum wahr bleibt.
Der Rest dieses Blogs geht diese Invarianten ein System nach dem anderen durch — die für Agenten gebaute Datenbank, der Deploy, der kein Byte bewegt, der Undo-Button für Daten, das Namespace-Modell. Und die Galerie zeigt das Ergebnis: eine echte App pro Tag, mit dem Prompt, aus dem sie entstand, und dem, was ihr Bau gekostet hat.