TYPO3 KI-fit machen: Wie klare Strukturen bessere Agenten-Ergebnisse liefern

KI-Agenten scheitern in TYPO3-Projekten selten an fehlender Rechenleistung. Sie scheitern an Kontextverlust: an TCA-Verzweigungen, Extbase-Boilerplate, impliziten Seiteneffekten und Regeln, die nur in Köpfen existieren. Genau dort entscheidet sich, ob ein Agent eine Änderung sauber umsetzt oder teure Review-Schleifen produziert.

Dass Architektur schwerer wiegt als Modellwahl, ist kein Bauchgefühl. LangChain verbesserte die Trefferquote seines Coding-Agenten von 52,8 % auf 66,5 % – ohne ein einziges Modell-Upgrade. Nur die Umgebung änderte sich: bessere Verifikationsschleifen, klarerer Kontext, engere Feedback-Loops. Dasselbe Modell, andere Ergebnisse.

Die Architektur einer Codebasis bestimmt die Qualität des Agenten – nicht umgekehrt.

Dieser Artikel trennt zwei Perspektiven: Was hat der TYPO3-Core bereits getan, um Code maschinenlesbarer zu machen? Und was können Sie als Extension-Entwickler:in in Ihrem Projekt ergänzen?

Inhaltsverzeichnis  

Warum KI-Lesbarkeit jetzt zählt  

In klassischen Projekten wurde Code für Menschen strukturiert, die Zeit hatten, sich in historische Entscheidungen einzuarbeiten. KI-Agenten arbeiten anders: Sie müssen mit begrenztem Kontext in kurzer Zeit das relevante Signal erkennen. Liu et al. zeigten 2023 in „Lost in the Middle", dass Sprachmodelle bei langen Kontexten eine U-förmige Aufmerksamkeitskurve aufweisen – sie bevorzugen Informationen am Anfang und Ende, der Mittelteil verliert bis zu 20 % an Wirksamkeit. Größere Kontextfenster verschärfen dieses Problem, statt es zu lösen.

Für TYPO3 bedeutet das: Je mehr Boilerplate, Wiederholung und implizite Regeln eine Extension enthält, desto höher ist das Risiko für unpräzise Patches, falsche Abkürzungen und unnötige Rückfragen. Wenn eine TCA-Datei 400 Zeilen verschachtelte Arrays enthält, sieht ein Agent viel Syntax und wenig Fachsignal.

Was der TYPO3-Core bereits liefert  

Das TYPO3-Ökosystem modernisiert sich seit mehreren Versionen in eine Richtung, die KI-Agenten direkt zugutekommt – auch wenn das nicht die ursprüngliche Absicht war. Wer diese Core-Änderungen kennt, versteht, warum TYPO3-Projekte heute strukturell besser für agentische Workflows aufgestellt sein können als viele andere PHP-Systeme.

Schema API und Record API ersetzen rohe TCA-Arrays  

Seit v13.2 bietet die Schema API einen typisierten, objektorientierten Zugang zu TCA-Strukturen. Statt direkt auf $GLOBALS['TCA'] zuzugreifen, nutzen Entwickler:innen eine API, die Felder, Typen und Relationen als Objekte bereitstellt. Die begleitende Record API (v13.3) transformiert rohe Datenbankwerte automatisch in typisierte Objekte: Record, FileReference, DateTimeImmutable. Relationen werden per Lazy Loading aufgelöst.

Für Agenten bedeutet das: weniger Array-Navigation, klarere Typen und ein vorhersehbares Objektmodell. Die Migration auf Schema API ist eine laufende Core-Initiative – der Core löst TCA als PHP-Array schrittweise ab.

Strikte Typen und PHP-Attribute in Extbase  

TYPO3 v13 erzwingt strikte Typisierung in Extbase-Kernklassen: ActionController, PersistenceManager, ObjectStorage und Domain-Model-Basisklassen sind durchgängig strikt typisiert. Wer Extbase-Klassen erweitert, muss seine Signaturen anpassen.

