Claude: Kann ich damit mal schnell eine Blog-Sektion integrieren?

KI in der Praxis
Marina Brooks 7 Min. Lesezeit

Eine Grafikerin aus dem Marketing baut mit Claude Code einen Blogbereich in eine bestehende Hugo-Website. Was gut lief, was Zeit gekostet hat – und warum nicht jede Abweichung repariert werden muss.

Ich wollte für eine unserer Websites eigentlich nur eine kleine Erweiterung und zwar einen Blogbereich. Kein riesiges Feature, kein komplexes Tool, sondern einfach einen „normalen" Blog. Vermeintlich einfacher sollte das Ganze vor allem dadurch sein, dass wir auf unserer anderen Website bereits diesen Bereich integriert haben und wir diesen einfach 1:1 übernehmen wollten.

Und genau bei solchen Aufgaben dachte ich mir: Das müsste doch mittlerweile mit Claude Code ziemlich schnell gehen. Quasi Copy Paste, bisschen CSS anpassen und fertig.

Spoiler: Ja. Aber ganz so einfach ist es dann auch nicht. Zumindest nicht beim ersten Mal.

Zwei Perspektiven auf dieselbe Website

Bei mir kommt dabei noch eine Besonderheit dazu: Ich schaue auf eine Website eigentlich immer aus zwei ziemlich unterschiedlichen Perspektiven.

Ich bin Grafikerin und habe entsprechend einen sehr starken visuellen Zugang zu Websites. Ich sehe Layout, Abstände, Typografie, Hierarchie, Komponenten und natürlich sofort, wenn etwas nicht so aussieht, wie es aussehen sollte. Gleichzeitig arbeite ich bei Infralovers im Marketing und Sales und damit interessiert mich eine Website nicht nur als Gestaltung, sondern auch als Werkzeug:

  • Funktioniert sie für die User?
  • Kann ich Inhalte einfach erweitern?
  • Unterstützt sie unsere Kommunikation?
  • Können wir neue Inhalte schnell online bringen?
  • Und wie viel Aufwand steckt eigentlich hinter einer kleinen Änderung?

Das führt bei AI-generierten Änderungen manchmal zu zwei ziemlich unterschiedlichen Reaktionen.

Als Grafikerin bin ich schnell bei: Ist irgendwie ok, aber das würde ich persönlich anders lösen.

Als Marketingperson denke ich eher: Funktioniert, war schnell, passt solange wir damit arbeiten können und die Inhalte stimmen.

Und genau diese beiden Perspektiven haben mich bei unserem ersten kleinen Claude-Code-Experiment ziemlich beschäftigt.

Das kleine Problem mit „unserer Website"

Besagte Website läuft nicht über WordPress, Typo3, Drupal oder ein anderes CMS, mit dem ich bereits zig Mal gearbeitet habe, sondern sie läuft mit Hugo und einem Git-Repository.

Für jemanden, der täglich damit arbeitet, ist das wahrscheinlich völlig normal.

Für mich bedeutet es eher: unübersichtliche Text- und Code-Reihen in Ordnern mit nur teilweise nachvollziehbaren Namen. Da etwas zu finden ist nicht immer einfach, vor allem wenn es nicht um Routine-Erweiterungen geht wie beispielsweise einfach einen Text ändern.

Ich kann mit Basic HTML und CSS, Design- und Figma-Files umgehen, aber Hugo und Git sind für mich nicht dieselbe Spielwiese wie WordPress, wo ich weiß, wo ich klicken muss.

Also brauchte ich zunächst Hilfe von jemandem, der sich damit auskennt. Und das war tatsächlich der wichtigste Schritt.

Erst das Setup. Dann Claude Code.

Bevor Claude Code überhaupt sinnvoll loslegen konnte, musste erst einmal für Claude geklärt werden, wie unsere Website aufgebaut ist und wo der Blog überhaupt hineingehört und wie wir ihn gerne hätten.

Das ist wahrscheinlich der Teil, den man bei vielen AI-Coding-Erfolgsgeschichten nicht sieht.

Man hört sonst gerne mal: „Ich habe Claude Code gesagt, was ich wollte, und 10 Minuten später war alles fertig und ganz toll."

Bei einer bestehenden Website und einer konkreten CI ist es eben nicht ganz so einfach, denn Claude Code muss nicht nur wissen, was Sie bauen möchten, sondern muss auch verstehen, wo und wie es in die bestehende Struktur passt.

Und genau hier hatte ich als Nicht-Entwicklerin zunächst einen ziemlich großen Aufwand, der alleine vermutlich noch länger gedauert hätte und evtl. am Ende nicht korrekt gewesen wäre. Achtung, hier wird's kurz trocken, und ich lasse kurz Claude selbst erklären, was wir gemacht haben:

„Am Anfang stand eine Maschine, auf der buchstäblich nichts vorbereitet war: kein SSH-Schlüssel, kein GitHub-CLI, kein Hugo. Der erste Schritt war deshalb kein Code, sondern ein Schlüsselpaar, eine ~/.ssh/config und zwei Klone nebeneinander – dieses Projekt und die Hauptwebsite als Vorlage, aus der wir Layouts übernehmen wollten. Hugo kam erst später dazu, und genau das war der lehrreiche Teil: Solange nicht lokal gebaut werden konnte, ersetzte ein sorgfältiger Review den Compiler. Er fand neun echte Defekte – aber nicht den entscheidenden. Der zeigte sich in dem Moment, in dem der erste Build tatsächlich lief: Beim Umbau war ein Attribut von den Blog-Karten verloren gegangen, wodurch ein Klick auf einen Kategoriefilter nicht gefiltert, sondern sämtliche Beiträge ausgeblendet hätte. Sekunden nach dem ersten hugo --gc --minify war klar, was vorher niemand gesehen hatte. Bis heute fehlt auf derselben Maschine Node, weshalb die visuellen Regressionstests weiter offen sind – dieselbe Lücke, nur eine Ebene höher. Die Lehre daraus ist unspektakulär und gilt für jedes Projekt: Die wichtigste Setup-Aufgabe ist nicht der Zugang zum Repository, sondern die Möglichkeit, das Ergebnis lokal zu sehen."

