EmDash Build im Test: Schreinerei-Website aus einem Absatz

Zusammen mit EmDash 1.0 hat das Projekt am 28. September auch EmDash Build vorgestellt, einen KI-Website-Builder. Du beschreibst, was du brauchst, und er baut daraus eine EmDash-Website mit Schema, Inhalten, Astro-Seiten und Adminbereich.

Mich hat vor allem interessiert, ob am Ende eine Website steht, die eine Redaktion selbst pflegen kann, oder eine hübsche Fassade, an die ohne Entwickler keiner mehr rankommt. Für den Test bekam EmDash Build deshalb ein typisches Mittelstands-Briefing, eine Schreinerei in Oberbayern. Begleitet wurde der Bau von der ersten Rückfrage bis zum exportierten Code, und zwar zweimal, mit demselben Briefing. Das hat sich gelohnt, denn herausgekommen sind zwei ziemlich verschiedene Websites.

Vorweg, damit du das einordnen kannst: Ich arbeite als Maintainer an EmDash mit, an EmDash Build selbst aber nicht. Das hier ist meine eigene Einschätzung, keine Aussage des Projekts. Die beiden Testläufe fanden am 6. und am 7. Oktober 2026 statt, jeweils in einer frischen Gast-Session. Die Screenshots stammen alle aus dem zweiten Lauf.

Was EmDash Build sein will

Laut README ist EmDash Build kein fertiges Produkt zum Buchen, sondern eine Alpha-Referenzanwendung für Hoster, Website-Builder und Plattformen, die ein Anbieter selbst betreibt und an seinen eigenen Login, seine Kontingente und seine Abrechnung anschließt. Den Code gibt es unter MIT-Lizenz auf GitHub.

Dafür braucht er mehrere Cloudflare-Produkte: Workers, Durable Objects, Containers bzw. Sandbox, Workers AI, AI Gateway, Artifacts und Workers for Platforms, dazu eine Zone mit Wildcard-Hostnamen für Vorschauen und Sites. Für die Vorabversion empfiehlt die Self-Hosting-Anleitung ein eigenes, isoliertes Cloudflare-Konto oder zumindest klar abgegrenzte Ressourcen.

Selbst betrieben veröffentlicht EmDash Build derzeit einen schreibgeschützten, statischen Snapshot über Workers for Platforms. Der Cloudflare-Blog beschreibt schon das Ziel, nämlich dass die Inhalte beim Veröffentlichen in eine EmDash-Site in Produktion umziehen. So weit ist es aber noch nicht. Laut EmDash-Blog ist diese Übertragung noch in Arbeit, und das Threat Model im Repository führt sie ausdrücklich als nicht verfügbar, bis der EmDash-Kern die nötigen Schnittstellen mitbringt.

Die öffentliche Demo unter build.emdashcms.com zeigt den Ablauf, veröffentlicht aber nichts. In der Konfiguration steht ENABLE_PUBLIC_PUBLISHING: "false". Der EmDash-Blog bittet außerdem, keine sensiblen Daten einzugeben, weil Quelltext und Inhalte zur Wiederherstellung gespeichert werden. Für meine Frage reicht die Demo trotzdem, denn bauen und im Adminbereich pflegen kann man dort.

Ein Absatz Briefing, ein paar Rückfragen

Das Briefing ging unverändert in das Eingabefeld der Demo:

Website für eine Schreinerei in Oberbayern, 12 Mitarbeiter, Möbel nach Maß und Innenausbau für Privatkunden und Hotels. Seiten: Leistungen, Referenzen mit Fotos, Team, Karriere, Kontakt. Ton: bodenständig, hochwertig.

Eine Anmeldung braucht es nicht. Gastprojekte hängen an einem Cookie, laut Code sind bis zu zehn pro Gast möglich.

