markusgraf_ch/content/blog/ki-generierte-website-praxisbeispiel/index.de.md

---
title: "KI Generierte Website - ein Praxisbeispiel"
date: 2025-10-30
description: "Meine Erfahrungen beim Aufbau dieser Website mit KI-unterstützter Entwicklung und OpenSpec statt unstrukturiertem 'Vibe Coding'."
---

### TL;DR

Meine persönliche Website war über vier Jahre veraltet und schwer zu pflegen. Für die Neugestaltung setzte ich auf KI-unterstützte Entwicklung mit OpenSpec statt unstrukturiertem „Vibe Coding". Der spezifikationsgetriebene Ansatz erwies sich als effizienter: Zunächst wurde das Projekt grob beschrieben, dann in kleinen Schritten umgesetzt – von der Initialisierung über Content-Migration bis zur mehrsprachigen Unterstützung. Die offenen Proposals erlaubten flexible Korrekturen während der Umsetzung. Mit Sub-Agents in Claude Code liess sich das Deployment automatisieren. Fazit: KI-gestützte Entwicklung erfordert Struktur und Dokumentation, fühlt sich aber wie produktive Teamarbeit an – man prüft mehr Code als man schreibt.

## Ausgangslage

Über mehr als vier Jahre blieb meine persönliche Website unverändert online. Die Inhalte waren veraltet, das statische HTML mühsam zu pflegen – wenig motivierend. Mit dem Ziel, mich beruflich neu zu positionieren und meine Sichtbarkeit zu erhöhen, habe ich das Projekt neu aufgesetzt.

## Warum KI – aber nicht „Vibe Coding"

Ich experimentiere seit einiger Zeit mit KI‑unterstützter Softwareentwicklung. In einfachen Fällen sind die Ergebnisse brauchbar, bei komplexeren Aufgaben jedoch häufig unzuverlässig. Diese Erfahrung hat mich davon überzeugt, auf unstrukturiertes „Vibe Coding" zu verzichten und stattdessen spezifikationsgetrieben vorzugehen.

## Spec‑Driven Development in der Praxis

Die Grundidee: Nicht Code direkt generieren lassen, sondern zuerst eine präzise Beschreibung dessen erstellen, was die Software leisten soll. Diese Spezifikation dient der KI als Leitplanke für wartbaren, qualitativ hochwertigen Code.

Ein erstes Experiment war eine [Webapplikation](https://codeberg.org/gurix/Reklamator) zur Zusammenfassung und Übersetzung von Benutzerfeedback. Die Resultate waren gut, jedoch erzeugte spec‑kit sehr viele Artefakte und verbrauchte unverhältnismässig viele Tokens. Für meine neue Website setze ich daher auf [OpenSpec](https://openspec.dev/): spürbar leichter, schneller und deutlich effizienter im Token‑Verbrauch.

## „Das grosse Ganze" beschreiben

Ich habe auf der grünen Wiese begonnen, OpenSpec installiert und in einem leeren Projekt initialisiert. Als AI‑Tool nutze ich Claude Code. Direkt im Anschluss beschrieb ich das Projekt in openspec/project.md. Dabei genügte eine grobe Skizze – vieles wurde vom Agenten automatisch sinnvoll strukturiert und korrekt ergänzt.

```markdown
# Project Context
## Purpose
Converting the existing static HTML website at markusgraf.ch 
into a Hugo-based static site...
```

## Vorschläge statt starre Spezifikationen

OpenSpec unterscheidet sich von spec‑kit insofern, als Spezifikationen bewusster offener formuliert werden – eher als Proposal denn als in Stein gemeisselte Vorgabe. In der Umsetzung erwies sich dieser schlankere Plan als leichter anpassbar. Bei spec‑kit ist das schwieriger, weil mehrere Dokumente parallel gepflegt werden müssen.

Aus den spec‑kit‑Erfahrungen habe ich bewusst auf sehr kleine Iterationen gesetzt: Zunächst nur die Initialisierung einer leeren Seite mit dem statischen Generator Hugo. Danach habe ich den Inhalt der bestehenden Seite übernommen, als erste Erweiterung eine Lebenslauf‑Seite ergänzt und anschliessend eine optionale englische Übersetzung eingeführt.

Diese Schritte blieben überschaubar und erforderten keine Änderungen am initialen Plan. Beim Deployment geriet ich jedoch ins Stocken. Ursprünglich wollte ich ein Skript erstellen lassen, das per FTPS auf den Server lädt – naheliegend beim Reseller‑Hosting, aber veraltet und in der Praxis unzuverlässig. Ich wechselte deshalb zu OpenSSH Secure Copy (scp). Schnell zeigte sich: Dateien wurden zwar übertragen, aber nicht sauber gespiegelt. Es drohte Chaos auf dem Server.

Die Lösung war ein Umstieg auf rsync über SSH, um die Zielstruktur exakt zu spiegeln. Proposal, Spezifikationen und Tasks habe ich entsprechend anpassen lassen – danach funktionierte die angepasste Implementation reibungslos. Der Mehrwert kleiner, offen formulierter Proposals wurde hier besonders deutlich: Der Plan kann während der Umsetzung an neue Erkenntnisse angepasst werden.

## Aufräumen und automatisieren

Nach erfolgreichem Rollout archiviere ich die umgesetzten Anpassungen: Artefakte wandern in einen Archivordner mit Zeitstempel, die Spezifikationen als „Single Source of Truth" in openspec/specs/. Damit bleiben aktuelle Spezifikationen klar getrennt von vorgeschlagenen Änderungen in openspec/changes/.

Zum Schluss habe ich Sub‑Agents in Claude Code getestet – ein naheliegender Anwendungsfall ist das Deployment.

```markdown
## Workflow
1. Verify current branch is 'main'
2. Build Hugo site
3. Verify build success
4. Execute scripts/deploy.sh
```

Bei einem entsprechenden Hinweis („Änderungen ausrollen") prüft der Agent automatisch die Voraussetzungen, baut die statischen Seiten und veröffentlicht die Resultate. Fehlt eine Voraussetzung, etwa ein ausstehender Commit, wartet der Agent und setzt anschliessend fort.

## Fazit: Ungewohnt – und gerade deshalb spannend

KI‑unterstützte Entwicklung zwingt zu Struktur: spezifizieren, dokumentieren, prüfen. Dass man am Ende überwiegend Code überprüft statt selbst zu schreiben, ist ungewohnt – aber produktiv. Der Dialog mit dem System fühlt sich an wie Zusammenarbeit im Team: Man diskutiert sinnvolle Implementierungswege, stellt Rückfragen und kommt so zügig zu belastbaren Ergebnissen. Und ganz ehrlich: Es macht einfach auch Spass, sich so ungezwungen mit dem Computer zu unterhalten, als wäre es ein guter Freund.