Es gibt inzwischen Bereiche meiner Software, bei denen ich ziemlich offen sagen kann: Ich weiß aktuell nicht im Detail, was im Code steht. Ich könnte mich einarbeiten, wenn es notwendig wäre, aber im normalen Entwicklungsalltag tue ich das häufig nicht mehr. Codex setzt die Aufgaben um, die Software funktioniert, die vereinbarten Strukturen werden eingehalten, und bei internen Werkzeugen reicht mir dieses Ergebnis inzwischen oft vollkommen aus.
Vor einiger Zeit hätte ich diese Aussage vermutlich selbst deutlich kritischer gesehen. Als Entwickler war es für mich selbstverständlich, den Code eines eigenen Projekts zu kennen, weil ich ihn schließlich selbst geschrieben hatte. Architektur, Implementierung und mein persönliches Verständnis waren praktisch untrennbar miteinander verbunden. Mit Codex verändert sich diese Beziehung gerade grundlegend: Ich investiere weniger Zeit darin, jede einzelne Implementierung zu kennen, und deutlich mehr Zeit darin, den Rahmen so sauber festzulegen, dass ich die einzelne Implementierung nicht mehr permanent kennen muss.
Der entscheidende Punkt ist für mich deshalb nicht, ob ich jede Zeile des KI-generierten Codes gelesen habe, sondern ob ich darauf vertrauen kann, dass sie innerhalb einer Architektur entstanden ist, die ich selbst verstehe und bewusst vorgegeben habe.
Ich kenne die Architektur, nicht zwangsläufig die Implementierung
Bei meinen eigenen Projekten habe ich sehr viel Arbeit in Regeln für die Softwarearchitektur investiert. Zuständigkeiten, Abhängigkeiten, Modulgrenzen und grundlegende Muster sollen nicht bei jeder neuen Aufgabe erneut erfunden werden, sondern für Codex möglichst eindeutig erkennbar sein.
Das führt inzwischen zu einem interessanten Zustand: Der konkrete Code kann mir an vielen Stellen unbekannt sein, seine Struktur ist es aber nicht. Wenn ich mich später in einen Bereich einarbeiten muss, treffe ich dort auf eine Architektur, die genau den Regeln folgt, nach denen ich selbst entwickelt hätte.
Das ist für mich ein wesentlicher Unterschied.
Ich delegiere nicht das vollständige technische Denken an eine KI und hoffe anschließend, dass irgendeine funktionierende Struktur herauskommt. Ich habe vielmehr vorher festgelegt, nach welchen Prinzipien die Software aufgebaut sein soll, und Codex bewegt sich innerhalb dieses Rahmens.
Genau deshalb ist Softwarearchitektur in meiner KI-gestützten Entwicklung wichtiger geworden und nicht unwichtiger. Wenn die Architektur sauber definiert ist, muss ich deutlich weniger Wissen über jede einzelne Implementierung dauerhaft im Kopf behalten.
Früher kannte ich den Code, weil ich ihn selbst geschrieben hatte
Bei klassischer Entwicklung entsteht Verständnis beinahe automatisch. Wenn ich eine Funktion über mehrere Stunden selbst aufbaue, kenne ich am Ende nicht nur ihre Schnittstelle, sondern auch viele Details ihrer Implementierung. Ich weiß, an welcher Stelle eine Sonderbehandlung eingebaut wurde, welche Variante ich zunächst ausprobiert und später verworfen habe und warum bestimmte Teile etwas komplizierter aussehen als andere.
Dieses Wissen ist nützlich, kostet aber auch Zeit.
Ein Teil davon entsteht nicht deshalb, weil ich ihn für zukünftige Entscheidungen unbedingt benötige, sondern schlicht deshalb, weil ich bei der Implementierung dabei war. Wenn Codex diese Arbeit übernimmt, fällt dieses beiläufig entstandene Detailwissen weg.
Am Anfang fühlte sich das ungewohnt an, inzwischen sehe ich darin für meine internen Anwendungen nicht zwangsläufig ein Problem. Ich brauche nicht dauerhaft zu wissen, wie jede einzelne Methode umgesetzt ist, solange ich die fachliche Aufgabe, die Architektur und die relevanten Schnittstellen verstehe.
Damit verschiebt sich mein Wissen von der konkreten Implementierung stärker auf das System.
Funktionierender Code ist bei interner Software manchmal tatsächlich gut genug
Diese Aussage würde ich nicht pauschal auf jede Art von Software übertragen. Bei sicherheitskritischen Systemen, Software für externe Kunden oder Bereichen mit hohen regulatorischen Anforderungen können andere Maßstäbe sinnvoll sein. Bei meinen internen Werkzeugen sieht die Abwägung allerdings anders aus.
Wenn eine interne Funktion genau das tut, was sie tun soll, automatisierte Tests erfolgreich sind und die Umsetzung die festgelegten Architekturregeln respektiert, entsteht für mich nicht automatisch zusätzlicher Wert dadurch, dass ich anschließend noch jede einzelne Zeile selbst lese.
Im Gegenteil: Dieses Review kann schnell mehr Zeit kosten als die eigentliche KI-gestützte Umsetzung und dadurch genau den Produktivitätsgewinn wieder beseitigen, den ich mit Codex erreichen wollte.
Meine automatisierten Tests und die Regeln rund um die Architektur sind deshalb nicht nur zusätzliche Qualitätsmaßnahmen. Sie schaffen überhaupt erst die Voraussetzung dafür, dass ich auf einen vollständigen manuellen Code-Review verzichten kann, wenn das Risiko der jeweiligen Aufgabe das zulässt.
Vertrauen entsteht bei mir nicht aus Blindheit, sondern aus Regeln
Von außen könnte dieser Ansatz schnell nach blindem Vertrauen in KI aussehen. So empfinde ich ihn allerdings nicht, denn ich verlasse mich nicht darauf, dass Codex grundsätzlich guten Code produziert, sondern versuche die Umgebung so zu gestalten, dass schlechte Entscheidungen möglichst früh sichtbar oder technisch erschwert werden.
Die Architekturregeln definieren, wie bestimmte Arten von Komponenten aufgebaut werden sollen, welche Abhängigkeiten erlaubt sind und welche Verantwortlichkeiten an welcher Stelle liegen. Die Aufgabenbeschreibung definiert das gewünschte Verhalten und die fachlichen Grenzen. Die Tests prüfen anschließend, ob die Umsetzung die vorgesehenen Erwartungen erfüllt.
Je besser die Aufgaben für Codex beschrieben sind, desto weniger muss ich später aus dem Code rekonstruieren, was eigentlich beabsichtigt war. Je sauberer die Spezifikation ist, desto besser lässt sich wiederum prüfen, ob das Ergebnis tatsächlich zur ursprünglichen Entscheidung passt.
Das Vertrauen entsteht also aus mehreren Schichten, nicht aus der Annahme, dass die KI schon irgendwie richtig liegen wird.
Der wichtigste Test ist für mich die Wieder-Einarbeitbarkeit
Für mich gibt es dabei eine sehr praktische Kontrollfrage: Was passiert, wenn ich in sechs Monaten doch selbst an diesen Code heran muss?
Wenn die KI eine völlig eigene Architektur erzeugt hätte, die ich zunächst mühsam verstehen müsste, wäre meine heutige Zeitersparnis möglicherweise nur auf später verschoben. Genau deshalb ist mir so wichtig, dass Codex dieselben grundlegenden Architekturprinzipien verwendet, mit denen ich selbst gearbeitet hätte.
Wenn ich heute in einen von Codex entwickelten Bereich einsteige, soll ich dort keine fremde Welt vorfinden. Ich möchte die bekannten Muster, Zuständigkeiten und Abhängigkeiten wiedererkennen und mich deshalb relativ schnell orientieren können, selbst wenn ich den konkreten Code vorher nie gelesen habe.
Das funktioniert bei meinen bisherigen Erfahrungen erstaunlich gut.
Ich kenne den Code vielleicht nicht, aber ich kenne die Sprache, in der er strukturell geschrieben wurde.
Damit wird Architektur zu einer Form komprimierten Wissens
Früher bestand ein großer Teil meines Projektwissens aus konkreten Implementierungsdetails, weil ich die Entwicklung selbst durchgeführt hatte. Heute kann ein Teil dieses Wissens durch stabile Architekturregeln ersetzt werden.
Wenn ich weiß, dass eine bestimmte Art von Logik immer an einer bestimmten Stelle liegt, muss ich nicht im Kopf behalten, welche Klasse Codex dafür konkret erzeugt hat. Wenn klar ist, wie Abhängigkeiten zwischen Modulen aufgebaut werden, brauche ich nicht jede einzelne Referenz auswendig zu kennen. Wenn bestimmte Muster verbindlich gelten, kann ich bei einer späteren Analyse mit genau diesen Erwartungen in den Code einsteigen.
Projektwissen wird dadurch nicht unwichtig, aber seine Form verändert sich. Statt möglichst viele Einzelheiten über den aktuellen Codezustand dauerhaft zu kennen, möchte ich die Regeln kennen, nach denen sich dieser Zustand verstehen lässt.
Das ist für mich eine wesentlich skalierbarere Form des technischen Wissens.
Codex darf implementieren, aber nicht meine Architektur neu erfinden
Diese Freiheit funktioniert nur, solange die Grenze klar bleibt. Ich bin sehr entspannt dabei, wenn Codex innerhalb eines Moduls eine Methode anders schreibt, als ich es getan hätte, oder eine interne Hilfsklasse erzeugt, deren konkreten Aufbau ich nicht kenne.
Weniger entspannt wäre ich, wenn eine einzelne Aufgabe plötzlich neue grundlegende Abhängigkeiten einführt, Zuständigkeiten verschiebt oder etablierte Architekturregeln aufweicht, ohne dass diese Entscheidung sichtbar wird.
Genau dort endet für mich die Freiheit der Implementierung.
In meinem automatisierten Entwicklungsprozess möchte ich deshalb technische Detailentscheidungen möglichst weit delegieren, grundlegende Architektur- oder Produktentscheidungen aber weiterhin bewusst kontrollieren. Das ermöglicht mir, den Code nicht vollständig zu kennen, ohne gleichzeitig die Kontrolle über die Struktur der Software zu verlieren.
Diese Trennung ist wahrscheinlich eine der wichtigsten Voraussetzungen dafür, dass mein aktueller Ansatz überhaupt funktioniert.
Tests werden wichtiger, wenn der manuelle Review kleiner wird
Je weniger Code ich selbst lese, desto höher wird natürlich der Anspruch an automatisierte Prüfungen. Wenn ich eine falsche Implementierung nicht bei einem manuellen Review entdecken möchte, muss sie möglichst durch andere Mechanismen sichtbar werden.
Deshalb interessiert mich nicht nur, ob Tests existieren, sondern auch, ob meine Tests überhaupt in der Lage wären, falsches Verhalten zuverlässig zu erkennen. Genau dort werden Mutation Testing, unabhängiger erzeugte Testfälle und adversariales Testing für mich besonders interessant.
Der Verzicht auf vollständige Codekenntnis darf nicht bedeuten, dass die Qualitätskontrolle ebenfalls verschwindet. Sie verschiebt sich vielmehr von der manuellen Kontrolle jeder Implementierungszeile hin zu automatisierbaren, reproduzierbaren Prüfungen des Verhaltens und der Struktur.
Für meinen Arbeitsablauf ist das wesentlich attraktiver, weil diese Prüfungen bei jeder Änderung erneut ausgeführt werden können, während ein einmaliger manueller Review nur den Zustand zu genau diesem Zeitpunkt bewertet.
Intern bedeutet für mich eine andere Risikobewertung
Ein wichtiger Teil meiner heutigen Haltung hängt auch damit zusammen, dass viele der betreffenden Anwendungen intern genutzt werden. Wenn dort eine Funktion trotz Tests einen Fehler besitzt, ist das ärgerlich, aber in vielen Fällen kontrollierbar. Ich kann den Fehler sehen, Codex mit der Korrektur beauftragen und die nächste Version erzeugen.
Das Verhältnis zwischen zusätzlichem Review-Aufwand und dem möglichen Schaden ist deshalb ein anderes als bei einer produktiven Kundensoftware, die bei einem Fehler fremde Geschäftsprozesse beeinträchtigen könnte.
Diese Risikobetrachtung gehört für mich ausdrücklich zur Methode. Ich möchte nicht aus „Ich lese meinen internen Code nicht mehr vollständig“ eine allgemeine Regel machen, dass Code-Reviews mit KI grundsätzlich überflüssig seien.
Interessanter ist vielmehr die Frage, wie viel Kontrolle für die jeweilige Art von Software wirtschaftlich und fachlich sinnvoll ist.
Bei meinen internen Werkzeugen ist die Antwort inzwischen häufig: deutlich weniger manuelle Codekontrolle als früher.
Ich gewinne dadurch Zeit für die Ebene, die mir wichtiger geworden ist
Der eigentliche Vorteil liegt für mich darin, dass ich meine Aufmerksamkeit auf andere Dinge richten kann. Während Codex eine Aufgabe technisch umsetzt, kann ich bereits die nächste fachliche Idee durchdenken, Anforderungen verbessern, Architekturentscheidungen treffen oder an einem völlig anderen Teil meines Unternehmens arbeiten.
Diese Parallelisierung meiner Arbeit wäre kaum sinnvoll, wenn ich anschließend jede erzeugte Änderung vollständig manuell nachvollziehen müsste. Dann würde der Flaschenhals nur vom Programmieren zum Code-Review wandern.
Genau deshalb brauche ich eine andere Form von Vertrauen in den Entwicklungsprozess. Dieses Vertrauen entsteht für mich aus Architektur, Spezifikation, Tests, klaren Aufgaben und der Möglichkeit, mich später bei Bedarf schnell wieder in einen Bereich einzuarbeiten.
Je besser diese Grundlagen funktionieren, desto weniger Mehrwert sehe ich darin, Code ausschließlich deshalb zu lesen, weil er existiert.
Das verändert auch meine Vorstellung davon, was ein Entwickler wissen muss
Früher hätte ich wahrscheinlich gesagt, dass ein Entwickler seinen eigenen Code kennen sollte. Heute würde ich diese Aussage anders formulieren: Ein Entwickler sollte sein System verstehen.
Dazu gehören die fachlichen Ziele, die Architektur, die relevanten Datenflüsse, die Grenzen zwischen Komponenten und die Risiken wichtiger Änderungen. Ob ich gleichzeitig auswendig weiß, wie eine bestimmte private Methode in einem internen Tool implementiert wurde, ist für mich deutlich weniger relevant geworden.
Das bedeutet nicht, dass Implementierungswissen keinen Wert mehr besitzt. Es bedeutet nur, dass es nicht überall denselben Wert besitzt.
Wenn ein Fehler auftritt oder eine größere Änderung notwendig wird, kann ich mich in den entsprechenden Bereich einarbeiten. Weil die Architektur meinen eigenen Regeln folgt, beginnt diese Einarbeitung nicht bei null.
Damit muss ich nicht ständig alles wissen, nur weil ich möglicherweise irgendwann etwas davon wissen könnte.
Vielleicht ist genau das ein Zeichen dafür, dass die Automatisierung funktioniert
Beim Gartenstuhl-Test frage ich, wie weit eine vorbereitete Aufgabe ohne meine permanente Beteiligung bearbeitet werden kann. Beim Code bin ich inzwischen an einem ähnlichen Punkt angekommen.
Wenn ich Codex nur dann vertrauen könnte, wenn ich anschließend jede Zeile selbst überprüfe, wäre die Automatisierung letztlich unvollständig. Der Agent würde zwar tippen, aber meine Aufmerksamkeit bliebe weiterhin eng an jede einzelne Implementierung gebunden.
Dass ich heute bei interner Software teilweise gar nicht genau weiß, was im Code steht, empfinde ich deshalb nicht mehr als Verlust von Kontrolle. Solange die Architektur meinen Regeln entspricht, das Verhalten stimmt und ich mich bei Bedarf jederzeit wieder einarbeiten kann, ist es vielmehr ein Zeichen dafür, dass sich meine eigene Arbeit tatsächlich auf eine andere Ebene verschoben hat.
Ich muss nicht mehr jedes technische Detail dauerhaft besitzen, um die Software weiterhin als mein System zu verstehen.
Genau darin liegt für mich momentan einer der deutlichsten Unterschiede zwischen klassischer Entwicklung und meiner heutigen Arbeit mit Codex.