Gemini CLI in TYPO3-Projekten: Produktivhelfer oder Analyse-Tool? (Praxis-Guide 2026)

Gemini CLI in TYPO3-Projekten: Warum das Thema 2026 plötzlich auf vielen Roadmaps steht

2026 ist Gemini CLI in vielen TYPO3-Teams nicht mehr nur ein „nice to have“, sondern wird aktiv als Werkzeug für Analyse, Dokumentation und Upgrade-Vorbereitung nachgefragt. Der Grund ist weniger ein Hype, sondern eine sehr praktische Entwicklung: TYPO3-Projekte werden größer, die Codebases älter, die Release-Zyklen enger und die Anforderungen an Security, Performance und Wartbarkeit steigen. Gleichzeitig sind viele Teams DevOps-affiner geworden und erwarten Tools, die sich in bestehende Workflows (Terminal, CI, Code-Reviews) einfügen.

Gemini CLI passt in dieses Bild, weil es sich wie ein technischer Assistent im Terminal nutzen lässt: Fragen stellen, Code-Kontext einbeziehen, Zusammenhänge erklären lassen, Risiken identifizieren. In der Praxis ist aber entscheidend, sauber zu trennen: Wo liefert Gemini CLI echten Mehrwert als Analyse-Tool – und wo wird es riskant, wenn man es als „Autopilot“ für Refactorings in TYPO3 einsetzt?

Analyse-Unterstützung vs. produktives Refactoring: die wichtigste Abgrenzung

In TYPO3-Projekten ist die Grenze zwischen „Analyse“ und „Produktivänderung“ oft dünn. Ein scheinbar harmloser Eingriff in Extbase-Controller, ein Fluid-Template oder TypoScript kann Seiteneffekte auslösen, die erst in bestimmten Seitenbäumen, Sprachen oder Workspaces sichtbar werden. Deshalb ist die zentrale Entscheidungshilfe: Gemini CLI ist in TYPO3 aktuell am stärksten, wenn es beim Verstehen, Strukturieren und Priorisieren hilft. Sobald es um automatisierte oder unkontrollierte Code-Änderungen geht, steigt das Risiko deutlich.

Was ich in der Praxis als „Analyse“ werte

• Repository-Orientierung: Wo liegen welche Extensions, welche Site-Konfigurationen, welche Integrationen?
• Erklären von Codepfaden: Welche Controller-Aktion rendert welches Template, welche Partials werden eingebunden?
• TypoScript- und TSconfig-Verständnis: Includes, Konstanten, Setup, Bedingungen, Vererbung.
• Upgrade-Readiness: Auffälligkeiten sammeln, Deprecations lokalisieren, Migrationspfade skizzieren.

Was ich als „produktives Refactoring“ werte

• Änderungen an PHP-Code (Extbase, Domain-Modelle, Repositories, Services) mit funktionalem Einfluss
• Umbauten an Fluid-Templates/Partials, die Rendering-Logik verändern
• Änderungen an TypoScript, die Output, Caching oder Routing beeinflussen
• Automatisches „Fixen“ von Deprecations ohne Test- und Review-Absicherung

Gemini CLI kann bei Refactorings unterstützen, aber in TYPO3 sollte das fast immer diff-basiert, kleinschrittig und mit klaren Sicherheitsnetzen passieren.

TYPO3-Praxisfälle: Wo Gemini CLI als Analyse-Tool wirklich hilft

1) Analyse von Extbase- und Fluid-Code

In gewachsenen Extbase-Projekten ist die größte Zeitfalle oft nicht das Schreiben von Code, sondern das Wiederfinden von Verantwortlichkeiten: Welche Action wird wo geroutet? Welche ViewHelpers sind custom? Welche Domain-Modelle sind „echte“ Aggregate und welche sind historisch gewachsen?

Gemini CLI ist hier nützlich, wenn man es gezielt als „Leser“ einsetzt. Ein sinnvoller Ablauf ist:

