Einblicke

Kunden mit Enterprise-Drupal-Plattformen fragen nicht mehr, ob KI Code schreiben kann. Die Frage, die wir heute bekommen, ist enger und deutlich nützlicher: Verkürzt sie die Zeit zwischen „die Website verhält sich seltsam“ und „wir wissen warum“?

Das ist eine Frage zur Ökonomie der Wartung, nicht zum Ersetzen von Entwicklern. Auf einer Plattform, die seit sechs Jahren läuft, vierzig Contrib-Module trägt und drei Generationen geerbten Custom-Codes enthält, verschlingt die Diagnose die Stunden. Die Behebung ist meist kurz, sobald man weiß, was zu beheben ist.

Wir setzen Claude seit knapp einem Jahr als Teil dieser Diagnoseschleife in produktiven Drupal-Projekten ein. Es folgt eine ehrliche Bilanz: wo es seinen Platz verdient, wo es selbstbewusst in die Irre führt und welche Leitplanken den Unterschied machen.

Was schnell gefunden wird

Das Muster ist konstant: KI ist stark, wo die Antwort bereits in dem Text steckt, den man ihr gibt, und schwach, wo die Antwort im Laufzeit- oder Datenbankzustand liegt.

• Stack Traces und Weiße Seiten. Ein WSOD-Backtrace zusammen mit den umliegenden dblog-Einträgen und der relevanten Moduldatei liefert in Sekunden eine gewichtete Liste möglicher Ursachen. Das ist der wertvollste Anwendungsfall. Ein erfahrener Entwickler kommt zum selben Ergebnis — nur fünfzehn Minuten später, nachdem er die Aufrufkette gedanklich durchlaufen hat.
• Cache-Invalidierungsketten. Die Cache-Metadaten von Drupal sind schwer im Kopf zu behalten: Kontexte, Tags und Max-Age setzen sich über Render-Arrays zusammen, und ein fehlendes Tag drei Ebenen tiefer erzeugt veralteten Output weit entfernt vom verursachenden Code. Mit dem Render-Array und der betroffenen Entität verfolgt die KI diese Komposition zuverlässig.
• Query-Pathologien in Views. Ein Slow-Query-Log neben der exportierten View-Konfiguration genügt, um das N+1-Muster, die fehlende Beziehung oder den Filter zu finden, der einen Full Scan erzwungen hat. EXPLAIN-Ausgaben liest sie gut.
• Hook-Reihenfolge und Interferenzen. Wenn zwei Module denselben Alter-Hook implementieren und das Ergebnis vom Gewicht abhängt, bringt die Beschreibung des Symptoms plus beide Implementierungen die Kollision meist sofort zum Vorschein.
• Veraltete APIs. Vor einem Major-Upgrade ist sie schnell und präzise darin, entfernte APIs in Custom-Modulen zu markieren und den Ersatz zu erklären — eine wirklich mühsame Aufgabe, gut erledigt.

Wo sie falsch liegt

Das sind Fehlermodi, die wir tatsächlich getroffen haben, keine theoretischen. Jeder hat uns Zeit gekostet, bis wir gelernt haben, drum herum zu planen.

• Der Zustand des Configuration Sync. Die KI sieht nicht, was in der aktiven Konfiguration gegenüber dem exportierten YAML steht, und sagt das auch nicht. Sie unterstellt einen plausiblen Zustand und argumentiert selbstbewusst daraus. Bei Konfigurationsfehlern sind ihre Vorschläge häufig falsch — auf eine Weise, die autoritativ klingt.
• Gepatchte Contrib-Module. Ein Modell denkt über die veröffentlichte Version eines Moduls nach. Wer drei Patches darauf mitführt — und das tut jede langlebige Drupal-Plattform —, dessen Datei entspricht nicht dem Modell der KI, und nichts im Gespräch deckt diese Abweichung auf.
• Alles Datenbankförmige. Verwaiste Felddaten, halbfertige Migrationen, Entity-Revisionen in inkonsistenten Zuständen: nichts davon ist im Code sichtbar, also auch nicht für das Modell.
• Versions-Drift. Die API-Oberfläche von Drupal hat sich über die letzten Major-Versionen erheblich verschoben. Manchmal vermischt die KI Idiome verschiedener Versionen zu Code, der richtig aussieht und nicht läuft. Nennen Sie immer die exakte Version.
• Erfundene Hooks und Services. Der gefährlichste Fehler, weil er der plausibelste ist. Hook- und Service-Namen, die es geben müsste, werden mit voller Überzeugung produziert. Prüfen Sie jede unbekannte API gegen den echten Code, bevor Sie darauf handeln.