Bevor EmDash Build loslegt, stellt es Rückfragen, und zwar auf Deutsch, wie das Briefing. Wie viele und welche, ist allerdings Glückssache. Im ersten Lauf kamen nach rund 20 Sekunden drei: der genaue Firmenname (freie Eingabe), was die Website hauptsächlich auslösen soll (vier Optionen von „Anfrage für ein individuelles Projekt“ bis „Bewerbung“) und in welche visuelle Richtung es gehen soll (drei Optionen, gewählt wurde „warm und materialbetont“). Im zweiten Lauf waren es nur zwei. Nach dem Namen kam wieder die Frage nach dem Ziel der Website, diesmal mit drei Optionen und ohne Bewerbung, und eine Frage zur Gestaltung gab es gar nicht. Die Richtung hat der Agent dann selbst festgelegt, und zwar ziemlich treffend: „warm und materialnah“.

In beiden Fällen fragte EmDash Build genau nach dem, was im Briefing fehlte, überflüssig war keine Frage. Als Name ging jedes Mal „Schreinerei Testholz“ ins Feld, als Ziel die individuelle Projektanfrage. Währenddessen fuhr im Hintergrund schon die Vorschau des leeren Projekts hoch.

Neun Minuten mit ein paar Umwegen

Am Ende meldete die Oberfläche „Built in 9m 23s“ beim ersten und „Built in 8m 52s“ beim zweiten Lauf, gezählt ab dem Abschicken der Antworten. Im Aktivitätsprotokoll kannst du jeden Schritt mitlesen: Content-Modell, Einstellungen und Menüs, Bildsuche bei Unsplash, Dateien schreiben, Inhalte anlegen, prüfen.

Ganz rund lief das nie, aber jedes Mal holperte es woanders. Im ersten Lauf schlug das Anlegen von Seiten mehrmals fehl, die Vorschau brach einmal ab, und ein Hinweis meldete „Session changes could not be saved“. Fast schon amüsant: Der Agent suchte lange per grep durch node_modules, um herauszufinden, wie Menüs funktionieren. Im zweiten Lauf blieb die Vorschau stabil, dafür scheiterte „Failed to create content pages“ gleich sechsmal hintereinander. Laut den technischen Details lehnte ein Link-Feld in einem Block relative Pfade wie /leistungen als ungültige URL ab. Dazu kamen ein paar fehlgeschlagene Updates an Blocktypen und rund zehn HTTP-500-Fehler in der Konsole. Der Agent hat sich in beiden Läufen jedes Mal selbst gefangen.

Was dabei im Hintergrund passiert, steht im Code. Jedes Projekt bekommt einen eigenen Container in Cloudflare Sandbox. Darin liegt ein vorbereitetes, bewusst leeres Projekt aus Astro, Tailwind und EmDash, eine Vorlage mit fertigem Design gibt es nicht. Das Gespräch und die Schleife aus Modell und Werkzeugen steuert ein Durable Object namens BuilderAgent, gebaut mit dem Agents SDK.

Schema und Inhalte legt das Modell über den MCP-Server von EmDash an, die Astro-Seiten schreibt es als Dateien in den Container. Die MCP-Werkzeuge sind auf eine feste Liste begrenzt, etwa content_create, menu_set_items oder settings_update. Bevor der Agent sich fertig meldet, prüft er seine Arbeit mit validate_site (Typecheck, alle öffentlichen Routen, kein React im öffentlichen Frontend) und schaut sich mit view_preview die Vorschau selbst an. Jeder stabile Stand landet als Git-Commit in Cloudflare Artifacts, und wenn der Container einschläft, wird das Projekt von dort wiederhergestellt.

Gebaut wird laut Code openai/gpt-5.6-luna mit hohem Reasoning-Aufwand, angesprochen über Cloudflare AI Gateway. Kleinere Aufgaben erledigt Workers AI, mit Llama 3.3 70B für Vorschläge zu nächsten Schritten und Whisper für die Spracheingabe. Ob auf der Demo genau dieser Code-Stand läuft, sieht man von außen allerdings nicht.

Nach rund neun Minuten stand also jedes Mal eine Website in der Vorschau. Zeit für einen genaueren Blick.

