Schnellerer Code, gleiche Auslieferung? Was KI wirklich mit dem Tempo der Softwareentwicklung macht

Eine Änderung erreicht die Nutzer nicht, wenn der Code geschrieben ist. Sie erreicht sie, nachdem jemand das Problem verstanden, den Code geschrieben, geprüft, durch die CI geschickt, repariert, deployt und in Produktion beobachtet hat. KI hat einen dieser Schritte enorm verdichtet. Die anderen haben sich viel weniger bewegt.

Das ist das Amdahlsche Gesetz, auf Teams angewendet: Wenn das Schreiben von Code ein Drittel der Durchlaufzeit war und nun nur noch ein Zehntel davon braucht, wird die gesamte Pipeline um weit weniger als das Zehnfache schneller. Der Rest der Durchlaufzeit ist weiterhin da, und er macht jetzt den größten Teil aus. Die Beschleunigung eines Schritts ist keine Beschleunigung der Auslieferung.

Nichts davon heißt, dass die Veränderung klein wäre. Bei manchen Arten von Arbeit ist sie ein echter Sprung:

• Von der Idee zum Prototyp

  Ein funktionierender Prototyp, für den früher ein Sprint nötig war, kann nun am Ende des Tages stehen. Teams testen mehr Ideen, bevor sie sich auf eine festlegen.

• Mechanische Arbeit

  Migrationen, Boilerplate, Test-Gerüste, API-Clients und repetitives Refactoring sind der Bereich, in dem Agenten die meisten Stunden bei geringstem Risiko sparen.

• Unbekanntes Terrain

  Eine Legacy-Codebasis, ein neues Framework oder eine selten genutzte Sprache zu lesen bedeutet nicht mehr eine Woche Einarbeitung bis zum ersten nützlichen Commit.

• Kleine Teams

  Zwei oder drei Personen können nun Produkte bauen und betreiben, für die früher eine ganze Abteilung nötig war. Das verändert nicht nur das Tempo, sondern auch, wer konkurrieren kann.

Wenn Code billig zu erzeugen wird, wird alles, was mit diesem Code geschehen muss, relativ teurer. Dasselbe Muster wiederholt sich:

• Das Review wird zur Warteschlange. Mehr und größere Pull Requests landen bei denselben wenigen Reviewern. Deren Aufmerksamkeit ist jetzt die knappe Ressource.
• Die CI leistet mehr Arbeit. Agenten iterieren, indem sie die Pipeline ausführen. Schnellere Iteration bedeutet mehr Läufe, und mehr davon schlagen auf dem Weg zum grünen Build fehl.
• Nicht jede Sitzung wird zur Änderung. Manche KI-Arbeit endet in einem Commit, manche in einem verworfenen Branch. Beides kostet Zeit und Geld, aber nur eines taucht in den Release Notes auf.
• Entscheidungen bleiben im Tempo von Menschen. Zu verstehen, was der Kunde braucht, sich auf den Umfang zu einigen und die Folgen in Produktion zu verantworten, ist nicht zehnmal schneller geworden.

Es ist verlockend, von „KI und Softwareentwicklung“ als einer globalen Kurve zu sprechen. In der Praxis ist die Beschleunigung sehr ungleich, und die Gründe sind größtenteils nicht technisch.

• Der Preis ist global, die Gehälter sind es nicht. Die Modellnutzung wird überall gleich bepreist, während die Kosten einer Ingenieurstunde zwischen Ländern stark variieren. Dieselbe KI-Rechnung kann für ein Team ein Rundungsfehler sein und für ein anderes einen erheblichen Teil des Budgets ausmachen.
• Regulierung setzt die Obergrenze. Banken, Gesundheitswesen und öffentlicher Sektor führen langsamer ein, weil zuerst Datenresidenz, Audit und Freigabeprozesse kommen. Ihr Tempo wird von Governance begrenzt, nicht von Werkzeugen.
• Altsysteme leisten Widerstand. Greenfield-Produkte spüren die Beschleunigung zuerst. Jahrzehntealte Systeme mit wenigen Tests und implizitem Wissen profitieren, aber langsamer und mit mehr Risiko.
• Fähigkeiten summieren sich. Teams, die gelernt haben, Agenten guten Kontext, kleine Aufgaben und schnelles Feedback zu geben, holen aus denselben Werkzeugen viel mehr heraus als Teams, die sie einfach eingeschaltet haben.

Das globale Bild lautet also weniger „alle sind schneller“ als „der Abstand zwischen schnellen und langsamen Teams wächst“. Diese Lücke wird heute eher durch Prozesse und Ökonomie bestimmt als durch den Zugang zu Modellen.

Wird etwas billiger, verbrauchen wir davon meist mehr. Software folgt demselben Weg. Interne Tools, die früher niemand finanziert hätte, entstehen nun an einem Nachmittag. Experimente, die zu teuer zum Ausprobieren waren, sind Routine. Die Welt schreibt nicht einfach dieselbe Software schneller; sie schreibt viel mehr Software.

Das hat einen Preis, der später fällig wird. Jede Zeile, die ausgeliefert wird, muss geprüft, abgesichert, aktualisiert und irgendwann von jemandem verstanden werden, der sie nicht geschrieben hat. Das Tempo der Erstellung ist gestiegen; das Tempo der Wartung muss mithalten, und diese Rechnung trifft erst allmählich ein.

Wenn das Schreiben von Code nicht mehr der langsame Teil ist, sagt die Messung, wie schnell Code geschrieben wird, wenig aus. Die entscheidenden Fragen betreffen die gesamte Änderung:

1. 1

   Der Änderung folgen, nicht dem Werkzeug

   Betrachten Sie den Weg von der Aufgabe über KI-Sitzung, Commit, Pull Request, CI und Deployment als eine Arbeitseinheit.
2. 2

   Zählen, was nie ausgeliefert wurde

   Sitzungen ohne Commit und ohne Merge geschlossene Pull Requests gehören zu den realen Kosten der Geschwindigkeit.
3. 3

   Die neue Warteschlange finden

   Wenn Änderungen jetzt im Review oder in der CI warten, liegt dort die nächste Verbesserung, nicht in noch einem Coding-Tool.
4. 4

   Unbekanntes sichtbar halten

   Eine Zahl mit fehlendem Preis ist unvollständig, nicht null. Ehrliche Lücken sind nützlicher als selbstsichere Summen.

Auf dieser Sicht ist Nythrex aufgebaut: die Kosten jeder Änderung vom KI-Prompt bis zur Produktion, mit der Grundlage jeder Zahl daneben. So funktioniert die Kette.

KI hat den Akt des Softwareschreibens schneller gemacht als je zuvor in der Geschichte. Ob daraus schnellerer Fortschritt wird, hängt von allem rund um den Code ab: wie Teams entscheiden, prüfen, testen, deployen und die Arbeit bezahlen. Die Teams, die die gesamte Pipeline sehen und nicht nur ihren schnellsten Schritt, sind diejenigen, deren Tempo tatsächlich bei ihren Nutzern ankommt.