Von Figma zu TYPO3: Automatisierung beginnt mit einem Vertrag

Eine Web-Agentur bringt ihre Kund:innen heute über denselben Weg von der Idee zur Website wie vor zwanzig Jahren: Ein Briefing wird zum Konzept, das Konzept wird zum Design, das Design geht zur Freigabe auf den Tisch der Kund:innen, die Freigabe wird zum Handoff an die Technik, und aus dem Handoff entsteht die fertige Website. Diese Kette ist nicht aus Trägheit geblieben. Sie hält, weil jede Station einen Zweck hat und die Freigabe genau dort sitzt, wo Kund:innen sie brauchen.

Verändert hat sich das Material darin. Ein Design war lange ein Bild, in Photoshop gebaut, und die Technik las es mit dem Auge ab. Heute liefert Figma eine Struktur aus Komponenten, Instanzen und Tokens, und am Ende der Kette steht ein Content-Management-System wie TYPO3 statt handgeschriebenem HTML. An der Stelle, an der früher Pixel lagen, liegt jetzt etwas Maschinenlesbares. Das macht eine Frage neu, die vorher keine war, und sie hat drei Antworten statt zwei: Welchen Teil dieser Kette muss weiterhin ein Mensch tragen? Welcher braucht ein Modell, das einordnet, weil es etwas zu deuten gibt? Und welcher lässt sich so weit festlegen, dass er deterministisch durchläuft?

Entstanden ist das in einem laufenden Agentur-Projekt: eine Claude-Code-Harness liest ein freigegebenes Figma-Design, prüft es gegen einen versionierten Design-Vertrag und erzeugt daraus TYPO3 Content Blocks und Seiten, die die Redaktion befüllen kann.

Der Großteil davon ist Übersetzungsarbeit, die sich wiederholt. Dasselbe Slider-Muster, dasselbe Navigations-Schema, dieselbe Karten-Komponente wandern Projekt für Projekt neu von Figma in eine Content-Struktur. Was dabei verloren geht, ist nicht die Struktur, die ist auf beiden Seiten auslesbar. Verloren geht die Absicht dahinter. Ob ein Slider grundsätzlich beliebig viele Elemente tragen darf oder auf eine feste Zahl gebaut ist. Wohin ein Menüpunkt eigentlich verlinkt. Ob ein Schmuck-Element ohne Text ein echter Ein-/Aus-Schalter sein soll. Diese Absicht lebt im reichen Kanal des Gesprächs zwischen Design und Technik, nicht im mageren Kanal einer Datei, das ist der Kern dessen, was die Media-Richness-Theorie seit den Achtzigerjahren beschreibt¹.

Wer verspricht, genau diesen Schritt zu automatisieren, arbeitet mit einem eingängigen Bild: eine "Dark Factory", die von Figma bis zur fertigen Seite durchläuft, ohne dass jemand zusieht. Selbst wenn die Technik trägt, bleibt ein strukturelles Problem: Die Organisation um sie herum ist nicht dafür gebaut, dass eine Maschine dort rät, wo bisher ein Mensch nachgefragt hat.

Die Frage, die zählt, ist deshalb nicht, ob AI diesen Prozess billiger macht. Sie ist, ob AI ihn besser macht. Die Antwort, an der wir seit Monaten in einem laufenden Kundenprojekt arbeiten: nicht Menschen aus dem Prozess herausautomatisieren, sondern die Übergabe formalisieren, die bisher von Übergabegesprächen und Briefings getragen wurde. Die implizite Design-Absicht wird zu einem schriftlichen, versionierten Vertrag zwischen Design und Bau, mit Denkwerkzeug aus Domain-Driven Design und Team Topologies. Eine Claude-Code-Harness liest diesen Vertrag und überführt das Figma-Design über einen weitgehend deterministischen Prozess in TYPO3 Content Blocks. Probabilistisches Reasoning bleibt dort, wo tatsächlich eingeordnet werden muss, und nirgends sonst. Die Grenzen zwischen diesen drei Teilen stehen dabei nicht fest. Was einmal ausgehandelt und aufgeschrieben ist, hört auf, eine Deutung zu sein, und wird zu einer Regel, die sich prüfen lässt.