Die verbindende Regel: Sie ist ein starker Denker über den Text, den man ihr gibt, und ein unzuverlässiger Rater über den Zustand, den man ihr nicht gegeben hat. Fast alle schlechten Ergebnisse gehen darauf zurück, dass jemand das Zweite erwartet hat.

Der Workflow, den wir tatsächlich nutzen

Drei Praktiken machen aus dem Obigen statt einer Spielerei etwas, das wir abzurechnen bereit sind.

Eine Projekt-Kontextdatei. Derselbe Ansatz, den wir für Next.js und KI-Agenten beschrieben haben, gilt direkt für Drupal — und wiegt hier schwerer, weil Drupals Konventionen schwerer zu erraten sind. Unsere hält fest: die exakte Core-Version, die gepatchten Contrib-Module und was die Patches tun, die Namespaces der Custom-Module, ob Config Sync autoritativ ist, und den lokalen Entwicklungs-Stack. Das eliminiert eine ganze Kategorie falscher Antworten, bevor sie entsteht.

Belege vor Meinung. Kein Diagnosegespräch beginnt mit einer Beschreibung des Symptoms in Prosa. Es beginnt mit Artefakten: der Ausgabe von drush watchdog:show, dem relevanten drush config:status, der echten Datei, der echten Query. Prosabeschreibungen sind die Stelle, an der menschliche Annahmen einsickern — und das Modell übernimmt sie vollständig.

Reproduzieren, dann beheben. Eine vorgeschlagene Ursache bleibt eine Hypothese, bis sie lokal reproduziert ist. Das klingt selbstverständlich und ist der am häufigsten übersprungene Schritt, weil eine überzeugende Erklärung sich wie eine fertige Diagnose anfühlt. Sie ist keine.

Was wir niemals delegieren

Ein Teil der Arbeit bleibt vollständig menschlich, und die Grenze verläuft nicht entlang der Fähigkeit — sondern entlang dessen, was passiert, wenn das Ergebnis falsch ist.

• Sicherheitsmeldungen. Patches werden von einem Menschen gelesen und eingespielt. Der Radius einer selbstbewusst falschen Antwort ist hier die gesamte Plattform.
• Major-Version-Upgrades. KI hilft enorm beim Inventar der Deprecations; sie führt das Upgrade nicht.
• Datenmigrationen. Alles, was in Produktionsdaten schreibt, wo eine subtil falsche Transformation Wochen später auffällt und teuer oder gar nicht mehr rückgängig zu machen ist.
• Alles mit Personenbezug. Produktionsinhalte mit personenbezogenen Daten gehören nicht in einen Prompt. Reproduzieren Sie stattdessen mit synthetischen Daten.

Was sich tatsächlich ändert

Die ehrliche Zusammenfassung ist unspektakulär: Sie verdichtet die Diagnose, und die Diagnose ist der größte Kostenblock. Untersuchungen, die früher einen Nachmittag gefressen haben, schließen häufig in unter einer Stunde. Die Behebung dauert genau so lange wie immer, das Review ist unverändert, die Deployment-Disziplin ist unverändert.

Was sie nicht tut: die nötige Expertise verringern. Jeder oben genannte Fehlermodus wird von jemandem erkannt, der Drupal gut genug kennt, um eine falsche Antwort als solche zu sehen — und bleibt für alle anderen unsichtbar. In den Händen eines Teams ohne fundierte Drupal-Erfahrung produziert dieses Werkzeug selbstbewusste, plausible, falsche Änderungen schneller als zuvor. Das ist eine schlechtere Position, als es gar nicht zu nutzen.

Deshalb behandeln wir es als Hebel auf eine bestehende Wartungsfähigkeit, nicht als deren Ersatz. Wenn Sie abwägen, wie eine Drupal-Plattform nach dem Launch gesund bleibt: unser Ansatz für den Betrieb von Drupal im großen Maßstab und unser Managed-Services-Team decken die operative Seite ab. Melden Sie sich, wenn Sie darüber sprechen möchten.