Die Fehler wurden zur Spezifikation.

Wie eine 400-seitige editorische Publikation ins Web übertragen wurde – und wie sich der Prozess dabei fast selbst automatisierte.

Diese Fallstudie handelt von einer Publikation, einem Prozess und einer Rückkopplungsschleife, die die meisten KI-gestützten Workflows nie hervorbringen. Es geht darum, was passiert, wenn man ein System anweist, seine eigenen Fehler zu dokumentieren, bevor diese Fehler überhaupt aufgetreten sind.

Am Ende stehen acht aufeinanderfolgende Kapitel ohne eine einzige Korrektur.

Das Projekt

Eine 400-seitige editorische Publikation – reich an Illustrationen, komplexer Typografie und einer über Jahre entwickelten visuellen Sprache – sollte im Web existieren. Nicht als PDF-Viewer, sondern als echte Webpublikation, in der Layout, Hierarchie und Ästhetik des Originals in HTML und CSS übersetzt werden.

Der konventionelle Weg wäre ein InDesign-Plugin-Export oder ein spezialisiertes Layout-to-Web-Tool gewesen. Beides existiert. Beides wäre in der ersten Stunde schneller gewesen.

Beides wurde nicht gewählt. Die Gründe hießen Kosten und Kontrolle. Plugin-Exporte erzeugen Ergebnisse, die der Kunde ohne Originalwerkzeug und Originaloperator kaum sinnvoll pflegen oder erweitern kann. Ein HITM-strukturierter Transfer erzeugt dagegen Output, den der Kunde vollständig besitzt: lesbares HTML, editierbares CSS, keine proprietären Abhängigkeiten. Jeder künftige Entwickler kann damit weiterarbeiten. Der Output bleibt lesbar.

Der Trade-off: langsamer als ein Plugin beim ersten Kapitel, schneller als ein Plugin in den letzten acht.

Die Bedingung, die alles verändert hat

Bevor das erste Kapitel überhaupt angefasst wurde, stand eine einzige Anweisung in der Projektspezifikation:

Dokumentiere alles. Jeden Fehler, jede Korrektur, jede Entscheidung. Die Dokumentation ist Teil des Deliverables.

Dieser Satz stand dort nicht, weil Fehler erwartet wurden, sondern weil sie unvermeidlich waren. In einem HITM-Build wird ein dokumentierter Fehler zur Randbedingung, und eine Randbedingung steuert jede folgende Session. Ein nicht dokumentierter Fehler verschwindet im Gesprächsverlauf. Ein dokumentierter Fehler wird Teil der Spezifikation.

Dass diese Regel schon vor dem ersten Problem geschrieben wurde, bestimmte die Entwicklung des gesamten Projekts.

Die ersten Stunden: Was schiefging

Die frühen Sessions waren unvollkommen. Das LLM vergaß Bilder; ganze Illustrationen fehlten im übertragenen Output. Es invertierte Farben einzelner Elemente, offenbar weil es die Quellgestaltung falsch las. Es traf Formatierungsentscheidungen, die der visuellen Logik des Originals widersprachen. Kleine Fehler, einzeln korrigierbar, aber reale Abweichungen vom Ausgangsmaterial.

Jeder Fehler wurde korrigiert. Und jede Korrektur wurde dokumentiert – nicht nachträglich in einer separaten Notizdatei, sondern in jener lebenden Spezifikation, die das LLM als Teil seines eigenen Workflows mitführte. Das Lerndokument wuchs parallel zur Arbeit. Als das dritte Kapitel abgeschlossen war, enthielt die Spezifikation nicht nur strukturelle Regeln des Transfers, sondern ein präzises Protokoll dessen, was fehlgeschlagen war und wie sich das richtige Verhalten definieren ließ.

Genau das ist der architektonische Zug, den viele KI-Workflows verpassen. Das Kontextfenster eines LLMs setzt zurück. Seine Erinnerung an die vorherige Session fehlt oder ist unzuverlässig. In einem rein konversationellen Workflow beginnt jede neue Session fast bei null, und dieselben Fehler tauchen wieder auf, weil es keinen Ort gibt, an dem Korrekturen gespeichert werden. Im HITM-Workflow leben diese Korrekturen in der Spezifikation. Sie reist in jede Session mit. Die Fehler wiederholen sich nicht.

Vom Korrigieren zur Automatik

Die Verbesserung war nicht plötzlich. Sie war strukturell und kumulativ.

Frühe Kapitel: Fehler wurden gefunden, korrigiert, Erkenntnisse in die Spezifikation überführt. Der Prozess war kollaborativ und korrektiv – mehr menschliche Beteiligung, mehr Review, mehr Intervention.

Mittlere Kapitel: Die angesammelten Randbedingungen begannen zu wirken. Weniger Fehler, verlässlicherer Output, weniger Korrekturen pro Kapitel. Das LLM operierte innerhalb eines immer präziser definierten Rahmens, und der Output spiegelte diese Präzision.

Die letzten acht Kapitel: keine Korrekturen mehr. Der Prozess war nahezu automatisch geworden – nicht weil das LLM „fähiger“ geworden wäre, sondern weil die Spezifikation vollständiger geworden war. Jeder Fehlermodus der frühen Sessions war nun als Randbedingung dokumentiert. Das System hatte gelernt, auf die einzige Weise, auf die ein zustandsloses KI-System lernen kann: über strukturierte externe Erinnerung, gepflegt durch die menschliche Operatorin oder den menschlichen Operator.