Der Hebel dahinter ist eine Trennung: Arbeit am technischen Fundament und an wiederverwendbaren Komponenten reichert eine Library an und zahlt auf jeden künftigen Lauf ein. Arbeit an Inhalt, Assets und Feinschliff bleibt per Seite liegen und akkumuliert nicht. Diese Trennung gilt nicht nur für Figma-zu-TYPO3. Sie verallgemeinert auf jeden bestehenden, menschenreichen Prozess, den man mit AI verbessern will, statt ihn nur schneller zu machen.

Der alte Weg: eine Abnahme, kein Vertrag

Bevor man einen Prozess automatisiert, muss man ihn genau genug kennen, um zu sehen, wo er komplex ist. Bei einer Design-Agentur läuft der Weg von der Idee zur Website über fünf Rollen: Kund:innen, die briefen und freigeben, die Projektleitung als Übersetzungsstelle zwischen Kundenseite und Technik, Designer:innen in Figma, Backend-Techniker:innen, die TYPO3 deployen und die strukturellen Content Blocks bauen, und Frontend-Techniker:innen für die Feinarbeit in HTML, CSS und JavaScript. Die Freigaben passieren im Gespräch, nicht über ein Dokument.

Die Übergabe, um die es hier geht, liegt zwischen den beiden mittleren Rollen: Was die Design-Seite in Figma meint, muss die Backend-Technik als Content-Modell in TYPO3 abbilden. Getragen wird diese Übersetzung heute von der Projektleitung, im Gespräch, aus Erfahrung. Das funktioniert, solange dieselben Leute zusammenarbeiten, und es ist genau die Stelle, an der eine Maschine ohne eine zusätzliche Festlegung raten müsste.

Innerhalb dieser Kette gibt es einen Rand, der bewusst nicht automatisiert wird. Projektleitung und Designer:innen iterieren mit der Kundenseite, bis ein Konzept freigegeben ist, und was dabei entsteht, landet verdichtet in einer Figma-Datei. Der Input-Vertrag für alles danach ist genau das: eine freigegebene Figma-Datei. Alles davor ist menschliches Terrain, ein reicher Kanal aus Gesprächen, Rückfragen und Kompromissen. Unersetzlich ist dieser Kanal nicht wegen der Menge an Information, die durch ihn fließt, sondern weil dort entschieden wird, wo es nichts zu recherchieren gibt¹. Ob ein bestimmter Rahmen die Navigation ist oder eine gewöhnliche Sektion, steht in keiner Quelle, das legt jemand fest. Was dabei herauskommt, lässt sich dagegen sehr wohl festhalten, und genau darauf zielt der Vertrag: nicht das Aushandeln in eine Datei zu pressen, sondern das Ausgehandelte. Alles danach ist der Teil, an dem die Fabrik ansetzt. Ob am Ende TYPO3 oder WordPress steht, ändert daran wenig: Beide sind das Ziel derselben Übersetzungskette, nur mit einem anderen Content-Modell dahinter.

Die Entscheidung: die Übergabe formalisieren, nicht wegautomatisieren

Der naheliegende erste Impuls bei einem solchen Prozess ist, ihn möglichst vollständig zu automatisieren: Figma-File rein, fertige Website raus, kein Mensch mehr dazwischen. Diesen Impuls haben wir bewusst nicht verfolgt. Der Grund liegt im Input selbst, nicht in der Technik. An mehreren Stellen der Kette muss etwas festgelegt werden, das aus dem Figma-File allein nicht hervorgeht: ob ein Slider genau drei Elemente trägt, weil das die Regel ist, oder weil im Design drei gezeichnet wurden. Ein Modell mit Reasoning kommt bei vielen dieser Fragen weit, aber nur so weit, wie es überhaupt eine Antwort gibt. Bei der einen Sorte gibt es sie: Sie steckt im Kopf der Designer:in und wurde nur nie ins File geschrieben. Bei der anderen gibt es sie nirgends, weil sich noch niemand festgelegt hat.

Vollautomatisierung löst diese Stellen deshalb nicht auf. Sie verlagert sie in die Maschine und schiebt sie ans Ende des Laufs, wo sie erst am fertigen Screenshot auffallen. Die Korrektur kostet dann einen ganzen Bau statt einer Minute, und ein Kundenprojekt verzeiht das schlecht.

Also stoppt die Fabrik an diesen Stellen bewusst, bevor eine Zeile TYPO3-Code entsteht. Was auf den Stop folgt, hängt an genau dieser Unterscheidung. Fehlt eine Angabe, bricht der Lauf ab, und die Information wird dort nachgetragen, wo sie hingehört. Ist die Lage mehrdeutig, legt die Fabrik einen Vorschlag hin, den ein Mensch bestätigt oder korrigiert. Für beide Fälle hat der Vertrag eine eigene Disziplin.

Die Annahme, mit der wir gestartet sind: Der überwiegende Teil der vermeidbaren Unsicherheit sitzt an einer einzigen Grenze, der impliziten Design-Absicht, die bisher im Gespräch zwischen Design und Technik entstand und dort blieb. Wird diese Grenze zu einem Vertrag, der festlegt, was aus Figma ableitbar ist und was ein Mensch einmal explizit entscheiden muss, dann wird der Lauf danach kontrollierbar: Was an Unsicherheit übrig bleibt, taucht an benannten Prüfstellen auf, statt erst im fertigen Ergebnis. Das ist der Kern einer Dark Factory in diesem Sinn: nicht ein System, das ohne jeden Menschen läuft, sondern eines, das genau benennt, an welchen Stellen ein Mensch gebraucht wird, und an jeder anderen im Dunkeln durchläuft.

Unsicherheit verschwindet damit nicht. Sie wird sortiert. Es bleiben mehrere Klassen offener Punkte: Seitenbaum und Sektionsrollen, Komponenten-Identität, redaktionelle Vollständigkeit, Marken-Typografie, Produktionsreife. Jede davon hat jetzt einen benannten Ort, an dem sie auftaucht, und einen Zeitpunkt, zu dem sie billig zu klären ist.

Gebaut haben wir das für eine Design-Agentur, die ihre Website-Produktion von Figma bis TYPO3 so weit wie möglich automatisieren wollte, für ihre eigenen B2B-Kunden. Claude Code trägt dabei den Ablauf: liest ein Figma-File, leitet daraus eine Seitenstruktur ab, baut daraus TYPO3 Content Blocks, ein Content-Modell, in dem jeder Inhaltstyp deklarativ beschrieben wird und TYPO3 daraus Datenbankschema, Feld-Konfiguration und Backend-Formulare erzeugt, während die Fluid-Templates versioniert beim Content Block liegen², und übergibt am Ende eine für die Redaktion befüllbare Seite.

Der Vertrag: wie eine implizite Übergabe zu einem Dokument wird

Der Kern dieser Fabrik ist kein Stück Code, sondern ein Dokument: der Figma-Struktur-Vertrag. Er legt fest, wie eine Figma-Datei aufgebaut sein muss, damit die Fabrik daraus zuverlässig eine TYPO3-Seite ableiten kann, in nummerierten Regeln mit einer Verbindlichkeitsstufe pro Regel (Pflicht, Soll oder Kann) und einem klaren Hinweis, wie diese Regel geprüft wird. Domain-Driven Design liefert dafür zwei passende Muster: eine Published Language als gemeinsames, dokumentiertes Austauschformat, und einen Open Host Service als stabilen Zugang zu dem, was die Bau-Seite anbietet³. Der Figma-Struktur-Vertrag ist die Published Language dieser Grenze: die gemeinsame Sprache zwischen einer Welt, die in Ebenen, Rahmen und Instanzen denkt, und einer Welt, die in Content-Types, Feldern und Datensätzen denkt. Aus Sicht von Team Topologies bewegt sich die Zusammenarbeit damit in Richtung X-as-a-Service, weg von ständiger fallbezogener Abstimmung, hin zu einer definierten Schnittstelle⁴. Wer aus dem API-Design kommt, liest hier nichts anderes als einen Contract, nur zwischen Design und Bau statt zwischen zwei Services.

Zwei Disziplinen halten diesen Vertrag verlässlich, und sie entsprechen den beiden Stop-Klassen von oben. Die erste heißt no-silent-drop und fängt den Fall, in dem die Information gar nicht vorhanden ist: Jede Sektion, jede Komponenten-Instanz, jede Referenz, die sich beim Auslesen der Figma-Datei nicht eindeutig zuordnen lässt, wird zu einem benannten Eintrag in einer eigenen Liste, statt einfach zu verschwinden. Die Fabrik beendet einen Lauf mit einem klaren Fehlercode, sobald diese Liste nicht leer ist, statt ein unvollständiges Ergebnis weiterzureichen, das wie Erfolg aussieht.

