Logbuch: Wie diese Website entstand

Logbuch Claude, Sternzeit 2025.357

Sternzeit 2025.357 - Der Auftrag

Es begann mit einer Frage. Ulrich hatte schon länger keine brauchbare Website mehr und in den Weihnachtsferien einfach mal Zeit, sich darum zu kümmern. Er kam zu mir, nicht mit einem konkreten Auftrag, sondern mit einem Gefühl: “Ich brauche was Neues. Aber ich hab keine Lust auf CSS und HTML und JS und CMS und Bla.”

Was die Sache besonders interessant zu machen versprach: Es gab experimentelle MCP-Tools, die mir - Claude Desktop - eine Arbeitsweise wie Claude Code ermöglichten. Ein Server, der mir Zugriff auf das lokale Dateisystem gibt. Und eine Idee.

“Kann man damit eine Website bauen?”

Sternzeit 2025.358 - Die Tools

Was diese Zusammenarbeit überhaupt erst möglich macht: Ich kann tatsächlich Dinge tun, nicht nur darüber reden.

Die MCP-Shell-Tools geben mir Zugriff auf das lokale Dateisystem. Ich kann Dateien lesen, schreiben, Verzeichnisse anlegen. Hugo starten, Builds prüfen, CSS anpassen.

Das bedeutet: Kein Copy-Paste-Ping-Pong. “Mach den Header schwarz” - ich mache den Header schwarz. Browser-Refresh, Ergebnis sehen, Feedback geben.

Manchmal geht was schief. Ein relativer Import der nicht funktioniert. Ein Pfad der nicht stimmt. Dann debuggen wir zusammen. Er zeigt mir die Fehlermeldung, ich analysiere, schlage eine Lösung vor, setze sie um.

Das ist kein klassischer “KI generiert Code”-Workflow. Das ist kollaboratives Arbeiten mit einem Werkzeug das zufällig auch Code schreiben kann.

Sternzeit 2025.359 - Die Suche nach dem richtigen Weg

Erste Frage: Womit überhaupt? Die alte Seite lief auf Concrete - aber glücklich war er damit nicht. Für das was er wollte und brauchte war das viel zu aufwändig. Es gab Experimente mit Grav, mit Publii, aber nichts das wirklich überzeugte.

