Was wird hier gebaut?
Diese Website ist eine statische Website aus HTML (Seitenstruktur), CSS (Gestaltung) und JavaScript (Verhalten) ohne Baukasten und ohne Framework. Am 8. November 2026 bestand sie aus 131 HTML-Dateien, die Sitemap führte 126 Adressen. Ausgeliefert wird sie über Vercel; jede Änderung landet zuerst auf einem eigenen Zweig im Versionsverwaltungssystem Git und wird erst nach meiner Freigabe veröffentlicht.
Ich bin kein Entwickler. Den Code schreibt Claude Code, ein Werkzeug von Anthropic, das Dateien liest, ändert und Befehle ausführt. Meine Rolle ist die eines Auftraggebers: Ich lege fest, was passieren soll, woran wir erkennen, dass es geklappt hat, und gebe frei oder lehne ab.
Wie läuft eine Änderung ab?
- Plan: Jede größere Runde beginnt mit einem schriftlichen Plan. Jede Maßnahme hat einen Befund, eine Änderung und ein Abnahmekriterium, das sich als Befehl prüfen lässt.
- Zweig je Welle: Die Maßnahmen sind in Wellen gebündelt. Jede Welle bekommt einen eigenen Zweig, jede Maßnahme einen eigenen Commit. Im November liefen so die Wellen 1 bis 4.
- Prüfen nach jeder Maßnahme: Claude Code führt das Abnahmekriterium als Befehl aus und schreibt Befehl und Ausgabe in ein Log.
- Gesamtprüfung nach jeder Welle: Erst wenn beide automatischen Prüfungen fehlerfrei sind, startet die nächste Welle.
- Abweichungen offenlegen: Wo der Plan nicht passt, steht das mit Begründung im Log, statt still anders umgesetzt zu werden.
- Freigabe: Ich lese das Log und die Vorschau, entscheide offene Fragen und gebe den Merge frei. Danach folgt eine Prüfung auf der Live-Seite.
Welche Prüfungen laufen automatisch?
Der Validator (npm run check) prüft jede HTML-Datei: genau eine Hauptüberschrift, keine doppelten Kennungen (IDs), funktionierende interne Links und Sprungmarken, gültige strukturierte Daten, passende Datumsangaben und eine vollständige Sitemap. Seit dem 11. November 2026 prüft er zusätzlich, ob sichtbare häufige Fragen und ihre strukturierten Daten wortgleich sind, und ob jeder Preis neben einem Formatnamen mit einem zentralen Faktenregister übereinstimmt.
Der Browser-Audit (npm run test:browser) öffnet jede Seite in mehreren Bildschirmbreiten und sucht nach Überläufen, Bildfehlern, JavaScript-Fehlern und Barrieren. Am 8. November 2026 meldete er 786 Viewport-Prüfungen ohne einen einzigen Befund.
Nach dem Livegang kommen Messungen auf der echten Website dazu, etwa Lighthouse. Am 8. November 2026 lag die Startseite mobil bei Performance 99.
Welche Fehler sind passiert und wie wurden sie gefunden?
Drei Fehler aus dem Log der Novemberwellen, weil sie zeigen, wofür die Prüfungen da sind und wo sie nicht reichen.
Ein Bereinigungsskript hat die CSS-Datei beschädigt
Beim Entfernen ungenutzter CSS-Regeln hat ein Skript überlappende Stellen geschnitten und einen kaputten Kommentar in der Stildatei hinterlassen. Der Validator hat das nicht gemeldet, weil er HTML prüft, nicht CSS. Aufgefallen ist es beim Durchsehen der Änderungen vor dem Commit. Die Änderung wurde verworfen und korrigiert neu ausgeführt.
Ein neuer Absatz hat das Layout der Startseite gebrochen
Ein zusätzlicher Satz im oberen Bereich der Startseite, direkt eingefügt, hat das Desktop-Layout zerschossen: Der erste Button rutschte auf 6.534 Pixel nach unten. Ein umschließender Container hat das behoben. Seitdem misst die Abnahme die Position des ersten Buttons bei 390 und 1440 Pixeln Breite.
Eine Prüfung, die es gar nicht gab
Die Projektbeschreibung behauptete, der Validator vergleiche die sichtbaren häufigen Fragen mit den strukturierten Daten. Eine Suche im Code ergab: Diese Prüfung existierte nicht. Bis dahin hatte nur ein eigenes Prüfskript während der Umsetzung den Abgleich gemacht. Am 11. November 2026 kam die Prüfung tatsächlich in den Validator.
Was kannst du davon übernehmen?
- Schreib das Abnahmekriterium vor die Änderung. „Sieht gut aus“ ist keine Abnahme, ein Befehl mit erwarteter Ausgabe schon.
- Lass protokollieren, nicht zusammenfassen. Ein Log mit Befehl und Ausgabe lässt sich prüfen, eine Erfolgsmeldung nicht.
- Automatische Prüfungen haben blinde Flecken. Der CSS-Fehler zeigt: Ein Mensch schaut trotzdem auf die Änderungen.
- Behauptungen in der Dokumentation gegen den Code prüfen. Die fehlende Prüfung stand lesbar in der Projektbeschreibung, ohne dass es sie gab.
Die Vorlagen, mit denen du ein eigenes Projekt so aufsetzt, stehen im Claude-Code-Guide. Ob das ohne Programmierkenntnisse geht, beantwortet Claude Code ohne Programmieren. Wenn ihr das im Unternehmen einführen wollt: Claude Code im Unternehmen einführen.
Worauf stützt sich dieser Bericht?
Alle Zahlen und Fehler stammen aus den internen Umsetzungs-Logs der Optimierungswellen vom 8. und 11. November 2026 und aus den Prüfausgaben im Projekt. Kundendaten enthält der Bericht nicht.
Häufige Fragen
Braucht man Programmierkenntnisse, um so zu arbeiten?
Für diese Arbeitsweise nicht im engeren Sinn, aber man muss Abnahmekriterien formulieren und Prüfausgaben lesen können. Den Code schreibt Claude Code, die Entscheidung über Freigaben bleibt beim Menschen.
Prüft Claude Code seine Arbeit selbst?
Es führt die festgelegten Prüfungen aus und schreibt die Ergebnisse ins Log. Ob die Prüfungen ausreichen und ob eine Änderung live geht, entscheidet ein Mensch.
Kann ich die Vorlagen für mein eigenes Projekt nutzen?
Ja. Die Vorlagen für Projektgedächtnis, Berechtigungen, Werkzeuganbindung, Skills, Hooks und Subagents stehen im Claude-Code-Guide zum Kopieren und als Download.
Ich begleite Geschäftsführungen und Teams dabei, KI vom Einzelexperiment in einen belastbaren Betrieb zu überführen. Schwerpunkt: Prozesse zuerst, Werkzeuge danach. Praxis aus Industrie, Tourismus, Veranstaltungen und weiteren Unternehmensbereichen.