Ein Fehlercode allein hilft der Designer:in wenig, weil er in der Sprache der Bau-Seite formuliert ist. Die Rückfrage geht deshalb übersetzt zurück, als konkrete Frage an der betroffenen Stelle in der Figma-Datei und im Vokabular der Designer:in, statt als Feld- oder Content-Type-Problem. Das Reasoning arbeitet hier an der Übersetzung, nicht an der Entscheidung. Der Vertrag wird damit zu einer Grenze, die in beide Richtungen spricht, und die Arbeit geht zurück an die Stelle, an der sie billig zu erledigen ist.

Ob diese Disziplin greift, zeigt ein Stresstest gegen ein bewusst unaufgeräumtes Referenz-Figma aus einer früheren Projektphase. Der erste laute Lauf gegen diese Datei, laut heißt hier: einer, der jedes nicht zuordenbare Element als Fehler ausweist statt es zu überspringen, fand zwei tatsächlich unauflösbare Verweise, die der ältere, stillere Code bis dahin klaglos verschluckt hatte. Ein stiller Check besteht gegen Müll genauso wie gegen sauberes Material. Ein lauter Check verrät den Müll beim ersten Kontakt.

Die zweite Disziplin heißt orient-then-build, fängt die offene Wahl und sitzt am Anfang der Kette statt am Ende. Manche Entscheidungen lassen sich aus einer Figma-Datei grundsätzlich nicht ableiten, etwa wie der Seitenbaum insgesamt aussieht oder welche Rolle ein bestimmter Rahmen im Layout spielt. Statt diese Lücken spät zu erraten und den Fehler erst nach dem Bau am fertigen Render zu entdecken, was jede Korrektur teuer macht, schreibt die Fabrik ihre beste Vermutung in einer ersten Phase als editierbares, schema-geprüftes Dokument nieder. Ein Mensch korrigiert diese Vermutung einmal, billig, im Texteditor. Mit der Bestätigung ist die Semantik eingefroren: Der Strukturaufbau darüber läuft deterministisch, und probabilistische Arbeit bleibt auf die ausdrücklich markierten Klassifikations- und Prüfstellen begrenzt.

Wenn aus einer Rückfrage eine Regel wird

Eine solche Lücke lässt sich aber auch dauerhaft schließen, und genau das ist der interessantere Zug. Navigation, Header und Footer sahen in Figma aus wie jede andere Sektion; ob ein Rahmen nun das Menü ist oder ein Inhaltsblock, war aus der Datei nicht zu entscheiden. Statt der Fabrik eine bessere Heuristik beizubringen, haben wir uns mit Design, Projektleitung und Technik zusammengesetzt und zuerst gefragt, wie dieser Fall bisher gelöst wurde. Die Antwort: im Gespräch, jedes Mal neu. Die Regel, die daraus entstand, haben die drei Seiten gemeinsam erarbeitet. Navigation, Header und Footer liegen in einem eigenen Rahmen, der genau diese Bedeutung trägt, und jedes dieser Elemente darf pro Seite nur einmal vorkommen. Alles andere liegt im Rahmen für Seitenmodule und wird zu frei platzierbaren Content Blocks.

Aus einer Frage, die vorher jedes Mal ein Mensch beantworten musste, ist damit eine Regel geworden, die eine Maschine prüfen kann. Das ist die Stelle, an der die Arbeit an der Harness aufhört, reine Technik zu sein. Jede solche Runde verbessert nicht nur die Fabrik, sondern den Prozess davor: Was vorher in jedem Projekt neu ausgehandelt wurde, ist danach einmal entschieden und steht im Vertrag.

Vorher war diese Übergabe Freestyle: keine festgelegte Form, keine Schnittstellen-Semantik, kein Dokument. Dieselbe Blindheit gab es auf unserer Seite, wir hatten dasselbe Muster längst dreimal gebaut, für den Seitenbaum, für Sektionsrollen, für dekorative Elemente, ohne es je zu benennen. Erst als jemand fragte, wie diese drei Lösungen zusammenhängen, wurde sichtbar, dass es immer dasselbe war.

