AI-Generated Code in der Praxis: Wie Agenturen 2026 Review, Freigabe und Qualität sauber organisieren

Warum Geschwindigkeit ohne Kontrolle teuer werden kann

AI-generierter Code ist 2026 in Agenturen kein Experiment mehr, sondern Alltag: kleine Refactorings, Boilerplate, Tests, Migrationsskripte, Template-Anpassungen, sogar Teile von Integrationen. Das Problem ist nicht, dass KI „zu viel kann“, sondern dass sie sehr schnell plausibel wirkende Änderungen produziert, die im echten Projektbetrieb schwer kontrollierbar werden, wenn Prozesse fehlen.

In Kundenprojekten sind die Kosten von Fehlern selten „nur“ technische Schulden. Typische Folgekosten sind: Regressionen in kritischen Checkout- oder Formularstrecken, Sicherheitslücken durch unbedachte Defaults, unklare Verantwortlichkeiten bei Incidents, und Zeitverlust, weil niemand mehr nachvollziehen kann, warum eine Änderung überhaupt so umgesetzt wurde. Besonders teuer wird es, wenn KI-Output als Autorität behandelt wird: „Die KI hat das so vorgeschlagen“ ist keine prüfbare Begründung.

Der zentrale Hebel ist daher nicht mehr die Frage, ob KI Code schreiben darf, sondern unter welchen Guardrails KI-Änderungen in ein Repository gelangen: nachvollziehbar, testbar, reviewbar, mit klarer Ownership und dokumentierten Entscheidungen. Geschwindigkeit ist dann ein Ergebnis guter Kontrolle – nicht ihr Ersatz.

Die häufigsten Fehler im Umgang mit AI-Code

1) Unerkannte Seiteneffekte durch „lokal plausiblen“ Code

KI optimiert häufig auf lokale Korrektheit: eine Funktion wird „schöner“, ein Service „sauberer“, ein Query „performanter“. In Legacy-Systemen sind aber Seiteneffekte oft Teil der Realität: implizite Caches, Event-Listener, Hook-Reihenfolgen, globale Konfigurationen, oder historisch gewachsene Workarounds. AI-Code kann diese Nebenbedingungen übersehen, weil sie nicht explizit im Prompt oder Kontext stehen.

2) Fehlerhafte Annahmen über Legacy-Code und Domain-Regeln

Ein Klassiker: Die KI nimmt an, dass ein Feld immer befüllt ist, dass IDs numerisch sind, dass Preise brutto/netto konsistent sind, oder dass ein Status-Enum vollständig ist. In Shop- und CMS-Projekten sind Domain-Regeln oft in Konfiguration, Datenbestand oder Integrationen „versteckt“. Ohne gezielte Tests und Review-Fragen rutschen solche Annahmen durch.

3) Security-Probleme durch unsichere Defaults

Viele KI-Vorschläge sind funktional, aber nicht sicher: fehlende Output-Escaping-Regeln, zu breite CORS-Settings, unzureichende Rechteprüfungen, unsichere Dateiuploads, oder SQL/Template-Injection-Risiken. Besonders riskant: „quick fixes“ in Controller- oder API-Schichten, die AuthZ/CSRF/Rate-Limits umgehen, um ein Symptom zu beheben.

4) Fehlende Nachvollziehbarkeit: Prompt, Kontext und Entscheidung verschwinden

Wenn niemand dokumentiert, welcher Auftrag an die KI ging, welcher Kontext genutzt wurde (Dateien, Logs, Tickets), und warum man eine Lösung akzeptiert hat, wird die Änderung später schwer wartbar. Das ist nicht nur ein Wissensproblem, sondern ein Compliance- und Haftungsproblem in Kundenprojekten.

5) Zu viel Vertrauen in Tool-Output statt in Tests und Reviews

KI kann überzeugend argumentieren, aber nicht garantieren, dass die Änderung im Projektkontext korrekt ist. Teams, die KI-Text als „Beweis“ behandeln, ersetzen Engineering durch Rhetorik. Der Gegenpol ist nicht Misstrauen, sondern verifizierbare Checks: Tests, Linting, Security-Scanner, reproduzierbare Builds, Review-Checklisten.

6) Unklare Ownership: „Die KI hat’s gemacht“

Ownership ist nicht optional. Wenn ein PR gemerged wird, muss klar sein, wer fachlich und technisch dafür einsteht. In Agenturen gilt das doppelt: Kundenerwartung, SLA/Support, und die Notwendigkeit, Änderungen auch Monate später erklären zu können. KI kann Autor sein, aber nicht Verantwortlicher.

Ein belastbarer Review- und Freigabeprozess für Agenturen

Ein praktikabler Zielprozess für 2026 muss zwei Dinge gleichzeitig leisten: (1) KI produktiv nutzbar machen, (2) Risiken systematisch abfangen. Der folgende Ablauf ist bewusst „langsam genug“, um sicher zu sein, und „schnell genug“, um im Alltag zu funktionieren.

