Diese Website neu aufbauen – mit Claude als Copilot

Dieser Blog läuft auf einer Next.js (opens in a new window)-Vorlage, die ich seit 2024 nutze. Sie hat einwandfrei funktioniert. Ich konnte Beiträge schreiben und auf „Publish“ klicken.

Dann begann sie, wie die meisten Vorlagen, technische Schulden anzuhäufen: die Art, die erst auffällt, wenn GitHub (opens in a new window) dir Sicherheitswarnungen schickt und Dependabot Dutzende Pull Requests öffnet, für die du keine Zeit hast.

Heute Abend habe ich mich hingesetzt, um ein oder zwei davon zu beheben. Einige Stunden später hatte ich, mit Claude (opens in a new window) als Wegweiser und Copilot, den Großteil des Innenlebens der Vorlage ersetzt und aktualisiert.

Hier eine Zusammenfassung dessen, was wir gemeinsam erreicht haben, und warum manches davon nützlich sein könnte für alle, die einen Tech-Stack pflegen, den sie nicht selbst zusammengestellt haben.

Eine Vorlage ist ein Ausgangspunkt

Eine Startvorlage ist ein großzügiges Geschenk von jemandem, der etwas Nützliches gebaut und es verschenkt hat. Der Code funktionierte in dem Moment, in dem er veröffentlicht wurde. Aber die Autoren der Vorlage sind nicht verpflichtet, ihn weiter zu pflegen.

Mit der Zeit entwickelt sich das Framework weiter. React entwickelt sich weiter. Sicherheitshinweise erscheinen, aber die Patches kommen in der Vorlage nie an. Die Korrekturen sind für jemanden, der weiß, was er tut, nicht schwer umzusetzen … aber dieser Jemand war nicht ich.

Die Vorlage, die ich nutze, heißt Next.js Blog with Draft Mode (opens in a new window). Sie erschien erstmals im April 2020 und ist ein statischer Blog mit Preview Mode, gebaut für Next.js und Contentful (opens in a new window). Weil sich der zugrunde liegende Tech-Stack ständig weiterentwickelte, war ein Update der Vorlage längst überfällig.

Seit heute Abend nutzt die Vorlage Next.js 16 mit App Router, asynchrone dynamische APIs, die aktuelle React-Version und dazu schicke Optimierungen wie einen RSS-Feed und eine Sitemap.

Wie die Zusammenarbeit tatsächlich lief

Ich will hier genau sein, denn „Ich habe KI benutzt“ kann vieles bedeuten. Ich bin kein Entwickler. Ich kann Code gut genug lesen, um zu verstehen, was er tut, und ich kann eine Datei bearbeiten, wenn mir jemand sagt, welche Zeilen ich ändern soll.

Mein Ansatz war, in Claude ein eigenes „Projekt“ speziell für die Aktualisierung dieses Blogs anzulegen. So konnte es sich an unsere Chats erinnern und Kontext und Vorgeschichte mitnehmen.

Noch besser: Dank einer GitHub-Integration konnte Claude den Code im Repo direkt synchronisieren und prüfen. Das ist eine Stufe „leichter“ als Claude Code (opens in a new window), und zwar mit Absicht. Ich wollte das Bindeglied sein und die Änderungen mitverfolgen.

Das Schöne daran? Claude gruppierte die vorgeschlagenen Upgrades nach Dringlichkeit und Aufwand.

Die Arbeitsteilung sah also so aus: Ich traf die redaktionellen Entscheidungen und committete die Änderungen ins Repo. Claude diagnostizierte Probleme, schrieb den Code, sagte voraus, was kaputtgehen würde, und führte mich durch die Fehler, wenn die Vorhersagen danebenlagen (was ein paarmal passierte).

Wenn ich Fehlerprotokolle einfügte, sagte mir Claude, welche Datei ich bearbeiten und was ich ändern sollte. Führte ein Update zu einem fehlgeschlagenen Deployment, prüfte es den aktuellen Stand der Datei, statt zu raten.