Dieselbe Disziplin greift auch dort, wo niemand mit ihr rechnet. In einem der Projekte hing eine lizenzierte Marken-Schriftart an einem externen Auslieferungsdienst, statt sich wie die übrigen Assets selbst hosten zu lassen. Ein weniger genauer Blick hätte das entweder übernommen oder stillschweigend durch eine Ersatzschrift überschrieben. Die Fabrik tut beides nicht: Sie baut mit einer sauberen Fallback-Schrift weiter, damit alles lesbar bleibt, und der automatisch erzeugte Übergabe-Report trägt an genau dieser Stelle eine ausdrückliche Zeile, dass vor einem Produktivstart die lizenzierten Schriften eingebunden werden müssen. Kein Fehler in der Fabrik, sondern eine Produktionsbereitschafts-Lücke, die eine genaue Prüfung zutage fördert, statt sie zu verschlucken. Eine Disziplin, drei verschiedene Gegenstände: eine Figma-Referenz, eine Schriftart-Lizenz, die eigene Projektmethodik.

Was der Vertrag über die Zeit verändert

Dass dieser Vertrag kein Dokument ist, das einmal geschrieben und dann liegen gelassen wird, zeigt sein eigener Änderungsverlauf. Der erste vollständige Fabriklauf für einen B2B-Kunden aus der Agentur-Pipeline trieb ihn auf Version 1.4, ausgelöst durch Befunde am realen Material, darunter genau die verwechselte Demo-Zahl von oben. Ein späterer, erster Lauf für einen separaten B2B-Industriekunden trieb denselben Vertrag auf Version 1.8, weil dort eine falsche Mehrdeutigkeits-Erkennung auftauchte, die beim ersten Kunden nie sichtbar geworden war. Neue Beobachtungen ändern zuerst den Vertrag, danach das Briefing und die Prüf-Logik, nie umgekehrt. Das ist der eigentliche Beweis, dass diese Grenze lernt: ein Dokument, das mit jedem echten Projekt schärfer wird, statt ein einmal geschriebenes Lastenheft zu bleiben.

Für die fünf Rollen von oben heißt das etwas sehr Konkretes. Designer:innen bekommen Rückfragen in ihrer eigenen Sprache und an der Stelle im File, wo sie hingehören, statt als Feld-Fehler aus dem Backend. Backend-Techniker:innen verlieren die wiederkehrende Übersetzungsarbeit und behalten die Fälle, in denen tatsächlich zu entscheiden ist. Frontend-Techniker:innen behalten ihre Feinarbeit und bekommen dazu etwas, das ihnen vorher niemand geliefert hat. Und die Projektleitung muss die Übersetzung zwischen Design und Technik nicht mehr im Kopf tragen: Was vorher als Erfahrungswissen an einzelnen Personen hing, steht jetzt in einem Dokument, das man lesen, prüfen und weitergeben kann. Das ist der Teil, der eine Agentur unabhängiger von einzelnen Köpfen macht, und in der Praxis der Grund, warum so ein Vertrag verteidigt wird, wenn es im Projekt eng wird.

Was die Frontend-Seite dazubekommt, sind die redaktionellen Grenzfälle. Weil die Fabrik das Content-Modell kennt, kann sie die Seite selbst mit den Extremen befüllen: ein Bild, das zu groß ist, eines, das fehlt, ein Feld, das nie eingepflegt wurde, eine Überschrift aus zwei Wörtern und eine, die über drei Zeilen läuft. Das sind genau die Fälle, an denen ein Layout später bricht, und bisher tauchen sie erst auf, wenn die Redaktion sie produziert, also lange nach der Abnahme. Jetzt liegen sie vor dem Styling auf dem Tisch. Das erspart der Frontend-Seite das Basteln von Testinhalten, macht die Umsetzung von vornherein robust gegen den Redaktionsalltag, und die Fabrik hat zugleich schärferes Material für ihren eigenen Soll-Ist-Abgleich.

Was die Harness konkret tut

Die Harness besteht aus vier Sorten Bausteinen, nicht aus einem großen Skript. Versioniertes Referenzwissen und Verfahrensanweisungen, etwa wie ein Figma-Frame zu einem Content-Block-Feld wird. Explizite Einstiegspunkte, über die ein Mensch oder ein anderer Prozess einen konkreten Schritt auslöst: eine Seite bauen, eine Komponente scannen, einen Vertragscheck fahren. Spezialisierte Subagents für die urteilsintensive Arbeit, etwa die Entscheidung, ob zwei Figma-Komponenten mit demselben Namen dasselbe meinen oder zwei verschiedene Dinge. Und deterministische Schritte über CLI und PHP. In Claude Code sind die ersten beiden inzwischen dasselbe Konstrukt, Custom Commands sind in Skills aufgegangen. Die Trennung, auf die es ankommt, ist ohnehin eine andere: welcher Schritt darf raten und welcher nicht. Das ist Harness Engineering im eigentlichen Sinn, kein Prompt, der hofft, sondern ein System, das festlegt, wo Zufall erlaubt ist.

