Eine Homepage, die ihr eigenes Versprechen einlöst

Wie aus sechs Fachbüchern in rund zehn Tagen eine hochautomatisierte Publishing-Plattform wurde — und warum genau das die zentrale These dieser Bücher belegt.

Summary

Wer über KI-gestützte Softwareentwicklung schreibt, steht vor einer unbequemen Prüfung: Stimmt eigentlich, was ich behaupte? Meine Bücher argumentieren, dass sich mit konsequentem KI-Einsatz die Geschwindigkeit ernsthafter Software-Projekte dramatisch erhöhen lässt — ohne die Qualität zu opfern. Die naheliegendste Art, diese These zu prüfen, war, sie auf sich selbst anzuwenden. Das Ergebnis ist the-book-publisher: eine Pipeline, die jede Buchquelle automatisiert in Blog-Artikel, LinkedIn-Beiträge, Slide-Carousels und das verkaufte E-Book verwandelt und daraus eine mehrsprachige Homepage speist. Der entscheidende Punkt ist nicht die Technik, sondern die Rechnung: Was klassisch ein mehrmonatiges Projekt mit einem kleinen Team wäre, stand in rund zehn Tagen. Dieser Artikel beschreibt zuerst den Zweck, dann die Anforderungen und das tragende Konzept, danach knapp die Umsetzung und das Setup — und schließt mit der komprimierten Timeline, an der sich das Tempo ablesen lässt. Die Kernbotschaft vorweg: Eine hochautomatisierte Publishing-Site lässt sich mit KI sehr schnell bauen. Und damit ist die Site selbst der beste Beleg für das, was die Bücher versprechen.

1. Der Zweck: ein Versprechen muss sichtbar werden

Ein Fachbuch über KI-gestützte Entwicklung lebt von seiner Glaubwürdigkeit. Sie können einen überzeugenden Satz nach dem anderen schreiben — solange das Ergebnis abstrakt bleibt, bleibt auch der Zweifel. Was wäre also, wenn nicht das Buch von der Methode erzählt, sondern ein reales Projekt sie vorführt?

Genau diese Rolle übernimmt die Homepage. Sie ist nicht bloß ein Schaufenster für die Titel, sondern der lebende Beweis für deren zentrale These. Wenn ich behaupte, dass KI-gestützte Entwicklung Projekte um ein Vielfaches beschleunigt, dann ist eine in zehn Tagen entstandene Publishing-Plattform kein Marketing — sie ist Empirie an einem einzigen, ehrlichen Fall.

Dazu kommt ein zweiter, sehr praktischer Zweck. Self-Publishing heißt: Sie sind nicht nur Autor, sondern auch Verlag, Marketing-Abteilung und Vertrieb in Personalunion. Jedes Kapitel müsste eigentlich für mehrere Kanäle aufbereitet werden — ein Blog-Artikel hier, ein LinkedIn-Post dort, ein Slide-Carousel für die Reichweite, dazu das E-Book. Bei einem Kapitel ist das Fleißarbeit. Bei sechs Büchern mit zusammen über hundert Kapiteln ist es schlicht nicht mehr von Hand zu leisten. M.a.W.: Ohne Automatisierung skaliert das Schreiben, aber nicht das Veröffentlichen.

2. Die Anforderung: eine Quelle, viele Kanäle — ohne Auseinanderdriften

Bevor eine Zeile entstand, stand die Anforderung. Und sie war anspruchsvoller, als sie zunächst klingt.

Aus einer Wahrheitsquelle — dem fertig gesetzten LaTeX-Buch — sollten viele plattformspezifische Artefakte entstehen: ein Blog-Artikel als kanonischer Inhalt, ein LinkedIn-Post mit Aufhänger und Kernbotschaft, ein Slide-Carousel, eine techlastigere Variante für eine Entwickler-Community sowie das verkaufte E-Book. Und parallel dazu eine mehrsprachige Homepage, auf der all das zusammenläuft.