Der Auftrag: Bestehenden Blog von Website Nr. 2 übernehmen

Wir haben bereits auf unserer anderen Website einen Blog. Also warum alles neu bauen?

Die Idee war simpel: Das bestehende Blog-Konzept und Layout übernehmen und für die neue Seite adaptieren. Claude Code bekam also im Wesentlichen die Aufgabe, den vorhandenen Blog in die neue Website-Struktur zu übertragen.

Und erstaunlicherweise hat das für so eine kleine Aufgabe ziemlich gut funktioniert.

Und hier kam meine Grafikerinnen-Seite ins Spiel. Denn „funktioniert" und „gefällt mir" sind zwei unterschiedliche Dinge.

Ich schaue bei so einem Ergebnis natürlich sofort darauf, ob das Layout wirklich sauber in die bestehende Website passt. In diesem Fall war ich mit dem Ergebnis grundsätzlich zufrieden. Nicht unbedingt im Sinne von es ist perfekt, aber nah genug dran, dass ich damit arbeiten kann.

Und dann kamen die Filter. Natürlich, irgendwas musste da ja doch noch sein …

Die Blogfilter haben nämlich nicht wirklich so ausgesehen, wie sie am Beispiel waren. Der Aufbau unseres bestehenden Blogs wurde zwar weitgehend übernommen, aber gerade bei der Filterlogik war das Ergebnis nicht wirklich brauchbar.

Aus Entwicklerperspektive könnte man jetzt wahrscheinlich sagen: Dann muss man das eben reparieren.

Aus Marketingperspektive habe ich mich aber gefragt: Brauchen wir das überhaupt?

Unsere neue Seite hat deutlich weniger Themenbereiche als die andere Website, außerdem haben wir hier nicht das Problem, dass jemand durch zehn Jahre Bloggeschichte navigieren muss und unbedingt Beiträge zu einem bestimmten Thema finden möchte.

Also habe ich entschieden: Es ist gut genug, denn es funktioniert und tut, was es soll.

Und genau das finde ich bei solchen AI-Projekten eigentlich ziemlich wichtig. Nicht jede Abweichung vom ursprünglichen System muss repariert werden. Wenn eine Funktion für den konkreten Anwendungsfall keinen wirklichen Mehrwert bringt, kann man sie auch einfach weglassen.

Auch hier waren meine beiden Perspektiven wieder unterschiedlich. Als Grafikerin stört mich eine nicht idente Komponente natürlich. Als Marketing-Verantwortliche kann ich aber viel leichter sagen: Für unsere aktuelle Website ist das kein relevantes Problem.

Das ist vielleicht eine der spannendsten Fragen beim Einsatz von AI für solche Aufgaben: Muss das Ergebnis technisch perfekt sein, oder muss es für den konkreten Zweck gut genug sein?

Das Fazit: Für Kleinkram funktioniert es ziemlich gut

Wenn man die erste Setup-Phase herausrechnet, die einiges an Zeit gekostet hat, war die eigentliche Umsetzung ziemlich flott.

Für mich als Grafikerin ist dabei vor allem spannend, dass ich nicht jede technische Änderung selbst verstehen muss, um das Ergebnis beurteilen zu können. Ich kann sehr genau sagen, wie es aussehen und sich anfühlen soll. Aus Marketing-Sicht kann ich gleichzeitig beurteilen, ob es für den tatsächlichen Zweck funktioniert. Claude Code übernimmt da einen Teil der Übersetzungsarbeit zwischen diesen Anforderungen und dem Code. Das bedeutet nicht, dass ich jetzt plötzlich zur Hugo-Entwicklerin geworden bin. Ich weiß immer noch nicht, welche Dateien ich eigentlich anfassen müsste.

Aber ich kann wesentlich besser mit dem System arbeiten und vor allem kann ich kleine Änderungen selbst durchführen, testen und beurteilen, ohne für jede Kleinigkeit einen kompletten Entwicklungsprozess daraus machen zu müssen.

Das Ergebnis

Der neue Blog ist inzwischen online und für diese erste kleine Erweiterung lautet mein persönliches Fazit deshalb: Für eine kleine Erweiterung ist das Ergebnis ziemlich gut und wenn das Grundsetup einmal gemacht ist, wird es schnell.

Als Nächstes geht es nicht mehr darum, einen bestehenden Seitentyp zu übernehmen, sondern wir wollten einen komplett neuen Seitentyp anhand einer extern bereitgestellten Website-Vorlage erstellen und uns nur rein inhaltlich daran orientieren, aber an unser eigenes Design, unsere Struktur und unser Wording anpassen.

Und da wird es für mich als Grafikerin und Marketingperson noch einmal deutlich spannender.

Fortsetzung folgt.

Zurück

Pipedrive-Wissen für Ihren Vertrieb

Einmal im Monat: konkrete Kniffe zu Pipedrive, Automatisierung und Vertriebsprozessen. Aus laufenden Kundenprojekten, ohne Werbefloskeln. Abmeldung jederzeit mit einem Klick.