Large Codebases & AI 2026: Warum Kontextbegrenzung wichtiger ist als Modellgröße

Large Codebases und AI 2026: Warum Kontextbegrenzung wichtiger ist als Modellgröße

In großen, gewachsenen Codebases ist „mehr Kontext“ nicht automatisch „bessere Antworten“. 2026 sind Modelle zwar leistungsfähiger, aber die Engpässe liegen in der Praxis woanders: in der Kontextauswahl, der Reproduzierbarkeit von Änderungen und der Disziplin, mit der Teams Scope begrenzen. Wer AI in Enterprise-nahen TYPO3-/PHP- oder Monorepo-Umgebungen produktiv einsetzen will, muss weniger über Modellgrößen diskutieren und mehr über Kontextstrategien, Diff-Workflows und Architekturgrenzen.

Dieser Artikel ordnet die technischen Ursachen ein und liefert einen praxistauglichen, reproduzierbaren Workflow für Teams mit großen Repositories: von Pfad-Filterung über Diff-first bis zu konkreten Teamregeln. Fokus: Entwickler in großen Projekten, Agenturen mit gewachsenen Codebases, DevOps-Verantwortliche und Teams, die AI nicht als „Chat“, sondern als Bestandteil eines Engineering-Prozesses nutzen.

Worum es wirklich geht (Suchintention)

• Technische Einordnung: Token-Limits, Kontextfenster, Retrieval, und warum „Kontextnutzung“ nicht gleich „Kontextgröße“ ist.
• Architektur: Grenzen, Module, Pfade, Ownership und wie man AI-Änderungen in großen Systemen kontrollierbar hält.
• Praxis: Diff-first-Strategien, Scope-Disziplin, reproduzierbare Prompts/Inputs und konkrete Empfehlungen.

Warum große Repositories AI vor neue Probleme stellen

In kleinen Projekten kann ein Modell oft „genug“ sehen, um sinnvolle Änderungen vorzuschlagen. In großen Repositories (Monorepos, Multi-Package-Setups, TYPO3-Instanzen mit Extensions, Legacy-PHP plus modernem Frontend) kippt das Verhältnis: Die Menge potenziell relevanter Dateien wächst schneller als die Fähigkeit, sie sinnvoll zu gewichten.

Typische Symptome in großen Codebases

• Unklare Source of Truth: Mehrere Konfigurationen, parallele Patterns, alte und neue APIs.
• Ähnliche Namen, unterschiedliche Semantik: z. B. mehrere „Service“-Klassen mit unterschiedlichem Lifecycle oder DI-Container-Setup.
• Querschnittsthemen: Logging, Security, Caching, Feature Flags, die überall „ein bisschen“ vorkommen.
• Historische Artefakte: Dead Code, veraltete Tests, nicht mehr genutzte Integrationen.

AI reagiert darauf mit einem Mix aus Overfitting auf zufällige Signale (falsche Korrelationen), „kreativen“ Ergänzungen (Halluzinationen) und Vorschlägen, die zwar lokal plausibel sind, aber global gegen Architekturregeln verstoßen.

Token-Limits vs. tatsächliche Kontextnutzung

Viele Diskussionen drehen sich um Kontextfenster: 32k, 128k, 1M Tokens. In der Praxis ist das nur die Obergrenze. Entscheidend ist, wie gut das Modell die relevanten Teile identifiziert und wie stabil es über lange Kontexte priorisiert. Mehr Kontext kann sogar die Qualität senken, wenn irrelevante Informationen dominieren.

Warum „großes Kontextfenster“ nicht automatisch hilft

• Aufmerksamkeitsverdünnung: Relevante Details konkurrieren mit vielen irrelevanten Tokens.
• Konfliktierende Signale: Alte Patterns und neue Patterns stehen nebeneinander; das Modell mischt sie.
• Fehlende Projektintention: Architekturentscheidungen sind selten vollständig im Code dokumentiert.
• Retrieval ist nicht Magie: RAG/Indexing findet „ähnliche“ Stellen, nicht zwingend die „richtigen“.

Risiken von „zu viel Kontext“: Noise, Halluzinationen, falsche Korrelationen

In großen Repos ist das Risiko nicht nur, dass AI „etwas Falsches“ sagt, sondern dass sie es überzeugend sagt. Drei Failure-Modes sind besonders relevant:

• Noise: Unwichtige Dateien (z. B. alte Migrationsskripte) beeinflussen die Lösung stärker als die aktuelle Implementierung.
• Halluzinationen: Das Modell ergänzt nicht existierende Klassen/Config-Schlüssel, weil es sie aus ähnlichen Projekten „kennt“.
• Falsche Korrelationen: Eine zufällige Namensähnlichkeit führt zu falschen Abhängigkeiten (z. B. falscher Event-Listener, falscher Hook).

