In der Softwareentwicklung starten viele von uns (mich eingeschlossen) den Tag heute mit einer neuen Session ihres Lieblings-KI-Coding-Assistenten – manchmal sogar noch vor der IDE – und lassen Coding Agents für uns die Implementierung übernehmen. Das zeigt, wie tief Tools wie Claude, GPT oder Gemini bereits in unserem Alltag verankert sind. Kein Wunder, denn die KI-Modelle machen riesige Sprünge in den Bereichen Qualität, Reasoning und Geschwindigkeit. Zudem setzen Tech-Unternehmen alles daran, Integrationen und Plugins zu entwickeln, die diese Modelle sinnvoll nutzen und uns die beste User Experience bieten.

​Ein Beispiel: Ein CLI wie Claude Code ist zu einem mächtigen Werkzeug geworden, mit dem man nicht nur schreibt, sondern auch plant, Agents steuert, eigene Workflows definiert und vieles mehr.

Durch meine private und professionelle Erfahrung mit Agentic Programming beschäftigt mich jedoch immer wieder eine fundamentale Frage:
​Wir schreiben Code mittlerweile oft nicht mehr selbst – aber müssen wir ihn überhaupt noch verstehen, steuern oder gar sehen?

In der ersten Phase der Code-Erstellung können wir theoretisch komplett loslassen und nur das Ergebnis aus funktionaler Sicht beurteilen. Doch spätestens, wenn in Production Bugs auftreten – und lieber Leser, du weißt, dass sie es tun werden – müssen wir in irgendeiner Form die Fehler verstehen und sie in der Codebasis fixen. Man könnte argumentieren: Die Modelle schreiben Code von Grund auf immer fehlerfreier, und falls später Bugs auftreten, beauftragen wir einfach wieder die KI, diese zu lösen. In dieser Logik ist selbst unverständlicher oder fehlerhafter Code nicht mehr unser Problem, sondern das der KI.

Doch in vielen Produktivumgebungen mit sensitiven Kundendaten ist es oft nicht ratsam – in manchen Fällen aus Datenschutzgründen sogar unmöglich –, der KI einen Zugriff zu gewähren, um diese Daten zu lesen und zu analysieren, Fehler zu reproduzieren und sie anschließend zu fixen. Hier kommt es zur ersten und oft bitteren Konfrontation zwischen dem Menschen und völlig fremdem Code.

Aber selbst wenn wir annehmen, dass KI-Tools auf Produktionsdaten zugreifen dürfen, müssen wir im nächsten Schritt der KI so weit vertrauen, dass sie diese Fehler durch Code- und Datenmanipulation fixen kann!

Den eigenen Code nicht zu kennen und die Architektur nicht aktiv mitzugestalten, sorgt später nicht nur für unangenehme Überraschungen, sondern kann gefährliche Folgen mit sich bringen. Diesen Ansatz finde ich in erster Linie unnötig und sogar ineffizient.

Gerade weil die KI das „Doing“ wunderbar übernehmen kann, können und sollen wir uns umso mehr auf die Architektur und Struktur konzentrieren sowie den „von Grund auf“ guten Code reviewen. Wir geben der KI die Richtung vor und bringen sie immer wieder auf den richtigen Track zurück, wenn sie davonläuft. Dass wir unseren Code nicht selbst schreiben, heißt nicht, dass wir ihn nicht kennen und genau so meinen.

Ein gut durchdachter und lesbarer Code ist nicht nur für den Menschen sinnvoll und „noch“ notwendig; auch die KI profitiert langfristig davon. Code, der auf einer gesunden Basis aufbaut, ermöglicht es der KI, auch zukünftige Features nach stabilen Mustern zu entwickeln, statt sich in einem Netz aus technischer Schuld zu verfangen.