Ein Agent bekommt eine Spezifikation, generiert Code, schickt ihn durch Unit-Tests, Mutationstests und statische Analysen und übergibt am Ende der Pipeline das Ergebnis zur Freigabe. Zwischen der ursprünglichen Aufgabe und der Auslieferung hat kein Mensch eine Zeile gelesen. Robert C. Martin, Autor von Clean Code, hat diesen Ansatz öffentlich beschrieben: Er liest den von seinen Agenten erzeugten Code nicht mehr, sondern umgibt die Agenten mit strengen Einschränkungen – Tests, Gherkin-Szenarien, QA-Verfahren, Qualitätsmetriken, Mutationstests, Testabdeckung. Er sagt, so gewinne er Vertrauen in den erzeugten Code, weil dieser den ganzen Prüfparcours durchlaufen muss.
Aussagen bekannter Persönlichkeiten ändern sich schnell, und Martin hat sein Vorgehen inzwischen relativiert. Darum geht es hier nicht. Dem Softwareentwickler Mark Seemann geht es um eine andere Frage: Was bedeutet es für die Softwareentwicklung, wenn KI-Agenten Code Review teilweise ersetzen? Am besten erklärt man das mit einem Bild, das du kennst – der Sicherheitskontrolle am Flughafen. Niemand durchsucht jedes Gepäckstück von Hand. Stattdessen greifen mehrere Schleusen ineinander: Röntgen, Metalldetektor, Stichprobe, Hundestaffel. Keine Station ist unfehlbar, aber zusammen filtern sie den größten Teil der Gefahren heraus. So funktioniert eine gute Testpipeline.
Warum das Lesen von Code nie ein Garant war
Wenn du diese Analogie akzeptierst, wirkt die Vorstellung, den Code nicht mehr zu lesen, weniger radikal. Der erste Reflex lautet: Wie soll man wissen, ob der Code korrekt ist, wenn ihn niemand anschaut? Dieser Reflex stammt aus einer Zeit, in der das Lesen die einzige Kontrolle war. Programmierer machen Fehler. Wir schreiben Code im Glauben, dass er etwas Bestimmtes tut, und stellen später fest, dass er sich anders verhält – eine Nullreferenz, eine Schleife, die um eins daneben liegt, ein Zustand, der unerwartet verändert wird. Das passiert ständig.
Code Review gehört zu den wirksamsten Methoden, um solche Defekte zu finden. Die Fachliteratur – etwa Code Complete, zweite Auflage, Kapitel 21 – weist darauf hin, dass systematische Reviews einen erheblichen Teil der Fehler abfangen. Aber nicht jeden. Manche Fehler entkommen selbst einer disziplinierten Inspektion. Ein Mensch, der auf Code schaut, war also nie narrensicher. Wer heute verlangt, KI-generierten Code in jedem Fall durchzulesen, verlangt eine Sicherheit, die auch das menschliche Lesen nie geboten hat.
Software Engineering als Abfolge falsifizierbarer Vorhersagen
Dave Farley beschreibt in Modern Software Engineering eine Sicht auf das Fach, die sich mit Seemanns eigener deckt. Software Engineering läuft im Kern darauf hinaus, rasch Rückmeldung auf falsifizierbare Aussagen über das System zu bekommen. Eine Behauptung wie „diese Funktion liefert die Summe der Bestellungen“ wird nicht dadurch wahr, dass sie plausibel klingt, sondern dadurch, dass ein Test sie widerlegen könnte und es nicht tut. Das Prinzip gilt, egal ob ein Mensch oder ein Modell den Code getippt hat.
Ein verwandtes Thema ist der Umgang mit KI-Agenten, die wie Teams organisiert werden: Ein Agent schreibt automatisierte Tests, ein zweiter macht das Code Review, ein dritter prüft die Konsistenz mit den Anforderungen. Ist das ein unendlicher Regress – wer prüft am Ende den Prüfer? Unsere menschenzentrierten Praktiken sind genauso wenig perfekt. Auch die testgetriebene Entwicklung, für Seemann der wissenschaftlichste Zugang zur Softwareherstellung, kennt ihre Fehlerquelle: Der häufigste TDD-Fehler ist der Test, den du nicht geschrieben hast. Ein fehlender Testfall lässt das System unterbestimmt, und niemand merkt es.
Die Haftungsfrage: Wer unterschreibt, wenn niemand schreibt?
Ein vollständig agentengesteuertes Release ist leicht vorstellbar: Menschen sind beteiligt, aber nicht als Programmierer und nicht als Reviewer. Niemand blickt in den Code, das Team verlässt sich auf andere Qualitätssicherungstechniken. Angenommen, die Fehlerquote liegt dabei niedriger als in jedem vergleichbaren menschlichen Prozess – niedriger, nicht null. Auch dann gelangen Fehler in die Produktion. Viele sind harmlos: eine leicht verschobene Schaltfläche, eine Anzeige in der falschen Sprache, eine doppelt eintreffende Nachricht. Andere gehen weiter: falsch berechnete Rabatte, ein hängendes Signal, im schlimmsten Fall eine tödliche Fehlfunktion.
Sobald der Schaden groß genug ist, stellt sich die Frage nach der Verantwortung. Am leichten Ende steht der Mars Climate Orbiter, der 327,6 Millionen Dollar kostete, ohne dass ein Gesetz gebrochen wurde. Ein Softwareunternehmen, in dem ein solcher Fehler ohne Konsequenz bleibt, wäre die Ausnahme – irgendjemand trägt die Folge, im Zweifel ein Sündenbock. Sobald rechtliche Haftung ins Spiel kommt, geht es vor Gericht, und wie im Dieselskandal können einzelne Entwickler zur Verantwortung gezogen werden. Ob das fair ist oder die tatsächlichen Abläufe widerspiegelt, ist nebensächlich. Gerichte bilden sich ihre Auffassung davon, wer verantwortlich ist, unabhängig davon, wie Software entsteht.
Der Dialog, den Seemann ironisch entwirft, trifft es gut. Ein Angeklagter wendet ein, das LLM habe den Fehler geschrieben. Das Gericht antwortet sinngemäß, es könne kein Sprachmodell ins Gefängnis schicken, sehr wohl aber die Person, die das Release abgezeichnet hat. Wer über ein vollständig KI-gesteuertes Vorgehen nachdenkt, muss die Haftungsfrage von Anfang an mitdenken. Die Unterschrift unter der Freigabe bleibt ein menschlicher Akt, auch wenn die Zeilen darunter maschinell erzeugt wurden.
Menschen spielen die Wahrscheinlichkeiten – das Tesla-Beispiel
Ein Blick in ein anderes Feld hilft. Im Juni 2026 hat die dänische Verkehrsbehörde Færdselsstyrelsen das Tesla-FSD-System zugelassen, mit der Auflage, dass der Mensch hinter dem Lenkrad letztverantwortlich bleibt. Fahrer sollen den Verkehr beobachten und eingreifen, sobald eine gefährliche Situation droht. Die Prognose ist absehbar: Je besser das System funktioniert, desto sorgloser werden die Fahrer. Nach einigen Wochen am Steuer sitzen viele am Handy und achten kaum noch auf den Verkehr. Es geht meistens gut.
Und dann kommt selten ein Unfall. Nach aktuellem dänischem Recht droht dem Fahrer, wenn Menschen ums Leben kommen, eine Verurteilung wegen fahrlässiger Tötung – in der Regel Freiheitsstrafe. Ob der Auslöser ein Softwarefehler war, ändert daran nichts. Rechtlich liegt die Verantwortung an einer anderen Stelle, oft weil die Gesetzgebung der technischen Realität hinterherhinkt. Dasselbe Muster, erwartet Seemann, wird sich bei KI-gesteuerter Softwareentwicklung einstellen. Menschen werden auf die Wahrscheinlichkeit setzen, weil sie verlockend aussieht. Wie viel Aufwand du in Absicherungen steckst, spielt dabei kaum eine Rolle: Du kannst das ausgefeilteste Verifikationssystem aufbauen und trotzdem für Fehler haftbar sein.
Das führt zu einer unangenehmen Frage: Wie fühlst du dich dabei, LLM-generierte Software zu veröffentlichen? Bist du bereit, für eine KI ins Gefängnis zu gehen? Die Antwort verlangt eine Vorstellung davon, was Verantwortung künftig bedeuten soll.
Was das konkret bedeutet
Software Engineering ist vielleicht nicht das, was wir geglaubt haben. Genauer: Es ist nicht auf die Methoden festgelegt, die um menschliche Programmierer und Tester kreisen. Eine vollständig automatisierte Softwareherstellung ist denkbar, und sie kann mindestens so sicher arbeiten wie das, was wir heute kennen. Der nicht-technische Teil dieses Wandels könnte der schwierigere werden.
Während die Systeme zuverlässiger werden, bleibt der menschliche Begriff von Haftung und Verantwortung zurück. Wenn etwas schiefgeht, schreiben Unternehmen den Fehler dann als „niemandes Schuld“ ab? Behandelt man schwere Defekte vor Gericht als eine Art Unfall, vergleichbar einem technischen Gebrechen? Oder trägt wieder ein Mensch die Verantwortung – und wer soll das sein, wenn niemand den Code geschrieben hat?
Für die Praxis folgt daraus mindestens eines: Wer KI-generierte Software veröffentlicht, sollte nicht nur in Tests und Code Review durch KI-Agenten investieren, sondern auch in eine klare Antwort auf die Unterschrift. Wer zeichnet ab, wer haftet, wer dokumentiert, welche Prüfungen wann stattgefunden haben. Die Testpipeline ist das eine, die Nachvollziehbarkeit der Entscheidung das andere. Der Flughafenvergleich hilft bis zuletzt: Die Kontrollen mögen automatisiert sein, doch die Verantwortung für das, was durchgelassen wurde, trägt der Betreiber – nicht das Röntgengerät.
Quelle: blog.ploeh.dk