Der eigentliche Knackpunkt steckt im Wörtchen „ohne Auseinanderdriften”. Wer schon einmal denselben Inhalt an fünf Stellen gepflegt hat, kennt das Problem: Sie korrigieren eine Zahl im Buch — und Blog, Folien und E-Book erzählen ab sofort eine andere Geschichte. Stellen Sie sich eine Setzerei vor, in der jede Ausgabe eines Werks von einem anderen Setzer aus dem Gedächtnis nachgebaut wird. Nach drei Auflagen weiß niemand mehr, welche Fassung die richtige ist. Genau dieses Auseinanderdriften musste die Anforderung von vornherein ausschließen.

Daraus folgten drei harte Bedingungen, die das ganze Projekt prägen. Erstens: Es darf nur eine Quelle geben, aus der sich alles Übrige ableitet — ändert sich das Kapitel, läuft die Erzeugung neu, und alle Kanäle ziehen nach. Zweitens: Es darf nichts erfunden werden. Jede Zahl, jede Quelle im erzeugten Text muss sich auf das Buch zurückführen lassen — sonst ist das Artefakt wertlos, schlimmer noch: gefährlich. Drittens: Der Mensch behält die inhaltliche Hoheit. Die Maschine liefert Entwürfe, aber was veröffentlicht wird, entscheide ich.

3. Das Konzept: eine Zwischenrepräsentation als Vertrag

Wie löst sich die Aufgabe „eine Quelle, viele Kanäle” sauber? Die naive Variante wäre, für jeden Kanal ein eigenes Programm direkt auf das LaTeX loszulassen. Das funktioniert genau so lange, bis das erste Buch andere LaTeX-Befehle benutzt als das zweite — dann brechen alle Kanäle gleichzeitig. LaTeX ist mächtig, aber fehleranfällig zu verarbeiten; diese Komplexität an fünf Stellen zu wiederholen, wäre der sichere Weg ins Chaos.

Der tragende Gedanke des Projekts ist deshalb eine Zwischenrepräsentation: Jedes Kapitel wird einmal in ein sauberes, strukturiertes Zwischenformat übersetzt — eine Art normierter Bauplan des Kapitels mit Überschriften, Kernaussagen, Zahlen und Quellen. Erst gegen diesen Bauplan arbeiten alle weiteren Schritte. Das LaTeX selbst sieht nur noch eine einzige Stelle der Pipeline.

Der Gewinn lässt sich an einem Bild fassen. Die Zwischenrepräsentation ist wie die genormte Palette in der Logistik: Sobald die Ware einmal palettiert ist, interessiert es den Gabelstapler, den LKW und das Hochregal nicht mehr, ob darin Schrauben oder Bücher liegen — sie alle sprechen „Palette”. Genauso muss der Blog-Generator nicht wissen, wie LaTeX funktioniert. Er muss nur das Zwischenformat verstehen. Die fehleranfällige Spezialarbeit ist damit genau einmal gekapselt, und jeder Kanal wird unabhängig prüfbar.

3.1 Profilgesteuert: ein neues Buch braucht keine neue Programmierung

Aus diesem Konzept fällt fast nebenbei eine Eigenschaft heraus, die für die Skalierung entscheidend ist. Weil sich die LaTeX-Eigenheiten von Buch zu Buch unterscheiden, steckt das Buch-spezifische Wissen nicht im Programmcode, sondern in einer kleinen, gut lesbaren Konfigurationsdatei pro Buch — einem Profil. Ein neuer Titel bedeutet also: ein Profil anlegen, fertig. Kein neuer Code, kein neues Risiko. Was beim ersten Buch noch Entwicklung war, ist beim sechsten nur noch Konfiguration — und genau das ist der Punkt, an dem Automatisierung beginnt, sich auszuzahlen.

3.2 Mensch im Loop und Faktentreue: die zwei Sicherungen

Zwei Anforderungen aus Abschnitt 2 sind so wichtig, dass sie fest in den Arbeitsablauf eingebaut sind, statt auf Disziplin zu hoffen.

