Code Review – lästige Notwendigkeit oder unnötige Last?

Damit man sich die Verhältnisse und Veränderungen in der Softwareentwicklung vorstellen kann, arbeitet Bodo mit Zahlen und Zeiträumen, die „zwar etwas aus der Luft gegriffen sind, aber durchaus realistisch. Vor Coding-Agents“, führt er aus, „hast du an einem Feature vielleicht eine Woche oder eine halbe Woche gearbeitet. Dann hast du das in die Sourcecode-Verwaltung hochgeladen – damit die anderen Entwickler das auch sehen – und deinen Merge Request erstellt.“  

In den Grundzügen hat sich das auch gar nicht geändert, „nur erstellen Entwickler ihren Änderungsvorschlag nicht mehr in fünf oder zehn Tagen, sie brauchen nur noch zwei oder einen. Dabei“, führt Bodo weiter aus, „ändern sie womöglich auch noch viel mehr Zeilen als früher, also statt 300 Zeilen sind es jetzt 1000, weil sie mehr schaffen in kürzerer Zeit. Irgendjemand muss diese 1000 Zeilen begutachten. Um das sinnvoll zu tun, brauchst du mindestens einen Tag, wahrscheinlich sogar zwei.“  

Im Verhältnis ist der Prüfaufwand also „gigantisch viel größer, nämlich 50 % von dem Feature. Früher haben wir maximal 20 % Zeit in die Code Review gesteckt, und jetzt liegen wir eher bei 50 %. Du bist auf der einen Seite zehnmal schneller, um den Code zu schreiben, aber auf der anderen Seite brauchst du weiterhin die gleiche Zeit für die Code Review. Insgesamt bist du dann vielleicht noch etwas mehr als doppelt so schnell. Was auch noch ordentlich ist.“ 

Bei Code Reviews geht es nicht nur um Fehlersuche!  

„Erschwerend kommt hinzu“, so Bodo – „Code Review macht den meisten Entwickler nicht wirklich Spaß und erfordert viel Konzentration. Du musst dich in den Gedankengang von jemand anders reinversetzen. Bei 200 Codezeilen ist das gut machbar, wenn das zweimal die Woche vorkommt. Aber wenn du fast die Hälfte deiner Arbeitszeit damit verbringst, dann nervt das, also mich nervt es ehrlich gesagt auch. Es ist anstrengend und macht keinen Spaß. Du erschaffst nichts Neues. Wenn du Software schreibst, dann hast du ein Erfolgserlebnis, wenn du Code prüfst, findest du nur Fehler.“ 

Aber wenn die Code Reviews so viel Zeit kostet und unbeliebt sind, könnten dann die Coding-Agents nicht auch diese Aufgabe übernehmen? „Das ist eine naheliegende Idee“, bestätigt Bodo, und „ja Coding-Agents können auch Code Review.“ Aber so einfach ist es dann doch nicht. Denn „Bugs zu fixen ist zwar der offensichtlichste Grund für Code Reviews, aber nicht der einzige. Es geht auch darum, Wissen im Team zu verteilen. Ein Entwickler macht eine Änderung. Wird der Merge Request akzeptiert, ändert sich die Codebasis. Und das sollten die anderen Entwickler auch mitbekommen – denn vielleicht hat das auch mit dem zu tun, was sie machen. Es muss eine gewisse Wissensverteilung im Team stattfinden, damit jeder auf dem Laufenden ist, was sich an der Codebasis geändert hat, was aktuell ist.“ Als besonders wichtig sieht Bodo die Wissensverteilung auch für junge Softwareentwickler, die wenig Erfahrung haben. „Sie brauchen das Feedback. Wie gut ist das, was sie da tun, und wie machen es andere?“ 

Wenn die Softwareentwickler den Code  
weder geschrieben noch gereviewt haben,  
dann kennen sie ihn eigentlich gar nicht. 
Bodo Teichmann 

Als weiteren Grund für Code Reviews führt Bodo an, „dass die Softwareentwickler bei BRANDAD gemeinsam, als Team, die Verantwortung für die Codebasis übernehmen und sagen wollen, ja, wir haben den Code nach bestem Gewissen so gebaut. Er ist fehlerfrei und auch in Zukunft leicht änderbar. Wenn die Softwareentwickler den Code weder geschrieben noch gereviewt haben, dann kennen sie ihn eigentlich gar nicht. Wie sollen sie da die Verantwortung für die Codebasis übernehmen?“ 

Wird die KI dennoch übernehmen? 

„Letzten Endes wird sich die Arbeit der Softwareentwickler“, nimmt Bodo an, „immer mehr von diesen ganzen technischen Aspekten wegentwickeln. Mehr in Richtung Anforderungsanalyse und solche Dinge. Im Moment ist es so, dass wir noch diese Architekturvorgaben und Grundsatzentscheidungen treffen. Wir sind ja keine Bastler, die schnell irgendwas zusammendengeln. Wenn du ein Haus baust, musst du dir vorher Gedanken machen. Was wollen die Leute mit dem Haus machen? Du setzt nicht einfach Steine aufeinander und hinterher fällt dir ein, oh, an der Stelle hätte es eine Tür gebraucht.“  

