Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Thorsten Ball glaubt, dass das Handwerk des Programmierens verschwindet. Ich glaube, dass er mit der Richtung recht haben könnte. Aber Zukunftsbild und heutige Verantwortung darf man nicht miteinander verwechseln.

Thorsten Ball ist Softwareentwickler, Autor von Writing An Interpreter In Go und Mitgründer von Amp, einem Coding-Agent-Research-Lab. Er beobachtet diese Entwicklung nicht nur, er baut daran mit. Das macht seine Thesen sehr interessant, und erklärt zugleich die Perspektive, aus der er argumentiert.

Seine Prognose ist radikal: Code Reviews, Unit Tests, Terminals, heutige Teamstrukturen. Vieles davon verschwindet.

Sein stärkstes Argument:

Most bugs won’t be „coding“ bugs. They’ll be „you asked for the wrong thing“ bugs.

Zwei Perspektiven, die man auseinanderhalten muss

Thorsten Balls Text ist ausdrücklich ein Blick in die Zukunft. Auf seiner eigenen Website schreibt er, dass einige seiner Prognosen bei Unternehmen wie Amp bereits Realität seien, andere aber Zeit brauchen. In einem älteren Interview mit dem Fraunhofer IEM wird die Perspektive noch deutlicher: Amp orientiert sich bewusst an der technologischen Frontier, nicht am durchschnittlichen Enterprise-Entwickler. Ball selbst unterscheidet dabei zwischen dem Handwerk des Codeschreibens, das verschwindet, und dem Handwerk des Softwarebauens, das seiner Prognose nach wichtiger wird denn je.

Genau an dieser Bruchstelle setze ich an.