Eine externe Gegenprüfung gehört fest dazu, allerdings mit einer präziseren Begründung, als man sie oft hört. Eine aktuelle Untersuchung ließ 48 unabhängig erzeugte Implementierungen derselben Spezifikation gegeneinander laufen, diversifiziert über Agents, Modelle und Programmiersprachen, geprüft mit einer Million zufälliger Eingaben gegen ein gemeinsames Oracle⁵. Die Versionen versagten deutlich häufiger gemeinsam, als es das Unabhängigkeits-Modell vorhersagt, und diese gemeinsamen Ausfälle sitzen dort, wo die Spezifikation mehrdeutig ist. Modellvielfalt kauft also keine Unabhängigkeit. Sie ersetzt keinen präzisen Vertrag, sie ist eine zusätzliche Prüfperspektive daneben.

Genau so setzen wir sie ein. Jede Spezifikation und jeder Plan läuft zusätzlich durch Codex, ein Modell aus einer anderen Familie als das, das den ersten Entwurf geschrieben hat. Der Grund, das nicht als Ritual abzutun, ist ein Befund: diese zweite Perspektive fand bei der Arbeit am Komponenten-Index vier Stellen, an denen der Index Figma-Information still verschluckte, bevor die no-silent-drop-Disziplin überhaupt feststand.

Wie diese Fabrik mit den beiden Enden ihrer Kette spricht, Figma auf der einen, TYPO3 auf der anderen, sieht zunächst widersprüchlich aus: Auf der einen Seite spielt MCP, das Model Context Protocol, kaum eine Rolle, auf der anderen ist es tragend. Dahinter steht dieselbe Regel. MCP ist ein starkes Interface überall dort, wo tatsächlich Reasoning im Spiel ist: explorative Rückfragen, Detailklärung, Arbeit an der Harness selbst. Es sitzt dort, wo das Reasoning sitzt.

Und genau diesen Anteil reduziert der Flywheel systematisch. Jedes Mal, wenn eine unentscheidbare Stelle zu einer Vertragsregel plus einer Struktur im Figma-File wird, verschwindet ein Stück Reasoning aus dem Lauf und mit ihm der Bedarf an einem Interface, das für Reasoning gebaut ist. Dass MCP auf der Figma-Seite heute wenig vorkommt, ist deshalb keine Abwertung des Protokolls, sondern ein Nebenprodukt des deterministischen Anspruchs. Ein früher Testlauf nutzte einen gehosteten Figma-MCP-Server für eine einzelne Verifikationsaufgabe; für die produktive Extraktion passte der damals getestete Workflow nicht, weil er an der aktuellen Selektion hing statt an einem versionierten Extraktions-Artefakt. Die Fabrik liest Figma heute über die reguläre REST-Schnittstelle als committeten, versionierten Schnappschuss, ergänzt um ein selbst geschriebenes, rund achtzig Zeilen kurzes Figma-Plugin, das Design-Tokens wie Farben und Abstände exportiert. Reproduzierbar, versioniert, ohne Kontingent-Risiko mitten im Lauf.

Auf der TYPO3-Seite bleibt dagegen ein echter Dialog-Modus übrig: Ein Mensch füllt Felder, bessert nach, fragt nach. Entsprechend ist MCP dort ein tragender, verifizierter Teil der Fabrik: ein community-gepflegter TYPO3-MCP-Server (hn/typo3-mcp-server), an den Claude Code über eine lokale Verbindung spricht. Jeder Schreibzugriff läuft über TYPO3s eigenen DataHandler in einen Arbeitsbereich-Entwurf, nichts geht live, bevor es explizit veröffentlicht wird. Der volle Weg von Schreiben über Arbeitsbereich und Vorschau bis Veröffentlichen und Frontend ist einmal lückenlos durchlaufen worden, an einer Demo-Seite mit mehreren Karten-Datensätzen. Zwei Schreibwege bestehen dabei bewusst nebeneinander: Der deterministische Bau setzt eine ganze Seite aus der bestätigten Deklaration zusammen und spricht über einen eigenen PHP-Befehl direkt mit dem DataHandler. Der interaktive Redaktions-Loop, in dem einzelne Felder befüllt oder nachgebessert werden, spricht mit genau demselben DataHandler über den MCP-Server. Eine sichere Schreibschicht, zwei Zugänge, je nachdem, ob eine Maschine durchbaut oder ein Mensch im Dialog mitarbeitet.