Das Gegenmittel ist nicht „noch mehr Kontext“, sondern kontextarme, überprüfbare Arbeitseinheiten: kleine Diffs, klare Pfade, klare Akzeptanzkriterien.

Diff-first-Strategie: Änderungen statt Codebase „erklären“ lassen

Diff-first bedeutet: AI arbeitet primär auf Basis einer konkreten Änderung (Diff, Patch, PR), nicht auf Basis einer vagen Aufgabenbeschreibung plus riesigem Kontextdump. Das reduziert Interpretationsspielraum und macht Ergebnisse reviewbar.

Warum Diff-first in Enterprise-Setups besser skaliert

• Review-Kompatibilität: Teams reviewen Diffs, nicht Chatverläufe.
• Reproduzierbarkeit: Der Input ist versioniert (Commit/PR), nicht „was gerade im Chat stand“.
• Scope-Kontrolle: Der Diff begrenzt, was sich ändern darf.

Praktischer Ablauf (Step-by-step)

• Step 1: Problem in ein kleines, testbares Ziel schneiden (z. B. „Nur Validierung in Controller X anpassen“ statt „Security verbessern“).
• Step 2: Relevante Pfade definieren (z. B. nur eine TYPO3-Extension, nur ein Package im Monorepo).
• Step 3: Minimalen Kontext bereitstellen: betroffene Dateien + angrenzende Interfaces/Contracts + relevante Config.
• Step 4: AI erzeugt einen Patch/Diff, nicht nur Text.
• Step 5: Lokale Checks ausführen (Tests, Lint, Static Analysis) und Ergebnisse als Feedback in die nächste Iteration geben.
• Step 6: Review anhand definierter Architekturregeln (z. B. „keine neuen Abhängigkeiten über Modulgrenzen“).

Pfad-Filterung und Scope-Disziplin: Der wichtigste Hebel

Pfad-Filterung ist die operative Umsetzung von Architekturgrenzen. Sie verhindert, dass AI quer durch das Repo „optimiert“ und dabei unbeabsichtigt Seiteneffekte erzeugt. In TYPO3-Projekten ist das besonders relevant, weil sich Logik oft über Extensions, Sitepackages, Konfiguration (TypoScript/YAML) und Composer-Abhängigkeiten verteilt.

Konkrete Regeln, die in der Praxis funktionieren

• Rule 1: Änderungen nur in einem definierten Pfad-Set zulassen (z. B. packages/sitepackage/ oder typo3conf/ext/my_ext/).
• Rule 2: Pro AI-Iteration maximal N Dateien ändern (z. B. 5–10), sonst neu schneiden.
• Rule 3: Keine „Drive-by-Refactorings“: Formatierungen, Umbenennungen, „Cleanup“ nur in separaten PRs.
• Rule 4: Abhängigkeiten sind explizit: neue Composer-Packages oder neue Services nur mit Architektur-Review.

TYPO3-/PHP-Beispiele: Wo Scope typischerweise aus dem Ruder läuft

• Extbase/DI: AI mischt Constructor Injection, GeneralUtility::makeInstance und Container-Services ohne Projektstandard.
• Konfiguration: Änderungen in YAML/TypoScript werden „mitgedacht“, aber nicht getestet; Ergebnis: Laufzeitfehler in bestimmten Sites.
• Monorepo: AI passt ein Shared-Package an, ohne alle Consumer zu berücksichtigen (Breaking Change).

Reproduzierbare Workflow-Strategien (für Teams, nicht für Einzelpersonen)

In großen Projekten scheitert AI-Einsatz selten an der Modellqualität, sondern an fehlender Prozesshygiene: Inputs sind nicht nachvollziehbar, Outputs nicht testbar, und Entscheidungen verschwinden im Chat. Reproduzierbarkeit heißt: Jede AI-Änderung ist mit denselben Schritten erneut herstellbar und überprüfbar.

Workflow-Baustein 1: „Context Pack“ als Artefakt

Statt „schick dem Modell das Repo“ erstellt ihr pro Task ein kleines Context Pack: relevante Dateien, kurze Architekturregeln, Akzeptanzkriterien, und die Kommandos, die grün sein müssen. Das kann als Datei im Repo liegen (z. B. docs/ai/contextpacks/TICKET-123.html oder .txt) und wird im PR referenziert (ohne Chat-Abhängigkeit).