Die erste ist das Freigabe-Gate. Jedes erzeugte Artefakt trägt zunächst den Status „Entwurf”. Erst wenn ich es geprüft und freigegeben habe, fließt es in Folien, Homepage und Versand. Die Pipeline ist also bewusst kein Knopf, der ungelesen ins Internet postet. Sie ist eine Manufaktur, die Ihnen einen sauberen Entwurf auf den Tisch legt — die Unterschrift leisten Sie.

Die zweite Sicherung ist ein automatischer Faktentreue-Abgleich. Jede Zahl im erzeugten Text wird gegen die Buchquelle geprüft; was sich dort nicht belegen lässt, wird blockiert oder durch eine nachweisbare Variante ersetzt. Warum dieser Aufwand? Weil ein erfundenes Detail in einem Fachbuch-Umfeld nicht nur ein Fehler ist, sondern ein Vertrauensbruch. Lieber eine Aussage weniger als eine erfundene Zahl — denn die ist schon zu viel.

Sie könnten einwenden, dass solche Kontrollen Tempo kosten. Das Gegenteil ist der Fall: Gerade weil die Maschine die mühsame Belegprüfung übernimmt, kann ich der Geschwindigkeit überhaupt erst trauen. Tempo ohne Kontrolle wäre fahrlässig — Tempo mit eingebauter Kontrolle ist der eigentliche Fortschritt.

4. Die Umsetzung: eine KI-gestützte Pipeline

Wie sieht die Umsetzung aus, ohne in die Tiefe der Technik zu gehen? Im Kern ist es eine Kette idempotenter Stufen — jede liest definierte Eingaben, schreibt definierte Ausgaben und lässt sich einzeln erneut ausführen, ohne den Rest zu beschädigen. Ändert sich ein Kapitel, wird nur dieses Kapitel neu verarbeitet; unveränderte Kapitel bleiben unberührt und verursachen keine Kosten.

Die kreative Übersetzung — vom Kapitel zum lesbaren Blog-Artikel, zum Post, zur Folien-Struktur — übernimmt ein KI-Modell, eingebettet als ein klar umrissener Schritt in dieser Kette. Damit die Texte nicht „nach KI” klingen, schreibt das Modell entlang einer hinterlegten Stilvorgabe. Alles andere — das Lesen der Quelle, das Rendern der Folien, der E-Book-Bau, das Erzeugen der Website — läuft deterministisch und ohne KI. M.a.W.: Die KI steht dort, wo Sprachgefühl gebraucht wird; überall sonst arbeiten verlässliche, wiederholbare Werkzeuge.

Beim Werkzeugkasten habe ich bewusst auf etabliertes, langlebiges Handwerkszeug gesetzt statt auf Exotisches: Python für die Pipeline-Logik samt Anbindung an die Claude-API, ein TeX-naher Build für das verkaufte E-Book, ein leichtgewichtiger Renderer für die Slide-Carousels, das statische Web-Framework Astro für die mehrsprachige Homepage und ein selbst gehostetes, datenschutzfreundliches Kommentarsystem auf einem deutschen Server. Welches Werkzeug genau welche Stufe bedient, ist für diesen Artikel zweitrangig — wichtig ist das Prinzip dahinter: bewährte Bausteine, sauber entkoppelt, von KI dort gestützt, wo es den größten Hebel hat.

5. Das Setup: warum „schnell” hier nicht „schludrig” heißt

An dieser Stelle entsteht erfahrungsgemäß ein Reflex: Zehn Tage — das klingt nach Hauruck, nach Prototyp, nach „läuft auf meinem Rechner”. Das Gegenteil ist der Anspruch, und er ist der eigentliche Kern der Methode.