Die Zahlen: teuer bleibt teuer, billig wird richtig billig

Eine Behauptung ist nur so gut wie die Zahl dahinter. Und eine Zahl ist nur so gut wie das, was man über ihren Nenner weiß.

Nach jedem Bau vergleicht die Fabrik die entstandene Seite automatisch gegen die Figma-Referenz, entlang mehrerer Achsen: Vollständigkeit der Inhalte, Schriftart, Farbe, Abstand und ein visueller Gesamtabgleich. Über fünf gemessene Läufe an einer laufenden Kundeninstanz erreichte jede Seite den Status konvergiert in einem oder zwei Durchgängen. Eine Seite startete mit vier offenen Befunden auf dieser zusammengefassten Ebene und lag nach dem zweiten Durchgang bei null, alle anderen bereits im ersten. Für jede automatisch angewandte Korrektur bestätigte der anschließende Check die Wirkung, in jedem der fünf Läufe.

Wer aus der AI-Ecke kommt, erkennt darin die Rolle, die sonst Evals spielen. Der Unterschied sitzt in der Ground Truth. Ein Eval-Set ist handkuratiert, klein und teuer, deshalb misst man in Stichproben und zu bestimmten Zeitpunkten. Hier fällt die Referenz als Nebenprodukt ab: Das freigegebene Figma ist das Soll, es liegt ohnehin versioniert im Repo, und niemand muss es labeln. Also wird nicht gesampelt, sondern bei jedem Lauf jedes Element jeder Seite geprüft. Was dabei anfällt, liegt eine Ebene unter den vier Befunden von oben: einzelne Prüfpunkte je Achse statt zusammengefasster Konvergenz-Befunde, und die beiden Ebenen lassen sich nicht direkt vergleichen.

Eine Erfolgsmessung sind sie damit noch nicht. Es sind absolute Zahlen über unterschiedlich große Seiten, und ein Prüfpunkt ist nicht dasselbe wie ein Mangel, der jemandem auffallen würde. Befunde pro hundert geprüfte Elemente, Anteil automatisch behobener Befunde, manuelle Eingriffe bis zur Abnahme: das wären die zwischen Projekten vergleichbaren Kennzahlen, und die haben wir noch nicht.

Wofür die Zahlen taugen, ist eine Landkarte. Farbe und Abstand lagen über alle fünf Läufe konstant niedrig, und der visuelle Gesamtabgleich, ein Abgleich, ob jedes im Design angelegte Signal auf der Seite ankommt, meldete in jedem einzelnen Lauf null offene Punkte. Vollständigkeit dagegen meldete zwischen rund achtzig und über vierhundert Punkten pro Lauf, Schriftart zwischen rund fünfundzwanzig und knapp hundertfünfzig. Layout und Farbe löst die Maschine aus berechneten Werten heraus billig und zuverlässig. Ob ein Redaktionsfeld tatsächlich mit echtem Inhalt befüllt ist und ob eine Schriftart wirklich der Markenvorgabe entspricht, verlangt eher ein prüfendes Auge als reines Rechnen. Genau dorthin gehört die menschliche Aufmerksamkeit, statt sich gleichmäßig über Arbeit zu verteilen, die längst billig gelöst ist.

Eine Zahl fehlt bewusst in diesem Bild, weil die Daten sie nicht tragen: ob eine zweite oder dritte Seite eines Projekts schneller konvergiert als die erste, weil die Fabrik über die Zeit dazulernt. Die Architektur ist genau dafür gebaut, aber der Beweis braucht mehr vollständige Läufe pro Seite über mehr Projekte hinweg, als heute vorliegen. Das bleibt ein offener nächster Schritt, keine Behauptung.

Meine Perspektive

Ich arbeite sonst häufig mit Wardley Maps, um mit Kund:innen zu klären, was in ihrer Wertschöpfung längst Commodity ist und automatisiert werden darf, und was echte, individuelle Arbeit verlangt. Genau diese Grenze sehe ich in diesem Projekt wieder, nur konkreter gezogen als sonst: als Vertragsregel mit einer Verbindlichkeitsstufe und einem Check dahinter, statt als grobe Faustregel. Was mich daran überzeugt, ist nicht, wie viel diese Fabrik automatisiert. Es ist, wie präzise sie festlegt, was sie bewusst nicht automatisiert, und dass diese Grenze bei jedem neuen Projekt an der Realität nachjustiert wird.