Das ist der Unterschied zwischen einem hilfreichen Mitstreiter und einem selbstsicheren Wichtigtuer (ob künstlich oder nicht), der deine Zeit verschwendet.

Der Sicherheitscheck war einfacher, als die Zahl der Warnungen vermuten ließ

GitHub zeigte 36 Sicherheitslücken an. Zwei kritisch. Neunzehn hoch. Das sieht schlimm aus, bis man sie danach sortiert, wo sie tatsächlich stecken.

Rund zwanzig davon stammten aus einer einzigen Abhängigkeit, die in der Produktion gar nichts zu suchen hatte – ein CLI-Tool, das die Vorlage der Bequemlichkeit halber als Laufzeit-Abhängigkeit für die lokale Entwicklung eingetragen hatte. Nichts davon landet in der Produktion. Es zu entfernen, beseitigte die meisten Warnungen mit einem einzigen Commit.

Weitere sieben betrafen indirekte Build-Werkzeuge, die beim Build laufen, nicht bei jedem Seitenaufruf. Sie sind wichtig für eine saubere Lieferkette, aber nicht für „Jemand kann meinen Blog hacken“. Eine saubere Neuinstallation mit gepatchten Versionen hat sie erledigt.

Die übrigen paar waren echt: eine veraltete Framework-Version, der ein Jahr an Sicherheitspatches fehlte. Das waren die Stellen, auf die es wirklich ankam, und sie waren schnell behoben.

Bei der Datenschicht war am meisten Luft nach oben

Jetzt wird es lustig. Die Vorlage holte die Beiträge bei jedem Seitenaufruf mit zwei nacheinander ausgeführten GraphQL-Abfragen aus Contentful. Ohne Caching. Beide Abfragen lieferten den vollständigen Beitragstext, auch wenn die Komponente nur Titel und Teaser brauchte.

Nichts davon war kaputt – Seiten wurden angezeigt, Beiträge erschienen –, aber jeder Besuch zog mehr Daten, als die Seite tatsächlich nutzte.

Drei kleine Änderungen (parallele Abfragen, ein einstündiger Cache mit Revalidierung über Tags, getrennte Feldsätze für vollständige Beiträge und Vorschaukarten), und die Datenschicht lief rund. Die Website wurde schneller, und die Contentful-APIs wurden deutlich seltener angefragt.

Das Besondere: Claude hat das von sich aus angesprochen. Ich hatte mich über die Speed-Insights-Werte beschwert und erwartet, dass man mich auf zu große Bilddateien hinweist. Claude zeigte stattdessen auf die Datenschicht, und das erwies sich als grundlegend wichtiger.

Bilder mit Komprimierung und sinnvollen Größen

Also gut. Bilder. Die ursprüngliche Vorlage lud auf jedem Gerät übergroße Titelbilder – auf Smartphones, Tablets und Desktops gleichermaßen –, weil jedem <Image> das sizes-Attribut fehlte, das dem Browser sagt, wie das Bild tatsächlich angezeigt wird.

Ohne diesen Hinweis nehmen Browser an, dass das Bild in voller Fensterbreite angezeigt wird, und wählen die größte verfügbare Version.

Die Lösung war eine Kombination: Contentfuls Bild-API nach WebP statt JPEG fragen, jedem Titelbild ein sizes-Attribut geben, damit der Browser den tatsächlichen Anzeigekontext kennt, und die größte verfügbare Größe in der Konfiguration der Vorlage begrenzen.

Unterm Strich laden die Seiten für die Leser schneller und verbrauchen dabei weniger Bandbreite. Schön.

Bilder im Beitragstext waren kaputt

Darüber habe ich mich am meisten gefreut. Das Aufmacherbild der Vorlage wurde problemlos angezeigt. Aber wenn ich ein Bild in einen Beitrag einbetten wollte – einen Screenshot, eine Abbildung, ein Diagramm –, scheiterte der Renderer stillschweigend.

