Wie Forge entstand: der deterministische KI-Compiler für Websites

Jeder KI-Website-Baukasten funktioniert gleich: Du tippst einen Prompt, ein LLM schreibt HTML, und du bekommst, was es dir gibt. Manchmal ist es gut. Manchmal nicht. Du klickst noch einmal auf „Erzeugen“ und bekommst etwas völlig anderes – anderes Layout, andere Farben, andere Qualität. Das Ergebnis ist im Kern unvorhersehbar.

Wir haben dieses Modell ausgeliefert. Es funktionierte. Menschen haben damit echte Websites gebaut. Aber als wir zusahen, wie Tausende Seiten erzeugt wurden, zeigte sich ein Muster: Das LLM verbrauchte die meisten seiner Tokens dafür, Dinge neu zu erfinden, über die es gar nicht hätte entscheiden sollen. Navigationssysteme. Farbkontrast. Mobile Breakpoints. Anker-Links. Schriftenladen. Markup für Kontakt- formulare.

Jede Erzeugung war ein neuer Würfelwurf bei Problemen, die richtige Antworten haben.

Forge ist unsere Antwort auf diese Beobachtung. Es ist keine schrittweise Verbesserung – es ist eine grundlegend andere Architektur dafür, wie KI Websites baut.

Das Problem, wenn KI rohes HTML schreibt

Wenn du ein LLM bittest, „eine Website für einen Barbershop zu erstellen“, muss es gleichzeitig Tausende Entscheidungen treffen: Welche Bereiche sollen rein. In welcher Reihenfolge. Wie die Navigation aussieht. Welche Farben. Wie mobile Layouts funktionieren. Wie Schriften geladen werden. Wie Anker-Links verdrahtet werden. Wie das HTML semantisch aufgebaut wird. Wie mit Kontrastverhältnissen umzugehen ist. Wie Öffnungs- zeiten formatiert werden. Wie eine Telefonnummer als klickbarer Link dargestellt wird.

Manche dieser Entscheidungen sind kreativ: welche Bereiche rein sollen, welche Farbpalette zu einem Barbershop passt, wie das Gesamtgefühl sein soll.

Die meisten sind Technik: Die Navigation muss zu echten Ankern scrollen, das Kontrastverhältnis muss mindestens 4,5:1 betragen, die Telefonnummer muss im E.164-Format stehen, die Schrift muss von Google Fonts mit Preconnect geladen werden, das mobile Layout muss unter 480 px vertikal gestapelt sein.

Überlässt du dem LLM beides, sind die kreativen Entscheidungen gut, die technischen aber uneinheitlich. Manche Erzeugungen haben perfekten Kontrast. Andere nicht. Manche haben funktionierende Anker-Links. Andere haben tote Hrefs, die auf Bereiche zeigen, die es nicht gibt. Manche laden Schriften korrekt. Andere binden ein Font-Face ein, das nie aufgelöst wird.

Die Erkenntnis hinter Forge: Kreative Entscheidungen von technischen Entscheidungen trennen. Die KI übernimmt die Kreativität. Ein Compiler übernimmt die Korrektheit.

Die zweistufige Architektur

Forge teilt die Website-Erzeugung in zwei getrennte Phasen:

Phase 1: Die KI entscheidet, was gebaut wird (SiteSpec)

Statt rohes HTML zu schreiben, erstellt die KI eine strukturierte Spezifikation – ein JSON-Dokument, das wir SiteSpec nennen. Die SiteSpec beschreibt, welche Bereiche die Seite haben soll, welche Inhalte in jeden Bereich gehören, wie die Farbpalette und die Typografie sein sollen, wie die Navigation aussieht und wie die gesamte Gestaltung behandelt wird.

Die KI trifft alle kreativen Entscheidungen: Soll es eine dunkle, luxuriöse Ästhetik sein oder eine helle, redaktionelle Anmutung? Soll der Hero eine kondensierte Überschriftenschrift wie Bebas Neue nutzen oder eine elegante Serifenschrift wie Cormorant Garamond? Sollen die Bereiche eine Galerie, ein Kennzahlenband, FAQ oder ein Team-Raster enthalten?

Aber die KI entscheidet NICHT, wie irgendetwas davon gerendert wird. Sie schreibt keine einzige Zeile HTML oder CSS. Sie beschreibt die Absicht.

Phase 2: Der Compiler rendert es perfekt (jedes Mal)

Die SiteSpec geht in einen deterministischen Compiler – eine reine Funktion, die eine Spezifikation und ein Playbook entgegennimmt und in sich geschlossenes, produktionsreifes HTML ausgibt. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe.