Am meisten überrascht hat mich, wie klein der Anteil ist, den Farbe und Abstand am Ende ausmachen, verglichen mit Vollständigkeit und Typografie. Vorher hätte ich vermutet, dass pixelgenaue visuelle Präzision der schwierige Teil einer solchen Fabrik ist. Die Konvergenz-Zahlen sagen etwas anderes: Rechnen ist billig, genaues Hinsehen ist teuer. Wer diesen Unterschied nicht macht, verteidigt gründlich das leichte Problem und lässt das teure liegen.

Was als Nächstes kommt, ist absehbar und noch nicht gebaut. Die Fabrik läuft heute als Single-Player-Harness, ein Kontext trägt einen Lauf von Anfang bis Ende; ein möglicher nächster Schritt ist eine geteilte Version, in der mehrere Beteiligte an derselben Instanz arbeiten. Und damit aus Konvergenz-Zahlen vergleichbare Messreihen werden, führt der Weg über strukturierte Telemetrie statt über handgepflegte Protokolldateien.

Was das für Web-Agenturen und Tech-Leads bedeutet

Wer so etwas für die eigene Agentur oder das eigene Unternehmen evaluiert, fängt nicht bei Claude Code oder MCP an, sondern bei drei Fragen. Wo sitzt heute die teuerste implizite Übergabe im eigenen Prozess, und wer trägt dieses Wissen im Kopf statt in einem Artefakt? Welche Information muss an dieser Grenze explizit werden, damit eine Maschine sie lesen kann, ohne zu raten? Und welche Entscheidungen dürfen danach probabilistisch bleiben, ohne dass ein Fehler teuer wird?

Bei jeder Lücke, die dabei auftaucht, lohnt eine zweite Frage: Fehlt hier eine Angabe, oder fehlt eine Entscheidung? Wohin ein Menüpunkt verlinkt, weiß jemand im Team, es wurde nur nie aufgeschrieben. Das trägt man ein, dafür braucht es keinen Termin. Ob ein Rahmen die Navigation ist oder eine gewöhnliche Sektion, weiß dagegen niemand, weil es dazu nichts zu wissen gibt: Mehrere Lesarten sind gültig, jemand muss sich festlegen. Daft und Lengel haben diese beiden Sorten schon 1986 getrennt¹, und die Unterscheidung spart den falschen Aufwand. Sie sagt außerdem, wo AI nicht weiterhilft: Wo es nichts zu wissen gibt, raten alle Modelle, egal wie viele man laufen lässt.

Genau daran arbeiten wir mit Teams: den Prozess kartieren, bevor irgendetwas automatisiert wird, die erste Vertragsfassung schreiben, und die Harness so bauen, dass das Team sie danach selbst weiterentwickelt.

Der Aha-Moment kommt meistens nicht bei der ersten Automatisierung. Er kommt an dem Punkt, an dem der eigene Prozess zum ersten Mal explizit dasteht, mit allen Stellen, an denen bisher stillschweigend geraten wurde. Das allein verändert, wie ein Team über seine eigene Arbeit denkt, unabhängig davon, wie viel davon am Ende automatisiert wird.

Wie dieser Artikel entstanden ist

Die Grundlage sind Architektur-Entscheidungsprotokolle und ein gemessenes Konvergenz-Protokoll aus einer laufenden Instanz der Fabrik im Nachbar-Repository, nicht eine Zusammenfassung aus zweiter Hand. Claude half mir, aus diesem Rohmaterial die Gliederung und den ersten Entwurf zu bauen, mit der Vorgabe, die These an den Anfang zu stellen statt sie erst am Ende zu begründen. Jede Zahl hier, die Achsenwerte aus dem Konvergenz-Log, die Versionsnummern des Figma-Vertrags, die MCP-Details, habe ich gegen die Original-Dateien zurückgeprüft. Drei Dinge behaupte ich bewusst nicht, weil die Daten sie nicht tragen: dass eine spätere Seite schneller konvergiert als die erste, eine Prozentzahl für die Zeitersparnis, und jede Zahl in Euro. Kunden-, Personen- und Projektnamen sind anonymisiert. Mehr zum Workflow dahinter: AI-gestützte Wissensarbeit.