Ich habe vor wenigen Tagen geschrieben (https://2s-datenschutz-entwicklung.de/de/wissen/beitrag/weniger-mikromanagement-ist-nicht-dasselbe-wie-weniger-governance-codequalitaet-in-der-ai-gestuetzten-softwareentwicklung), dass ich anfange, meine Schranken abzurüsten. Repository-Regeln, kleinteilige Arbeitsanweisungen, Prompt-Regelwerke: Vieles davon war eine Antwort auf frühere Modellgenerationen und behindert heute teilweise mehr, als es hilft. Aber u.a. ein Code Review gehört für mich immer noch zum Alltag.

Warum? Weil Softwareentwicklung unter organisatorischen und regulatorischen Rahmenbedingungen erfolgen muss.

Wo ich ihm zustimme

Der Engpass verschiebt sich. Wenn Code-Erzeugung immer billiger wird, gewinnen Anforderungen, Architekturentscheidungen und die Frage, welches Problem überhaupt gelöst werden soll, erheblich an Bedeutung.

Und Ball hat recht: Menschliche Kontrolle jeder einzelnen Codezeile wird mit zunehmender Autonomie von Coding Agents immer weniger skalieren.

Das heißt aber nicht, dass Kontrolle verschwindet.

Sie verändert ihren Gegenstand.

Wo ich beim heutigen Stand eine Grenze ziehe

Wenn der Fehler bereits im Auftrag steckt, ist ein klassisches Code Review sicherlich nicht der perfekte Kontrollpunkt. Aber Review kann heute sehr wohl der Ort sein, an dem ein fachlich falscher Auftrag sichtbar wird. Ein Entwickler mit Domänenwissen sieht im Ergebnis Zusammenhänge, die weder Spezifikation noch Test vollständig erfasst haben.

Dazu kommen Fehlerklassen, die mit der fachlichen Aufgabenstellung nur mittelbar zusammenhängen: unsichere Defaults, Injection-Pfade, fehlerhafte Autorisierung, personenbezogene Daten im Log, problematische Abhängigkeiten.

Ein korrekter Auftrag garantiert noch keine sichere Software.

Und vor allem gilt für regulierte Organisationen heute noch etwas anderes:

Software muss nicht nur funktionieren. Ihre Eignung, ihre Veränderungen und die angewandten Kontrollen müssen nachweisbar sein.

Das ist keine theoretische Governance-Forderung. DORA verlangt beispielsweise für betroffene Finanzunternehmen dokumentierte Entwicklungsverfahren, Tests und Freigaben. Bemerkenswert ist dabei, was dort nicht steht: Verlangt wird eine Quellcodeprüfung mit statischen und dynamischen Verfahren und ein nachverfolgter Aktionsplan. Nicht, dass ein Mensch den Code liest. Das Kontrollziel ist normiert, das Artefakt nicht.

Beim AI Act sieht man dasselbe Prinzip auf einer anderen Ebene: Bei Hochrisiko-KI-Systemen sollen technische Dokumentation und Protokollierung gerade ermöglichen, Entwicklung und Verhalten nachvollziehbar zu machen und Konformität prüfen zu können.

Deshalb ist für mich die entscheidende Frage nicht, ob das heutige Code Review überlebt.

Vielleicht hat Thorsten Ball recht und der Pull Request, wie wir ihn kennen, verschwindet tatsächlich.

Vielleicht werden Unit Tests teilweise durch andere Formen maschineller Verifikation ersetzt.

Vielleicht interessieren uns irgendwann weder Sourcecode noch Programmiersprache besonders.

Aber daraus folgt nicht, dass Nachweisbarkeit verschwindet.

Im Gegenteil: Wenn Menschen immer weniger von der konkreten Implementierung sehen, muss an anderer Stelle belastbar nachgewiesen werden können:

• Was sollte das System tun?
• Wer hat die Anforderung und das Risiko bewertet?
• Gegen welche Anforderungen wurde geprüft?
• Welche Tests und Kontrollen wurden durchgeführt?
• Welche Version ist freigegeben worden?
• Welche Architekturentscheidung lag zugrunde?
• Welche Änderung wurde vorgenommen – und warum?
• Welche Evidenz belegt, dass das Ergebnis für seinen vorgesehenen Zweck geeignet ist?

Die Artefakte dafür dürfen sich verändern.

Vielleicht besteht der Nachweis der Zukunft nicht mehr aus einem Menschen, der 800 geänderte Codezeilen liest. Vielleicht besteht er aus automatisiert erzeugter und kryptografisch nachvollziehbarer Evidence, Agent-Traces, reproduzierbaren Tests, Policy-as-Code und maschinenprüfbaren Constraints.

Das Kontrollziel bleibt trotzdem bestehen.

Gates prüfen die Spezifikation – nicht deren fachliche Wahrheit

Das ist für mich der Kern der Diskussion.

Ausführbare Governance ist richtig und notwendig. Aus Anforderungen werden überprüfbare Akzeptanzkriterien, aus Architekturprinzipien technische Constraints, aus „das sollte funktionieren“ reproduzierbare Evidence.

Aber auch die Spezifikation selbst ist ein menschliches Artefakt.

Akzeptanzkriterien können perfekt ausgeführt werden und trotzdem das falsche Problem beschreiben.

Automatisierte Verifikation kann sehr zuverlässig feststellen, ob ein System seiner Spezifikation entspricht. Sie beweist damit noch nicht, dass die Spezifikation fachlich richtig, regulatorisch vollständig oder geschäftlich sinnvoll war.

Wenn Balls These stimmt und künftig ein großer Teil der Fehler tatsächlich „you asked for the wrong thing“ lautet, wird genau diese Ebene wichtiger.

Was daraus folgt

Für mich entstehen deshalb zwei unterschiedliche Kontrollziele:

Implementierungs- und Konformitätsfehler erkennen. Das wird zunehmend automatisierbar. Hier bin ich sehr nah bei Thorsten Ball.

Entscheidungen verantworten und nachweisbar machen. Das ist Technical Governance.

Wenn ein Agent einen Pull Request erzeugt, oder künftig vielleicht gar keinen Pull Request mehr, muss eine Organisation trotzdem bestimmen können, warum diese Änderung gewollt war, wer sie verantwortet und auf welcher Grundlage ihre Eignung festgestellt wurde.

Deshalb dokumentiere ich auch weiterhin Architekturentscheidungen als ADRs.

Ein Constraint kann das Was erzwingen. Er dokumentiert nicht automatisch das Warum, die betrachteten Alternativen und die Konsequenzen einer Entscheidung.

Genau diese Information lässt sich später nicht verlässlich aus dem fertigen Code rekonstruieren.

Und genau sie wird relevant, wenn Monate oder Jahre später jemand fragt:

Warum wurde dieses System so gebaut? Und worauf beruhte die Entscheidung, dass es geeignet war?

Balls Zukunftsbild halte ich deshalb für ausgesprochen interessant.

Nur würde ich daraus für Organisationen im Jahr 2026 nicht ableiten:

Wir brauchen weniger Governance.

Sondern:

Wir müssen Governance schneller auf eine Ebene bringen, auf der sie auch mit zunehmend autonomer Softwareentwicklung funktioniert.

Nicht weniger Engineering. Nicht weniger Qualitätssicherung. Weniger menschliche Mikrokontrolle der Implementierung, und mehr systemische Governance von Anforderung, Entscheidung, Prozess und Ergebnis.

Welche Entwicklungspraktik wird durch AI Agents tatsächlich überflüssig, und welches Kontrollziel bleibt bestehen, auch wenn sich seine technische Umsetzung vollständig verändert?

P.S. Und nein: Das Terminal (CLI) wird niemals sterben 🙂