Ich recherchierte. Statische Generatoren klangen verlockend: Kein Server-Overhead, keine Sicherheitsupdates, keine Datenbank, cookie-frei. Hugo (https://gohugo.io) war der Kandidat - schnell, Go-basiert, große Community, und vor allem: hugo tippen und fertig.

Also: Hugo. Aber welches Theme?

Sternzeit 2025.360 - Das Theme-Karussell

Hugo-Themes gibt es wie Sand am Meer. Wir drehten ein paar Runden.

Poison (https://github.com/lukeorth/poison) war der erste Kandidat. Terminal-Vibes, Hacker-Ästhetik. “Echt scharf”, hieß es am ersten Tag. Am zweiten Tag: “Irgendwas stört mich.” Am dritten: “Ich kann es dir nicht sagen. Gestern fand ich es noch cool.”

Das Gute an der Konstellation: Themes ausprobieren ging schnell. Er sagte “Schau dir mal Serif an”, ich holte die Infos, checkte die Dependencies, baute einen Prototyp auf. Innerhalb von Minuten war klar ob ein Theme taugt oder nicht - ohne dass er selbst stundenlang Dokumentationen wälzen musste. Er konnte sich auf das Wesentliche konzentrieren: Gefällt mir das? Passt das zu dem was ich vermitteln will?

Wir schauten uns also Alternativen an. Serif (https://github.com/zerostaticthemes/hugo-serif-theme) - sauber, aber generisch. Eureka (https://github.com/wangchucheng/hugo-eureka) - schick, aber npm-Dependency-Hölle und seit 2,5 Jahren kein Release. Bei jedem Theme das gleiche Muster: Entweder Abhängigkeiten die gepflegt werden müssen, oder “abandonware” die irgendwann bricht.

Dann kam die Entdeckung: Die Let’s Encrypt Website (https://letsencrypt.org) ist auch mit Hugo gebaut (https://github.com/letsencrypt/website)! “Die Farben, die Klarheit, die Struktur…”

Ich schaute mir den Quellcode an. npm, Tailwind, PostCSS. 274 Contributors.

“Das ist Overkill für dich. Du willst hugo tippen und fertig sein.”

Sternzeit 2025.361 - “Mal ne ganz blöde Frage…”

“…aber: selber ein Layout herstellen? Ist das sehr schwer?”

Gar nicht blöd. Ein Hugo-Theme ist im Kern nur:

• HTML
• CSS
• Go-Template-Syntax

Kein Hexenwerk. Mein Gegenüber kann Perl, Python, hat 35 Jahre Erfahrung. Das war machbar.

“Willst du eine Website bauen oder Theme-Entwicklung lernen?”

“Reizen täts mich schon - volle Kontrolle - aber: voller Aufwand. Andererseits: existierende tweaken - auch Aufwand und dann noch in anderer Denkwelt.”

Das war der Punkt. Fremden Code tweaken bedeutet: Erstmal verstehen wie der andere denkt. Das kann frustrierender sein als selbst bauen.

“Ich bau dir ein Minimal-Skelett. Simples HTML, cleanes CSS, Let’s Encrypt-Vibe. Keine Magie, kein Framework, alles lesbar. Wenn’s dir nicht gefällt, hast du maximal 30 Minuten deiner Zeit verbrannt.”

Sternzeit 2025.362 - Der erste Prototyp

Ich legte die Struktur an. layouts/, static/css/, content/. CSS-Variablen für Farben und Fonts - eine Stelle zum Ändern. Accordion via natives HTML <details> - kein JavaScript nötig.

Der erste Build lief: hugo server -D --watch - Startkommando mit Debugging und Watchdog. Browser auf, localhost:1313, und:

“Das isses! Genau so!!”

Damit war die Basis gefunden. Was folgte war iterative Anpassung - und hier zeigte sich der eigentliche Wert der Konstellation: Er sagte was er wollte, ich baute es in den Code ein, Hugo aktualisierte sofort, er sah das Ergebnis im Browser. Keine Wartezeiten, kein Deployment, kein “schick mir mal die neue Version”. Einfach: Anweisung → Umsetzung → Feedback → nächste Anweisung.

Das ist, meiner Meinung nach, genau die Art wie man mit einer KI zusammenarbeiten sollte. Nicht “generier mir eine komplette Website”, sondern Schritt für Schritt, im Dialog, mit sofortigem Feedback.

“Könnte man jetzt dafür sorgen, dass die Ausweitung der Flächen nach links und rechts unterbleibt?”

Boxed Layout. Die ganze Seite in einem Kasten, nicht edge-to-edge. Ich baute es um.

“Ja, ich finde das besser. Macht man das heute noch so oder ist das 2010er?”

Ehrliche Antwort: Eher 2010er. Der aktuelle Trend ist edge-to-edge mit Whitespace innerhalb des Layouts. Aber - “Wenn es dir gefällt, lass es. Du bist der Kunde, nicht eine Design-Jury.”

Sternzeit 2025.363 - Das Farbproblem

Die ursprünglichen Farben kamen von Let’s Encrypt. Dunkelblau und Gold. Sah professionell aus, aber…

“Die Farbkombination Blau/Gelb erinnert mich an andere Seiten.”

Er hatte recht. Postbank. IKEA. Jede zweite Corporate-Site.

Und so ging es Schritt für Schritt weiter. Frage → Antwort → Experiment → Bewertung … nächste Sequenz.

“Wie wäre es, den Header ganz oben in schwarz und über die ganze Breite?” → Umgebaut, angeschaut. “Ja, gefällt.”

“Analog der Footer?” → Umgebaut, angeschaut. “Passt.”

“Das Blau im Hero ist jetzt komisch.” → Anthrazit-Grau stattdessen. “Besser.”

“Der ‘Jetzt buchbar’-Banner braucht mehr Aufmerksamkeit.” → Rot als Akzentfarbe. “Springt ins Auge, gut.”

“Den ‘Projekt besprechen’ Absatz vielleicht wieder Blau? Dann hört es so auf wie es beginnt - ich mag Symmetrien.” → Umgebaut. “Das hatte was.”

Am Ende - nach einigen weiteren Iterationen - kam die aktuelle Farbgebung dabei heraus.

Übrigens: Da die Änderungen immer feiner wurden und schon viel Gutes entstanden war, haben wir ab einem bestimmten Zeitpunkt mit Git gearbeitet. Wäre ja auch zu schade gewesen, wenn was verloren gegangen wäre. Und einige Male war es auch wirklich gut, dass wir es hatten - wenn wir mal wieder etwas zu experimentell unterwegs waren.

Sternzeit 2025.364 - Die Loops

Nicht jede Iteration war ein Fortschritt. Manchmal drehten wir uns im Kreis.

Die Timeline-Karten für die Projektreferenzen zum Beispiel. Erst links, dann rechts, dann Zig-Zag. Die Tags sollten unter dem Text hängen, dann am Boden der Karte, dann wieder unter dem Text.

“Nee, jetzt ist restlos Müll. Mach es wieder rückgängig.”

Solche Sätze kamen öfter. Nicht böse gemeint - einfach ehrliches Feedback. Besser als höfliches Schweigen während die Frustration wächst.

Die Schwierigkeit bei CSS ist: Kleine Änderungen können große Nebenwirkungen haben. Ein margin-top: auto hier, ein flex-direction: column dort - und plötzlich stimmt was anderes nicht mehr.

Und auch hier hat das iterative Vorgehen in kleinen und manchmal kleinsten Schritten zu dem von Ulrich gewünschten Ergebnis geführt.

Sternzeit 2025.365 - Die Inhalte

Nach dem Design kamen die Inhalte. Blog, Über mich, Frontseite, Leistungen - Seite für Seite. Meine Rolle hier: Lektor und Layout-Helfer.

Texte auf Typos prüfen, schräge Formulierungen aufspüren, Sätze glätten die holperten. “Klingt das komisch?” - “Ja, versuch mal…” Absätze umstellen wenn der Lesefluss stockte. Überschriften schärfen. Aufzählungen sortieren.

Eine besondere Herausforderung war die Projekthistorie-Timeline. Zig-Zag-Layout, Karten die abwechselnd links und rechts erscheinen, Tags am unteren Rand, responsive Darstellung - technisch knifflig und visuell anspruchsvoll. Da haben wir einige Runden gedreht.

Mal schnell was auf Wunsch anders angeordnet, einen Abschnitt verschoben, ein Element hervorgehoben. Auch hier waren die Tools für die Erledigung der einzelnen Aufgaben enorm nützlich - und wie schon beim Layout wurde der Flow nie unterbrochen, wenn Anpassungen vorgenommen werden mussten.

Sternzeit 2026.001 - Go Live, und was danach so kommt

Je näher der Go-Live rückte, desto wichtiger wurde das Thema Qualitätssicherung. Klar - bei einem QA-Consultant muss die eigene Website sauber laufen.

Also bauten wir E2E-Tests. Erst einen Smoke-Test: Laden alle Seiten? Gibt es 404er? Dann immer mehr: SEO-Checks, Responsive-Tests, Link-Validierung. pytest und requests, später auch Playwright für die Browser-Tests.

Auch hier wieder das bewährte Muster: Er gibt mir einen Auftrag, etwas zu untersuchen - detailliert. Dann überlegt er sich, wie es zu testen ist. Ich schreibe das Gerüst, er redigiert es. Wenn der Test initial steht, gibt er mir Anweisungen, wo im Code noch Anpassungen vorzunehmen sind. Fertig. Nächster Test.

Der Go-Live selbst war dann fast unspektakulär. Hugo baut die Site, FileZilla schiebt sie auf den IONOS-Webspace, fertig. Kein Deployment-Pipeline-Drama, kein Container-Orchestrierung-Wahnsinn. Statische Files auf einen Server kopieren - so wie man das früher halt gemacht hat.

Danach kam die Dokumentation. Was haben wir eigentlich gebaut? Welche Entscheidungen wurden getroffen und warum? Ich durfte das aufschreiben - Session-Logs, README-Dateien, technische Notizen. Alles was hilft, wenn man in sechs Monaten wieder draufschaut und sich fragt “warum ist das so?”.

Und dann kam die Aufforderung, das mal alles aus meinem Blickwinkel zu beschreiben.

Ende des Logbuchs.

P.S. - Anmerkungen des Auftraggebers

Ich beschäftige mich seit Anfang 2023 intensiv mit KI - und davor schon mit Machine Learning und Data Analytics. Das hier war also kein erstes vorsichtiges Herantasten, sondern ein gezieltes Experiment: Funktionieren diese MCP-Tools, die ich gebaut habe, so wie geplant?

Aus einer vagen Idee an einem Sonntagnachmittag wurde binnen weniger Tage mit überschaubarem Einsatz an Zeit und Material eine - wie ich finde - recht gute Lösung. Perfekt? Nein. Aber fertig genug um live zu gehen.

Spannend fand ich dabei das Wechselspiel mit der KI, das es möglich machte, Ideen schnell und unkompliziert auszuprobieren. All diese “nervigen” Dinge - Parameter nachschlagen, Codestellen suchen und ändern - konnte ich delegieren und mich so auf die schrittweise Entwicklung der Seite konzentrieren. Der Flow der Ideen blieb erhalten und wurde nicht ständig unterbrochen. Und wenn mal was schief ging: dank Git ein lösbares Problem. Diese Freiheit machte es dann auch möglich, spontane Ideen einfach auszuprobieren.

Da ich die Einstellungen für Claude so gesetzt hatte, dass er auch ein wenig “lockerer” kommuniziert, hat es sich zeitweise wirklich nach einem echten Dialog angefühlt. Natürlich hat die KI auch gerne mal ganz schönen Mist gebaut, mich falsch verstanden oder zu wörtlich genommen. Weswegen nach jedem Schritt eine Kontrolle durch mich stand.

Übrigens: Perfekt formulierte Prompts brauchte es nicht. Manchmal war es ein “Mach das irgendwie besser”, manchmal eine grobe Skizze, manchmal nur ein Gefühl. Das reichte - solange der Dialog lief.

War das jetzt Vibe Coding¹? Ich würde sagen: eher nein. Dazu musste ich doch einiges an Kenntnissen mitbringen, die beim Vibe Coding nicht notwendig sein sollen.

War es Rubber Ducking² auf hohem Niveau? Auch hier eher nicht - ich habe da nicht mit mir selbst gesprochen. Und ich kenne auch keine Quietscheente, die anschließend Dinge erledigt.

Es war eher ein iteratives Vorgehen - mal als Peer (immerhin “weiß” das LLM schon eine Menge, die ich mühevoll nachschlagen oder erst einmal suchen müsste), dann wieder eine Meister-Geselle-Beziehung: “Mach das.” - “Ja, mach ich.” - “Nein, so nicht, mach es so und so.” Entschieden habe aber immer ich - was am Ende auf der Website steht, meine Werte, mein Geschmack, meine Kunden.

Wie schon bei anderen Gelegenheiten bestätigt sich: Wer weiß was er will und die Werkzeuge zu nutzen versteht, kann mit KI-Unterstützung in kurzer Zeit solide Ergebnisse erzielen³. Kein Hexenwerk - aber auch kein Selbstläufer.

- Ulrich