Muss ein Entwickler den Code noch verstehen?

Ich gebe inzwischen Code frei, den ich nicht Zeile für Zeile gelesen habe. Das ist kein Geständnis, sondern der Alltag in der Softwareentwicklung mit KI. Die Rolle verschiebt sich: vom Mechaniker, der baut, zum Prüfer, der freigibt. Tragbar ist dieser Wechsel nur, wenn die Prüfung wirklich etwas prüft — und genau da wird es unbequem.

Was hat sich an der Arbeit eines Entwicklers wirklich verändert?

Früher lief die Arbeit in drei Schritten: verstehen, schreiben, testen. Am Ende stand ein Satz, der Verantwortung trug: „Ich habe es gebaut.“

Heute läuft sie so: Aufgabe beschreiben, Ergebnis prüfen, freigeben. Am Ende steht ein anderer Satz: „Es funktioniert.“

Das ist keine Randerscheinung mehr. Im DORA-Report 2025 von Google Cloud geben 90 Prozent der befragten Fachleute an, KI bei der Arbeit zu nutzen, und über 80 Prozent halten sich damit für produktiver. Im selben Report sagen 30 Prozent, sie hätten wenig oder gar kein Vertrauen in den erzeugten Code. Beides zusammen beschreibt die neue Rolle genau: Man arbeitet täglich mit etwas, dem man nicht traut — also prüft man.

Der Entwickler wird vom Mechaniker zum TÜV.

Der Vergleich ist nicht abwertend, im Gegenteil. Ein Prüfer baut nichts, und trotzdem hängt an seiner Unterschrift, ob ein Fahrzeug auf die Straße darf. Er kennt nicht jede Schraube. Er weiß, welche Punkte über die Sicherheit entscheiden. Genau diese Kompetenz zählt jetzt.

Warum ist „alle Tests grün“ kein Beweis?

Weil ein Testlauf nur das prüft, was jemand einmal hineingeschrieben hat. Das klingt banal, hat aber eine unbequeme Folge: Eine Suite kann beeindruckend umfangreich sein und trotzdem aus keinem Grund rot werden, den ein Kunde bemerken würde.

Das ist kein Verdacht, sondern gemessen. Inozemtseva und Holmes haben 2014 an großen Java-Programmen untersucht, wie gut Testabdeckung die Wirksamkeit einer Test-Suite vorhersagt. Ergebnis: Kontrolliert man die Größe der Suite, bleibt nur eine niedrige bis mittlere Korrelation — und strengere Abdeckungsmaße machen es nicht besser. Die Arbeit bekam auf der ICSE 2014 einen Distinguished-Paper-Award.

Für uns heißt das: Abdeckung ist keine Aussagekraft. Ich habe in unseren eigenen Projekten eine Suite, die genau in diese Falle läuft — viele Prüfungen, aber keine davon berührt einen Weg, den der Kunde tatsächlich geht.

Der Prüfstein dagegen ist eine einzige Frage: Würde dieser Test rot werden, wenn der Kunde morgen anruft? Wenn nicht, ist er Dekoration.

Was ist die gefährlichste Fehlerart in KI-Anwendungen?

Die, die wie Erfolg aussieht.

Eine unserer Anwendungen meldete brav, sie sei durchgelaufen: keine Auffälligkeiten. In Wahrheit hatte das Modell dahinter gar nicht geantwortet. Weder die Oberfläche noch die Tests haben es gemerkt — beide sahen einen erfolgreichen Lauf ohne Befunde. Ein leeres Ergebnis und ein sauberes Ergebnis sind auf dem Bildschirm nicht zu unterscheiden.

Dass Systeme mit maschinellem Lernen eine eigene Klasse verborgener Risiken tragen, ist keine neue Erkenntnis. Google-Forscher um D. Sculley haben das schon 2015 beschrieben: verwischte Systemgrenzen, unbemerkte Abhängigkeiten, Konfigurationsschulden — Fehlerarten, die klassische Software-Tests nicht abbilden, weil das Verhalten nicht nur im Code steht, sondern in Daten und Modellen.