Schritt 1: Analyse und Risiko-Klassifizierung (vor dem Prompt)

Bevor KI überhaupt Code schreibt, klassifiziert ihr die Änderung. Das entscheidet, welche Guardrails greifen.

• Low Risk: reine Refactorings ohne Verhaltensänderung, interne Typen, Kommentare, Tests ergänzen.
• Medium Risk: neue Features hinter Flags, UI-Anpassungen, neue Endpunkte ohne sensible Daten.
• High Risk: Auth/AuthZ, Checkout/Payment, personenbezogene Daten, Dateiupload, Admin-Funktionen, Deployment/CI, Security-relevante Konfiguration.

Praxisregel: Wenn ihr nicht sicher seid, ist es High Risk. Für High Risk gilt: kleinere Diffs, mehr Review-Augen, keine Auto-Merges, und zwingende Security-Checks.

Schritt 2: Begrenzter Auftrag an die KI (Scope und Constraints)

Der Prompt ist kein „Mach mal fertig“, sondern ein Arbeitsauftrag mit Grenzen. Gute Constraints reduzieren Halluzinationen und Seiteneffekte:

• Scope: Welche Dateien/Module dürfen geändert werden? Welche nicht?
• Akzeptanzkriterien: Welche Tests müssen grün sein? Welche Edge-Cases sind relevant?
• Architekturregeln: z.B. keine neuen Dependencies, keine DB-Schema-Änderung, keine Änderungen an Security-Middleware ohne explizite Freigabe.
• Projektkontext: relevante Code-Stellen, Logs, Ticket-Links (als Text), erwartetes Verhalten.

Wichtig: Der Prompt selbst wird Teil der Dokumentation. Speichert ihn im PR (z.B. als Abschnitt „AI Context“) oder als Datei im Repo (z.B. docs/ai/2026-05-11-ticket-1234.md). So bleibt nachvollziehbar, welche Annahmen die KI hatte.

Schritt 3: KI liefert Änderung als Diff-orientierten Vorschlag

Lasst euch Änderungen so geben, dass sie als Diff reviewbar sind: keine „hier ist der komplette File-Inhalt“ ohne Bezug. Wenn euer Tool das nicht kann, erzwingt es organisatorisch: kleine PRs, klar abgegrenzte Commits, und keine massenhaften Formatierungsänderungen im selben PR.

Schritt 4: Diff-Review mit Checkliste (nicht nur „sieht gut aus“)

Der Review ist der Kern. Für AI-Code braucht ihr eine andere Review-Haltung: weniger Vertrauen in die Intention, mehr Fokus auf Auswirkungen.

• Verhaltensänderung identifizieren: Was ändert sich für Nutzer, Admins, APIs, Jobs?
• Seiteneffekte: Caching, Events/Hooks, Transaktionen, Nebenläufigkeit, Fehlerbehandlung.
• Security: Input-Validierung, Output-Escaping, Rechteprüfung, CSRF, SSRF, Uploads, Secrets.
• Backward Compatibility: Datenformate, API-Responses, Template-Variablen, Extensibility.
• Observability: Logs, Metriken, sinnvolle Fehlermeldungen (ohne sensitive Daten).

Praxis-Tipp: Reviewer sollten mindestens eine „Gegenprobe“ machen: eine Stelle suchen, an der die Änderung nicht greift, aber greifen müsste, oder umgekehrt. Das deckt falsche Annahmen schnell auf.

Schritt 5: Lokale Tests (reproduzierbar, nicht „bei mir geht’s“)

Bevor CI läuft, sollte der Autor lokal die minimalen Checks ausführen. Das reduziert CI-Lärm und zwingt dazu, die Änderung wirklich auszuführen.

composer install

composer test

Wenn euer Projekt andere Standard-Commands hat, definiert sie zentral (z.B. in composer scripts) und macht sie zur Teamkonvention. Wichtig ist nicht das Tool, sondern die Reproduzierbarkeit.

Schritt 6: CI-Prüfung als Gate (Tests, Linting, Security, Build)

CI ist euer objektiver Schiedsrichter. Für AI-Code gilt: Kein Merge ohne grüne Pipeline. Und: Die Pipeline muss die Risiken abdecken, die KI typischerweise einführt (z.B. Security und Regressionen).

Für High-Risk-Änderungen ergänzt ihr verpflichtende Jobs: SAST/Dependency-Scan, Template-/XSS-Checks, Secret-Scan, sowie ggf. E2E-Smoketests.

Schritt 7: Manuelle Freigabe mit dokumentierter Entscheidung

Der letzte Schritt ist eine bewusste Entscheidung, nicht ein Klick. Dokumentiert im PR:

• Was wurde geändert? (1–3 Sätze, fachlich)
• Warum ist es korrekt? (Verweis auf Tests, Screenshots/Logs als Text, Edge-Cases)
• Welche Risiken bleiben? (z.B. „Legacy-Edge-Case X nicht abgedeckt“)
• Wer übernimmt Ownership? (Name/Rolle)

Das ist besonders wichtig, wenn KI beteiligt war: Die Dokumentation ersetzt das fehlende „Bauchgefühl“, das man bei selbstgeschriebenem Code oft hat.

Warum Auto-Merge, unkontrollierte Schreibrechte und fehlende Guardrails problematisch sind

Auto-Merge klingt nach Effizienz, ist aber in Kundenprojekten oft ein Risiko-Multiplikator:

• Auto-Merge: Wenn CI nicht alles abdeckt (und das tut sie nie), werden Fehler automatisiert in Produktion befördert.
• Unkontrollierte Schreibrechte: Wenn KI-Agents direkt in Hauptbranches pushen oder PRs selbst mergen dürfen, verliert ihr die klare Verantwortungs- und Prüfspur.
• Fehlende Guardrails: Ohne Branch-Protection, Review-Pflicht, und definierte Checks wird KI zum „schnellen Chaos“: viele kleine Änderungen, aber keine Sicherheit, dass das System als Ganzes stabil bleibt.

Die Agenturrealität: Ihr arbeitet oft parallel an mehreren Kunden, mit unterschiedlichen Release-Zyklen und SLA-Anforderungen. Ein einziger unkontrollierter Merge kann Support-Kosten und Vertrauen beschädigen, die den Produktivitätsgewinn von Wochen auffressen.

Welche Checks in TYPO3-, Shopware- und CI/CD-Workflows besonders wichtig sind

TYPO3: Konfiguration, Caching, Templates, Rechte

• Extbase/Fluid-Sicherheit: konsequentes Escaping, keine unvalidierten Request-Parameter in Queries.
• TypoScript/Config-Änderungen: kleine Diffs, klare Begründung, Auswirkungen auf Caching prüfen.
• Upgrade-/Compatibility-Fallen: KI schlägt gern APIs vor, die in eurer TYPO3-Version anders sind. Prüft Version-Kompatibilität explizit.
• Backend-Rechte: Änderungen an BE-Modulen/Permissions immer als High Risk behandeln.

Shopware: Checkout, Preise, Events, DAL

• Checkout/Payment: immer High Risk, immer zusätzliche Tests (mindestens Smoke/E2E).
• Preislogik: brutto/netto, Währungen, Rundungen, Steuerregeln. KI macht hier oft „mathematisch saubere“, aber fachlich falsche Vereinfachungen.
• Events/Subscribers: Seiteneffekte und Reihenfolgen prüfen; KI übersieht gern, dass andere Plugins mithören.
• DAL/Queries: Performance und Security (Filter, Criteria) prüfen; keine „quick queries“ ohne Indizes/Begründung.

CI/CD: Supply Chain, Secrets, reproduzierbare Builds

• Dependency-Änderungen: KI fügt gern Libraries hinzu. In Kundenprojekten: neue Dependencies nur mit Begründung, Lizenz-Check und Security-Scan.
• Secret-Scanning: verpflichtend, weil KI beim Debugging gern Tokens/Keys „beispielhaft“ einbaut.
• Build-Reproduzierbarkeit: Lockfiles, feste Versionen, keine „latest“-Tags in Build-Images.
• Branch-Protection: mindestens 1–2 Reviews, CI required, kein Direkt-Push auf main.

Wenn ihr Guardrails technisch verankern wollt, beginnt mit Branch-Protection und verpflichtenden Status-Checks. Das ist der kleinste Hebel mit großer Wirkung.

Fazit: Handlungsempfehlung für Teams, die KI professionell einsetzen wollen

AI-generierter Code ist 2026 dann ein Vorteil, wenn er in einen Prozess eingebettet ist, der Nachvollziehbarkeit, Testbarkeit und Ownership erzwingt. Der wichtigste Mindset-Shift: KI ist ein Beschleuniger für Umsetzung, aber kein Ersatz für Engineering-Disziplin.

• Definiert eine Risiko-Klassifizierung und koppelt daran Review- und Testpflichten.
• Macht Prompts und Kontext reviewbar und speicherbar (PR-Template oder docs/ai).
• Erzwingt kleine Diffs und eine Review-Checkliste, die Seiteneffekte und Security priorisiert.
• Setzt auf CI als Gate und verbietet Auto-Merge für High-Risk-Bereiche.
• Klärt Ownership: Jede Änderung hat einen verantwortlichen Menschen, unabhängig davon, wer den Code „geschrieben“ hat.

So bleibt KI ein Werkzeug, das Geschwindigkeit liefert, ohne Kontrolle zu verlieren – und eure Kundenprojekte bleiben wartbar, auditierbar und sicher.