Als ich angefangen habe, Codex intensiver für meine Softwareentwicklung einzusetzen, lag eine bestimmte Erwartung ziemlich nahe: Wenn die KI gut genug programmieren kann, müsste es doch eigentlich reichen, das gewünschte Ergebnis grob zu beschreiben und den Rest dem System zu überlassen. Bei kleinen, klar abgegrenzten Änderungen funktioniert das tatsächlich erstaunlich oft, doch je größer eine Aufgabe wird und je stärker sie vorhandene Architektur, Fachlogik, Datenmodelle oder mehrere Komponenten gleichzeitig berührt, desto deutlicher zeigt sich für mich, dass genau das Gegenteil gilt. Je mehr operative Umsetzung ich an Codex abgebe, desto wichtiger wird die Qualität der Beschreibung, auf deren Grundlage diese Umsetzung überhaupt stattfindet.
Das liegt weniger daran, dass Codex jede Kleinigkeit vorgeschrieben werden müsste, sondern daran, dass eine KI fehlende Informationen nicht einfach verschwinden lässt. Wenn eine Anforderung unklar ist, muss trotzdem irgendeine Entscheidung getroffen werden, damit die Arbeit weitergehen kann. Genau an diesem Punkt entscheidet sich, ob ich lediglich die technische Umsetzung delegiere oder zusätzlich unbemerkt Produktentscheidungen abgebe, die ich eigentlich selbst treffen wollte.
Kleine Aufgaben dürfen weiterhin klein bleiben
Nicht jede Änderung braucht eine ausführliche Spezifikation. Wenn ein Button an der falschen Stelle steht, eine eindeutig bekannte Fehlermeldung korrigiert werden soll oder eine klar abgegrenzte Methode ein nachvollziehbares Problem besitzt, wäre es unsinnig, daraus erst ein mehrseitiges Konzept zu machen. Eine gute Arbeitsweise erkennt für mich gerade auch, wann zusätzlicher Prozess keinen Nutzen mehr bringt.
Schwieriger wird es bei Aufgaben, die auf den ersten Blick ebenso einfach klingen, in Wirklichkeit aber viele nicht ausgesprochene Entscheidungen enthalten. Eine Anweisung wie „Baue eine automatische Wiederholung ein“ wirkt zunächst konkret, lässt aber offen, welche Fehler überhaupt wiederholt werden dürfen, wie oft ein erneuter Versuch stattfinden soll, welcher Abstand sinnvoll ist, was nach einem Neustart passiert, wie doppelte Ausführung verhindert wird und ab welchem Punkt der Vorgang endgültig als fehlgeschlagen gilt. Wenn ich diese Fragen nicht beantworte, hat sich die Arbeit nicht reduziert, sondern lediglich verschoben, denn irgendjemand oder irgendetwas muss sie später beantworten.
Genau deshalb orientiere ich die Länge einer Aufgabe heute stärker daran, wie viel fachliche Unsicherheit darin steckt. Eine technisch eindeutige Änderung darf in zwei Sätzen beschrieben sein, während eine Funktion mit mehreren Zuständen, Ausnahmen und langfristigen Auswirkungen entsprechend mehr Kontext benötigt.
Ich beschreibe stärker das gewünschte Verhalten als den Lösungsweg
ChatGPT und Codex erfüllen bei mir bewusst unterschiedliche Aufgaben, und das beeinflusst unmittelbar, wie ich Codex-Aufträge formuliere. In ChatGPT diskutiere ich zunächst, was eine Funktion fachlich leisten soll, welche Randbedingungen gelten und welche Entscheidungen getroffen werden müssen; Codex bekommt anschließend eine Beschreibung des gewünschten Verhaltens und soll dieses Verhalten sinnvoll in die vorhandene technische Struktur integrieren.
Früher war ich stärker geneigt, den konkreten Lösungsweg gleich mitzuliefern, weil ich selbst beim Schreiben der Aufgabe bereits darüber nachgedacht hatte, welche Klasse ich verändern, welche Methode ich ergänzen oder welche Datenstruktur ich verwenden würde. Heute versuche ich an dieser Stelle bewusster zu trennen. Wenn es sich nicht um eine verbindliche Architekturvorgabe handelt, interessiert mich weniger, ob Codex genau denselben internen Lösungsweg wählt wie ich, solange die bestehende Architektur respektiert wird und das fachliche Ergebnis stimmt.
Dadurch wird die Aufgabenbeschreibung nicht zwangsläufig detaillierter im Sinne von mehr technischen Anweisungen, sondern präziser in Bezug auf Ziel, Grenzen und überprüfbares Verhalten. Ich möchte Codex nicht erklären, wie es jede Zeile schreiben soll; ich möchte möglichst wenig Zweifel daran lassen, was nach der Umsetzung gelten muss.
Gute Aufgaben enthalten genauso deutlich, was nicht passieren darf
Eine der Veränderungen, die sich bei mir erst mit zunehmender Codex-Nutzung entwickelt hat, betrifft die Abgrenzung einer Aufgabe. Bei klassischer Entwicklung war es für mich relativ einfach, während der Arbeit zu erkennen, dass eine angrenzende Verbesserung zwar interessant wäre, aber nicht mehr zum aktuellen Thema gehört. Eine KI kann dagegen sehr schnell erkennen, dass sich im Umfeld einer Änderung noch weitere Strukturen vereinheitlichen oder refaktorieren ließen, und manchmal ist dieser Vorschlag technisch sogar ausgesprochen sinnvoll.
Trotzdem möchte ich nicht, dass aus jeder kleinen Änderung nebenbei ein größeres Umbauprojekt entsteht. Deshalb beschreibe ich heute bewusster, welche Bereiche verändert werden dürfen, welches bestehende Verhalten unverändert bleiben soll und an welcher Stelle Codex lieber eine Rückfrage beziehungsweise eine Blockierung erzeugen soll, statt einen größeren Schritt eigenständig einzuleiten.
Gerade bei KI-gestützter Softwarearchitektur wird diese Grenze für mich immer wichtiger, weil die Geschwindigkeit der Umsetzung sonst schnell größer wird als meine Fähigkeit, alle Nebenwirkungen vollständig zu beurteilen. Ein klar definierter Scope schützt also nicht nur den Code, sondern auch meine eigene Aufmerksamkeit.
Akzeptanzkriterien sind wertvoller als allgemeine Qualitätswünsche
Formulierungen wie „mach das sauber“, „achte auf gute Qualität“ oder „baue es robust“ klingen vernünftig, helfen bei der späteren Bewertung aber erstaunlich wenig. Sie beschreiben eine Erwartung, ohne eindeutig festzulegen, woran erkennbar ist, ob diese Erwartung erfüllt wurde.
Nützlicher sind konkrete, beobachtbare Zustände. Wenn ein Vorgang nach drei Fehlversuchen blockiert werden soll, gehört diese Regel in die Aufgabe. Wenn eine Funktion nach einem Neustart ihren Zustand wiederherstellen können muss, sollte das ausdrücklich erwähnt werden. Wenn ein Wert bei fehlender Datenbasis als unbekannt dargestellt werden soll und ausdrücklich nicht geschätzt werden darf, ist genau diese Aussage später sowohl für die Umsetzung als auch für die Prüfung wichtig.
Damit entsteht ein direkter Zusammenhang zu meinen automatisierten Tests. Gute Akzeptanzkriterien helfen nicht nur Codex beim Bauen, sondern schaffen eine unabhängige Grundlage dafür, das Ergebnis anschließend gegen die ursprüngliche Erwartung zu prüfen. Je klarer die fachliche Aussage formuliert ist, desto weniger muss die Testlogik aus dem vorhandenen Code erraten, was vermutlich gemeint gewesen sein könnte.
Technische Freiheit bleibt trotzdem wichtig
Eine gute Aufgabe bedeutet für mich ausdrücklich nicht, dass ich jede interne Entscheidung schon im Voraus treffen muss. Wenn Codex innerhalb eines Moduls zwischen zwei technisch gleichwertigen Implementierungen wählen kann und sich aus dem vorhandenen Projekt eindeutig ergibt, welche Variante besser passt, möchte ich diese Entscheidung nicht künstlich wieder an mich ziehen.
Die Grenze verläuft für mich dort, wo eine technische Entscheidung Auswirkungen auf das fachliche Verhalten, auf übergeordnete Architektur oder auf langfristige Zuständigkeiten besitzt. Ob eine Hilfsmethode intern anders strukturiert wird, ist häufig reine Umsetzung. Ob ein Prozess nach einem Fehler automatisch erneut ausgeführt wird oder auf eine Freigabe warten soll, ist dagegen eine Produktentscheidung.
Diese Unterscheidung ist nicht immer eindeutig, und gerade deshalb halte ich sie für so wichtig. Je autonomer Codex arbeitet, desto sinnvoller muss der Entscheidungsraum beschrieben sein, in dem diese Autonomie stattfinden darf.
Aus einer Spezifikation müssen sinnvolle Arbeitseinheiten entstehen
Eine ausführliche Spezifikation beschreibt bei größeren Themen häufig wesentlich mehr als eine einzelne technische Änderung. Sie enthält fachliche Regeln, Zusammenhänge, Abhängigkeiten und teilweise mehrere Funktionen, die nicht alle in einem einzigen Codex-Auftrag umgesetzt werden sollten.
Deshalb liegt zwischen Konzept und konkreter Umsetzung bei mir zunehmend eine weitere Aufgabe: Das größere Vorhaben muss in sinnvoll abgegrenzte Arbeitspakete zerlegt werden, die später in Agenda landen können. Eine gute Aufgabe sollte eigenständig genug sein, dass ihr Ergebnis nachvollziehbar geprüft werden kann, gleichzeitig aber nicht künstlich in so viele Kleinstschritte zerfallen, dass der Zusammenhang zwischen ihnen verloren geht.
Genau darin liegt eine der Schwierigkeiten automatisierter Planung. Eine einzige riesige Aufgabe erzeugt viel Veränderung auf einmal und macht spätere Fehler schwerer zuzuordnen, während hundert winzige Aufgaben unnötigen Steuerungsaufwand erzeugen und möglicherweise ständig denselben Kontext neu aufbauen müssen. Die richtige Granularität hängt deshalb nicht an einer festen Zahl von Dateien oder Zeilen, sondern daran, ob ein Arbeitspaket einen sinnvollen fachlichen oder technischen Abschluss besitzt.
Rückfragen sind kein Fehler des Systems
Ein Ziel meiner Vorbereitung ist natürlich, unnötige Rückfragen zu vermeiden. Wenn Codex nach wenigen Minuten feststellt, dass eine grundlegende Entscheidung fehlt, die ich bereits in der Konzeptphase hätte treffen können, war meine Aufgabe vermutlich nicht gut genug vorbereitet.
Trotzdem möchte ich nicht erreichen, dass Codex unter keinen Umständen mehr eine Frage zurückgeben darf. Das wäre sogar gefährlich, weil dann jede fehlende Information zwangsläufig durch eine eigene Annahme ersetzt werden müsste. Besonders bei größeren Themen ist es für mich völlig legitim, wenn die technische Analyse einen Konflikt sichtbar macht, den ich in der fachlichen Planung noch gar nicht erkennen konnte.
In meiner geplanten Prozesskette soll eine Aufgabe deshalb sauber blockieren können, wenn sie ohne eine echte Entscheidung nicht sinnvoll fortgesetzt werden kann. Ein blockierter Auftrag ist kein gescheiterter Automatismus, sondern kann genau das richtige Ergebnis sein, wenn dadurch verhindert wird, dass eine falsche Annahme tief in die Implementierung eingebaut wird.
Schlechte Anforderungen werden durch gute KI nicht ungefährlicher
Je besser Coding-Agenten werden, desto verlockender wird die Vorstellung, dass gute Anforderungen irgendwann weniger wichtig werden könnten, weil das Modell fehlende Details intelligent ergänzen kann. Technisch stimmt das zum Teil bereits heute, denn Codex kann aus erstaunlich knappen Beschreibungen plausible Lösungen ableiten und dabei vieles selbst erschließen.
Gerade darin liegt aber das Risiko. Eine schwache KI macht eine unklare Anforderung möglicherweise durch einen offensichtlichen Fehler sichtbar, während eine sehr gute KI eine falsche Interpretation so sauber und überzeugend umsetzen kann, dass sie erst deutlich später als Problem erkannt wird. Die Qualität des Codes kann dann sogar dazu beitragen, dass die falsche fachliche Richtung weniger auffällt.
Für mich ist das einer der Gründe, warum die intensive Konzeptarbeit vor der Umsetzung mit zunehmender KI-Leistung nicht an Bedeutung verliert. Je schneller aus einer Vorstellung ein funktionierendes System werden kann, desto günstiger ist es, einen Denkfehler vorher in einem Gespräch zu entdecken, statt ihn später aus einer professionell umgesetzten Lösung wieder herauszubauen.
Gute Aufgaben dienen auch dem zukünftigen Projektwissen
Eine präzise Aufgabenbeschreibung besitzt für mich inzwischen noch einen weiteren Wert: Sie dokumentiert, warum eine Änderung überhaupt vorgenommen wurde. Der fertige Code zeigt später den technischen Zustand, verrät aber nicht zwangsläufig, welche fachliche Erwartung dahinterstand und welche Alternativen bewusst ausgeschlossen wurden.
Projektwissen wird bei größeren KI-gestützten Projekten zunehmend zu einem eigenen Problem, weil Codex bei einer späteren Änderung nicht automatisch all die Entscheidungen kennt, die Monate zuvor zu einer bestimmten Struktur geführt haben. Gute Aufgaben und Spezifikationen können deshalb einen Teil dieser Geschichte bewahren, sofern die relevanten Erkenntnisse anschließend nicht einfach in abgeschlossenen Chats verschwinden.
Das bedeutet nicht, jede Codex-Unterhaltung dauerhaft zu archivieren und später wieder einzulesen. Interessant sind vielmehr die Entscheidungen, die langfristige Bedeutung besitzen und bei einer ähnlichen Aufgabe erneut berücksichtigt werden müssen.
Die Qualität der Aufgabe bestimmt irgendwann die Qualität der Automatisierung
Mein Gartenstuhl-Test ist im Grunde die praktische Konsequenz daraus. Wenn ich eine Aufgabe vom Smartphone aus freigeben möchte und anschließend nicht alle paar Minuten eingreifen will, muss vorher ausreichend klar sein, welches Ziel verfolgt wird, welche Entscheidungen bereits gefallen sind und wo die Grenzen der technischen Autonomie liegen.
Je stärker mein Prozess automatisiert wird, desto weniger sinnvoll ist es, fehlende Klarheit erst mitten in der Ausführung zu entdecken. Wenn später mehrere Agenten parallel arbeiten, Tests automatisch entstehen und Deployments nach definierten Freigaben selbstständig durchgeführt werden, wird eine unklare Aufgabe nicht nur zu einem kleinen Kommunikationsproblem, sondern kann mehrere nachgelagerte Schritte gleichzeitig in die falsche Richtung schicken.
Genau deshalb sehe ich gute Aufgabenbeschreibungen heute nicht als bürokratischen Zusatz zur eigentlichen Entwicklung. Sie werden selbst zu einem Teil der technischen Infrastruktur, auf der meine Automatisierung aufbaut.
Früher konnte ich eine unklare Anforderung während des Programmierens stillschweigend mit meinem eigenen Wissen ergänzen, weil Planung und Umsetzung im selben Kopf stattfanden. Heute möchte ich diese Verbindung bewusst aufbrechen, denn nur dann kann ich Umsetzung delegieren, ohne gleichzeitig die Kontrolle darüber zu verlieren, welches Produkt dabei entsteht.
Die Aufgaben werden dadurch nicht zwangsläufig immer länger. Sie werden aber bewusster. Und je mehr Codex für mich übernimmt, desto wertvoller wird genau diese Klarheit.