WordPress-Theme mit einem KI-Coding-Agenten bauen

Kann ein KI-Coding-Agent wirklich ein WordPress-Theme bauen?

Ja, ein KI-Coding-Agent kann ein komplettes WordPress-Theme bauen. Wirklich alles gehört dazu: Templates, Block-Patterns, ein Designsystem in theme.json, eigene PHP-Funktionen. Ich weiß das ganz genau, weil ich es selbst mit Claude Code gemacht habe.

Das fertige Theme lief von März bis Mai 2026 auf meiner Seite. Pagespeed hat dabei 99 bis 100 Punkte gemessen, ganz ohne Elementor oder einen Page-Builder dazwischen.

Diese Antwort überspringt aber den Teil, der eigentlich zählt. Wie kommst du dahin? Ob das gut funktioniert, hängt weniger vom Werkzeug ab. Es hängt vor allem davon ab, wie du das Projekt aufsetzt, bevor du den ersten Prompt tippst.

Überspringst du diesen Schritt, liefert der Agent trotzdem etwas, aber selten das, was du eigentlich wolltest. Meistens ist es etwas, das du in der nächsten Session wieder auseinandernehmen musst.

Hier ist, was ich beim Bau eines kompletten Blockthemes mit einem KI-Coding-Agenten gelernt habe, den ersten gescheiterten Versuch eingeschlossen. Richtig aufgesetzt heißt konkret: eine klare Ordnerstruktur, eine kurze Instruktionsdatei und ein Designsystem, bevor überhaupt ein Template entsteht.

Struktur, bevor du promptest

Bevor du eine einzige Zeile Theme-Code schreibst, leg deine Ordnerstruktur fest. Sonst entscheidest du das später doch noch, nur mitten im Bauen und unter Zeitdruck. Entscheide außerdem, was in die Instruktionsdatei des Agenten kommt, CLAUDE.md bei Claude Code oder das Äquivalent bei deinem Tool.

Ein theme.json-gesteuertes Blocktheme braucht viele Dateien, die zusammenspielen. Dazu zählen Templates, Patterns, die Datei mit den Design-Tokens, functions.php für eigene Logik und CSS obendrauf.

Weiß der Agent vorher nicht, wie diese Teile zusammenhängen, erfindet er seine eigene Struktur. Und spätestens bei der zweiten Datei passt diese Struktur schon nicht mehr. Jede neue Aufgabe bringt dann eine neue Logik mit, weil dem Agenten das Gedächtnis fehlt, das über Sessions hinweg trägt. Am Ende hast du fünf verschiedene Ideen davon, wo ein Pattern liegen soll, und keine davon stimmt mit den anderen vier überein.

Ich halte einen Planungsordner neben dem Theme, nicht darin. So bleiben die Notizen und Pläne des Agenten auch nach dem Launch noch erhalten. Die liest man später noch mal, wenn man vergessen hat, warum eine Entscheidung so gefallen ist. Läge der Ordner im Theme selbst, würde er irgendwann mit ausgeliefert, und genau das will niemand.

Auch die Instruktionsdatei bleibt kurz. Eine CLAUDE.md unter 40 Zeilen, die auf fokussierte Unterdokumente verweist, funktioniert besser als eine Datei, die jede Namenskonvention und jede Designentscheidung auf einmal tragen soll. Der Agent liest diese Datei vor jeder Aufgabe.

Wer sie vollstopft, zahlt für Kontext, der mit der eigentlichen Aufgabe nichts zu tun hat. Der Agent verliert dann genau die Regeln aus dem Blick, die gerade relevant wären. Warum eine überladene Instruktionsdatei nach hinten losgeht, hab ich in Context Engineering: Herausforderungen und Tipps genauer beschrieben.

Das Designsystem zuerst: theme.json und Tokens

Bevor der Agent auch nur ein Template anfasst, gehört das Designsystem in theme.json. Das ist die Datei, in der ein Blocktheme Farben, Schriftgrößen, Abstände und Schatten an einer Stelle hält.

