Engineering-Blog

Wie die Plattform wirklich funktioniert.

Deep-Tech-Artikel für Entwickler:innen — die Bytes auf der Leitung, die LSNs und die Funktionen, die die Arbeit machen. Kein Marketing-Geschwafel.

Start here

Most AI app builders stop at the preview. What production actually demands — and the architecture that answers it.

Part 1ArchitectureAI-agentsKubernetes

Anatomie einer KI-App-Plattform, die es bis in die Produktion schafft

Aus einem Prompt ein laufendes Produkt zu machen, ist kein Modellproblem — es ist ein Systemproblem. Das hier ist die Landkarte der ganzen Maschine: wie aus einer Chat-Nachricht ein isolierter Kubernetes-Workload mit eigenem Postgres-Branch wird, der auf null skaliert; warum die Arbeit des Agenten von Compilern und Live-Probes bewertet wird statt von seiner eigenen Meinung; und wie ein Release zur Promotion eines Datenbank-Branches mit Rollback-Anker wird. Jeder andere Beitrag in diesem Blog nimmt eine Box dieses Diagramms ins Detail.

14. Juni 2026 7 min read

Part 2ProductArchitectureAI-agents

Die Preview ist nicht das Produkt

Jeder KI-App-Builder zeigt dir Minuten nach einem Prompt eine laufende Preview — die Generierung ist der Teil, der einfach geworden ist. Das Produkt ist alles, was halten muss, nachdem sich ein Fremder eingeloggt hat: Deploys, die seine Daten nicht anrühren, ein Rollback, der etwas bedeutet, Secrets, die niemand eingefügt hat, Leerlaufkosten von null und eine Recovery-Story für jeden Weg, auf dem ein Build sterben kann. Eine Tour durch die Lücke und die Design-Haltung, die sie schließt: Der Agent darf sich irren; die Plattform nicht.

14. Juni 2026 4 min read

Part 3ProductAI-agentsArchitecture

Das Leben einer Wochenend-App

Ein Freitagabend, ein beiläufiger Absatz über eine Ausgabentabelle für einen Skitrip — und eine Plattform, die all das tut, was die Demo nie zeigt. Das ist die wahre Geschichte einer einzelnen App: echte Prompts, echte Zeitstempel, echtes Geld — von der ersten Nachricht bis zur verifizierten, eingefrorenen, kostenlosen Anwendung. Jeder Halt auf der Timeline ist eine Tür in die Mechanik, die das Ganze so unspektakulär gemacht hat.

14. Juni 2026 8 min read

Part 4ProductArchitectureDeployment

Adorable vs. Lovable, v0, Bolt und Replit: wo dein Backend wirklich läuft

Jeder AI-App-Builder generiert inzwischen eine funktionierende Full-Stack-App. Die Kategorie hat sich auf die einfachen 80% geeinigt. Was diese Tools weiterhin unterscheidet, sind drei Fragen, die auf keiner Landingpage stehen: wo dein Backend-Code tatsächlich läuft, was ein Deploy mit deinen Daten anstellt und wie viele bewegliche Teile — Services und Apps — ein Projekt fassen kann. Misst man Lovable, v0, Bolt, Replit und uns an diesen Achsen, spaltet sich das Feld auf eine Weise, die die Feature-Tabellen verbergen.

15. Juni 2026 10 min read

The database

Copy-on-write Postgres branches, scale-to-zero compute, deploys as branch promotions, and time-travel for the data an agent can break.

Part 1ArchitecturePostgresNeon

Warum Postgres mit getrenntem Storage und Compute die richtige Datenbank für KI-Agenten ist

Wer Datenbanken erstellt, ist längst kein Mensch mehr, der ein Provisioning-Formular ausfüllt — es ist ein Agent, der Hunderte kurzlebiger, größtenteils im Leerlauf laufender Datenbanken hochfährt. Diese Last bricht die Annahmen, auf denen ein klassisches „ein Postgres pro App" aufbaut. Hier ist, warum die Trennung von Storage und Compute mit Copy-on-Write-Branching und Scale-to-Zero die Architektur ist, die wirklich passt — Primitiv für Primitiv auf das abgebildet, was Agenten tun.

14. Juni 2026 9 min read

Part 2ArchitecturePostgresRust

Scale-to-Zero-Postgres: ein Rust-Proxy, der deine Datenbank mitten im Connect aufweckt

Jede App auf der Plattform bekommt ihr eigenes Postgres, das im Leerlauf nichts kostet — das Compute skaliert auf null. Der Trick liegt darin, es beim nächsten Connect transparent aufzuwecken: ein Rust-Proxy spricht das Postgres-Wire-Protokoll, parkt den Client, skaliert ein K8s-Deployment 0→1 und leitet die Query weiter, sobald die Datenbank läuft. Hier kommen das Wire-Parsing, das Single-Flight-Wakeup und die tokio-Notify-Registrierungsdisziplin, die das Wakeup unter Nebenläufigkeit korrekt hält.

14. Juni 2026 8 min read

Part 3ArchitecturePostgresNeon

Time-Travel für Code UND Daten: die Datenbank-Fehler eines KI-Agenten rückgängig machen

Ein KI-Agent führt mit voller Überzeugung eine Migration aus, die die falsche Spalte droppt. Git gibt dir ein Undo für Code; für Daten gibt es keins. So funktioniert Time-Travel für Code und Daten auf Copy-on-Write-Postgres-Timelines — der Checkpoint am LSN, das Copy-on-Write-Restore und die Cache-Kohärenz, die das Repointen des Compute korrekt hält.

