KI-Code und das kaputte Belohnungssystem


KI-Code und das kaputte Belohnungssystem

Wir erleben gerade eine seltsame Umkehrung im Software Engineering. KI-Tools haben es trivial einfach gemacht, Code zu produzieren — irgendeinen Code — in unglaublicher Geschwindigkeit. Was früher Stunden sorgfältiger Überlegung erforderte, kann jetzt in Sekunden mit einem gut formulierten Prompt generiert werden. Oberflächlich betrachtet sieht das nach reinem Produktivitätsgewinn aus. In der Praxis entsteht dadurch ein kulturelles Problem.

Der Aufwand hat sich verschoben

Folgendes beobachte ich: Ein Ingenieur verwendet einen KI-Assistenten, um eine große Code-Änderung zu generieren. Die meiste Zeit fließt in den Prompt, vielleicht ein paar Iterationen, und dann wird das Ergebnis zum Code Review eingereicht. Der Code kompiliert. Vielleicht besteht er sogar die Tests. Die Code-Qualität ist jedoch nicht hoch — der Code ist schwer lesbar, schlecht strukturiert, voller subtiler Probleme, die erst sichtbar werden, wenn ein Mensch mit echter Erfahrung sich das Ganze sorgfältig ansieht.

Dieser Mensch ist der Reviewer.

Der Reviewer muss jetzt Code lesen und verstehen, den er nicht geschrieben hat, in einem Stil, den er nicht gewählt hat, der oft ein Problem auf eine Weise löst, die er nie so angegangen wäre. Er muss identifizieren, was falsch ist, erklären, warum es falsch ist, Verbesserungen vorschlagen und dann darauf warten, dass der Autor das Feedback in sein KI-Tool einspeist für eine weitere Runde. Und wieder. Und wieder.

Was früher ein kollaborativer Prozess war, ist zu einer Art Outsourcing geworden — nur dass das Outsourcing in die falsche Richtung geht. Der erfahrene Ingenieur, derjenige, der das System tatsächlich versteht, leistet jetzt die schwere kognitive Arbeit. Aber er tut das in der Rolle des Reviewers, nicht des Autors. Der Credit, die Impact-Metriken, der Launch — all das geht an die Person, die den Prompt eingetippt hat.

Das Belohnungsproblem

In den meisten Tech-Unternehmen wird Leistung an Impact gemessen. Features liefern, Code einreichen, Ergebnisse vorzeigen. Die Person, deren Name auf der Code-Änderung steht, bekommt den Credit. Das war schon immer eine Vereinfachung, aber es hat gut genug funktioniert, als das Schreiben von Code ein tiefes Verständnis des Problems und des Systems erforderte.

Jetzt ist diese Gleichung kaputt. Wenn die eigentliche intellektuelle Arbeit — das Verständnis, die Qualitätssicherung, das architektonische Urteilsvermögen — auf der Reviewer-Seite stattfindet, wir aber weiterhin den Autor belohnen, dann haben wir ein System gebaut, das das falsche Verhalten incentiviert. Wir belohnen Leute für die Produktion von Masse und vergessen die Leute, die Qualität sicherstellen.

Das ist nicht nur ein Code-Review-Problem. Die gleiche Dynamik spielt sich bei Dashboards, Design-Dokumenten, Konfigurationsänderungen ab — bei allem, wo KI die Produktion einfach, aber die Bewertung schwer macht. Wenn alles, was der Autor tut, darin besteht, Output mit einer KI zu generieren und sich dann darauf zu verlassen, dass erfahrene Kollegen die Probleme finden und Lösungen vorschlagen — was genau trägt der Autor dann bei?

Die Verantwortung muss zurück zum Autor

Ich denke, wir brauchen einen kulturellen Wandel. Die Verantwortung dafür, guten, überprüfbaren und verstandenen Code zu produzieren, muss beim Autor bleiben. KI-Tools zu verwenden ist in Ordnung — sogar großartig. Aber wenn man nicht jede Zeile seiner Änderung erklären kann, wenn man nicht begründen kann, warum der eigene Ansatz richtig ist, wenn man den Reviewer braucht, um die eigene Logik durch Review-Kommentare quasi neu zu schreiben, dann ist man nicht bereit, diese Änderung einzureichen.

Die Messlatte für Code Reviews sollte nicht sinken, nur weil das Produzieren von Code einfacher geworden ist. Wenn überhaupt, sollte sie steigen. Von Autoren sollte erwartet werden, dass sie Verständnis demonstrieren, nicht nur Output.

Und wenn sich herausstellt, dass der erfahrene Reviewer das Ganze selbst schneller und besser hätte schreiben können — dann sollte vielleicht genau das passieren. Es gibt keinen Produktivitätsgewinn, wenn ein Junior-Ingenieur Code per Prompt generiert, den ein Senior-Ingenieur dann mühsam über fünf Runden Review-Kommentare korrigieren muss. Das ist nichts anderes, als dass der Senior-Ingenieur den Code schreibt — nur mit zusätzlichen Umwegen.

Autoren sollten die Verantwortung übernehmen, deren Arbeit zu verstehen und zu Qualität zu liefern. Unsere Belohnungssysteme müssen widerspiegeln, wo der echte Aufwand und das echte Urteilsvermögen liegen — oder wir landen in einer Welt, in der die Leute, die den Code tatsächlich am Laufen halten, dafür keinerlei Anerkennung mehr bekommen.