Was in der Vorschau stand

Das Content-Modell passt in beiden Läufen wirklich zum Betrieb, auch wenn es jedes Mal anders geschnitten war. Im ersten Lauf gab es fünf Collections (Seiten, Leistungen, Referenzen, Team und Karriere) und fünf eigene Blocktypen, darunter einen Seiteneinstieg, einen Kontaktbereich und eine Projektgalerie. Im zweiten waren es vier Collections, denn die Leistungen wurden zu einer einzelnen Seite aus Bild-Text-Blöcken, und vier Blocktypen, etwa einen Ablauf in drei Schritten und wieder eine Projektgalerie. Eine Referenz hat jeweils Projektname, Kurzbeschreibung, Titelbild, Bereich, Ort, eine Projektbeschreibung als Rich Text und eine Bildergalerie mit Bildunterschriften, im ersten Lauf zusätzlich das Jahr. Alle Feldnamen im Adminbereich sind deutsch. Das kommt näher an das heran, was ich selbst modellieren würde, als ich erwartet hatte.

Ganz sauber ist es nicht. Im ersten Lauf bot das Feld „Bereich“ Privat, Hotel und Innenausbau an, also zwei Kundengruppen und eine Leistung in einem Feld. Im zweiten Lauf waren es „Möbel nach Maß“, „Innenausbau“ und „Hotelausbau“, das ist deutlich näher dran. Die Beschäftigungsart einer Stelle war einmal eine Auswahl aus Vollzeit, Teilzeit, Ausbildung und Praktikum, beim zweiten Mal ein freies Textfeld. Und die Collection „Team“ ist für Personen gedacht, mit Name, Rolle und Porträt, der Agent hat sie aber beide Male mit Abteilungen gefüllt, mal drei, mal vier. Das geht auf eine gute Regel zurück: Der Systemprompt verbietet, Namen, Kontaktdaten oder Referenzen zu erfinden, also gibt es auch keine ausgedachten Mitarbeiter. Die drei Referenzprojekte hat der Agent sich allerdings beide Male doch ausgedacht und mit Unsplash-Fotos bebildert.

Die Seiten sehen nach Handwerk aus und nicht nach SaaS-Landingpage, mit Serifenschrift und großen Bildflächen. Die Farben waren allerdings verschieden, im ersten Lauf warme Erdtöne, im zweiten ein dunkles Tannengrün mit Terrakotta-Akzenten. Der erste Lauf baute 14 Routen, der zweite 10, und alle funktionierten. Das Deutsch ist beide Male gut: idiomatisch, in der Sie-Form und mit korrekten Umlauten und ß. Einen Satz wie „Maßarbeit, die nicht laut sein muss.“ aus dem ersten Lauf würde ich so stehen lassen, ebenso „Gut gemacht. Für lange.“ aus dem zweiten. Im ersten Lauf stand auf der Kontaktseite allerdings derselbe Einleitungstext zweimal nebeneinander, im zweiten nicht mehr.

Beim Kontaktformular hört der Komfort dann auf, denn es verschickt in keinem der beiden Läufe etwas. Der Agent hat das jeweils offen gesagt, weil im Briefing keine Empfängeradresse stand. Gelöst hat er es aber unterschiedlich. Im ersten Lauf war es ein schlichtes GET-Formular mit einem Hinweis darunter, die Eingaben landeten also in der URL. Im zweiten fängt ein Skript das Abschicken ab und lädt die Angaben als projektanfrage.txt auf den Rechner der Besucherin herunter, mit dem Hinweis, sie könne die Datei nun an die Schreinerei senden. Ohne JavaScript fällt es wieder auf GET zurück. Selbst betrieben würde EmDash Build so ein Formular übrigens gar nicht veröffentlichen, denn laut Code lehnt der statische Snapshot Formulare ab, die an die eigene Domain schicken. Für eine echte Website muss hier jemand mit Entwicklerkenntnissen ran.