Dazu kommt der menschliche Anteil, und der ist gut belegt. In einer kontrollierten Studie von Neil Perry und Kollegen (ACM CCS 2023) schrieben Teilnehmer mit KI-Assistent bei vier von fünf Aufgaben unsichereren Code als die Kontrollgruppe — und hielten ihren Code gleichzeitig eher für sicher. Wer der KI weniger vertraute und mehr an der Aufgabenstellung arbeitete, kam zu besseren Ergebnissen. Die Zuversicht wächst also schneller als die Qualität.

Die Sicherung dagegen ist billig. Bei jedem Lauf bekommt das Modell eine einzige, banale Frage gestellt, deren Antwort bekannt ist. Kommt sie nicht, ist der Lauf rot — egal, was die Oberfläche meldet. Bei uns steht das im Standard für betriebene Anwendungen; die Bestandsanwendungen ziehen wir eine nach der anderen darauf nach. Das ist ehrliche Vorleistung und keine Wochenendaufgabe, aber es ist dieselbe Arbeit, die man sonst bei jeder Freigabe von Hand macht — nur einmal statt jedes Mal.

Warum fühlt sich KI schneller an, als sie ist?

Hier liegt die zweite Falle, und sie betrifft nicht die Technik, sondern die Selbsteinschätzung.

Das Forschungsinstitut METR hat im Juli 2025 einen randomisierten Versuch veröffentlicht: 16 erfahrene Open-Source-Entwickler, 246 echte Aufgaben in Projekten, die sie im Schnitt seit fünf Jahren kennen. Mit KI-Werkzeugen brauchten sie 19 Prozent länger. Nach der Arbeit schätzten dieselben Entwickler, KI habe sie um 20 Prozent schneller gemacht. Vorher hatten sie 24 Prozent Beschleunigung erwartet.

Das Gefühl und die Messung zeigen also in entgegengesetzte Richtungen — bei Fachleuten, in ihrem eigenen Code.

Woran die Zeit hängt, zeigt die Stack-Overflow-Entwicklerumfrage 2025 sehr klar: 84 Prozent nutzen KI-Werkzeuge oder planen es, aber 66 Prozent nennen als größte Frustration Lösungen, die „fast richtig, aber nicht ganz“ sind, und 45 Prozent verlieren spürbar Zeit beim Debuggen von KI-Code. Nur 33 Prozent trauen der Genauigkeit, 46 Prozent misstrauen ihr ausdrücklich.

„Fast richtig“ ist die teuerste Kategorie, die es gibt. Falsch fällt auf. Richtig ist fertig. Fast richtig kostet die Prüfung, die man sich gerade sparen wollte. Wer wissen will, warum eine einzelne Kennzahl darüber nichts aussagt, findet die Rechnung dazu in unserem Artikel über 95 Prozent Genauigkeit.

Was passiert mit Code, den niemand mehr versteht?

Er wird nicht sofort falsch. Er wird unbeweglich.

GitClear hat für die Untersuchung „The Maintainability Gap“ 623 Millionen Code-Änderungen aus den Jahren 2023 bis 2026 ausgewertet. Die Richtung ist eindeutig: Doppelte Code-Blöcke haben um 81 Prozent zugenommen. Der Anteil verschobener Zeilen — das übliche Anzeichen für Aufräumen und Umbauen — ist von 21 Prozent im Jahr 2022 auf 3,8 Prozent gefallen, während kopierte Zeilen von 9,4 auf 15,7 Prozent gestiegen sind. Und neu geschriebener Code hängt sich seltener an vorhandenen an: Die Zahl der Aufrufe fremder Funktionen je tausend geänderter Zeilen ist seit 2023 um 35 Prozent gesunken.

Im Klartext: Es wird mehr geschrieben und weniger verstanden. Kopieren ist billiger geworden als Aufräumen — und wer kopiert, statt umzubauen, baut sich in fünf Jahren die Software, die niemand mehr anfassen will.