Das Projekt folgt demselben disziplinierten Vorgehen, das die Bücher predigen: erst die Anforderung klären und in prüfbare Akzeptanzkriterien überführen, daraus Tests ableiten, dann implementieren. Architektur-Entscheidungen mit Langzeitwirkung werden festgehalten, bevor Code entsteht — der Code folgt der Entscheidung, nicht umgekehrt. Und über allem wachen harte, automatisierte Qualitäts-Gates: Formatierung, Typprüfung, Komplexitäts- und Duplikationsgrenzen, Test- und Sicherheits-Scans. Wer an diesen Schranken vorbeischreibt, blockiert sich selbst — nicht den nächsten Release, sondern schon den nächsten Merge.

Der entscheidende Perspektivwechsel ist dieser: KI ersetzt nicht das Engineering, sie beschleunigt es. Die Sorgfalt bleibt; was wegfällt, ist die Langsamkeit. Stellen Sie sich den Unterschied zwischen einem Handwerker mit Handsäge und demselben Handwerker mit einer präzisen Maschine vor — die Maßhaltigkeit ist dieselbe oder besser, nur die Zeit pro Schnitt ändert sich radikal. Genau so verhält sich diszipliniertes „Agentic Engineering” zum klassischen Vorgehen. Und genau deshalb ist die abwartende Haltung — „erst mal schauen, ob sich das durchsetzt” — heute das größere Risiko als der mutige, aber kontrollierte Einstieg.

6. Die Timeline: zehn Tage, sichtbar gemacht

Bleibt die Frage, die alles entscheidet: Wie schnell ging es wirklich? Die Versionshistorie des Projekts lügt nicht — sie ist auf den Tag genau nachvollziehbar.

Der Auftakt fiel auf den 20. Juni 2026 mit dem Projektgerüst; die Architektur war am Vortag abgestimmt. Schon am ersten Tag standen die Kerne der zentralen Verarbeitungsstufen. In den folgenden Tagen wurde die Pipeline gehärtet und die Inhaltsproduktion hochgefahren — der 23. Juni war der dichteste Tag mit über siebzig nachvollziehbaren Änderungen, an dem Kapitel für Kapitel der sechs Titel durch die Pipeline lief und als Blog-Artikel live ging. Danach kamen das E-Book mit Diagrammen und Bildern, eine vollständige Überarbeitung des Homepage-Layouts, Suchmaschinen-Optimierung, ein eigenes Web-Studio für Projekt-Beiträge und schließlich die betriebsfertige Auslieferung auf einem Server. Der vorerst letzte Stand datiert auf den 29. Juni 2026.

Macht in Summe: rund zehn Kalendertage, 176 nachvollziehbare Änderungen, sechs Buchtitel — von der leeren Wiese bis zur betriebsfertigen, mehrsprachigen Publishing-Plattform mit verkaufsfertigem E-Book und Distributionswegen. Nicht als Wegwerf-Prototyp, sondern unter dem vollen Qualitätsregime aus Abschnitt 5.

6.1 Die Eckdaten des Systems — damit die zehn Tage einen Maßstab bekommen

Eine Zeitangabe ohne Umfang ist eine halbe Aussage. „In zehn Tagen gebaut” kann eine Bastelei meinen oder ein ernsthaftes System — den Unterschied machen die Eckdaten. Hier sind sie, ausgelesen aus dem Projekt selbst:

Kennzahl	Wert
Produktivcode (Python-Pipeline)	~6.800 Zeilen
Testcode	~5.700 Zeilen
Codebasis gesamt	über 12.000 Zeilen
Funktionen / Klassen	402 / 36
Automatisierte Testfälle	368
Pipeline-Stufen (entkoppelt)	6
Zentraler Datenvertrag	1 (Chapter-IR-Schema)
Artefakttypen je Kapitel	4 (Blog, LinkedIn, Slides, dev.to)
Externe Schnittstellen	Claude-API, dev.to, Kommentardienst
Qualitäts-Gates	Typprüfung (strict), Komplexität (Block ≤ 10, Schnitt Grade A), Duplikation (≥ 9.0), Coverage (Line ≥ 80 %, Branch ≥ 70 %, Diff ≥ 90 %), Secret-/CVE-/SAST-Scan, Faktentreue-Audit

