Wenn ich heute über Automatisierung in der Softwareentwicklung nachdenke, geht es mir längst nicht mehr nur darum, dass Codex Code für mich schreibt. Der eigentliche Reiz liegt für mich darin, den gesamten Weg von einer ersten Idee bis zu einer produktiv laufenden Änderung so weit zu strukturieren und zu automatisieren, dass ich nur noch an den Stellen eingreifen muss, an denen tatsächlich eine Entscheidung, eine Freigabe oder Verantwortung bei mir liegt.
Das Ziel ist also nicht, möglichst viele einzelne Arbeitsschritte durch KI zu ersetzen. Ich möchte vielmehr eine zusammenhängende Kette schaffen, in der ein Konzept sauber vorbereitet, technisch übersetzt, in Aufgaben zerlegt, umgesetzt, getestet und schließlich nach einer bewussten Freigabe ausgerollt wird.
Der Gartenstuhl-Test beschreibt dieses Ziel bereits aus einer eher praktischen Perspektive. Der vollständige Prozess dahinter ist allerdings deutlich umfangreicher als ein einzelner Klick auf „Freigeben“.
Am Anfang steht weiterhin nur eine Idee
Die erste Phase beginnt bei mir nicht in Visual Studio Code und auch nicht in Agenda, sondern meistens in ChatGPT.
Größere Themen lasse ich dort zunächst ausführlich hinterfragen, weil ich verhindern möchte, dass unklare Produktentscheidungen erst während der technischen Umsetzung entstehen. Aus einer zunächst groben Vorstellung wird Schritt für Schritt eine Spezifikation, in der fachliche Anforderungen, Sonderfälle, Abgrenzungen und offene Entscheidungen möglichst eindeutig beschrieben sind.
Diese Phase ist für mich entscheidend, weil sich Fehler hier noch sehr günstig korrigieren lassen.
Wenn ich nach zwanzig Fragen merke, dass die ursprüngliche Idee in eine falsche Richtung läuft, kann ich sie ändern, ohne bereits Code, Datenmigrationen oder eine halbe Benutzeroberfläche zurückbauen zu müssen.
Automatisierung beginnt deshalb für mich nicht beim Programmieren.
Sie beginnt mit einer ausreichend guten Beschreibung dessen, was überhaupt automatisiert umgesetzt werden soll.
Danach muss aus dem Konzept technische Arbeit werden
Sobald das fachliche Konzept stabil genug ist, kommt Codex ins Spiel.
ChatGPT und Codex erfüllen bei mir dabei bewusst unterschiedliche Aufgaben. ChatGPT hilft mir, die Idee zu verstehen und Entscheidungen zu treffen, während Codex anschließend den tatsächlichen technischen Kontext kennt und prüfen kann, wie sich die Spezifikation in das vorhandene Repository einfügt.
Bei kleinen Änderungen kann daraus relativ direkt eine Umsetzung entstehen. Bei größeren Themen möchte ich dagegen vermeiden, dass Codex versucht, das komplette Konzept in einem einzigen großen Arbeitsgang zu verändern.
Stattdessen soll das Vorhaben zunächst in einzelne, möglichst klar abgegrenzte Aufgaben zerlegt werden.
Diese Aufgaben landen anschließend in Agenda.
Agenda trennt Vorbereitung und Ausführung
Agenda ist für mich deshalb mehr als eine Aufgabenliste.
Ich kann ein großes Thema vollständig durchdenken und technisch vorbereiten lassen, ohne damit gleichzeitig die gesamte Umsetzung zu starten. Die einzelnen Arbeitspakete liegen bereit, besitzen Abhängigkeiten und können einzeln freigegeben werden.
Das ist gerade für mich als Einzelunternehmer wichtig, weil ich dadurch Arbeit zeitlich entkoppeln kann.
Ich muss nicht in demselben Moment planen, programmieren, testen und deployen.
Ich kann heute ein Konzept fertigstellen, Codex daraus Aufgaben erzeugen lassen und diese erst später starten, wenn die Voraussetzungen stimmen oder ich das dafür notwendige Kontingent einsetzen möchte.
Diese Trennung macht auch die parallele Arbeit mit mehreren KI-Systemen deutlich einfacher, weil unterschiedliche Phasen gleichzeitig laufen können, ohne dass alles unmittelbar miteinander vermischt wird.
Nach der Freigabe soll Codex möglichst selbstständig arbeiten
Wenn eine Aufgabe vollständig vorbereitet und von mir freigegeben wurde, möchte ich nicht jeden technischen Schritt einzeln bestätigen müssen.
Codex darf dann das Repository analysieren, Dateien verändern, Builds ausführen, Fehler untersuchen und innerhalb der vorhandenen Spezifikation technische Entscheidungen treffen.
Dabei gibt es für mich eine wichtige Grenze.
Eine technische Detailentscheidung darf Codex treffen, wenn sie sich aus der vorhandenen Architektur und den Anforderungen sinnvoll ableiten lässt. Sobald dagegen eine echte fachliche Entscheidung fehlt, soll die Aufgabe nicht einfach mit einer plausiblen Annahme weiterlaufen.
Dann möchte ich lieber eine sauber blockierte Aufgabe als eine eigenmächtig erfundene Produktentscheidung.
Automatisierung bedeutet für mich nicht, dass die KI alles selbst entscheiden darf.
Sie bedeutet, dass die KI möglichst viel selbstständig ausführen darf, nachdem die relevanten Entscheidungen bereits getroffen wurden.
Die Umsetzung ist erst der halbe Weg
Eine erfolgreiche Implementierung und ein grüner Build reichen mir nicht.
Meine automatisierten Tests sollen anschließend gezielt versuchen, Fehler zu finden, statt lediglich zu bestätigen, dass der offensichtlichste Ablauf funktioniert.
Idealerweise geschieht das ebenfalls ohne ständige manuelle Begleitung. Testfälle werden erzeugt, vorhandene Tests ausgeführt und gefundene technische Fehler können erneut in die Umsetzung zurückfließen.
Wenn eine eindeutige Abweichung von der Spezifikation gefunden wird, muss ich dafür nicht zwingend eingreifen. Codex kann die Ursache untersuchen, eine Korrektur vornehmen und die Tests erneut starten.
Erst wenn die Ursache in einer unklaren Anforderung oder einem echten fachlichen Konflikt liegt, brauche ich wieder selbst zu entscheiden.
Dadurch entsteht ein Kreislauf aus Umsetzung, Prüfung, Korrektur und erneuter Prüfung, der im Idealfall weitgehend automatisch ablaufen kann.
Gerade das Testing ist noch nicht vollständig gelöst
Dieser Teil meiner Zielkette funktioniert heute allerdings noch nicht so unabhängig, wie ich ihn langfristig gerne hätte.
Codex kann Tests schreiben, und ein spezialisierter Test-Agent kann zusätzliche Fälle erzeugen. Trotzdem basiert die Implementierung derzeit auf derselben grundlegenden KI-Technologie wie ein großer Teil der Prüfung.
Damit bleibt das Risiko bestehen, dass beide Seiten dieselbe falsche Annahme teilen.
Eine wirklich belastbare Automatisierung braucht für mich deshalb langfristig eine stärkere Trennung zwischen Umsetzung und Prüfung.
Ob dafür ein anderes Modell, ein völlig anderes KI-System oder eine Kombination aus mehreren Testverfahren sinnvoll ist, ist noch offen.
Gerade solche ungelösten Punkte gehören für mich bewusst zu diesem Prozess. Ich möchte nicht so tun, als wäre die vollständig automatisierte Entwicklung bereits fertig, nur weil einzelne Teile davon heute gut funktionieren.
Vor dem Deployment möchte ich wieder bewusst eingreifen
Wenn Umsetzung und Tests erfolgreich abgeschlossen sind, kommt der Punkt, an dem die Änderung produktiv werden könnte.
Genau dort möchte ich ein klares Human Gate behalten.
Codex darf das Deployment vollständig vorbereiten. Es kann prüfen, welche Version ausgerollt werden soll, welche Datenbankänderungen notwendig sind, ob Abhängigkeiten erfüllt sind und welche Risiken bekannt sind.
Der tatsächliche Schritt in die produktive Umgebung soll aber erst stattfinden, nachdem ich ihn bewusst freigegeben habe.
Das ist für mich keine Schwäche der Automatisierung.
Es ist eine gewollte Grenze.
Solange ich allein für meine Systeme und Ergebnisse verantwortlich bin, möchte ich den Übergang von „technisch vorbereitet“ zu „produktiv verändert“ nicht vollständig aus der Hand geben.
Auch nach dem Deployment ist die Aufgabe noch nicht beendet
Ein erfolgreicher Deployment-Befehl beweist noch nicht, dass die neue Version tatsächlich funktioniert.
Vielleicht ist der Prozess technisch ohne Fehler durchgelaufen, aber ein Dienst startet anschließend nicht korrekt. Vielleicht funktioniert die Anwendung, aber eine wichtige Schnittstelle ist nicht mehr erreichbar. Vielleicht wurde eine Migration ausgeführt, das Ergebnis entspricht aber nicht dem erwarteten Zustand.
Deshalb gehört für mich eine automatische Prüfung nach dem Deployment zwingend in dieselbe Kette.
Die erwartete Version muss aktiv sein.
Notwendige Dienste müssen laufen.
Zentrale Funktionen müssen erreichbar sein.
Kritische Fehler in Logs oder Healthchecks dürfen nicht ignoriert werden.
Erst wenn diese Prüfungen erfolgreich waren, sollte Agenda eine Aufgabe tatsächlich als abgeschlossen betrachten.
Damit wird das Deployment nicht zum letzten technischen Befehl, sondern zum Übergang in eine weitere Prüfphase.
Rollback gehört genauso zum Konzept wie Deployment
Wenn ein Post-Deployment-Check fehlschlägt, stellt sich sofort die nächste Frage: Was passiert dann?
Eine gute Automatisierung darf nicht ausschließlich den glücklichen Weg kennen.
Je nach Anwendung könnte Codex eine vorherige Version wiederherstellen, ein Deployment stoppen oder einen eindeutig definierten Rückfallweg ausführen. Bei anderen Änderungen möchte ich möglicherweise bewusst selbst entscheiden, bevor ein Rollback startet.
Welche Variante sinnvoll ist, hängt stark vom jeweiligen Projekt und der Art der Änderung ab.
Entscheidend ist für mich nur, dass der Fehlerfall bereits Teil des Konzepts ist.
Wenn ein automatisierter Prozess nur dann funktioniert, wenn alles problemlos läuft, ist er noch nicht besonders weit automatisiert.
Der Prozess soll mich nur an den richtigen Stellen brauchen
Mein langfristiges Ziel lässt sich deshalb relativ einfach formulieren.
Ich möchte nicht bei jedem technischen Zwischenschritt gebraucht werden.
Ich möchte dort gebraucht werden, wo meine Rolle tatsächlich wichtig ist.
Bei der Entscheidung, was gebaut werden soll.
Bei Prioritäten.
Bei fachlichen Konflikten.
Bei ungewöhnlichen Risiken.
Und bei der bewussten Freigabe produktiver Änderungen.
Dazwischen darf die Technik gerne so viel Arbeit übernehmen wie möglich.
Das unterscheidet sich deutlich von der Vorstellung, KI solle irgendwann einfach völlig autonom Software entwickeln.
Ich möchte keine Autonomie um ihrer selbst willen.
Ich möchte möglichst wenig unnötige operative Abhängigkeit von meiner persönlichen Anwesenheit.
Als Einzelunternehmer ist genau das für mich besonders interessant
Wenn ich ein Team hätte, könnte ich Arbeit zwischen mehreren Menschen verteilen. Ich habe aber keine Angestellten und erledige Entwicklung, Tests, Betrieb, Konzeption und viele weitere Aufgaben selbst.
Deshalb besitzt Automatisierung für mich eine andere Bedeutung als nur Kostensenkung oder zusätzliche Geschwindigkeit.
Sie schafft Kapazität, die sonst gar nicht vorhanden wäre.
Das wird spätestens beim Thema Urlaub besonders deutlich, weil ein vorbereiteter Prozess weiterlaufen kann, ohne dass ich dafür wieder mehrere Stunden mit dem Laptop arbeiten muss.
Dasselbe gilt im normalen Alltag. Während eine freigegebene Aufgabe umgesetzt und getestet wird, kann ich bereits an einem anderen Konzept, einem Kundenthema oder einem völlig anderen Teil meines Unternehmens arbeiten.
Der fertige Ablauf ist noch ein Zielbild
Wenn ich den gesamten Prozess heute aufschreibe, sieht er ungefähr so aus:
Idee und fachliche Konzeptarbeit in ChatGPT.
Strukturierte Spezifikation als Übergabe.
Technische Analyse durch Codex.
Zerlegung in einzelne Aufgaben.
Verwaltung und Freigabe über Agenda.
Automatisierte Umsetzung.
Automatisierte Tests und gegebenenfalls Korrekturschleifen.
Vorbereitung des Deployments.
Bewusste Freigabe durch mich.
Automatisiertes Deployment.
Automatische Prüfung des produktiven Zustands.
Und bei Bedarf ein definierter Rückfallweg.
Einzelne Teile davon funktionieren heute bereits gut, andere existieren als Konzept und manche sind noch echte Baustellen.
Genau darin liegt für mich der interessante Teil.
Ich versuche nicht, nachträglich eine perfekte Methode zu beschreiben, die längst abgeschlossen ist. Ich baue diesen Prozess gerade auf und sehe währenddessen, welche Annahmen funktionieren und welche ich wieder ändern muss.
Wenn irgendwann tatsächlich eine sauber vorbereitete Idee bis zum überprüften produktiven Ergebnis durch diese Kette laufen kann, ohne dass ich dazwischen ständig technische Kleinarbeit erledigen muss, wäre mein eigentliches Ziel erreicht.
Nicht die vollautonome KI.
Sondern eine Softwareentwicklung, bei der ich meine Zeit möglichst dort einsetze, wo sie nicht sinnvoll automatisiert werden kann.