Der DORA-Report 2025 zeigt dieselbe Spannung von der anderen Seite. KI-Nutzung hängt dort inzwischen positiv mit dem Durchsatz zusammen — aber weiterhin negativ mit der Stabilität der Auslieferung. Der Satz, mit dem die Autoren das zusammenfassen, sollte in jeder Geschäftsführung hängen: KI repariert kein Team, sie verstärkt, was schon da ist. Wo Tests, Freigabe und Überwachung schwach sind, verstärkt sie eben das.

Wie sieht eine Prüfung aus, die etwas wert ist?

Fünf Punkte, an denen sich das im Alltag entscheidet:

Erstens: Die kritischen Wege werden so geprüft, wie der Kunde sie geht — im Browser, mit Anmeldung, mit echten Daten, nicht nur die Bausteine darunter.

Zweitens: Der KI-Pfad bekommt eine eigene, binäre Prüfung. Kam überhaupt eine Antwort? Diese Frage ist wichtiger als jede Qualitätsmessung, weil sie die Fehlerart abfängt, die wie Erfolg aussieht.

Drittens: Das Freigabekriterium heißt nicht „läuft in der Demo“, sondern „bleibt richtig, auch ohne mich“. Ein Tor, das auch greift, wenn ich müde bin oder ein Kollege freigibt, ist mehr wert als mein bester manueller Blick.

Viertens: Jede automatische Prüfung, die eine Handprüfung ersetzt, streicht diese Zeile aus der Freigabeliste. Sonst prüft man doppelt, und der Aufwand steigt statt zu sinken.

Fünftens: Nach der Freigabe wird gemessen, ob die Sache im Betrieb noch läuft und benutzt wird. Ohne diesen Teil beantwortet man nur „funktionierte es“, nicht „funktioniert es“.

Das ist der eigentliche Grund, warum wir so viel Aufmerksamkeit auf das Gerüst um ein Modell legen und nicht auf das Modell selbst — die Begründung dazu steht in Kontext schlägt Modell.

Was heißt das für einen Betrieb, der KI-Software einführt?

Du musst nicht Software lesen können. Aber du solltest andere Fragen stellen als „Ist das getestet?“.

Drei Fragen genügen, und sie funktionieren ohne jede Technikkenntnis:

Was wird geprüft — welche Wege, die unsere Leute wirklich gehen?

Woran würden wir merken, dass etwas kaputt ist, wenn niemand hinsieht?

Wer prüft, wenn die Person, die es gebaut hat, nicht mehr da ist?

Wer darauf klare Antworten bekommt, hat einen Partner. Wer als Antwort eine Prozentzahl bekommt, hat eine Behauptung.

Und die entlastende Nachricht: Das ist keine Frage von Konzerngröße. Ein kleiner Betrieb kann diese drei Fragen in zehn Minuten stellen — und ein guter Dienstleister freut sich darüber, weil sie die Arbeit sichtbar macht, die sonst niemand sieht.

Und wer schaut noch unter die Motorhaube?

Verstehen verschwindet nicht. Es wandert — von der einzelnen Zeile zum System und zu der Frage, woran man merken würde, dass etwas kaputt ist. Das ist eine andere Kompetenz als früher, aber keine kleinere: Wer freigibt, muss wissen, wo er hinschauen muss.

Der Umgang mit dieser neuen Rolle ist übrigens auch eine Frage der Aufmerksamkeit, nicht nur der Werkzeuge. Warum das Prüfen genau dann ausfällt, wenn man parallel etwas anderes anfängt, steht in Ist Deep Work mit KI noch möglich?.

Der TÜV baut den Motor nicht auseinander. Aber er weiß genau, wo er hinschauen muss.

Freigabe, die im Betrieb trägt?

Du willst wissen, ob die KI-Software in deinem Betrieb wirklich geprüft wird — und nicht nur grün meldet? Wir schauen uns gemeinsam an, welche Wege geprüft gehören und woran ein Ausfall auffällt.