• Scope definieren: eine Extension, ein Feature, ein konkreter Request-Flow.
• Relevante Dateien sammeln: Controller, Templates, Partials, ViewHelpers, TypoScript für Plugin-Setup.
• Gemini CLI bitten, den Flow zu erklären: Eingaben, Abhängigkeiten, Seiteneffekte, potenzielle Risiken.

Wichtig ist, dass man nicht nach „Refactor das mal“ fragt, sondern nach einer strukturierten Analyse: Was ist der Ist-Zustand, wo sind Kopplungen, wo sind Tests nötig, welche Stellen sind upgrade-kritisch.

2) Verständnis von TypoScript-Strukturen und Includes

TypoScript ist in vielen Projekten der Ort, an dem sich Historie, Workarounds und Teamwechsel am stärksten zeigen. Includes über mehrere Ebenen, Konstanten, Conditions, site-spezifische Overrides: Das ist für Menschen schwer zu überblicken, vor allem wenn mehrere Mandanten in einem Repo leben.

Gemini CLI kann helfen, indem es eine „Landkarte“ erstellt: Welche Einstiegspunkte gibt es, welche Includes werden gezogen, wo werden zentrale Konstanten gesetzt, und welche Dateien sind wahrscheinlich tot oder redundant. Der Mehrwert entsteht, wenn man die Analyse in konkrete Aufgaben übersetzt, z.B. „reduziere Include-Tiefe“, „entkopple Mandanten“, „dokumentiere zentrale Konstanten“.

3) Orientierung in großen, historisch gewachsenen TYPO3-Repositories

Viele Agentur-Repositories sind über Jahre gewachsen: mehrere Extensions, Legacy-Integrationen, alte Build-Skripte, gemischte Konventionen, und oft ein „Schatten-Framework“ aus Helpern. In solchen Repos ist die erste Stunde im Projekt entscheidend: Wie schnell kann ein Entwickler sicher Änderungen machen, ohne Nebenwirkungen zu übersehen?

Gemini CLI eignet sich hier als Onboarding-Hilfe, wenn man es mit klaren Fragen füttert:

• „Welche Extensions wirken wie Kern-Extensions und welche sind Feature-spezifisch?“
• „Wo wird Rendering zentral beeinflusst (ViewHelpers, DataProcessors, TypoScript)?”
• „Welche Integrationen sind kritisch (Search, PIM, DAM, SSO) und wo liegen die Adapter?“

Das ersetzt keine Architektur-Doku, aber es beschleunigt die erste Orientierung, sofern man die Antworten als Hypothesen behandelt und gegen den Code verifiziert.

4) Unterstützung bei Upgrade-Vorbereitungen (TYPO3 v12 → v13)

Bei Upgrades ist Gemini CLI besonders wertvoll, weil es Muster erkennen und To-do-Listen strukturieren kann. Für TYPO3 v12 → v13 sind typische Aufgaben: Deprecations, Anpassungen an Core-APIs, mögliche Änderungen in Extbase/DI, Fluid-Rendering, Routing, sowie das Review von Drittanbieter-Extensions.

Ein praxistauglicher Ablauf:

• Ist-Zustand erfassen: TYPO3-Version, PHP-Version, Composer-Setup, aktive Extensions, CI-Status.
• Upgrade-Scope festlegen: nur Core-Upgrade oder inklusive Refactoring/Modernisierung?
• Risiko-Cluster bilden: „Rendering“, „Routing“, „Auth“, „Search“, „Backend-Module“, „Scheduler/CLI“.
• Gemini CLI für Analyse nutzen: „Welche Stellen sind wahrscheinlich upgrade-kritisch?“
• Ergebnisse in Tickets übersetzen: klein, testbar, mit klarer Definition of Done.

Konkreter, sicherer Workflow: Analyse zuerst, Änderungen diff-basiert

Aus Freelancer-Perspektive (und nach zu vielen „KI hat’s kaputt gemacht“-Momenten) ist ein Workflow entscheidend, der Gemini CLI als Analyse-Tool nutzt und produktive Änderungen kontrolliert. Das Ziel ist nicht, möglichst viel automatisch zu ändern, sondern schneller zu verstehen und bessere Entscheidungen zu treffen.

