In einer aktuellen Folge eines Fachformats zum Thema Software-Testing sprechen Richard Seidl und Dr. Benjamin Hummel darüber, welche Aufgaben und welche Verantwortung Entwicklerinnen und Entwicklern bleiben, wenn Code von KI generiert wird. Die zugespitzte Frage lautet, ob am Ende nur noch das Lesen übrig bleibt. Sie trifft einen Punkt, der in Projekten längst spürbar ist: Der Engpass verschiebt sich von der Produktion zur Prüfung.

Der Aufwand wandert, er verschwindet nicht

KI-Assistenten erzeugen in kurzer Zeit große Mengen an Code. Das verkürzt die Phase, in der Zeilen entstehen — und verlängert die Phase, in der jemand beurteilen muss, ob diese Zeilen das Richtige tun. Wer eine Funktion selbst geschrieben hat, kennt die Annahmen dahinter. Wer sie vorgelegt bekommt, muss diese Annahmen erst rekonstruieren.

Das ist keine neue Disziplin. Code-Review, also die Durchsicht von Änderungen durch eine zweite Person, gehört seit Jahren zum Handwerk. Neu ist das Verhältnis: Früher war Review die Kontrolle über einen überschaubaren Zuwachs, heute kann sie zum Hauptanteil der Arbeitszeit werden. Wer Geschwindigkeitsgewinne einplant, sollte diesen Anteil mit einplanen — sonst wird Tempo im Entwurf durch Nacharbeit in der Integration aufgezehrt.

Lesen ist keine kleinere Tätigkeit

Generierter Code sieht oft plausibel aus. Er folgt gängigen Mustern, ist formatiert und kommentiert. Genau das erschwert die Prüfung, weil oberflächliche Signale für Qualität fehlen, an denen man früher hängen geblieben wäre. Die relevanten Fragen liegen tiefer:

  • Löst die Umsetzung die tatsächliche Anforderung oder nur die wörtlich formulierte Aufgabe?
  • Welche Randfälle sind behandelt, welche werden stillschweigend ignoriert?
  • Passt die Lösung zur bestehenden Architektur oder etabliert sie ein zweites Muster für dasselbe Problem?
  • Werden Daten korrekt validiert, Rechte geprüft, Fehler sauber behandelt?
  • Entstehen neue Abhängigkeiten, die gepflegt und aktualisiert werden müssen?

Diese Beurteilung setzt Erfahrung voraus. Man kann nur prüfen, was man selbst hätte entwerfen können. Das spricht dafür, in KI-gestützten Projekten nicht weniger, sondern gezielter Senior-Kompetenz einzusetzen — als Gegengewicht zur Menge.

Tests als das belastbarere Urteil

Reviews sind Stichproben durch Menschen und damit von Tagesform und Zeitdruck abhängig. Automatisierte Tests sind das wiederholbare Gegenstück. Sie beschreiben, was ein System leisten soll, und schlagen an, wenn eine Änderung diese Zusage bricht. In einem Umfeld, in dem Änderungen schneller und in größeren Blöcken eintreffen, steigt ihr Wert.

Wichtig ist die Blickrichtung. Tests, die nach dem generierten Code entstehen, bilden leicht nur ab, was der Code ohnehin tut — inklusive der Fehler. Tests, die aus der Anforderung abgeleitet werden, prüfen dagegen das gewünschte Verhalten. Deshalb lohnt es, fachliche Abnahmekriterien vor der Umsetzung zu formulieren, in einer Sprache, die auch Fachabteilungen verstehen.

Ebenso wichtig ist, dass hohe Testzahlen nicht mit Sicherheit verwechselt werden. Eine Kennzahl wie Testabdeckung — der Anteil des Codes, der bei Testläufen ausgeführt wird — sagt etwas über Reichweite, nicht über Relevanz. Entscheidend ist, ob die kritischen Pfade abgedeckt sind: Bezahlung, Anmeldung, Datenübernahme, Schnittstellen zu Drittsystemen.

Verantwortung bleibt bei Menschen

Für Auftraggeber ist die organisatorische Seite so wichtig wie die technische. Ein Assistenzsystem trägt keine Verantwortung; sie liegt bei denen, die den Code freigeben und betreiben. Diese Zuordnung sollte nicht implizit bleiben.

Praktisch heißt das, im Projektaufbau einige Punkte zu klären: Wer gibt Änderungen frei, und darf das dieselbe Person sein, die den Prompt formuliert hat? Welche Bereiche des Systems sind so sensibel, dass generierte Beiträge dort besonders geprüft oder ausgeschlossen werden? Wie wird dokumentiert, dass eine Änderung begutachtet wurde? Welche Regeln gelten für Lizenzen und für den Umgang mit internen Daten in Prompts? Und welche automatisierten Prüfungen müssen bestehen, bevor überhaupt ein Mensch liest?

Was sich im Projektalltag ändert

Sinnvoll ist eine Reihenfolge, in der Maschinen das Mechanische erledigen und Menschen das Urteil behalten. Statische Analyse, Formatierungsregeln, Abhängigkeits- und Sicherheitsprüfungen sowie die Testsuite laufen automatisch in der Build-Pipeline. Erst danach beginnt das fachliche Review — und dieses konzentriert sich auf Architektur, Randfälle und Nachvollziehbarkeit.

Hilfreich ist zudem, Änderungen klein zu halten. Große generierte Blöcke sind schwer zu beurteilen und werden im Zweifel durchgewinkt. Kleine, thematisch klar abgegrenzte Pakete lassen sich prüfen, testen und im Fehlerfall zurücknehmen.

Einordnung

Für Web- und Softwareprojekte bedeutet das eine verschobene Kostenstruktur: Was beim Schreiben eingespart wird, muss teilweise in Prüfung, Tests und Werkzeuge investiert werden — der Nettogewinn entsteht erst, wenn diese Struktur steht. Wer Angebote vergleicht, sollte daher nicht nur nach Geschwindigkeit fragen, sondern nach Review-Prozess, Testabdeckung kritischer Abläufe und klaren Freigabeverantwortlichkeiten. Die belastbarste Zusage in KI-gestützten Projekten ist nicht, wie schnell Code entsteht, sondern wie zuverlässig geprüft wird, was davon in Betrieb geht.

Quellen