Der Compiler verantwortet jede technische Entscheidung:

• Navigationsanker – jeder Nav-Link zeigt auf einen echten Bereich. Tote Anker sind unmöglich; der Compiler gleicht jedes #href mit den tatsächlichen Bereichs-IDs ab.
• Kontrastsicherheit – der Kontrast von Text auf Hintergrund wird geprüft und auf WCAG AA (4,5:1) durchgesetzt. Die KI wählt die Palette; der Compiler stellt die Lesbarkeit sicher.
• Wechsel der Flächen – keine zwei benachbarten Bereiche haben denselben Hintergrundton. Der Compiler wechselt automatisch zwischen Basis- und Sekundärflächen, um einen visuellen Rhythmus zu schaffen.
• Normalisierung der Kontaktdaten – Telefonnummern werden für tel:-Links in E.164 formatiert, WhatsApp- Kanäle automatisch erkannt, Öffnungszeiten und Adressen aufgeräumt. Jede Kontaktangabe funktioniert als echter, klickbarer Link.
• Schriftenladen – Google Fonts werden mit Preconnect und display-swap geladen. Keine kaputten Font-Faces, keine Layout- Verschiebung.
• Responsives Layout – jeder Block wird auf Mobil-, Tablet- und Desktop-Breakpoints korrekt gerendert. Die KI wählt keine Breakpoints; der Compiler erzwingt sie.
• Footer- und Nav-Synthese – lässt die KI einen Footer oder eine Navigation weg (was Tokens spart), leitet der Compiler sie aus den vorhandenen Bereichen ab. Nichts fehlt je im fertigen Ergebnis.

Warum das wichtig ist: Tempo und Determinismus

Tempo

Weil die KI strukturierte Daten statt rohes HTML erzeugt, ist die Ausgabe dramatisch kleiner. Eine komplette HTML-Seite erfordert 15.000–25.000 Tokens LLM-Ausgabe. Eine SiteSpec für dieselbe Seite braucht 4.000–6.000 Tokens – eine 3- bis 4-fache Reduktion. Das bedeutet direkt schnellere Erzeugung (unter 90 Sekunden für eine komplette Seite) und geringere Kosten.

Determinismus

Der Compiler ist eine reine Funktion. Bei derselben SiteSpec erzeugt er immer dasselbe HTML. Das bedeutet:

• Bearbeiten ist sicher. Änderst du im visuellen Editor eine Bereichsüberschrift, ändert sich nur dieser Bereich. Der Compiler rendert die Spezifikation neu, und der Rest der Seite bleibt identisch. Keine Kettennebenwirkungen.
• Qualität ist garantiert. Kontrast, Anker, Kontaktformatierung, Schriftenladen – alles ist bei jeder einzelnen Erzeugung korrekt, nicht nur manchmal.
• Testen ist möglich. Eine deterministische Engine lässt sich systematisch prüfen. Wir führen automatisierte Prüfungen zu Farb- kontrast, Anker-Integrität, Block-Vielfalt und Gestaltungsvarianz über Erzeugungen hinweg durch.

Begrenzte Kreativität

Hier die kontraintuitive Erkenntnis: Einschränkungen machen die KI kreativer, nicht weniger. Wenn das LLM davon befreit ist, Boilerplate-HTML und -CSS zu schreiben, verwendet es sein gesamtes Token- Budget für die Entscheidungen, die wirklich zählen – Bereichsauswahl, Inhaltsstrategie, Gestaltungsbehandlung, Farbtheorie. Das kreative Ergebnis ist gerade deshalb besser, weil das technische Ergebnis abgedeckt ist.

Das Playbook-System

Der Compiler hat nicht fest einprogrammiert, wie irgendein Block gerendert wird. Stattdessen nimmt er ein Playbook entgegen – ein Modul, das die Blockbibliothek definiert (wie jeder Bereichstyp zu HTML/CSS gerendert wird), das Gestaltungs-Auflösungssystem (wie Paletten und Typografie aufgelöst werden) und das Basis-Stylesheet.

Tausche das Playbook aus, und dieselbe SiteSpec wird in einer völlig anderen visuellen Sprache gerendert. Die Engine bleibt dieselbe. Die Blöcke ändern sich. Das macht Forge erweiterbar: neue Bereichstypen, neue Gestaltungsbehandlungen, neue Rendering-Strategien – alles, ohne den Compiler-Kern anzufassen.

Heute umfasst das Playbook des Seitengenerators über 26 verschiedene Block- typen – von Hero-Bereichen und Leistungslisten bis zu Kennzahlenbändern, Galerien, FAQ, Team-Rastern, Marquees, Buchungs-CTAs und mehr. Die KI wählt aus dieser Bibliothek je nach Branche und Inhalt, und der Compiler rendert sie pixelgenau.