Lesen Sie diese Tabelle einmal mit der Zeitachse zusammen: über zwölftausend Zeilen Code, davon fast die Hälfte Tests, in rund zehn Tagen — das sind im Schnitt deutlich über tausend Zeilen pro Tag. Und eben nicht hingeworfen, sondern bei einem Test-zu-Code-Verhältnis von nahezu 1:1 und unter harten, automatisierten Schranken, die jeden Merge blockieren, der sie reißt. Das ist der eigentliche Beleg: Nicht die Zeile entstand schneller, sondern die abgesicherte Zeile. M.a.W.: Tempo und Testabdeckung schließen sich nicht aus — sie bedingen sich, wenn die KI die Fleißarbeit übernimmt und der Mensch die Kontrolle behält.

6.2 Der Umfang der Site

Auch das Ergebnis nach außen ist kein Schaufenster mit drei Kacheln. Die Homepage trägt über 90 Blog-Artikel aus sechs Büchern, dazu sechs Buchseiten und weitere Projekt-Artikel — zusammen rund einhundert inhaltliche Seiten. Hinzu kommen die strukturellen Seiten, die eine Plattform erst rund machen: Start- und Übersichtsseiten, Schlagwort-Seiten, Volltextsuche sowie Impressum und Datenschutz, zweisprachig (DE/EN) angelegt. Jeder dieser Artikel ist nicht von Hand geschrieben, sondern aus der jeweiligen Buchquelle erzeugt und freigegeben — und genau hier zahlt sich das Konzept aus Abschnitt 3 aus: Hundert Seiten von Hand zu pflegen wäre ein Vollzeitjob; hundert Seiten aus einer Quelle abzuleiten ist ein Pipeline-Lauf.

Zur Ehrlichkeit gehört die Einordnung: Zehn Kalendertage sind keine zehn Personentage, und ein Solo-Projekt ohne Abstimmungsschleifen ist schneller als ein Team-Vorhaben mit Stakeholdern. Die Größenordnung aber bleibt bemerkenswert — und sie ist genau das, was die Bücher behaupten.

Fazit

Die schönste Eigenschaft dieses Projekts ist, dass es seine eigene Werbung überflüssig macht. Ich muss Ihnen nicht erzählen, dass KI-gestützte Entwicklung schnell und zugleich solide sein kann — die Seite, auf der Sie das hier lesen, ist dafür der Beleg. Sie ist aus genau der Methode entstanden, die meine Bücher beschreiben: ein klares Konzept (eine Quelle, eine Zwischenrepräsentation, viele Kanäle), zwei feste Sicherungen (Mensch im Loop, Faktentreue) und ein diszipliniertes Vorgehen, das Tempo nicht gegen Qualität eintauscht, sondern beides verbindet.

Wer macht jetzt was? Für mich heißt das: dieselbe Pipeline auf jedes weitere Buch anwenden und den Prozess weiter schärfen. Für Sie, wenn Sie vor ähnlichen Fragen stehen: Fangen Sie klein an, mit einem ehrlichen Pilotfall, und messen Sie das Ergebnis an harten Kriterien — nicht am Bauchgefühl. Die Werkzeuge sind da. Die Methode ist beschrieben. Was bleibt, ist die Entscheidung, sie zu nutzen.

Diese Plattform ist der Beweis, dass sich diese Entscheidung lohnt — sie hat das Versprechen der Bücher eingelöst, bevor das erste Exemplar verkauft war.

Hinweis zu den Zahlen: Alle Angaben zu Zeitraum (20.–29. Juni 2026), Anzahl der Änderungen (176 Commits), Buchtiteln (sechs), Codeumfang, Funktions-/Test-Zahlen und Artikelmenge stammen aus der Versionshistorie, dem Buch-Manifest und dem Quellbestand des Projekts und sind dort nachprüfbar. Coverage-Schranken und Qualitäts-Gates sind die in der CI hart erzwungenen Mindestwerte. Die Einordnung „Kalendertage ≠ Personentage” ist eine bewusst konservative Lesart, keine Untertreibung.