14. Juni 2026 8 min read

Part 4ProductPostgresNeon

Wir geben dem Agenten einen Undo-Button für deine Daten

Ein KI-Agent, der deine App baut, fährt nebenbei auch Migrationen, Massen-Edits und Seeds — destruktive Operationen, die git nicht rückgängig machen kann, weil git nur Code versioniert. Also haben wir dem Agenten ein Daten-Undo gegeben, das er selbst bedient: Er macht vor einer riskanten Operation einen Snapshot und rollt zurück, falls die Operation die Daten kaputt macht. Wir zeigen, wie das auf Copy-on-Write-Postgres funktioniert, warum der Restore denselben Connection-String behält und warum eine ganze Flotte solcher Apps im Leerlauf nichts kostet.

14. Juni 2026 6 min read

Part 5ArchitecturePostgresNeon

Deploy ist eine Branch-Promotion, keine Migration

Ein Release in die Produktion bedeutet normalerweise, Daten zu verschieben: dev dumpen, in eine separate Prod-Datenbank zurückspielen, die Migrationen laufen lassen und hoffen, dass nichts auseinandergedriftet ist. Auf Copy-on-Write-Timelines in Postgres hat das eine ganz andere Form — Produktion ist ein Branch, und Live-Gehen ist eine Promotion. Es bewegen sich keine Bytes, wenn Prod vom Head von dev geforkt wird; Re-Deploys schieben Prod vor und wenden nur die ausstehenden Migrationen an; ein Rollback ist ein Branch auf einen Zeitpunkt; und jede Umgebung skaliert unabhängig auf null. Hier ist das Modell — und die Mechanik darunter.

14. Juni 2026 6 min read

Part 6ArchitectureGitKubernetes

Was ein Rollback löschen darf

Ein Time-Travel-Rollback muss ein Projekt in einen kohärenten Zustand über drei sehr unterschiedliche Stores bringen: den git-Quellcode, die laufende Kubernetes-Runtime und einen geteilten Postgres-Branch. Die interessante Frage ist nicht „wie stellen wir wieder her?" — sondern „was dürfen wir physisch löschen, und wie bleiben wir dabei umkehrbar?" Die Antwort ist eine einzige Invariante: lösche nur, was entweder aus der git-History wiederherstellbar oder aus der Spec regenerierbar ist, und archiviere den einen relationalen Anker, der alles zusammenhält, weich statt hart.

14. Juni 2026 9 min read

The model

Which LLM drives the agent, how it's routed per task, and why a real bug is a truer benchmark than a leaderboard.

Part 1AI-agentsBenchmarkingModel-routing

Ein echter Bug ist ein ehrlicherer Benchmark als jedes Leaderboard

Jedes Modell kommt mit Leaderboard-Zahlen. Die messen deduktive One-Shot-Rätsel — und sagen dir fast nichts darüber, wie sich ein Modell verhält, wenn es an einem echten Problem in einem laufenden System feststeckt. Wir bekamen ein ungeplantes Kopf-an-Kopf-Rennen: derselbe Prompt, dieselbe kaputte Datei, dieselbe laufende App, zwei Modelle. Das eine verbrannte sein gesamtes Budget über 51 Schritte, leitete Kreuzprodukte von Hand immer wieder neu her und reparierte den Bug nie; das andere reparierte ihn in 19. Der Unterschied lag nicht in roher Intelligenz. Er lag in der *Strategie beim Feststecken* — und der Bug war, rein zufällig, so konstruiert, dass er genau das misst.

12. Juni 2026 15 min read

The runtime

A Kubernetes namespace per app: isolation, lifecycle, secrets, custom domains — the day-2 operations nobody demos.

Part 1ArchitectureMulti-appKubernetes

Die Schwerkraft der primären App

Ein Projekt auf dieser Plattform ist nicht eine App und ein Stack, sondern N isolierte Apps und M Services, die sich einen einzigen Kubernetes-Namespace teilen — alles provisioniert aus einer Chat-Nachricht. Sobald du das zulässt, reimt sich fast jeder Bug: Eine „neue Geschwister-App" kollabiert unbemerkt zurück in die primäre. Das ist die Geschichte, warum das immer wieder passiert, des einen Prinzips, das die ganze Bug-Klasse behebt — am einzigen Kontrollpunkt zum deklarierten Zustand konvergieren und mit Fehler abbrechen, statt auf die primäre App zurückzufallen — und wie dasselbe Prinzip, rückwärts ausgeführt, uns den gesamten Stack durch die Zeit reisen lässt (Code in git, Daten in einem geteilten Neon-Branch und die laufende K8s-Infrastruktur) zurück zu einem kohärenten Moment.

14. Juni 2026 13 min read

Part 2ArchitectureKubernetesLinux

Tausend untätige Apps pausieren: KEDA, CRIU und der cgroup-v2-Freezer

Jede App auf der Plattform soll nichts kosten, solange niemand hinschaut – und sofort zurück sein, sobald jemand wieder vorbeischaut. Wir haben uns für Container statt microVMs entschieden und dann drei Wege ausprobiert, Leerlauf kostenlos zu machen: Scale-to-Zero mit KEDA, Checkpoint/Restore mit CRIU und schließlich den cgroup-v2-Freezer mit Swap-Reclaim. Die ersten beiden haben uns auf sehr unterschiedliche Weise gezeigt, worin die eigentliche Beschränkung lag. Das ist die Chronik der Experimente, der Fehlermodi, auf die wir gestoßen sind, und des Designs, das überlebt hat.

14. Juni 2026 15 min read