Acht Kapitel in Folge. Null Korrekturen.

Was das über HITM zeigt

Die Spezifikation ist kein Dokument, das einmal vor Projektbeginn geschrieben und dann vergessen wird. Sie ist ein lebendes Artefakt.

Gerade in Langformprojekten – mit dutzenden Kapiteln, Modulen oder Komponenten – muss die Spezifikation mit dem Build mitwachsen. Jeder Fehler ist eine unentdeckte Randbedingung. Jede Korrektur ist neues architektonisches Wissen. Die Disziplin besteht darin, dieses Wissen sofort in die Spezifikation zurückzuschreiben, nicht im Nachhinein.

Die Anweisung „Dokumentiere alles“ ist eine Meta-Randbedingung: eine Regel darüber, wie das System auf seine eigenen Outputs reagieren soll. Sie kostet fast nichts, erzeugt aber einen sich aufschaukelnden Ertrag über das gesamte Projekt.

Staatenlosigkeit ist nur dann ein Problem, wenn es keine externe Erinnerung gibt.

LLMs erinnern sich nicht an frühere Sessions. Das wird oft als Grenze KI-gestützter Arbeit beschrieben. Im HITM-Workflow ist es keine Grenze, sondern eine Gestaltungsbedingung. Spezifikation, Handoff-Dokument und Lerndokument werden zur externen Erinnerung. Der Mensch hält den Zustand, den die KI nicht halten kann. Kohärenz über Sessions hinweg entsteht nicht aus Erinnerung der Maschine, sondern aus struktureller Disziplin.

Der Output ist günstiger und kontrollierbarer als die Plugin-Alternative. Das Plugin wäre in Stunde eins schneller gewesen, hätte aber Output produziert, der an ein spezifisches Werkzeug gebunden bleibt. Der HITM-Transfer erzeugte sauberes HTML und CSS – lesbar, editierbar, werkzeugunabhängig. Der Kunde besitzt den Output vollständig.

Langsamer Start. Sehr viel stärkeres Finish. Und ein Prozess, der am Ende fast keine menschliche Intervention pro Kapitel mehr brauchte.

Das Lerndokument als Deliverable

Die während des Projekts entstandene Dokumentation ist selbst ein HITM-Artefakt. Sie enthält:

• jeden aufgetretenen Fehler, präzise beschrieben
• die jeweilige Korrektur
• die daraus abgeleitete Randbedingung
• die Regel, die daraufhin in die Spezifikation aufgenommen wurde

Am Ende war dieses Dokument ein vollständiger Leitfaden für die Übertragung editorischer Designpublikationen ins Web mit KI-gestütztem strukturiertem Bauen. Kein theoretischer Leitfaden, sondern ein empirischer – abgeleitet aus 400 Seiten realer Arbeit, realen Fehlern und realen Korrekturen.

Genau das produziert HITM, was konversationelle KI-Workflows nicht produzieren: Wissen, das das Projekt überlebt. Das Lerndokument kann im nächsten Transfer wiederverwendet werden – vom selben Operator oder von jemand anderem. Die Fehler müssen nicht noch einmal gemacht werden. Die Randbedingungen sind bereits geschrieben.

Was diese Fallstudie demonstriert

Dokumentation ist eine strukturelle Entscheidung, keine administrative Nebenaufgabe. Die Regel, alles zu dokumentieren, stand in der Spezifikation, bevor der erste Fehler auftauchte. Genau dieses Timing ist entscheidend. Retrospektive Dokumentation hält fest, was passiert ist. Prospektive Dokumentation erzeugt ein System, das sich mit jedem Fehler verbessert.

Die Fehler wurden zur Spezifikation. Jeder Fehltritt der frühen Kapitel fügte eine neue Randbedingung hinzu. Jede Randbedingung verengte den Raum möglicher Fehloutputs. In den letzten Kapiteln war dieser Raum eng genug, dass das System zuverlässig korrekt arbeitete. Das Scheitern war nicht verschwendet. Es wurde zu strukturellem Input.

Ein langsameres Werkzeug kann das bessere Werkzeug sein. Der Plugin-Export war in Stunde eins schneller. Der HITM-Transfer war über 400 Seiten hinweg besser: günstiger, kontrollierbarer und mit Output, den der Kunde vollständig besitzt. Für Langformprojekte ist Startgeschwindigkeit nicht die richtige Metrik. Kontrolle, Lesbarkeit und Handoff-Qualität sind es.

Der Prozess kumuliert. Das Lerndokument dieses Projekts ist die Ausgangsspezifikation des nächsten. Jedes Projekt, das nach HITM gebaut wird, hinterlässt nicht nur ein Deliverable, sondern einen präziseren Randbedingungssatz für die Arbeit, die folgt. Genau darin liegt ein struktureller Vorteil, der mit Praxis wächst – und den kein noch so schneller Plugin-Export replizieren kann.

Die Human-in-the-Middle-Methodik ist unter jba.schmidtpabst.com dokumentiert.