Code, den Agenten schreiben, wird trotzdem geprüft

Hurukan wird zum großen Teil von Agenten gebaut. Sie schreiben Code, erzeugen Tests, lassen die Testsuite laufen, integrieren und stellen die Änderung zur Auslieferung bereit. Das verkürzt den Weg vom Erkennen eines Problems bis zur Behebung in einer laufenden Installation von Wochen auf Stunden – ein echter Vorteil.

Es ist aber auch die Behauptung in diesem Feld, die am ehesten aufgebläht wird. Deshalb lohnt es sich, aufzuschreiben, wo die Automatisierung endet und warum diese Grenzen nicht vorübergehend sind.

Was wirklich automatisiert ist

Umsetzung nach Spezifikation. Mit einer klaren Beschreibung der Änderung und der bestehenden Codebasis schreibt ein Agent eine plausible Umsetzung schneller als ein Mensch, und die mühsamen Teile langweilen ihn nicht.

Testerzeugung. Einschließlich der Fälle, die ein müder Mensch überspringt: die leere Liste, die Dublette, die Zeitzone, der gleichzeitige Schreibzugriff.

Integration und Pipeline. Bauen, Testsuite ausführen, Typen prüfen, die Routinekonflikte auflösen – und das kontinuierlich statt in Schüben.

Die langweilige Wartung. Abhängigkeits-Updates, Migrationen weg von veralteten Schnittstellen, Konsistenz über ähnliche Codepfade hinweg. Echte Arbeit, traditionell aufgeschoben, und genau die Art, die ein System leise verrotten lässt.

Was nicht automatisiert ist

Die Entscheidung, was gebaut wird. Eine Spezifikation ist ein Urteil über ein Geschäft, keine Programmieraufgabe. Agenten wissen nicht, welcher von fünf Fehlern für das Unternehmen zählt, das dieses System am nächsten Dienstag betreibt.

Architektur mit langen Folgen. Die Entscheidungen, mit denen man jahrelang lebt – wo eine Grenze verläuft, was das Datenmodell festschreibt, was bewusst unmöglich gemacht wird. Schnell und billig falsch zu treffen, teuer, falsch getroffen zu haben.

Review. Jede erzeugte Änderung durchläuft ein Review und dieselben Prüfpunkte wie jede andere. Der Geschwindigkeitsvorteil kommt von schnelleren Prüfpunkten, nicht von weniger. Wer das Zweite anbietet, beschreibt ein System, das irgendwann etwas ausliefert, das es nicht hätte ausliefern dürfen.

Die Release-Entscheidung. Ein Mensch entscheidet, was ein Unternehmen erreicht, das darauf läuft. Das wird nicht automatisiert – nicht, weil es nicht ginge, sondern weil die Verantwortung für ein schlechtes Release bei jemandem liegen muss.

Die Fehlerquelle, die man benennen sollte

Menge. Ein Agent erzeugt schnell eine große, plausible Änderung, und sie ordentlich zu prüfen, dauert so lange wie jedes andere Review. Teams, die das Tempo der Erzeugung messen und nicht das Tempo der Prüfung, häufen schlecht geprüften Code in einem Maß an, das kein menschlicher Prozess auffangen kann – und die Schulden kommen auf einen Schlag.

Die Abwehr: Erzeugte Änderungen müssen klein sein, Tests müssen wirklich unabhängig von der Umsetzung sein, und die Review-Kapazität muss die Größe sein, an der das Ganze bemessen wird. Ist das Review der Engpass, arbeitet das System richtig.

Warum wir es so deutlich sagen

Weil eine autonome Softwarefabrik nach der Behauptung klingt, man brauche keine Ingenieure mehr – und das ist sie nicht. Sie ist eine Behauptung über die Zeit zwischen einem Fehler und seiner Behebung, und die kann ein Kunde messen.

An dieser Version wollen wir uns messen lassen, und sie ist eine kleinere Behauptung, als die Worte nahelegen. Für ein Unternehmen, das seinen Betrieb auf diese Software stützen soll, ist eine kleinere Behauptung, die der Prüfung standhält, mehr wert als eine größere, die es nicht tut.