In Software entwickelnden Firmen wird seit dem Aufschwung von Coding Agenten oft die Frage gestellt, wie mit generiertem Code umgegangen werden soll:
- Es wird mehr Code generiert, es mangelt oft an Zeit für Reviews – wie lässt sich das lösen?
- Muss der generierte Code überhaupt noch gereviewed werden?
- Wer ist eigentlich verantwortlich für die Änderungen im Code?
Ich sehe das recht pragmatisch: Die Grundlagen guter Softwareentwicklung ändern sich nicht, nur weil die Werkzeuge mächtiger werden.
Wer trägt die Verantwortung?
Der Autor des Codes ist weiterhin der- oder diejenige, die den Coding Agent "bedient". Er oder sie ist voll verantwortlich für das Ergebnis. Nur weil eine KI die Zeilen tippt, entbindet das den Entwickler nicht von der Pflicht, den Code zu verstehen und für seine Korrektheit einzustehen.
Coding Agents sind Werkzeuge – sehr mächtige zwar, aber am Ende zählt das Ergebnis, das wir als Profis in die Codebasis einchecken.
Masse statt Klasse?
Durch KI entsteht oft eine größere Menge an Code in kürzerer Zeit. Hier müssen wir kritisch prüfen: Ist dieser Code wirklich notwendig oder obsolet?
Wird hier echter Mehrwert geschaffen oder wurde gerade der fünfte redundante Test-Case generiert? Ich habe schon Test-Cases gesehen, die Assert.True(true) implementieren, nur damit "mehr Tests" da sind. Solcher Code muss gnadenlos wieder weg. Quantität ist kein Qualitätsmerkmal, und "Vibe Coding" darf nicht dazu führen, dass wir unsere Repositories mit Boilerplate und unnützem Code fluten.
Code-Reviews als Knowledge Transfer
Gerade das Code-Review ist ein essenzielles Vehikel für den Wissenstransfer (Knowledge Transfer) innerhalb des Teams. Dem Review muss mindestens so viel Aufmerksamkeit geschenkt werden wie dem Entwickeln selbst.
Mir ist bewusst, dass die Realität im Projektalltag oft anders aussieht und Reviews als lästig empfunden werden. Aber auch hier kann generative KI helfen, das Review zu strukturieren und zu ergänzen. Ein Prompt wie "Schau mal auf diesen und jenen Aspekt von PullRequest #123" kann der KI helfen, eine Voranalyse zu machen. So habe ich einen Startpunkt, um auch einen großen PR effizient zu reviewen, ohne mich in Details zu verlieren. Die KI ersetzt das Review nicht, sie assistiert dabei.
Klarheit durch Führungskräfte
Scrum-Master*innen, Projektleiter*innen, Architekt*innen und das Management haben die Aufgabe, Klarheit in Aussagen wie "Wir müssen mehr KI verwenden" und "KI kann uns helfen" zu bringen.
Es muss klar sein, was damit gemeint ist: Nicht das Ersetzen von Code-Reviews, Junior-Entwickler*innen und allem, was im Controlling vermeintlich nur Geld kostet. Gemeint sein muss die Unterstützung von Entwicklung UND Code-Reviews einer jeden Entwickler*in. KI soll uns befähigen, besser zu arbeiten, nicht die Qualitätssicherung wegzurationalisieren.
Die Pflicht der Entwickler*innen
Es ist die Pflicht von uns Entwickler*innen, die Verantwortung für unsere eigenen Code-Änderungen zu übernehmen – egal ob handgeschrieben oder generiert. Wir müssen Code-Reviews aktiv einfordern und uns gegenseitig ausreichend Zeit geben, damit diese stattfinden können. Nur so können wir den vollen Impact im Team erreichen und verhindern, dass die technische Schuld durch unkontrollierten KI-Code explodiert.
TL;DR
Coding Agenten erhöhen den Pace und verschieben die Perspektive noch weiter zum Erstellen von Code. Umso mehr liegt es an Entwickler*innen, diese Perspektive wieder zurechtzurücken und dem Code-Review ausreichend Raum zu verschaffen. Management, Scrum-Master und Architekt*innen müssen diesen Raum gewähren und Klarheit bezüglich der Verwendung von Coding Agenten signalisieren.
Unterstützung benötigt?
Ihr wollt Coding Agents in eurem Unternehmen einführen, aber seid unsicher, wie ihr die Prozesse und Reviews strukturieren sollt? Wir helfen euch gerne dabei! Meldet euch einfach über unsere Kontaktseite und wir schauen gemeinsam, wie wir euer Team fit für die Zukunft machen können.