Werkzeuge wie Claude Code stehen für eine neue Generation von Entwicklungshilfen: Sie schreiben nicht nur einzelne Codezeilen vor, sondern arbeiten agentisch — das heißt, sie führen mehrschrittige Aufgaben in einem Projekt weitgehend selbständig aus, lesen dazu vorhandene Dateien, ändern mehrere Stellen und prüfen Zwischenergebnisse. Dass zu diesem Einsatzfeld inzwischen eigene Praxis-Workshops für Entwicklerinnen und Entwickler angeboten werden, ist ein gutes Indiz dafür, wie schnell sich das Thema von der Spielerei zur Alltagsfrage entwickelt hat.

Für Unternehmen, die Web- oder TYPO3-Projekte beauftragen, ist die interessante Frage nicht, ob ein Team solche Tools nutzt. Interessant ist, wie es sie nutzt — und was das für Termine, Qualität und Wartbarkeit bedeutet.

Der Unterschied zwischen Autovervollständigung und Agent

Klassische KI-Unterstützung in der Entwicklungsumgebung schlägt die nächsten Zeilen vor. Die Entscheidung, ob der Vorschlag passt, fällt sofort und im Kleinen. Agentische Werkzeuge arbeiten eine Ebene höher: Sie erhalten eine Aufgabenbeschreibung, verschaffen sich selbst einen Überblick über das Projekt und liefern anschließend ein Ergebnis, das mehrere Dateien betreffen kann.

Damit verschiebt sich die Rolle der Entwicklerin und des Entwicklers. Der Aufwand wandert von der Eingabe zur Formulierung der Aufgabe und zur Prüfung des Resultats. Wer eine Anforderung unpräzise beschreibt, bekommt schnell viel Code, der plausibel aussieht und trotzdem am Ziel vorbeigeht. Genau deshalb ist der strukturierte Einsatz — Aufgabenschnitt, Kontext, Abnahme — der eigentliche Lerninhalt und nicht die Bedienung des Werkzeugs.

Wo Tempo entsteht — und wo nicht

Erfahrungsgemäß profitieren vor allem Arbeiten, die klar umrissen und gut überprüfbar sind: Boilerplate, also gleichförmiger Grundgerüst-Code, Testfälle zu vorhandener Logik, Migrationsschritte, Umbenennungen über viele Dateien, das Erschließen fremder Codebestände. Auch die erste Orientierung in einem übernommenen Altsystem geht deutlich schneller, wenn ein Werkzeug Struktur und Abhängigkeiten zusammenfasst.

Wenig gewinnt man dort, wo die Schwierigkeit nicht im Schreiben liegt: bei fachlichen Entscheidungen, bei Architekturfragen mit langer Wirkung, bei Sicherheits- und Datenschutzabwägungen, bei allem, was tiefes Wissen über den Kunden und dessen Prozesse braucht. Diese Grenze offen zu benennen, schützt vor überzogenen Erwartungen an beiden Seiten des Projekttisches.

Review wird zum Engpass

Wenn Code schneller entsteht, entsteht auch mehr Code, der gelesen werden muss. Teams, die das unterschätzen, verlagern das Problem nur: Die Umsetzung dauert kürzer, die Abnahme länger, und in der Wartung zahlt man nach.

Praktisch bewährt hat sich, den Review-Aufwand bewusst einzuplanen statt ihn als Restposten zu behandeln. Dazu gehören überschaubare Änderungspakete, nachvollziehbare Commit-Historie und die Regel, dass niemand Änderungen freigibt, die er oder sie nicht versteht. Automatisierte Prüfungen in der Pipeline — statische Analyse, Coding-Standards, Tests — fangen einen Teil der Routinefehler ab und halten die menschliche Aufmerksamkeit für das frei, was wirklich Urteilsvermögen braucht.

Regeln, die im Projekt liegen sollten

Damit der Einsatz reproduzierbar bleibt, hilft es, Vorgaben nicht in Köpfen, sondern im Repository zu verankern:

  • Zuständigkeit: Verantwortlich für jede Änderung bleibt die Person, die sie einreicht — unabhängig davon, wer oder was den Code geschrieben hat.
  • Konventionen: Coding-Standards, Verzeichnisstruktur und Namensgebung dokumentiert im Projekt ablegen, damit ein Agent sich daran orientieren kann.
  • Grenzen: Festlegen, welche Bereiche nicht automatisiert bearbeitet werden — etwa Authentifizierung, Zahlungsabwicklung oder Migrationsskripte auf Produktivdaten.
  • Datenschutz: Klären, welche Inhalte überhaupt an einen externen Dienst gehen dürfen, und Zugangsdaten sowie Kundendaten konsequent aus dem Kontext heraushalten.
  • Tests: Für generierte Logik gilt dieselbe Testpflicht wie für handgeschriebene.

Besonderheiten in TYPO3-Projekten

In CMS-Projekten ist der Rahmen enger als in einem freien Greenfield-Projekt. TYPO3 bringt eigene Konventionen mit — Extension-Struktur, Konfigurationsdateien, Datenbankdefinitionen, Upgrade-Pfade zwischen den Versionen. Agentische Werkzeuge liefern hier gute Ergebnisse, wenn sie den relevanten Projektkontext kennen, und produzieren andernfalls Code, der zwar generisch korrekt wirkt, aber nicht zum Framework passt.

Nützlich ist der Einsatz deshalb vor allem bei wiederkehrender Fleißarbeit: Templates anpassen, Konfiguration konsistent nachziehen, Deprecations vor einem Versionswechsel aufspüren, Dokumentation zu bestehenden Extensions erstellen. Die inhaltliche Modellierung — welche Inhaltstypen, welche Redaktionsprozesse, welche Rechte — bleibt Handarbeit im Gespräch mit den Redaktionsteams.

Qualifikation als Teil der Einführung

Dass Workshops zu diesem Thema entstehen, verweist auf einen zweiten Punkt: Der Umgang mit agentischen Tools ist eine erlernbare Fähigkeit und keine Selbstverständlichkeit. Aufgaben sinnvoll schneiden, Kontext bereitstellen, Ergebnisse kritisch prüfen, Abbruchkriterien erkennen — das lernt ein Team schneller gemeinsam als jede Person für sich. Wer die Einführung begleitet, vermeidet außerdem, dass sich in einem Team fünf unterschiedliche, undokumentierte Arbeitsweisen etablieren.

Was das für Projekte bedeutet

Für Auftraggeberinnen und Auftraggeber verschiebt sich der Maßstab: Nicht die Frage, ob KI im Spiel ist, entscheidet über die Qualität, sondern ob ein Team nachweisbare Prozesse für Review, Tests und Verantwortung hat. Realistisch ist ein Tempogewinn bei klar umrissener Umsetzungsarbeit, während Konzeption, Architektur und Abnahme ihren Aufwand behalten. Wer bei der Auswahl eines Dienstleisters gezielt nach diesen Prozessen fragt, erkennt schneller, wo aus Geschwindigkeit auch Substanz wird.

Quellen