Wie Forge entstand

Forge begann nicht mit einem großen Plan. Es begann mit einem Prototyp – einer einzigen Datei compile.mjs, die eine handgeschriebene JSON-Spezifikation nahm und zu HTML renderte. Die Frage war einfach: Wenn wir die Blöcke selbst definierten und die KI nur die Inhalte füllte, wäre das Ergebnis besser als rohes LLM-HTML?

Es war so. Dramatisch besser. Der Prototyp renderte eine Barbershop- Seite mit perfektem Kontrast, funktionierender Navigation, korrektem Schriften- laden und einer stimmigen Dunkel-/Gold-Ästhetik – alles aus einer JSON- Spezifikation, die nur ein Bruchteil der Größe des entsprechenden HTML hatte.

Von dort aus nahm die Architektur Gestalt an:

1. Der Prototyp wurde zu einer typisierten, frameworkfreien Engine – importierbar in jeder JavaScript-Laufzeit ohne Abhängigkeiten von React, Next.js oder SiteDrop-Interna.
2. Die fest einprogrammierten Block-Renderer wurden zu einem steckbaren Playbook-System – jedes Playbook definiert eigene Blöcke, Design-Tokens und CSS.
3. Die LLM-Anbindung wechselte von rohem HTML zu strukturierter Tool-Nutzung (das SiteSpec-Schema IST das Tool-Schema – es bringt dem Modell bei, was es erzeugen soll, und begrenzt zugleich die Form der Ausgabe).
4. Ein selbstdokumentierendes Schema ersetzte den klassischen System-Prompt – die Schema-Beschreibungen bringen der KI bei, was jedes Feld bedeutet, sodass die „Grammatik“ nur wenige Zeilen umfasst.
5. Qualitäts-Gates – Kontrastprüfung, Ankerabgleich, Flächenwechsel, Kontaktnormalisierung – wurden in den Compiler eingebaut, damit sie bei jeder Erzeugung laufen, nicht als optionale Nachbearbeitung.

Das Ergebnis ist eine Engine, die anbieterunabhängig ist (sie funktioniert mit Claude, GPT, Gemini, DeepSeek, xAI – jedem Modell, das strukturierte Ausgabe unterstützt), frameworkfrei (als eigenständiges Paket herauslösbar) und deterministisch (gleiche Spezifikation → gleiches HTML, immer).

Was das für dich bedeutet

Wenn du SiteDrop nutzt, läuft Forge bereits, wenn du eine Seite erzeugst. Du musst nichts anders machen – die Verbesserung liegt in Qualität, Tempo und Konsistenz des Ergebnisses:

• Schnellere Erzeugung – Seiten entstehen in unter 90 Sekunden, weil die KI-Ausgabe 3- bis 4-mal kleiner ist.
• Konsistente Qualität – jede Erzeugung hat korrekten Kontrast, funktionierende Navigation, korrektes Schriftenladen und formatierte Kontaktdaten.
• Mehr Gestaltungsvielfalt – die KI wählt aus über 26 Blocktypen, über 4 Design-Archetypen und einer breiten Palette an Schriftkombinationen. Ein Barbershop bekommt eine dunkle, kondensierte Ästhetik; eine Zahnarztpraxis eine klare, redaktionelle Anmutung; ein Gourmetrestaurant eine luxuriöse Serifen-Gestaltung.
• Sichereres Bearbeiten – der visuelle Editor ändert die SiteSpec und rendert sie über den Compiler neu, sodass Änderungen vorhersehbar und nebenwirkungsfrei sind.

Wie es mit Forge weitergeht

Die Compiler-Architektur ist das Fundament für alles, was wir bauen. Weil die Engine spezifikationsgesteuert ist, ist jede neue Fähigkeit ein neuer Blocktyp, ein neues Playbook oder ein neues Design-Token – nicht ein Umbau der Erzeugungs-Pipeline. Das ist die Stärke der Trennung: Die KI wird besser im Entscheiden, der Compiler besser im Rendern, und beide verbessern sich unabhängig voneinander.

Wir glauben, dass dieses zweistufige Muster – KI für die Absicht, Compiler für die Ausführung – künftig der Weg sein wird, wie Webanwendungen gebaut werden. Nicht nur One-Page-Websites, sondern mehrseitige Anwendungen, Dashboards und interaktive Erlebnisse. Die KI beschreibt, was existieren soll. Der Compiler garantiert, dass es funktioniert.