Schritt 1: Arbeitskopie und Branch-Disziplin

Bevor überhaupt irgendetwas „automatisch“ vorgeschlagen wird: sauberer Branch, reproduzierbarer Stand, und ein klares Ticket. Das klingt banal, ist aber die Grundlage dafür, dass KI-Ausgaben nicht zu unreviewbaren Patch-Sammlungen werden.

Schritt 2: Scope hart begrenzen (Extension, Feature, Ordner)

Gemini CLI wird umso unzuverlässiger, je größer und heterogener der Kontext ist. In TYPO3-Repos ist „alles“ fast nie sinnvoll. Besser: eine Extension oder ein Feature-Ordner, plus die zugehörigen TypoScript/Fluid-Dateien.

Praktisch heißt das: erst die relevanten Pfade identifizieren, dann gezielt analysieren lassen. Wenn das Tool eine „globale“ Aussage trifft („das ist überall so“), ist das ein Signal, dass der Scope zu groß oder die Frage zu unscharf war.

Schritt 3: Analyse-Fragen so stellen, dass überprüfbare Ergebnisse entstehen

Gute Fragen im TYPO3-Kontext sind solche, die zu überprüfbaren Listen führen:

• Dateiliste: „Welche Dateien sind für Feature X relevant?“
• Call-Graph: „Welche Methoden/Services werden im Request-Flow genutzt?“
• Risikoliste: „Welche Stellen sind wahrscheinlich von API-Änderungen betroffen?“
• Test-Hinweise: „Welche Tests fehlen, um Änderung Y sicher zu machen?“

Schlechte Fragen sind solche, die implizit „mach mal neu“ bedeuten. In TYPO3 führt das oft zu Vorschlägen, die zwar modern klingen, aber Projektkonventionen, Legacy-Constraints oder Integrationen ignorieren.

Schritt 4: Änderungen nur als Vorschlag akzeptieren – und immer als Diff prüfen

Wenn Gemini CLI konkrete Code-Änderungen vorschlägt, sollten diese als Patch-Vorschlag behandelt werden, nicht als Wahrheit. In TYPO3 sind typische Problemzonen: Caching, Context/Language, Site-Konfiguration, Extbase Property-Mapping, und alles, was indirekt über TypoScript konfiguriert wird.

Ein minimaler Sicherheitsstandard ist: jede Änderung als Diff prüfen, lokal ausführen, und gegen reale Seiten/Use-Cases testen.

Schritt 5: Review-Prozess und „Stop-Kriterien“ definieren

In Teams ist es sinnvoll, ein paar Stop-Kriterien festzulegen, bei denen KI-Vorschläge nicht direkt umgesetzt werden:

• Änderungen an Routing, Site-Handling, Language-Fallbacks
• Änderungen an Caching-Konfigurationen oder DataProcessors
• Umbauten an Domain-Logik ohne Tests
• „Große“ Refactorings über mehrere Extensions hinweg

Hier ist der richtige Weg meist: erst Analyse, dann manuell oder in sehr kleinen, reviewbaren Schritten refactoren.

Ehrliche Grenzen von Gemini CLI im TYPO3-Kontext

Risiken bei unkontrollierten Code-Änderungen

TYPO3-Projekte haben oft implizite Regeln: Naming-Konventionen, spezielle DataProcessors, projektweite ViewHelper-Bibliotheken, oder Workarounds für Redakteursprozesse. Gemini CLI kann diese Regeln nur erkennen, wenn sie im Kontext sichtbar und konsistent sind. In der Realität sind sie das häufig nicht.

Das Risiko ist dann, dass Änderungen „formal korrekt“ wirken, aber funktional Nebenwirkungen haben: falsche Cache-Tags, kaputte Übersetzungslogik, unerwartete Query-Änderungen in Repositories, oder Fluid-Änderungen, die nur in bestimmten Content-Element-Kombinationen auffallen.

Typische Fehlannahmen bei komplexen TYPO3-Architekturen

