Die Softwareentwicklung verändert sich gerade schneller als ihre Werkzeuge. Nicht, weil GitHub schlecht geworden wäre. Nicht, weil CI versagt. Sondern weil nicht mehr Menschen den größten Teil des Codes schreiben. Agenten erzeugen Änderungen in einer Geschwindigkeit, die vor wenigen Jahren noch unmöglich gewirkt hätte.
Damit entsteht ein neues Problem. Nicht das Schreiben des Codes. Seine Verantwortung.
Heute prüfen wir jede Änderung, bevor sie integriert wird. Tests laufen. Security-Scanner laufen. Linter meckern. Menschen lesen Pull Requests, kommentieren, fordern Änderungen, geben irgendwann ihr Okay. Dieses Verfahren hat sich über Jahrzehnte bewährt, weil es zu der Geschwindigkeit passte, mit der Menschen Code schreiben.
Doch je schneller Agenten arbeiten, desto schwieriger wird diese Strategie. Ein einzelner Agent kann an einem Nachmittag mehr Pull Requests erzeugen, als ein Team früher in einer Woche geschrieben hätte. Und es bleibt nicht bei einem Agenten. Mehrere arbeiten parallel, an verschiedenen Teilen desselben Systems, manche greifen ineinander, manche widersprechen sich.
Irgendwann kann niemand mehr jede Änderung wirklich verstehen. Nicht, weil die Menschen schlechter geworden wären. Sondern weil das Volumen die Kapazität übersteigt, die ein Mensch beim gründlichen Lesen von Code überhaupt aufbringen kann.
Die naheliegende Reaktion: bessere Werkzeuge. Schnellere Scanner, klügere Linter, Reviewer, die selbst wieder KI-gestützt sind. Mehr Kontrolle, um mit mehr Menge Schritt zu halten.
Wir prüfen längst nicht mehr alles selbst
Bevor diese Frage weitergeht, lohnt ein ehrlicher Blick auf das, was heute schon passiert. Wir beginnen längst, den Prüfungen unserer Werkzeuge zu vertrauen, statt selbst zu prüfen. Der Test ist grün, also gehen wir davon aus, dass die Funktion tut, was sie soll. Der Scanner findet keine bekannte Schwachstelle, also gehen wir davon aus, dass keine da ist. Das Review ist knapp, aber positiv, also mergen wir.
Kein Mensch liest heute noch jede Zeile einer Abhängigkeit, die er in sein Projekt zieht. Kein Mensch versteht jedes Detail des Betriebssystems, auf dem sein Code läuft. Vertrauen in Werkzeuge und Prozesse war schon immer Teil der Arbeit. Was sich mit Agenten ändert, ist nur das Verhältnis. Früher war der Anteil, den ein Mensch tatsächlich noch gelesen hat, groß. Jetzt wird er klein.
Und damit stellt sich eine andere Frage als die nach besseren Werkzeugen: Vielleicht liegt das Problem gar nicht allein in der Menge an Code. Vielleicht liegt es in unserem Modell von Kontrolle selbst - in der Annahme, dass Vertrauen am Integrationspunkt entstehen muss, indem vorher möglichst alles geprüft wird.
Ein Blick in einen anderen Bereich
Ein menschlicher Körper besteht aus Billionen von Zellen. Jede einzelne teilt sich, produziert Proteine, reagiert auf ihre Umgebung, stirbt irgendwann und wird ersetzt. Keine zentrale Instanz überprüft jede dieser Handlungen, bevor sie stattfindet. Der Organismus funktioniert trotzdem, über Jahrzehnte, unter wechselnden Bedingungen.
Das ist keine Behauptung, Software und Organismus seien dasselbe. Es ist die Beobachtung, dass ein hochkomplexes System Kontrolle offenbar auch anders organisieren kann, als wir es in der Softwareentwicklung gewohnt sind.
Verantwortung entsteht dort lokal. Jede Zelle ist für ihren eigenen Bereich zuständig, kennt ihre Aufgabe, reagiert auf Signale aus ihrer unmittelbaren Umgebung. Sie muss nicht wissen, was am anderen Ende des Körpers passiert, um ihre Arbeit richtig zu machen.
Der Organismus als Ganzes beobachtet nicht jede einzelne Handlung. Er beobachtet den laufenden Zustand - und reagiert, wenn dieser Zustand von der Norm abweicht. Kontrolle findet also statt. Aber nicht als Vorabprüfung jeder Einzelaktion, sondern als fortlaufende Beobachtung und Reaktion auf Auffälligkeiten.
Auch der Mensch selbst steuert seine eigenen Zellen nicht einzeln. Er kann nicht entscheiden, dass diese eine Zelle jetzt so und nicht anders reagieren soll. Was er beeinflussen kann, sind Randbedingungen: was er isst, wie er sich bewegt, welchen Belastungen er sich aussetzt. Und er verlässt sich auf Regelkreise und ein Immunsystem, das im Hintergrund arbeitet, ohne dass er es im Detail steuert.
Wo Kontrolle tatsächlich stattfindet
Übertragen auf Software wäre das kein Rezept, sondern eine Verschiebung der Frage: Woran genau soll Kontrolle eigentlich ansetzen?
Wenn Entwickler ohnehin nicht mehr jede Zeile lesen, die in einem System entsteht, dann liegt ihre tatsächliche Einflussmöglichkeit vielleicht nicht in der internen Implementierung einer einzelnen Komponente. Sondern dort, wo sie wirklich gestalten können: bei Randbedingungen, bei Regeln, bei Verantwortungsgrenzen, bei Schnittstellen, bei Prüf- und Beobachtungsmechanismen - und bei der Definition dessen, was im Betrieb als Auffälligkeit oder Schaden gilt.
Wenn eine Komponente ihre Verantwortung erfüllt und ihre Schnittstelle einhält, wird zweitrangig, wie viel Code intern dafür nötig war oder wie er im Detail aussieht. Entscheidend ist dann nicht primär die Menge an Code, die in ein System gelangt, sondern ob eine Verantwortung weiterhin erfüllt wird, ob Beziehungen und Grenzen stabil bleiben, ob das System Auffälligkeiten im laufenden Betrieb erkennt, und ob ein Fehler lokal bleibt oder sich ausbreitet.
Das würde auch etwas anderes möglich machen: Mehrere Module könnten dieselbe Verantwortung übernehmen, dieselbe Schnittstelle erfüllen, und im laufenden Betrieb beobachtet werden. Welche Implementierung ihre Aufgabe unter realen Bedingungen tatsächlich besser erfüllt, müsste sich dann nicht vorab durch Review entscheiden, sondern könnte sich zur Laufzeit zeigen. Die geeignetere behält oder erhält mehr Arbeit, eine auffällige oder schlechtere verliert sie.
Vielleicht wäre damit auch ein anderer Umgang mit Veränderung möglich. Eine neue Implementierung müsste die bestehende nicht sofort ersetzen. Sie könnte dieselbe Verantwortung zunächst parallel übernehmen und sich unter realen Bedingungen bewähren. Erst wenn sie ihre Aufgabe zuverlässiger erfüllt, würde sie mehr Verantwortung übernehmen - nicht aufgrund einer einmaligen Entscheidung, sondern aufgrund fortlaufender Beobachtung.
Das wäre keine unkontrollierte Beliebigkeit. Die Auswahlregeln, die Sicherheitsgrenzen, die Rückfallmechanismen, die Beobachtung selbst - all das müsste weiterhin von Menschen gestaltet werden. Nur eben nicht mehr als Prüfung jeder einzelnen Codezeile vor der Integration, sondern als Gestaltung des Rahmens, in dem sich Implementierungen bewähren oder eben nicht.
Vielleicht brauchen wir nicht nur Werkzeuge, die immer mehr Code vorab prüfen können. Vielleicht müssen wir neu bestimmen, was Entwickler überhaupt kontrollieren sollten - und an welchem Ort diese Kontrolle sinnvoll stattfinden kann.
Der eigentliche Engpass liegt vielleicht gar nicht in GitHub, nicht in der CI-Pipeline, nicht im Reviewer-Mangel. Sondern darin, wie wir Verantwortung organisieren.