Läuft jeder Wert über diese Datei, reicht eine einzige Änderung am Token. Die Änderung wirkt dann überall dort, wo der Token verwendet wird. Sonst jagst du denselben Wert später in einem Dutzend Dateien einzeln, jedes Mal mit dem Risiko, eine Stelle zu übersehen.

Gib dem Agenten eine Designrichtung, bevor er theme.json anfasst. Ein paar Referenzbilder reichen, ein paar Adjektive, was auch immer den Punkt trifft. Bei mir war das „Retro-70er, dunkle Flächen, Akzentfarben“, dazu hochgeladene Screenshots.

Ein Mockup gab es nicht, und auch keine bestehende Seite zum Abkupfern. Der Agent braucht trotzdem einen Ausgangspunkt. Ganz ohne Richtung erfindet er seine eigene, und die passt selten zum Rest der Seite.

Token-Werte, die er sich selbst ausdenkt, landen sonst meistens generisch. Sie liegen irgendwo zwischen Standard-Blau und Standard-Grau.

Prüf das Ergebnis nach jeder Token-Änderung im Browser, nicht erst, wenn das ganze System steht. Nur so lässt sich jeder Schritt tatsächlich nachprüfen. Diese Angewohnheit zieht sich durch jeden Abschnitt, der noch kommt.

Templates und Patterns, eins nach dem anderen

Sind die Tokens gesetzt, baust du ein Template nach dem anderen: Startseite, Blog-Übersicht, einzelner Beitrag. Dazu kommen alle weiteren Inhaltstypen, die deine Seite sonst noch braucht.

Ein Pattern, das im Blog auftaucht, taucht oft auch auf der Startseite auf. Bleibt es an einer zentralen Stelle gepflegt, ändert sich sein Aussehen überall gleichzeitig, sobald du es einmal anpasst.

Blockthemes gliedern das in Templates und wiederverwendbare Patterns. Wer diese Trennung auch in seinen Prompts durchhält, hält jeden Schritt klein genug, um ihn wirklich zu prüfen. Sonst bekommst du am Ende ein Konvolut aus Änderungen, das sich nicht mehr zurückverfolgen lässt.

Ich hab in drei Wochen Bauzeit kein einziges Mal nach einer kompletten Seite in einem Prompt gefragt. Stattdessen prüfte ich einen Block im Browser, dann den nächsten. Hängen zwei Templates nicht voneinander ab, lässt ein fähiger Agent beide gleichzeitig laufen, mehrere kleine Aufgaben parallel statt einer großen. Jede davon bleibt so überschaubar genug, um sie in wenigen Minuten gegenzulesen.

Dieselbe Disziplin in kleinen Schritten steckt hinter den Prompting-Grundlagen, die ich für jede Agenten-Aufgabe nutze, nicht nur für WordPress. Ein großer Prompt ist selten schneller als drei kleine, er ist nur schwerer zu prüfen. Und genau das Prüfen ist die Arbeit, die eigentlich bei dir bleibt.

Die Gutenberg-Blocksyntax dem Agenten überlassen

Gutenberg-Blockmarkup hat eine eigene Syntax. Dazu gehören wp:group-Blöcke, Spacing-Presets und verschachtelte Block-Kommentare, die exakt passen müssen. Passt ein Kommentar nicht, wirft der Editor einen Fehler, manchmal ohne verständliche Meldung dazu.

Die Syntax musst du dafür trotzdem nicht vorher lernen. Das erspart dir die Einarbeitung in ein Format, das sich ohnehin regelmäßig weiterentwickelt.

Ich hab einfach beschrieben, was ich auf der Seite sehen wollte. Claude Code kannte die Spezifikation und hat Blockmarkup geschrieben, das genau dazu passte. Was ich beisteuern musste, war Klarheit über das Ergebnis, nicht die Syntax dahinter und auch nicht das Wissen, welches Attribut welchen Namen trägt.