In v14 geht die Bereinigung weiter: Extbase-Annotations (@Extbase\Validate) sind entfernt, ausschließlich native PHP-Attribute (#[Extbase\Validate]) werden akzeptiert. Die doctrine/annotations-Bibliothek ist nicht mehr nötig. Für KI-Agenten ist das ein klarer Gewinn: Attribute sind maschinenlesbar, IDE-navigierbar und statisch analysierbar – DocBlock-Annotations waren keines von alledem.

Fluid 5.0 mit strikter Typvalidierung  

Fluid 5.0 in TYPO3 v14 validiert ViewHelper-Argumente strenger als zuvor. Null-Werte erzeugen keine leeren HTML-Attribute mehr, sondern lassen das Attribut weg. Custom ViewHelpers benötigen explizite Return-Type-Deklarationen. Variable-Namen mit Unterstrich-Präfix sind reserviert.

Diese Strenge reduziert die Klasse von Fehlern, die Agenten in Templates produzieren können – das System meldet Typfehler zur Laufzeit sofort, statt sie als stilles Fehlverhalten durchrutschen zu lassen.

PSR-14 Events statt Legacy-Hooks  

Die Migration von Hooks und Signal/Slot auf PSR-14 Events läuft seit v10 und ist in v14 nahezu abgeschlossen. Events sind typisierte Klassen mit klar definierten Properties, registriert über Services.yaml. Für Agenten sind sie ungleich einfacher zu entdecken und korrekt zu verwenden als die alten Hook-Registrierungen mit Magic Strings und impliziten Parametern.

Content Blocks als deklarative Alternative  

Content Blocks (v2.0 seit November 2025, v14-kompatibel) verlagern die Definition von Content-Elementen, Record-Types und Page-Types in eine einzige config.yaml. TCA, SQL und Backend-Formulare werden automatisch generiert. Die Core-Integration begann in v13 mit Schema API, Record Transformation API und automatischer TCA-Feldwert-Transformation.

Content Blocks sind keine Core-Extension, sondern ein von der Community gepflegtes Paket – aber die Infrastruktur dafür wurde bewusst im Core verankert.

Rector und Fractor als Community-finanzierte Migrationswerkzeuge  

Für TYPO3 v14 entstanden 45 neue Rector-Regeln und 11 Fractor-Regeln, finanziert durch das Community Budget. Rector transformiert PHP-Code (Deprecations, Breaking Changes), Fractor deckt TypoScript, FlexForms, Fluid und composer.json ab. Für Agenten bedeutet das: automatisierte Migration statt manueller Suche nach veralteten Patterns.

Was Sie in Ihrem Projekt tun können  

Die Core-Modernisierung liefert das Fundament. Der entscheidende Hebel liegt aber in Ihrem Projekt: in der Extension-Architektur, den Schreibpfaden und den Regeln, die Sie für Agenten hinterlegen.

Property Hooks statt Getter/Setter  

Legacy-Extbase-Modelle sind für Agenten oft zu groß, aber inhaltlich zu dürftig. Ein Agent liest Dutzende Zeilen triviale Zugriffsmethoden, bevor die eigentliche fachliche Abweichung sichtbar wird. PHP 8.4 Property Hooks verlagern relevante Logik dorthin, wo sie hingehört: direkt an die Property. Das spart pro Feld rund 85 % Boilerplate.

<?php
declare(strict_types=1);

final class Article extends AbstractEntity
{
  protected string $title = '';

  public function getTitle(): string
  {
      return $this->title;
  }

  public function setTitle(string $title): void
  {
      $this->title = trim($title);

<?php
declare(strict_types=1);

final class Article extends AbstractEntity
{
  public string $title = '' {
      set {
          $value = trim($value);
          if ($value === '') {
              throw new \InvalidArgumentException('Title must not be empty');
          }
          $this->title = $value;
      }
  }
}

Content Blocks statt TCA-Streuung  

TCA ist mächtig, aber als großes PHP-Array für Agenten ein denkbar schlechter Arbeitsraum. Content Blocks verschieben die Fachdefinition in eine deklarative YAML-Datei – TCA, SQL und Backend-Formulare werden automatisch generiert. Eine Änderung am Inhaltstyp erfordert eine Datei statt vier.

name: webconsulting/faq-item
title: FAQ Item
typeName: wc_faq_item
fields:
- identifier: question
  type: Text
  required: true
- identifier: answer
  type: Textarea
- identifier: teaser_image
  type: File

DataHandler als einziger Schreibpfad  

Sobald ein Agent Daten in TCA-gemanagten Tabellen verändert, darf er nicht den bequemsten Weg nehmen, sondern den korrekten. In TYPO3 heißt dieser Weg DataHandler. Workspaces, Berechtigungen, Referenzindex und FAL-Relationen werden nur über diesen Pfad korrekt verarbeitet. Direkte QueryBuilder-Updates sehen kurzfristig schneller aus und kosten später Integrität.

<?php
declare(strict_types=1);

use TYPO3\CMS\Core\DataHandling\DataHandler;
use TYPO3\CMS\Core\Utility\GeneralUtility;

$data = [
  'tt_content' => [
      'NEW123' => [
          'pid' => 42,
          'CType' => 'textmedia',
          'header' => 'KI-fitte TYPO3-Architektur',
      ],
  ],
];

Projektregeln: .cursorrules, AGENTS.md und .cursor/rules  

Ein Agent ohne Projektregeln fällt auf generische Trainingsmuster zurück. Eine empirische Studie der UC Irvine (MSR 2026) analysierte 401 Repositories mit Cursor-Regeln und identifizierte eine klare Taxonomie: Conventions, Guidelines, Project Information und LLM Directives. Das Ergebnis: Persistente Regeln reduzieren die Varianz zwischen Sessions, Modellen und Entwickler:innen messbar.

AGENTS.md hat sich als Cross-Tool-Standard etabliert (Linux Foundation, Agentic AI Foundation). Cursor, Codex, Copilot, Windsurf und Devin lesen es nativ. Für TYPO3-Projekte gehören die kritischsten Pfade in dieses Format:

ALWAYS use TYPO3 DataHandler for write operations on TCA-managed records.
NEVER inject DataHandler via the constructor of another service.
ALWAYS prefer Content Blocks over manual TCA/SQL for new content types.
ALWAYS use PHP attributes (#[AsEventListener]) instead of Services.yaml tags.
ALWAYS run PHPStan and tests before proposing a refactoring as complete.
NEVER bypass Schema API with direct $GLOBALS['TCA'] access in new code.

Harness Engineering: Die Umgebung ist das Produkt  

Das Konzept des Harness Engineering beschreibt eine fundamentale Verschiebung: Nicht der Code ist das Produkt, sondern die Umgebung, in der Agenten Code produzieren. Ein Harness umfasst Verifikationsschleifen (Tests, Linter, CI), Kontextsteuerung (Dokumentation, Regeln), Constraints (Architekturregeln, Abhängigkeiten) und Feedback-Systeme (Logs, Metriken).

OpenAI demonstrierte das Prinzip in der Praxis: Ein Team von drei (später sieben) Engineers lieferte mit Codex-Agenten ein Produktionssystem mit rund einer Million Zeilen Code – jede Zeile von Agenten geschrieben, kein manueller Code. Die Engineers designten den Harness, nicht den Code.

Für TYPO3-Projekte besteht ein Minimum Viable Harness aus:

Strukturierte Spezifikationen statt Prosa  

Stefan van Egmond ließ 20 KI-Agenten dasselbe Feature implementieren – mit identischen Architekturregeln. Trotzdem wichen die Agenten bei grundlegenden Entscheidungen voneinander ab: Tags kopieren oder nicht, Status zurücksetzen, Fälligkeitsdaten übernehmen. Natural-Language-Spezifikationen sind mehrdeutig, schwer zu scannen und nicht testbar.

Die Lösung: Maschinenlesbare Spezifikationen, die auf Patterns aufbauen, die LLMs aus ihren Trainingsdaten bereits kennen – Pact Contracts, Design by Contract, Specification by Example. In TYPO3-Projekten lässt sich dieses Prinzip durch typisierte Interfaces, Contract-basierte DTOs und explizite Vor-/Nachbedingungen abbilden.

Priorisierte Roadmap für bestehende TYPO3-Projekte  

Fazit  

Wer TYPO3 für KI optimiert, schreibt nicht für Maschinen statt für Menschen. Er baut eine Codebasis, die für beide Seiten besser funktioniert: für Agenten, weil sie mit weniger Kontext präziser arbeiten können, und für Teams, weil Architekturentscheidungen sichtbarer und wiederholbarer werden.

TYPO3 bringt dabei einen Vorteil mit, der in der Diskussion oft übersehen wird: Der Core modernisiert sich bereits in die richtige Richtung. Schema API, strikte Typen, PSR-14 Events und die Content-Blocks-Infrastruktur sind keine Zukunftsversprechen – sie sind verfügbar und in Produktion einsetzbar. Die Frage ist nicht, ob sich die Investition lohnt, sondern wie schnell Sie die Brücke zwischen Core-Fundament und Projekt-Architektur schlagen.

Die drei stärksten Hebel auf Projektseite bleiben: weniger Boilerplate (Property Hooks, Content Blocks), explizitere Verträge (Typed Properties, PHP-Attribute, Schema API) und mechanische Absicherung (Harness Engineering mit PHPStan, Tests und CI-Gates).

Wenn Sie Ihre bestehende TYPO3-Codebasis darauf abklopfen wollen, wo KI heute noch gebremst wird, ist ein fokussierter Architektur-Review für TYPO3-Projekte der schnellste Startpunkt.