Entscheidend ist aber, wie es weitergeht, wenn jemand ohne Entwicklerkenntnisse übernimmt.

Kann die Redaktion übernehmen?

Zum großen Teil ja. Im Test bekam eine Referenz im Adminbereich einen neuen Titel. Die Änderung speichert EmDash automatisch als Entwurf, live geht sie erst mit „Änderungen publizieren“ und einem Klick im Bestätigungsdialog danach. Wer den Dialog übersieht und weiterklickt, wundert sich, warum die Vorschau noch den alten Titel zeigt. Nach der Bestätigung war die Änderung sofort in der Vorschau zu sehen. Leistungen, Referenzen, Stellen, Bilder und die Reihenfolge der Blöcke lassen sich ohne eine Zeile Code pflegen. Auf der Website selbst gibt es zusätzlich die Bearbeitungsleiste von EmDash.

Ein paar Lücken gibt es allerdings, und auch die waren nicht zweimal dieselben. Im ersten Lauf waren beide Menüs im CMS zwar angelegt, aber leer, die sichtbare Navigation kam aus einem Fallback im Layout. Im zweiten Lauf waren beide Menüs angelegt und gefüllt, und das Layout las sie direkt aus dem CMS. Feste Texte im Code gab es dagegen beide Male, nur an anderen Stellen: im Footer, in Überschriften auf der Startseite und auf der Kontaktseite, im ersten Lauf auch beim Firmennamen im Copyright. Wenn eine Redakteurin den Footer-Slogan ändern will, sucht sie im Adminbereich vergeblich nach einem Feld dafür.

Ein Folgeauftrag im Chat hat das jeweils in gut zwei Minuten repariert, und die Validierung lief durch. Im ersten Lauf ging es um die leeren Menüs und den Footer, im zweiten lautete der Auftrag an den Agenten, die fest codierten Texte im Adminbereich pflegbar zu machen. So ist es gedacht: Kleines erledigst du im Adminbereich, Größeres über den Agenten. Dafür muss aber erst einmal jemand die Lücken bemerken. Und das Ergebnis solltest du dir ansehen. Im zweiten Lauf hat der Agent die sechs neuen Felder, etwa „Footer-Slogan“, an die ganze Collection „Seiten“ gehängt. Jede Seite zeigt sie jetzt an, verwendet werden aber nur die Werte der Startseite. Wer den Footer ändern will, muss also wissen, dass er unter Seiten → Startseite steckt und nicht in den Einstellungen.

Dazu kamen ein paar Kleinigkeiten im Adminbereich. In beiden Läufen blieb er beim ersten Öffnen bei „Loading EmDash…“ hängen, mit einem React-Fehler in der Konsole („Invalid hook call“). Nach einem Neuladen lief er jedes Mal. Beim ersten Öffnen begrüßt er dich außerdem mit einem Willkommensdialog. Und bei allen deutschen Inhalten war „English“ als Inhaltssprache eingetragen, ebenfalls in beiden Läufen.

Die Sprache der Oberfläche richtet sich laut Code nach der Sprache, die der Browser anfragt, solange du in den Einstellungen keine andere gewählt hast. Im ersten Lauf war der Browser englisch eingestellt, und der Adminbereich war englisch. Im zweiten Lauf mit deutschem Browser kam er auf Deutsch, mit ein paar englischen Resten: „Categories“ in der Seitenleiste, „URL & language“ und „Content language“ im Editor, Zeitangaben wie „5 mins ago“ und ausgerechnet der Bestätigungsdialog beim Veröffentlichen, „Publish changes?“, dessen Knöpfe dann wieder deutsch sind.

Zweimal derselbe Auftrag, zwei verschiedene Websites

Falls du mitgezählt hast, ist es dir schon aufgefallen: Beide Läufe haben dasselbe Briefing bekommen und trotzdem nicht dieselbe Website gebaut.