Du tauschst Syntax-Schreiben gegen Ergebnis-Prüfung. Deshalb muss die Prüfung schärfer sein als bei Code, den du selbst getippt hast. Sieh dir den Block im Editor und im Frontend an.

Ein Block, der an einer Stelle richtig aussieht, kann sich an der anderen trotzdem falsch verhalten, weil der Editor eigene Stile lädt und die Live-Seite andere. Bei fremdem Markup, dem ich noch nicht traue, prüf ich das Ergebnis vorher gern isoliert. Dafür nutze ich zum Beispiel eine reine HTML-Vorschau ohne eigenes Projekt drumherum, bevor überhaupt etwas in das echte Theme wandert.

Wo es kippt

Der Fehler passiert, wenn du zu prompten anfängst, bevor die Basics stehen, wie das Projekt organisiert ist und wie viel die Instruktionsdatei zu tragen versucht. Fehlt dieses Fundament, liefert der Agent einen Haufen Dateien, die nichts miteinander zu tun haben, auch wenn jede einzelne für sich funktioniert.

Ich weiß das, weil es mir genau so passiert ist. Mein erster Versuch ist genau daran gescheitert. Ich hatte eine Struktur aus einem YouTube-Video übernommen, eine 400 Zeilen lange Instruktionsdatei ins Repo geworfen und angefangen zu tippen, ohne Designrichtung außer „soll gut aussehen“.

Der Agent hat dauernd Teile geliefert, die nicht zusammenpassten: falsche Farben, unpassende Abstände. Die Namen für dieselbe Sache wechselten dazu von Session zu Session, ohne dass eine davon wirklich falsch war.

Die Lösung waren weniger, aber bessere Instruktionen: eine Datei unter 40 Zeilen, dazu eine Ordnerstruktur, die schon vor der ersten Zeile Code feststand. Derselbe Agent hat danach an derselben Aufgabe über mehrere Sessions hinweg konsistent gearbeitet. Nichts an der Technik hatte sich geändert, nur die Vorbereitung davor.

Die fehlende Struktur hat mich den kompletten ersten Versuch gekostet. Richtig aufgesetzt, mit fester Ordnerstruktur und kurzer Instruktionsdatei, brauchte dagegen nur einen Nachmittag. Der eigentliche Bau des Themes zog sich danach über die restlichen drei Wochen des zweiten Anlaufs.

Skills sind die Ebene, die einen Agenten davon abhält, denselben Fehler über Sessions hinweg zu wiederholen. Sind sie dir noch neu, deckt mein Erfahrungsbericht zu Claude Code Skills ab, was sich bei mir dadurch geändert hat.

Der Beweis: was dabei tatsächlich entstanden ist

Die Version oben hab ich mit Claude Code gebaut, auf WordPress, PHP, Gutenberg und theme.json. Ich hab das allein gemacht, in rund drei Wochen, im zweiten, diesmal strukturierten Anlauf.

Fertig war ein Designsystem, komplett über theme.json gesteuert. Dazu kamen Templates und Patterns für jeden Inhaltstyp der Seite: für die Startseite, den Blog und einzelne Beiträge, für die Foto-Galerie und für das Glossar mit alphabetischer Navigation. Tool-Seiten und Use Cases bekamen eigene Templates ebenso. Im Theme steckten außerdem sieben interaktive Tools sowie eigene Post-Types mit strukturierten Daten und Sitemap-Steuerung über functions.php.

Das Theme hat eric-hinzpeter.de von März bis Mai 2026 betrieben, unabhängig von Elementor, mit einem Pagespeed-Wert von 99 bis 100. Inzwischen ist es durch die Next.js-Seite ersetzt, die du gerade liest, ebenfalls mit Claude Code gebaut.

Die Gründe dafür hatten nichts mit der Performance des Themes zu tun, sondern mit dem, was auf der Seite alles noch dazukommen sollte.

Richtest du Claude Code gerade zum ersten Mal ein, deckt mein Einstiegsguide Installation und das CLAUDE.md-Problem ausführlicher ab, als hier Platz war.