Kontakt
info@ai-trainer.ch
Ich habe mir gerade ein eigenes WordPress-Plugin gebaut. Kein Baukastensystem, kein Drittanbieter, kein monatliches Abo. Einfach: eine Beschreibung an Claude, ein bisschen hin und her, fertig. Das Plugin schaltet meiner Website eine Coming-Soon-Seite vor – mit meinem Design, meiner Logik, meinen Regeln.
Dauert hat es ungefähr zwanzig Minuten.
Was ich dabei gelernt habe – über den Nutzen, die Risiken, die richtigen Prompts und die ehrlichen Grenzen dieser Methode – das schreibe ich hier auf. Nicht als Hype, sondern als Erfahrungsbericht aus der Praxis.
Was ist Vibe Coding überhaupt?
Der Begriff stammt von Andrej Karpathy und beschreibt eine Arbeitsweise, bei der man mit einem KI-Modell Code schreibt, ohne selbst zwingend jede Zeile zu verstehen. Man beschreibt das Problem in natürlicher Sprache, bekommt Code zurück, testet ihn, gibt Feedback, iteriert.
Es ist kein Ersatz für erfahrene Entwickler. Es ist ein Werkzeug für Menschen, die ein klares Problem haben, ein begrenztes Budget und genug technisches Verständnis, um das Ergebnis einzuordnen.
Für WordPress-Plugins passt diese Methode erstaunlich gut – wenn man ein paar Dinge beachtet.
Warum macht das bei WordPress-Plugins Sinn?
WordPress-Plugins folgen einem klaren Muster. Es gibt eine Haupt-PHP-Datei mit einem definierten Header, eine Reihe von Hook-Punkten (add_action, add_filter) und eine gut dokumentierte API. Das ist für KI-Modelle wie Claude oder ChatGPT ideales Terrain: viel Trainingsdaten, klar strukturierte Muster, wenig Überraschungen.
Für typische Einzel-Plugins – eine Wartungsseite, ein einfaches Formular, ein Custom Post Type, eine kleine Redirect-Logik – reicht Vibe Coding aus. Man bekommt funktionierende, lesbare PHP-Dateien, die sich sauber in WordPress integrieren.
Der entscheidende Unterschied zu einem Plugin aus dem Repository: Du weisst genau, was drin ist. Kein aufgeblähter Code, keine unnötigen Abhängigkeiten, keine Update-Probleme, kein Vendor-Lock-in.
Die echten Vorteile – ohne Schönfärberei
Kontrolle. Ein selbst generiertes Plugin macht genau das, was du beschrieben hast – nicht mehr, nicht weniger. Kein Tracking, keine Upsells, keine versteckten API-Aufrufe.
Wartbarkeit. Ein Plugin mit 80 Zeilen PHP ist wartbarer als eines mit 8.000. Wenn etwas nicht funktioniert, findest du es. Wenn du es dem Modell zeigst, findet es es auch.
Autarkie. Das Plugin hat keine Abhängigkeiten zu anderen Plugins oder externen Services. Es läuft für sich allein. Das ist kein Zufall, das ist eine bewusste Architektur-Entscheidung – und weiter unten erkläre ich, warum das sicherheitstechnisch wichtig ist.
Kosten. Null. Ausser der Zeit für den Chat.
Worauf du beim Prompten unbedingt achten musst
Das Ergebnis eines KI-generierten Plugins steht und fällt mit der Qualität deiner Beschreibung. Hier sind die Punkte, die ich als entscheidend erlebt habe.
1. Zweck und Kontext zuerst
Beschreibe nicht nur, was das Plugin tun soll, sondern warum und in welchem Kontext. «Schreibe ein WordPress-Plugin» ist zu wenig. Besser:
«Ich brauche ein WordPress-Plugin, das für alle Besucher eine statische HTML-Seite anzeigt, solange ich an der Website arbeite. Admins sollen die Website normal sehen. Die HTML-Seite muss ich selbst bearbeiten können, ohne PHP anzufassen.»
Der Kontext hilft dem Modell, sinnvolle Architektur-Entscheidungen zu treffen – zum Beispiel: Template in einer separaten Datei statt hartcodiert im PHP.
2. Randbedingungen explizit nennen
Was darf das Plugin auf keinen Fall tun? Was muss immer erreichbar bleiben?
«wp-login.php und wp-admin müssen immer erreichbar sein. Das Plugin darf keine externen Abhängigkeiten haben. Keine Datenbank-Einträge.»
KI-Modelle sind gut darin, bekannte Patterns umzusetzen. Sie sind weniger gut darin, Edge Cases vorauszudenken, die du nicht erwähnt hast.
3. Sicherheitsanforderungen explizit stellen
Das ist der wichtigste Punkt. Verlange konkrete WordPress-Sicherheitsfunktionen explizit:
«Stelle sicher, dass alle Nutzereingaben mit
sanitize_text_field()bereinigt werden. Nutzeesc_url(),esc_attr(),esc_html()konsequent. Prüfe Nonces bei allen Formular-Aktionen. Nutzecurrent_user_can()für alle Admin-Aktionen.»
Wenn du das nicht explizit verlangst, bekommst du Code, der funktioniert – aber nicht zwingend abgehärtet ist.
4. Lizenz und Herkunft klären
Wenn du ein bestehendes Plugin als Inspiration zeigst, sag dem Modell explizit, dass du keinen abgeleiteten Code willst, sondern eine eigene Implementierung. Das ist nicht nur eine ethische Frage, sondern eine rechtliche.
«Das angehängte Plugin dient nur als Inspiration für den Feature-Umfang. Schreibe das Plugin komplett neu und unabhängig davon.»
5. Iterieren, nicht perfektionieren
Dein erster Prompt muss nicht perfekt sein. Beschreibe das Kernproblem, prüfe den ersten Entwurf, und verfeinere dann gezielt. Drei Iterationen sind besser als ein Mega-Prompt.
Wie du deine WordPress-Instanz trotzdem sicher hältst
Vibe Coding und WordPress-Sicherheit sind kein Widerspruch – wenn du die richtigen Architektur-Prinzipien anwendest.
Autarke Plugins bauen
Das wichtigste Prinzip: Jedes Plugin, das du selbst baust, sollte für sich allein funktionieren. Keine Abhängigkeiten zu anderen Plugins, keine externen API-Aufrufe, keine gemeinsamen Datenbank-Tabellen.
Warum? Weil du den Angriffsvektor kontrollierst. Ein Plugin, das nur eine HTML-Datei einliest und ausliefert, hat eine minimale Angriffsfläche. Ein Plugin, das eine externe Library lädt, einen REST-Endpoint öffnet und mit einem Drittdienst kommuniziert, hat eine erheblich grössere.
WordPress-Sicherheits-Basics, die dein Prompt immer enthalten sollte
Diese Funktionen kennst du vielleicht noch nicht auswendig – aber Claude und ChatGPT kennen sie. Verlange sie explizit:
- Eingaben bereinigen:
sanitize_text_field(),sanitize_email(),absint()je nach Typ - Ausgaben escapen:
esc_html(),esc_attr(),esc_url()– nie rohe Variablen in HTML ausgeben - Nonces verwenden: Jedes Formular, das Aktionen auslöst, braucht eine Nonce – das verhindert CSRF-Angriffe
- Capabilities prüfen: Immer
current_user_can()nutzen, nie davon ausgehen, dass ein Nutzer die nötige Berechtigung hat - Direct Access verhindern: Jede PHP-Datei sollte oben beginnen mit
defined('ABSPATH') || exit;
Code lesen, nicht blind vertrauen
Das ist der Punkt, an dem viele Vibe-Coder scheitern: Sie schauen den generierten Code nicht an. Das ist ein Fehler.
Du musst kein PHP-Experte sein, um einen 80-Zeilen-Code grob zu verstehen. Frag das Modell, was jede Funktion macht. Lass dir kritische Stellen erklären. Das dauert fünf Minuten und gibt dir ein echtes Sicherheitsgefühl – nicht nur ein gefühltes.
Staging first
Jedes neue Plugin erst auf einer Staging-Umgebung testen, nicht direkt auf Produktion. Das kostet beim ersten Mal etwas Aufwand, spart aber potenziell erheblich mehr.
Wo die Grenzen liegen – ehrlich
Vibe Coding für WordPress-Plugins funktioniert gut für einfache, klar abgegrenzte Aufgaben. Es hat echte Grenzen, die du kennen solltest.
Komplexe Datenbankoperationen. Sobald ein Plugin mehrere Tabellen, komplexe Queries und Migrations-Logik braucht, wird der generierte Code schnell unübersichtlich und fehleranfällig.
E-Commerce und Zahlungsverarbeitung. Plugins, die Geldtransaktionen verarbeiten, gehören nicht in Vibe-Coding-Terrain. Die Fehlerkosten sind zu hoch, die Compliance-Anforderungen zu komplex.
Skalierbarkeit. Ein Plugin, das für eine kleine Website funktioniert, kann bei hohem Traffic Probleme machen. Performance-Optimierung ist ein Bereich, in dem generierter Code schnell an Grenzen stösst.
Security Audits. KI-generierter Code ist kein Ersatz für einen echten Sicherheits-Audit. Wenn du sensible Nutzerdaten verarbeitest oder dein Plugin öffentlich verfügbar machen willst, lass es von jemandem mit Erfahrung prüfen.
Regelmässige Updates. Drittanbieter-Plugins werden gepflegt, wenn WordPress-Core-Updates kommen. Dein selbst gebautes Plugin nicht automatisch. Du trägst die Verantwortung, bei grossen WordPress-Updates zu prüfen, ob noch alles funktioniert.
Mein persönliches Fazit
Ich baue mir inzwischen alle einfachen WordPress-Plugins selbst. Wartungsseiten, Custom-Redirects, kleine Meta-Box-Erweiterungen, Deployment-Helfer. Das spart mir Geld, gibt mir Kontrolle und ich weiss genau, was auf meiner Instanz läuft.
Es ist kein Freifahrtschein für alles. Aber für den Bereich, in dem es funktioniert, ist es ein echtes Werkzeug – kein Spielzeug.
Die wichtigste Erkenntnis: Vibe Coding macht dich nicht zum Entwickler. Es macht dich zum Auftraggeber, der weiss, was er will, und der das Ergebnis einordnen kann. Das ist eine Fähigkeit, die sich lohnt zu entwickeln.