Das ist kein Fehler, das liegt in der Natur der Sache. Rückfragen, Content-Modell, Seiten und Texte erzeugt ein Sprachmodell, und das antwortet nicht zweimal gleich. Für dich heißt das: Was ich hier beschreibe, sind zwei Stichproben, kein festes Ergebnis. Bei dir kann EmDash Build andere Fragen stellen, ein anderes Schema anlegen und andere Lücken lassen.

Stabil waren eher die Grundzüge. Beide Male gab es ein passendes, deutsch beschriftetes Content-Modell, gutes Deutsch, ausgedachte Referenzen, Abteilungen statt Menschen im Team, ein Formular, das nichts verschickt, Texte im Code und denselben Hänger im Adminbereich. Wo genau es hakt, wechselt dagegen von Lauf zu Lauf. Eine Checkliste, die du einmal abarbeitest und dann für jedes Projekt abhakst, gibt es deshalb nicht. Jedes Ergebnis musst du dir neu ansehen.

Für die Redaktion sieht das trotzdem ordentlich aus. Was ein Entwickler vorfindet, zeigt der Export.

Ein Blick in den Code

Über „Export“ bekommst du einen git clone-Befehl mit einem Lesetoken, der nach rund einer Stunde abläuft. Direkt aus der Oberfläche kopiert, schlug er in beiden Läufen fehl, mit Git 2.54 und der Meldung „URL rejected: Port number was not a decimal number“. Schuld ist ein unkodiertes ?expires= im Token, das die URL zerlegt. Auf dem Mac kommst du in der Standard-Shell zsh nicht einmal bis zu Git, denn zsh liest das Fragezeichen als Platzhalter und bricht mit „no matches found“ ab. Mit URL-kodiertem Token (%3F statt ?, %3D statt =) hat es geklappt. Ein Hinweis noch: Git speichert die URL samt Token in der .git/config des Klons. Der Token läuft zwar ab, ist aber trotzdem ein Geheimnis auf der Platte. Nimm ihn nach dem Klonen mit git remote remove origin wieder heraus, bevor du den Ordner weitergibst oder irgendwohin pushst.

Im Klon steckt das komplette Projekt, ein ganz normales Astro- und EmDash-Projekt, und unter .wrangler/ liegen die lokale Datenbank und die Medien. Eine Bau-Historie bekommst du nicht mit, das Repository hat genau einen Commit namens „session snapshot“. Und dieser Snapshot ist der Stand, den der Agent zuletzt gesichert hat. Im zweiten Lauf fehlte im ersten Klon die Änderung aus dem Adminbereich, obwohl das Panel „Includes your content and media“ verspricht. Erst nach dem nächsten Auftrag an den Agenten war sie im Export enthalten.

Das Panel und die mitgelieferte GETTING-STARTED.md nennen Node 22 oder neuer, die package.json verlangt allerdings Node 24. Ein Hindernis ist das nicht, mit Node 22 gibt pnpm install nur eine Warnung aus und die Site läuft trotzdem. Unter Node 24 war pnpm install nach rund elf Sekunden durch, und pnpm dev stand nach rund neun Sekunden, mit allen Seiten, Texten und Bildern aus der lokalen Datenbank. Den Adminbereich unter /_emdash/admin öffnest du lokal über den Dev-Bypass-Link, den der Server in der Konsole ausgibt. Er kam mit deutschem Browser auf Deutsch und ohne Hänger. Kleiner Stolperstein: Astro 7 lief hier mit astro dev als Hintergrundprozess, beendet wird er mit astro dev stop statt mit Strg+C.

Der Code selbst ist schlank. Für 14 Routen reichten im ersten Lauf rund 400 Zeilen Astro, im zweiten waren es rund 410 für 10 Routen. Alles wird serverseitig gerendert, und im öffentlichen Teil steckt kein React. Abfragen laufen über getEmDashEntry und getEmDashCollection mit Cache-Hinweisen, Blöcke über typisierte, versionierte Renderer. Es gibt einen Skip-Link, Labels an den Formularfeldern und eine mobile Navigation, die mit <details> ohne JavaScript auskommt. Von Hand pflegen möchte ich ihn trotzdem nicht. Viel Markup steht in sehr langen Einzelzeilen, im ersten Lauf teils eine ganze Seite in einer Zeile, und fehlende Einträge leiten auf /404 weiter, statt mit Status 404 zu antworten.

