9. April 2026

Fuenf agile Praktiken gegen die Qualitaetsfalle bei AI-generiertem Code

Das Problem: Schneller Code, versteckte Risiken

AI-Coding-Assistenten steigern die Produktivitaet messbar -- Studien zeigen Zuwachse zwischen 15 und 55 Prozent. Gleichzeitig entstehen neue Risiken, die sich mit klassischen Review-Prozessen schwer fangen lassen. AI-generierter Code sieht oft korrekt aus, enthaelt aber Sicherheitsluecken, schleppt technische Schulden ein oder produziert Bugs, die erst spaet auffallen. Ohne geeignete Leitplanken verschiebt sich das Problem lediglich: Die Entwicklungsgeschwindigkeit steigt, die Codequalitaet sinkt.

Die Antwort liegt nicht in neuen Werkzeugen, sondern in der konsequenten Anwendung bestehender agiler Praktiken -- angepasst an die spezifischen Fehlerklassen von AI-generiertem Code.

Die fuenf Praktiken

1. Test-Driven Development (TDD)

Tests zuerst schreiben, dann AI generieren lassen. Die Tests fungieren als ausfuehrbare Spezifikation und definieren das erwartete Verhalten, bevor Code existiert. Das ist entscheidend, weil AI-Agents dazu neigen, plausibel aussehenden Code zu produzieren, der subtile Anforderungen verletzt. InfoWorld nennt ein konkretes Beispiel: Eine AI-generierte Steuerberechnungsfunktion sah korrekt aus, verletzte aber gesetzliche Rundungsvorschriften. Ein vorab geschriebener Test haette das sofort gefangen.

2. Behaviour-Driven Development (BDD)

Given-When-Then-Szenarien liefern kontextreiche Spezifikationen in natuerlicher Sprache. Fuer AI-Agents sind sie besonders nuetzlich, weil sie die Intention hinter einer Funktion explizit machen -- genau das, was Agents typischerweise fehlt. Die Ergebnisse sind konkret: AI-generierter Code, der auf BDD-Szenarien basiert, erreicht laut dem Artikel eine Korrektheit von rund 95 Prozent.

3. Acceptance Test-Driven Development (ATDD)

Stakeholder definieren Akzeptanztests vor der Implementierung. Das schliesst eine Luecke, die TDD und BDD offenlassen: Geschaeftslogik, die nur die Fachseite kennt. Beispiel aus dem Artikel: Eine globale Rabattfunktion, die technisch korrekt implementiert war, aber die Geschaeftsregeln fuer bestimmte Produktkategorien ignorierte. ATDD haette das durch vorab definierte Akzeptanzkriterien verhindert.

4. Pair Programming

Zwei Entwickler, die gemeinsam AI-Output reviewen. Eine Studie zeigt einen klaren Befund: Code-Qualitaetsmetriken verschlechterten sich, wenn Entwickler AI-Tools isoliert nutzten. In Pair-Programming-Kontexten verbesserten sie sich. Der zweite Entwickler faengt nicht nur funktionale Fehler, sondern erkennt auch architektonische Fehlentscheidungen, die ein AI-Agent mangels Systemverstaendnis trifft.

5. Continuous Integration (CI)

Automatisierte Testsuiten bei jedem Merge, ergaenzt um spezialisierte Checks fuer AI-spezifische Risiken: Sicherheitsscans, Lizenzpruefungen, Abdeckungsmetriken. CI ist die letzte Verteidigungslinie und faengt Regressionen, die durch AI-generierte Aenderungen in bestehenden Code eingeschleust werden.

Was die Forschung zeigt

Der zentrale empirische Befund: Codequalitaet sinkt, wenn Entwickler AI-Tools allein nutzen. Sie steigt, wenn AI-Tools im Pair-Programming-Kontext eingesetzt werden. Das klingt kontraintuitiv -- mehr Augen auf weniger eigenen Code -- erklaert sich aber dadurch, dass der Review-Fokus sich verschiebt. Statt eigenen Code zu pruefen, bewerten zwei Entwickler fremden (AI-generierten) Code. Das erfordert kritischere Aufmerksamkeit und profitiert von geteiltem Domain-Wissen.

Empfehlung fuer den Alltag

Die fuenf Praktiken sind keine Entweder-oder-Entscheidung. Sie bilden gestaffelte Verteidigungslinien:

Wer bereits TDD praktiziert, hat die wichtigste Grundlage. Der naechste konkrete Schritt: AI-generierten Code nicht allein reviewen, sondern systematisch im Paar bewerten.

Quellen

Nach oben