Contentful lieferte das Bild korrekt aus. Die React-Komponente, die es anzeigen sollte, verwendete jedoch eine Eigenschaft, die schon vor einiger Zeit als veraltet markiert worden war. Das Ergebnis: leerer Raum, wo meine Bilder hätten sein sollen.

Und jetzt? Zwanzig Zeilen neuer Code im Rich-Text-Renderer, und ich kann Bilder ordentlich in Beiträge einbetten. Dabei dient das Beschreibungsfeld des Assets in Contentful automatisch als Bildunterschrift.

Hätte ich mir das nur früher angesehen. Lange dachte ich, die Funktion sei einfach nie eingebaut worden. Dass sie kaputt war, wusste ich gar nicht.

Das muss man Claude lassen: Das kam zur Sprache, weil ich beschrieben habe, was mir als Autor fehlte, nicht als technische Beschwerde – und Claude erkannte die Ursache als Fehler im Renderer statt als Grenze des Inhaltsmodells. Allein hätte ich lange gebraucht, um diesen Unterschied zu erkennen.

Wie „fertig“ aussieht

Am Ende des Abends hatte ich:

• ein aktualisiertes Framework

• aktuelles React

• gepatchte Abhängigkeiten

• einen selbst gehosteten Entwurfsmodus

• eine ordentlich gecachte Datenschicht

• eine responsive Bild-Pipeline

• SEO-Metadaten pro Beitrag mit Unterstützung für Open Graph und Twitter Cards

• Sitemap, robots.txt und RSS-Feed

• strukturierte Daten für Suchmaschinen

• ein eigenes Favicon und Apple-Icon

• eine einzige kanonische Domain

• funktionierende Bilder im Beitragstext

• externe Links, die sich wie üblich in einem neuen Tab öffnen

• und eine Dependabot-Konfiguration, die das Repo aktuell halten soll

Und das ist erst der Anfang. Seitdem kritzle ich fleißig in ein Notizbuch, welche Verbesserungen ich als Nächstes umsetzen möchte.

Was ich gelernt habe

Vorlagen sind Ausgangspunkte. Es ist ein Fehler, sie als fertige Produkte zu behandeln. Wer einen Blog auf dem Code anderer betreibt, sollte sich auf den Tag einstellen, an dem er selbst die Verantwortung dafür übernehmen muss.

Die gute Nachricht: Mit einer fähigen KI an der Seite ist diese Übernahme deutlich weniger schwierig, weil sie für Nicht-Techniker die Lücke zwischen „Das ist kaputt“ und „So reparierst du es“ schließt.

Ich habe trotzdem jede Entscheidung selbst getroffen. Ich habe trotzdem jeden Commit verantwortet. Aber was mich früher Stunden der Suche in Dokumentationen und des Ausprobierens gekostet hätte, ist jetzt eine Sache von ein paar Minuten Unterhaltung.

Das verschiebt spürbar, was eine einzelne Person mit begrenzten Mitteln erreichen kann. Und für mich ist es ein Zeichen, dass persönliche Websites ehrgeiziger werden, nicht bescheidener, je besser KI-Werkzeuge werden.

Danke fürs Lesen.

Editorial illustration, low-angle view of a plumber crouched forward on the kitchen floor, his back to the camera, reaching into the dark cabinet beneath a kitchen sink. The worn leather soles of his work boots are visible in the foreground as he crouches, denim overalls and a rolled-sleeve plaid shirt stretched across his back. His head and shoulders disappear into the shadowed cabinet, face unseen. A small puddle of water has spread from beneath the cabinet onto the patterned linoleum floor near his boots, catching a glint of light. A heavy pipe wrench and open toolbox rest on the floor beside him, with smaller fittings scattered nearby. Modest mid-century American kitchen, retro cabinetry, lived-in domestic atmosphere. Warm directional light from the right, deep painterly shadows, gouache illustration with visible brushwork, muted earth-tone palette, mid-century American editorial style.