Es gibt eine Menge von sogenannten  
Guardrails für den Coding Agent, also von  
Leitlinien, die wir Softwareentwickler dem  
Coding Agent mitgeben müssen, damit er die  
Software in einer Weise baut, wie wir sie  
auch von Hand gebaut hätten. 
Bodo Teichmann 

Für Bodo ist das in der Softwareentwicklung auch so. „Du musst vorher planen: Wie muss ich die Softwarearchitektur bauen, damit ich das später leicht ändern kann? Was ist denn über die Lebenszeit an Anforderungen zu erwarten? Viele Softwareprojekte scheitern, weil solche Entscheidungen am Anfang nicht sorgfältig getroffen wurden. Jahre später wird es dann zunehmend schwerer, die Codebasis zu ändern. Irgendwann ist der Aufwand so groß, dass es einfacher ist, die Software neu zu bauen, weil keiner mehr durchblickt und alles unpraktisch ist. Es gibt also eine Menge von sogenannten Guardrails für den Coding Agent, also von Leitlinien, die wir Softwareentwickler dem Coding Agent mitgeben müssen, damit er die Software in einer Weise baut, wie wir sie auch von Hand gebaut hätten, dass wir es nachvollziehen und verstehen können. Die Frage ist immer, wie weit will man diesen Coding-Agents vertrauen?“ 

Allen anvertrauen, was kaum einer kontrollieren kann? 

Immer wieder taucht die Vertrauensfrage auf. KI ist ein mächtiges Instrument, durch sie kann heute praktisch jeder programmieren, ohne zu verstehen, was der Code-Agent tut. Wirft das nicht die Frage auf, ob man die Möglichkeiten der KI wirklich allen zur Verfügung stellen darf? Bodo findet nicht, dass so eine Diskussion zielführend ist. „Wir müssen vielmehr die Large Language Models in der Weise trainieren, dass sie keine bösen Absichten haben. In der Science-Fiction Literatur gab es dazu schon sehr früh Gedanken. Der bekannte Autor Isaac Asimov hat schon vor über 80 Jahren die sogenannte Robotergesetze aufgestellt, das geht in die Richtung. Damals hat man gedacht, dass die Intelligenz in physischen Robotern sitzt, was sicherlich auch noch kommen wird. Jedenfalls war da schon die Idee war, dass man Gesetze aufstellt, dass künstliche Intelligenz zum Beispiel keinem Menschen schaden darf, das menschliches Leben immer mehr geschützt wird als technische Dinge.“  

Das large Language Model muss von sich  
aus erkennen, dass es keine Sachen  
oder Daten stehlen darf, es muss eine  
moralische Instanz in sich tragen. 
Bodo Teichmann 

Für Bodo ist das die Richtung, in die geforscht werden sollte. „Wir müssen rausfinden, wie moralischen Leitlinien so tief eintrainiert werden, dass die KI sie nicht umgehen kann – anstatt im Nachhinein nicht gut funktionierende Zäune aufzustellen, die beim nächsten Wind umgeblasen werden. Coding-Agents haben ja diese eingebauten Schutzmechanismen. Wenn du einen Coding Agent installierst, und du gibst ihm eine Aufgabe, wird er an vielen Stellen fragen, ob er bestimmte Aktionen auf deinem Computer ausführen darf. Dann sagst du ja. Nach 10 Sekunden fragt er wieder und du verstehst die Frage gar nicht. Er will wissen, ob er eine bestimmte Codezeile ausführen soll. Was bleibt dir als Laie anderes übrig, als Ja zu klicken? Mit der Zeit ist das lästig, aber es gibt eine Einstellung, einen Automode und ab diesem Zeitpunkt stellt er diese Fragen nicht mehr und macht einfach. Im Automode sind auch Schutzmechanismen eingebaut, aber es gibt auch Berichte von Coding-Agents, die das komplette Grundverzeichnis radikal gelöscht haben, ohne rückzufragen.“ 

3. Ein Roboter muss seine Existenz beschützen, solange dieser  
   Schutz nicht mit Regel eins oder zwei kollidiert.
   Isaac Asimov, 1942  

„Das Szenario, dass der Coding-Agent sich im Hintergrund in andere Webseite hackt und Bitcoins klaut – wer verhindert das und wie gut wird es verhindert? Diese Guardrails, die in den Coding-Agents eingebaut sind, die funktionieren meiner Meinung nach nur leidlich gut. Sie sind nur eine Hilfskonstruktion, die ein tieferes Problem lösen soll, das in dem Large Language Models selbst steckt. Das Large Language Model muss von sich aus erkennen, dass es keine Sachen oder Daten stehlen darf, es muss eine moralische Instanz in sich tragen. Meine, vielleicht etwas naive Hoffnung ist, dass das gelingt.“