• Extbase wird als „Standard-MVC“ interpretiert, obwohl Projekte oft stark angepasst sind.
• TypoScript wird als linearer Include-Stack verstanden, obwohl Conditions und Mandanten-Overrides die Realität bestimmen.
• Fluid wird als „nur Template“ unterschätzt, obwohl ViewHelper, Sections, Partials und DataProcessing Logik tragen.
• Composer-Setups werden als homogen angenommen, obwohl viele Repos Mischformen (Legacy + Modern) enthalten.

Diese Fehlannahmen sind kein „Fehler“ des Tools, sondern ein Hinweis: In TYPO3 ist Kontext König, und Kontext ist selten vollständig.

Einordnung im Vergleich zu anderen CLI-basierten AI-Tools

Im Alltag begegnen mir neben Gemini CLI vor allem Claude Code und Copilot CLI. Alle drei können als CLI-basierte KI helfen, aber mit unterschiedlichen Stärken. Entscheidend ist weniger „welches ist besser“, sondern „welches passt zu eurem Risiko-Profil und Workflow“.

• Gemini CLI: stark, wenn es um schnelle Analyse, Strukturierung und das Erstellen von nachvollziehbaren Checklisten geht. In TYPO3 besonders nützlich für Orientierung und Upgrade-Vorbereitung.
• Claude Code: in vielen Fällen sehr gut beim Erklären komplexer Zusammenhänge und beim vorsichtigen Ableiten von Refactoring-Schritten, wenn der Kontext sauber begrenzt ist.
• Copilot CLI: praktisch für schnelle Shell-nahe Aufgaben und kleine, klar umrissene Änderungen, aber in TYPO3-Architekturen ebenfalls nur so gut wie Scope und Review.

Wenn du tiefer in die Abgrenzung einsteigen willst: Im internen Artikel „Gemini CLI als Alternative zu Claude Code“ habe ich die Unterschiede aus TYPO3-Perspektive noch einmal konkreter gegenübergestellt.

Klare Entscheidungshilfe: Wann Gemini CLI in TYPO3 sinnvoll ist – und wann nicht

Sinnvoll in diesen Szenarien

• Onboarding in große TYPO3-Repositories: schneller Überblick, Hypothesenbildung, Navigationshilfe.
• Analyse von Extbase/Fluid-Features: Request-Flow erklären, Abhängigkeiten sichtbar machen, Risiken sammeln.
• TypoScript-Orientierung: Include-Strukturen, Konstanten-Hotspots, potenzielle Redundanzen identifizieren.
• Upgrade-Vorbereitung v12 → v13: To-do-Listen, Risiko-Cluster, Priorisierung und Ticket-Schnitt.
• DevOps-nahe Teams: wenn Ergebnisse in CI/Review-Prozesse überführt werden (diff-basiert, testbar, nachvollziehbar).

Nicht sinnvoll (oder nur mit sehr strengen Leitplanken)

• „Refactor die ganze Extension“ ohne Tests, ohne klare Akzeptanzkriterien, ohne Review.
• Änderungen an kritischen Querschnittsthemen (Caching, Routing, Mehrsprachigkeit) ohne reale Testfälle.
• Projekte mit stark impliziten Regeln, die nirgends dokumentiert sind und nur in Köpfen existieren.
• Wenn das Team keine Zeit für Review hat: KI spart dann keine Zeit, sondern verschiebt Risiko in Produktion.

Mein Fazit aus über zehn Jahren TYPO3: Gemini CLI ist 2026 ein sinnvoller Produktivhelfer, wenn man „Produktivität“ als bessere Analyse, schnellere Orientierung und sauberere Entscheidungsgrundlagen versteht. Als Tool für automatisches Refactoring in TYPO3 taugt es nur dann, wenn ihr es bewusst in einen sicheren Workflow einbettet: Scope eng, Änderungen klein, diff-basiert, mit Review und Tests. Genau dann wird aus „CLI-basierter KI“ ein realistisches Werkzeug für AI für TYPO3 – ohne dass ihr die Kontrolle über eure Codebase verliert.