Zum Hauptinhalt springen
How Can We Help?
< All Topics

Theme- und Plugin-Entwicklung verändert sich durch KI-Coding-Assistenten grundlegend. KI-Coding-Assistenten (z. B. Claude Code, Cursor, GitHub Copilot, Codex) schreiben heute grosse Teile von Plugins, Blöcken und Themes. Das beschleunigt enorm, verschiebt aber die Rolle der Entwickler: weniger tippen, mehr spezifizieren, prüfen und absichern.

Wofür KI besonders gut ist

  • Boilerplate: Plugin-Grundgerüste, Custom Post Types, Settings-Seiten, REST-Routen, Abilities
  • Blöcke: block.json, Edit-/Save-Komponenten, PHP-only-Blöcke, Interactivity API
  • theme.json, Patterns und Style Variations aus einem Design-Briefing
  • Tests (PHPUnit, Playwright E2E) und Refactorings, z. B. PHP-Kompatibilität für 8.4/8.5
  • Dokumentation, Changelogs, readme.txt
  • Code-Reviews und Erklärungen fremder Plugins

Typische Schwächen von KI-Code in WordPress

  • Veraltete Muster: Klassische Themes statt Block-Themes, jQuery statt moderner APIs, deprecated Funktionen. Modelle kennen ältere Dokumentation besser als neue (z. B. APIs aus 6.9/7.0).
  • Sicherheitslücken: Fehlende Nonce-Prüfung, fehlende Capability-Checks, ungeescapte Ausgaben, $wpdb->query() ohne prepare(), permission_callback => '__return_true'.
  • Erfundene Funktionen oder Hooks, die plausibel klingen, aber nicht existieren.
  • Überdimensionierte Lösungen, wo ein Core-Feature reichen würde.

Ein solider Workflow

  1. Kontext geben: Eine Projektdatei (z. B. CLAUDE.md oder AGENTS.md) mit Zielversionen (WP 7.x, PHP 8.3+), Coding Standards, Namespace/Prefix, Sicherheitsregeln und Architekturentscheidungen. Agenten halten sich deutlich besser an explizite Regeln.
  2. Aktuelle Doku einbinden: Developer-Handbuch-Abschnitte oder Dokumentations-MCP-Server bereitstellen, damit der Agent nicht aus veraltetem Wissen arbeitet.
  3. Lokale Umgebung mit Werkzeugen: wp-env oder DDEV, WP-CLI, Composer. Agenten können dann selbst testen, statt nur zu raten.
  4. Automatische Prüfungen als Leitplanken:
    • phpcs mit WordPress-Coding-Standards (inkl. Sicherheits-Sniffs für Escaping, Nonces, Prepared Statements)
    • PHPStan mit szepeviktor/phpstan-wordpress
    • Plugin Check (offizielles Plugin bzw. wp plugin check), das auch WordPress.org bei Einreichungen und Updates nutzt
    • PHPUnit und Playwright
  5. Kleine Schritte, häufige Commits. Jede KI-Änderung im Diff prüfen, nicht nur das Ergebnis im Browser.
  6. Menschliches Security-Review für alles, was Eingaben verarbeitet, Rechte prüft, Dateien schreibt oder Datenbankabfragen baut.

KI-Features in eigenen Plugins

  • Den Core AI Client nutzen statt eigene Anbieter-SDKs und Key-Felder. Der Betreiber wählt den Anbieter unter Connectors.
  • Funktionen als Abilities registrieren, damit sie für Agenten nutzbar sind (siehe Eigene Abilities registrieren).
  • Modell-Ausgaben immer als nicht vertrauenswürdige Eingabe behandeln: sanitizen, escapen, nie direkt als Code, SQL oder HTML ausführen.

Fazit

KI macht gute Entwickler schneller, aber nicht automatisch sicherer. Die Qualität entsteht durch Spezifikation, Tests und Review, also die Teile, die man nicht an das Modell delegieren sollte.

Weiterführende Artikel

Quellen und Dokumentation

Schlagwörter: