Im Moment arbeite ich allein, weshalb viele klassische Probleme eines Entwicklerteams für mich im täglichen Betrieb gar nicht auftreten. Wenn ich an einem Projekt etwas ändere, muss ich mich nicht mit einem Kollegen abstimmen, der gleichzeitig dieselbe Komponente bearbeitet, und ich brauche niemandem mitzuteilen, dass ich gerade einen bestimmten Bereich des Codes anfasse.
Mit Codex verändert sich diese Situation allerdings schon heute ein Stück weit, weil ich mehrere Arbeiten parallel anstoßen kann. Mehrere ChatGPT- und Codex-Arbeitsstränge können bei mir gleichzeitig laufen, obwohl weiterhin nur eine Person dahintersteht. Je stärker diese Parallelisierung wird, desto deutlicher tauchen Probleme auf, die bisher eher für größere Teams typisch waren.
Noch interessanter wird die Frage für mich mit Blick auf eine mögliche spätere Zusammenarbeit mit weiteren Menschen. Dann arbeitet nicht mehr nur eine Person mit mehreren KI-Systemen, sondern möglicherweise mehrere Menschen mit jeweils mehreren Codex-Arbeiten am selben Repository.
Genau dafür habe ich bereits ein Konzept entwickelt. Praktisch gelöst ist das Problem allerdings noch nicht.
Git löst nur einen Teil des Problems
Die naheliegende Antwort auf parallele Entwicklung lautet zunächst Git. Unterschiedliche Arbeiten können in eigenen Branches stattfinden, Änderungen lassen sich zusammenführen und klassische Merge-Konflikte werden sichtbar.
Das ist notwendig, löst für mich aber nicht das eigentliche Problem.
Ein Merge-Konflikt zeigt nur, dass zwei Änderungen technisch dieselbe Stelle im Code berührt haben. Zwei Arbeiten können sich jedoch inhaltlich widersprechen, obwohl Git keinen einzigen Konflikt meldet.
Ein Beispiel wäre eine gemeinsame Komponente, deren Verhalten von zwei unterschiedlichen Aufgaben verändert wird. Die eine Arbeit erweitert eine Schnittstelle, während eine andere Aufgabe auf Grundlage des bisherigen Verhaltens eine neue Funktion darauf aufbaut. Beide Änderungen lassen sich technisch möglicherweise problemlos zusammenführen, obwohl das Gesamtergebnis fachlich nicht mehr konsistent ist.
Je mehr Codex eigenständig verändert, desto größer wird diese Gefahr, weil einzelne Arbeitsaufträge in kurzer Zeit wesentlich umfangreichere Änderungen erzeugen können.
Für mich reicht es deshalb nicht, Konflikte erst beim Zusammenführen der fertigen Änderungen zu entdecken.
Ich möchte möglichst vorher wissen, welche Arbeiten sich gegenseitig beeinflussen können.
Ordner sind dafür keine ausreichende Grenze
Zunächst könnte man das Repository einfach in Bereiche aufteilen und festlegen, dass immer nur eine Arbeit gleichzeitig in einem bestimmten Verzeichnis stattfinden darf.
Das wäre einfach, aber für ein größeres System zu grob.
Softwarearchitektur hält sich nicht zuverlässig an Ordnergrenzen. Eine fachliche Funktion kann aus einer Benutzeroberfläche, einer gemeinsamen Bibliothek, einer Datenbankkomponente und mehreren Schnittstellen bestehen, die an völlig unterschiedlichen Stellen des Repositories liegen.
Umgekehrt können in demselben Verzeichnis mehrere fachlich vollständig unabhängige Komponenten liegen.
Eine Sperre auf Ordnerebene würde deshalb entweder viel zu viel blockieren oder wichtige Überschneidungen gar nicht erkennen.
Für mein Konzept brauche ich stattdessen logische Arbeitsbereiche.
Diese Bereiche beschreiben nicht nur, wo eine Datei liegt, sondern zu welchem fachlichen oder technischen Teil des Systems sie gehört.
Eine Aufgabe kann mehrere Bereiche gleichzeitig betreffen
Das wird besonders bei Querschnittsfunktionen wichtig.
Eine Änderung kann beispielsweise fachlich zu einer bestimmten Website oder einem bestimmten Kosmos-Modul gehören und gleichzeitig gemeinsamen Code verändern, den auch andere Bereiche verwenden. Damit besitzt die Aufgabe nicht einfach eine einzige Zuständigkeit.
Bevor eine solche Arbeit startet, müsste deshalb analysiert werden, welche logischen Bereiche tatsächlich betroffen sind.
Genau hier sehe ich eine sinnvolle Aufgabe für Codex.
Wenn Codex ohnehin das Repository analysiert, bevor aus einem Konzept konkrete Arbeit entsteht, könnte es gleichzeitig ermitteln, welche Komponenten voraussichtlich verändert werden müssen. Agenda könnte diese Information anschließend verwenden, um zu entscheiden, welche Aufgaben parallel gestartet werden dürfen.
Agenda wäre damit nicht mehr nur eine Aufgabenliste, sondern zunehmend eine Art Verkehrsregelung für parallele KI-Arbeit.
Das Problem muss erkannt werden, bevor der Code verändert wird
Mein Ziel wäre, dass eine Aufgabe vor ihrem Start die benötigten logischen Bereiche beansprucht.
Wenn Aufgabe A beispielsweise die Bereiche X, Y und Z benötigt, darf eine andere Aufgabe parallel laufen, solange sie ausschließlich andere Bereiche betrifft.
Benötigt Aufgabe B ebenfalls Y, muss sie warten.
Das klingt zunächst relativ einfach. Die eigentliche Schwierigkeit steckt aber darin, zuverlässig zu bestimmen, welche Bereiche eine Aufgabe tatsächlich benötigt.
Eine Spezifikation kann beispielsweise nach einer kleinen Änderung in der Benutzeroberfläche aussehen, während sich bei der Analyse herausstellt, dass zusätzlich eine gemeinsame Datenstruktur geändert werden muss. Diese Erkenntnis entsteht möglicherweise erst, nachdem Codex das vorhandene Projekt genauer untersucht hat.
Die Bereichserkennung muss deshalb Teil der technischen Planung sein und darf sich nicht ausschließlich darauf verlassen, was in der ursprünglichen Aufgabenbeschreibung steht.
Mit mehreren Menschen wird das Problem noch größer
Solange nur ich mit Codex arbeite, kann ich viele potenzielle Überschneidungen noch selbst erkennen, weil alle Arbeitsaufträge letztlich durch meinen Kopf gegangen sind.
In einem Team funktioniert das nicht mehr zuverlässig.
Dann könnte eine Person an einem Thema arbeiten, während eine andere Person unabhängig davon ein zweites Konzept vorbereitet. Beide starten jeweils mehrere Codex-Arbeiten, ohne zwangsläufig zu wissen, welche internen Komponenten die jeweils andere Seite gerade verändert.
Aus zwei Menschen werden dadurch technisch schnell wesentlich mehr parallele Arbeitsstränge.
Das ist für mich ein wichtiger Unterschied zu klassischer Zusammenarbeit.
Wenn zwei Entwickler jeweils selbst Code schreiben, ist ihre Arbeitsgeschwindigkeit begrenzt. Wenn beide gleichzeitig mehrere KI-Arbeiten anstoßen können, steigt der mögliche Durchsatz erheblich, aber ebenso schnell steigt der Koordinationsbedarf.
Die KI beseitigt das Teamproblem deshalb nicht.
Sie kann es sogar beschleunigen.
Agenda müsste dann nicht Menschen, sondern Arbeit koordinieren
Ich möchte deshalb auch in einem solchen Szenario nicht darüber nachdenken, welcher Mensch gerade welchen Ordner „besitzt“.
Interessanter ist die Frage, welche Arbeiten sich gegenseitig beeinflussen.
Eine Person könnte mehrere unabhängige Aufgaben gestartet haben, während eine andere Person nur eine einzige Aufgabe bearbeitet, die jedoch einen zentralen gemeinsamen Bereich berührt. Die reine Zuordnung zu Personen hilft bei dieser Entscheidung kaum weiter.
Agenda müsste stattdessen wissen, welche Aufgaben laufen, welche Bereiche sie beanspruchen und welche weiteren Arbeiten deshalb warten müssen.
Das wäre für mich die sinnvollere Abstraktion.
Nicht:
„Timo arbeitet gerade an diesem Teil.“
Sondern:
„Diese Aufgabe verändert aktuell diese drei logischen Bereiche, daher dürfen andere Aufgaben mit denselben Abhängigkeiten noch nicht starten.“
Trotzdem bleiben echte menschliche Abstimmungen notwendig
Eine solche technische Koordination kann allerdings nicht jede Zusammenarbeit ersetzen.
Wenn zwei Konzepte sich fachlich widersprechen, hilft keine Bereichssperre. Wenn unterschiedliche Vorstellungen zur Architektur bestehen, muss darüber entschieden werden. Wenn zwei Änderungen jeweils für sich sinnvoll sind, gemeinsam aber zu einem schlechten Produkt führen, braucht es weiterhin eine inhaltliche Abstimmung.
KI und Agenda können verhindern, dass technische Arbeiten unkontrolliert gleichzeitig dieselben Teile verändern.
Sie können aber nicht automatisch festlegen, welche Produktentscheidung die richtige ist.
Genau dort würde für mich weiterhin die eigentliche Zusammenarbeit zwischen Menschen stattfinden.
Das Konzept ist vorhanden, die Praxiserfahrung fehlt noch
Mir ist wichtig, diese Idee nicht so darzustellen, als hätte ich bereits ein erprobtes System für große KI-gestützte Entwicklerteams.
Das habe ich nicht.
Ich arbeite aktuell allein und kann daher nur einen Teil der Probleme praktisch erleben. Die Überlegungen zu logischen Bereichen, automatischer Erkennung von Abhängigkeiten und Sperren in Agenda sind ein Konzept für eine Situation, die bei mir selbst noch nicht vollständig eingetreten ist.
Trotzdem halte ich es für sinnvoll, diese Fragen früh zu stellen.
KI verändert die Kosten und Geschwindigkeiten klassischer Entwicklungsprozesse, und genau dadurch können Koordinationsprobleme wesentlich früher relevant werden als bisher.
Wenn eine einzelne Person bereits mehrere Arbeiten parallel laufen lassen kann, reicht es bei mehreren Personen wahrscheinlich nicht mehr, ausschließlich auf die üblichen Mechanismen aus Branches, Pull Requests und späteren Merge-Konflikten zu setzen.
Vielleicht wird Koordination wichtiger als Programmierung
Das ist für mich eine der interessantesten möglichen Folgen KI-gestützter Entwicklung.
Je besser Codex die konkrete Umsetzung übernimmt, desto weniger knapp wird möglicherweise irgendwann die reine Programmierleistung. Stattdessen werden Architektur, Priorisierung, Abhängigkeiten und Koordination zu den begrenzenden Faktoren.
Dann besteht das Problem eines Entwicklerteams nicht mehr hauptsächlich darin, genug Code zu schreiben.
Das Problem besteht darin, sehr viel parallel erzeugbare technische Arbeit so zu organisieren, dass am Ende immer noch ein zusammenhängendes Produkt entsteht.
Ob mein Konzept mit Agenda und logischen Arbeitsbereichen dafür tatsächlich funktioniert, muss sich erst noch zeigen.
Wenn es so weit ist, wird genau das wahrscheinlich der interessantere Folgeartikel.