Im Code fallen noch drei Dinge auf:

• Das Projekt pinnt emdash und @emdash-cms/cloudflare auf 0.40.0, nicht auf 1.x. Die Version zeigt auch der Adminbereich unten links an. Ein noch offener Pull Request stellt neue Sites auf EmDash 1.1 um, bestehende Projekte bleiben laut seiner Beschreibung auf 0.40.
• In astro.config.mjs steht der Schlüssel vite zweimal. Der zweite überschreibt den ersten, den EmDash Build für die Vorschau eingefügt hat. Dazu passen die fehlgeschlagenen HMR-WebSocket-Verbindungen in der Konsole, im zweiten Lauf 59 Stück in einer Sitzung. Lokal mit pnpm dev merkst du davon nichts, die verlorenen Einstellungen braucht nur die Vorschau in der Sandbox.
• wrangler.jsonc hat weder einen Cron Trigger noch IDs. Ohne IDs legt der erste Deploy die D1-Datenbank selbst an, ohne Standortangabe, und den Standort kannst du danach nicht mehr ändern. Wer den Export selbst deployen will, legt Datenbank und Bucket deshalb besser vorher mit Standort an und trägt die IDs ein. Wie das geht und was ein falscher Standort an Ladezeit kostet, steht in unserem Artikel zur D1-Region. Den Weg vom Projekt zur laufenden Site auf Cloudflare zeigt Kevins Einstiegsartikel.

Fazit

Zurück zu meiner Frage vom Anfang. EmDash Build baut aus einem Absatz Briefing tatsächlich eine Website, die eine Redaktion zum großen Teil selbst pflegen kann. Beim Content-Modell und bei der Sprache trifft es mehr, als ich erwartet hatte. Die Rückfragen waren sinnvoll, das Schema passt zu einer Schreinerei, und das Deutsch ist brauchbar. Genau das unterscheidet EmDash Build von Buildern, die nur statisches HTML erzeugen.

Fertig ist es aber nicht, das sagt schon das Etikett Alpha. Beim Bauen gab es in beiden Läufen Fehler, der Adminbereich hing beide Male beim ersten Öffnen, und der Clone-Befehl war kaputt. Einige Texte stecken im Code, das Formular verschickt nichts, und der Export braucht Nacharbeit. Dazu kommt, dass dasselbe Briefing nicht zweimal dieselbe Website ergibt. Du kannst also nicht einmal prüfen, was EmDash Build liefert, und dich danach darauf verlassen. Live geht ohnehin nichts, denn die Demo veröffentlicht nicht, und selbst betrieben bekommst du derzeit einen schreibgeschützten Snapshot statt einer bearbeitbaren Produktionsinstanz. Ein Gespräch mit dem Kunden ersetzt EmDash Build auch nicht. Firmendaten, echte Referenzen, Fotos, Impressum, Datenschutz und ein funktionierendes Formular liefert der Agent nicht, und das soll er auch nicht.

Für Kundenprojekte reicht das heute noch nicht. Für Hoster und Plattformen, die selbst einen KI-Builder anbieten wollen, ist es dagegen ein gut dokumentierter Startpunkt, der sein Sicherheitsmodell offen beschreibt. Agenturen bekommen ein Werkzeug für den ersten Entwurf, den danach ein Entwickler übernimmt und Stück für Stück durchsieht. Mittelständische Kunden direkt davorsetzen würde ich aber noch nicht.

Grundlage dieses Artikels sind zwei Testläufe am 6. und 7. Oktober 2026 auf build.emdashcms.com, jeweils in einer frischen Gast-Session. Code-Stand emdash-build Commit 72b205f.