Workflow-Baustein 2: Diff als primärer Output

Der Output ist ein Patch/Commit. Text ist nur Begründung. Das zwingt zu Präzision und reduziert „vage“ Vorschläge.

Workflow-Baustein 3: Checks als Gate

AI-Änderungen sind nur so gut wie die Gates. Für PHP/TYPO3-Umgebungen sind das typischerweise Unit/Functional Tests, PHPStan/Psalm, Coding Standards und ggf. Integrationstests.

composer install

composer test

Wichtig: Wenn euer Projekt andere Kommandos nutzt (z. B. phpstan, phpunit, rector, ecs), müssen genau diese in den Gate-Prozess. AI darf nicht „erfinden“, was grün sein soll; das Team definiert es.

Strukturierter Vergleich: Drei Kontextstrategien im Enterprise-Alltag

1) „Alles in den Kontext“ (Repo-Dump)

• Vorteil: Schnell, keine Vorbereitung.
• Nachteil: Hohe Noise-Rate, instabile Ergebnisse, schwer reproduzierbar.
• Geeignet für: Explorative Analyse, nicht für produktive Änderungen.

2) Retrieval/RAG „automatisch“

• Vorteil: Skaliert besser als Repo-Dump, findet ähnliche Stellen.
• Nachteil: Ähnlichkeit ist nicht Relevanz; kann falsche Patterns verstärken.
• Geeignet für: Code-Navigation, erste Hypothesen, aber mit menschlicher Pfad-Kontrolle.

3) Kuratierter Kontext + Diff-first (empfohlen)

• Vorteil: Niedrige Noise-Rate, reviewbar, reproduzierbar, teamfähig.
• Nachteil: Erfordert Disziplin und initiale Prozessarbeit.
• Geeignet für: Produktive Änderungen in großen TYPO3-/PHP-/Monorepo-Systemen.

Konkrete Empfehlungen für Teams (Checkliste)

• Definiert „Allowed Paths“ pro Task: Welche Verzeichnisse dürfen sich ändern? Alles andere ist out of scope.
• Setzt ein Diff-Limit: Wenn der Patch zu groß wird, Task splitten.
• Schreibt Architekturregeln kurz und hart: z. B. „Keine neuen Abhängigkeiten aus Extension A nach B“, „Nur PSR-Logger“, „Keine Global State Helpers“.
• Verlangt Tests als Output: Jede funktionale Änderung braucht mindestens einen Test oder eine nachvollziehbare Begründung, warum nicht.
• Behandelt AI wie einen Junior mit Turbo: schnell im Tippen, aber ohne Projektgedächtnis; Review bleibt Pflicht.
• Loggt Inputs/Outputs: Context Pack + Diff + Check-Ergebnisse gehören in den PR.
• Trainiert „Scope Language“: Aufgabenbeschreibung muss Grenzen enthalten (Pfad, Modul, API, Nicht-Ziele).

Realistische Caveats (damit es nicht in der Produktion knallt)

• Legacy-Zonen: In alten TYPO3-/PHP-Bereichen fehlen Tests. Diff-first hilft, aber ihr braucht zusätzliche manuelle Checks oder Snapshot-Tests.
• Konfigurationsdrift: Staging/Prod unterscheiden sich. AI kann das nicht erraten. Konfig muss Teil des Context Packs sein.
• Monorepo-Kopplung: Eine kleine Änderung kann viele Consumer betreffen. Ohne Impact-Analyse (z. B. Suche nach Imports/Usages) ist jeder Patch riskant.
• Security: AI kann sichere Patterns vorschlagen, aber auch unsichere. Security-Gates (SAST, Dependency Scans) sind nicht optional.

Fazit: Kontextbegrenzung ist Architekturarbeit

2026 entscheidet nicht primär die Modellgröße darüber, ob AI in großen Codebases hilft, sondern die Fähigkeit des Teams, Kontext zu begrenzen und Änderungen reproduzierbar zu machen. Diff-first, Pfad-Filterung und Scope-Disziplin sind keine „Prompt-Tricks“, sondern Engineering-Prinzipien. Wer sie konsequent umsetzt, bekommt weniger Halluzinationen, stabilere PRs und einen AI-Workflow, der zu Enterprise-Realitäten passt: reviewbar, testbar, auditierbar.

Wenn ihr in TYPO3-/PHP- oder Monorepo-Umgebungen arbeitet, ist die wichtigste Investition nicht ein größeres Modell, sondern ein kleiner, harter Prozess: Context Packs, klare Grenzen, und Checks als Gate. Das skaliert mit Teamgröße, Repo-Größe und Release-Druck.