softwarearchitektur.de
Essay · November 2026

Programmieren war nie der Punkt

Coden hat mir immer Spaß gemacht. Aber es war Mittel zum Zweck. Wichtiger war mir, zu verstehen, Modelle zu bauen und die Probleme der Menschen zu lösen, die meine Software nutzen. Jetzt, wo Agenten den Code schreiben, zeigt sich, warum.

Eine frühe Prägung

Ich habe an der TU Berlin Informatik studiert und mich im Hauptstudium auf Software Engineering bei Christiane Floyd konzentriert, später war ich bei ihr wissenschaftlicher Mitarbeiter, zuerst in Berlin, später in Hamburg. Sie hat uns sehr früh einen Text nahegelegt, der damals kaum jemandem in der Industrie etwas sagte: Peter Naurs Programming as Theory Building von 1985.

Naurs These ist einfach und unbequem. Das eigentliche Ergebnis des Programmierens ist nicht der Code. Es ist die Theorie, die die Programmierer im Kopf aufbauen: ein Verständnis davon, wie das Programm die Welt abbildet, warum es so gebaut ist und wie es sich sinnvoll ändern lässt. Der Code ist nur der sichtbare Niederschlag dieser Theorie. Geht das Team auseinander, stirbt die Theorie, auch wenn der Code bleibt. Wer das Programm dann ändern will, ohne die Theorie zu haben, beschädigt es.

Christiane Floyd hat das zwei Jahre später in einen größeren Rahmen gestellt. In Outline of a Paradigm Change in Software Engineering (1987) stellt sie der produktorientierten Sicht, Software als fertiges Produkt aus Programmen und Dokumenten, eine prozessorientierte gegenüber: Software entsteht in Prozessen des Lernens und der Kommunikation mit den Menschen, die sie nutzen, in einer Welt, deren Anforderungen sich ständig ändern.

Was daraus für meine Arbeit folgte

Diese beiden Texte haben mein Bild vom Beruf geprägt. Ein Softwarearchitekt ist für mich nie in erster Linie jemand gewesen, der die eleganteste Klassenstruktur entwirft. Sondern jemand, der verstehen will: das Problem der Nutzer, die Fachlichkeit, die Zusammenhänge im System. Und der dieses Verständnis in Modelle fasst, die andere teilen können.

Heute verantworte ich bei iteratec das Softwarearchitekten-Training. Es ist nur ein Baustein bei der Ausbildung unserer Architekten, aber wer dort Technologie-Folien erwartet, wird enttäuscht. Es geht um Kommunikation, ums Vermitteln und ums Hinterfragen. Um die Frage, wie ein Team zu einem gemeinsamen Verständnis kommt und wie man Entscheidungen so begründet, dass andere sie nachvollziehen und auch infrage stellen können. Das ist Floyds Prozesssicht, angewandt auf die Architekturarbeit.

Und jetzt schreiben Agenten den Code

Wer Programmieren für den Kern der Softwareentwicklung hält, muss KI-Agenten als Bedrohung oder als Erlösung sehen. Wer mit Naur und Floyd darauf schaut, sieht etwas anderes: Agenten nehmen uns den Teil ab, der immer nur Umsetzung des Modells war. Den Teil, in dem die Theorie entsteht, nehmen sie uns nicht ab.

Aber Programmieren war auch eine Gelegenheit, die Theorie aufzubauen. Wer eine Funktion schrieb, musste verstehen, wo sie hingehört. Wer im Code-Review fremden Code las, glich seine Theorie mit der des Kollegen ab. Diese Gelegenheiten fallen weg, wenn der Agent schreibt und ein zweites Modell den Code reviewt. Der Code entsteht schneller, als ein Team seine Theorie davon bilden kann. Wer zehnmal schneller codet, versteht sein System nicht zehnmal schneller.

Das ist der eigentliche Engpass, der in den Produktivitätszahlen nicht auftaucht. Margaret-Anne Storey nennt ihn „Cognitive Debt“: Technische Schuld lebt im Code, kognitive Schuld in den Köpfen. Der Code kann sauber sein, und trotzdem weiß niemand mehr, warum er so ist. Dabei hilft es leider auch nicht, aus dem Code nachträglich Dokumente zu erzeugen. Diese können nur festhalten, was umgesetzt wurde, es fehlt aber das „Warum“, und das ist ein wichtiger Teil des Modells.

Die Theorie muss geteilt sein

Daraus folgt für mich die wichtigste Aufgabe des Architekten im Zeitalter der Agenten. Nicht der Prompt, nicht der Harness allein, sondern das gemeinsame Verständnis. Die Theorie darf nicht nur im Kopf einer Person und erst recht nicht nur im Kontextfenster einer Agenten-Session existieren. Sie muss im Team geteilt sein, mit den Fachleuten abgeglichen und so begründet, dass jemand Neues sie sich erarbeiten kann.

Das ist harte Arbeit, und sie fühlt sich nicht nach Produktivität an. Gespräche, Modelle an der Wand, Entscheidungen, die man aufschreibt und gemeinsam durchgeht. Genau die Arbeit, die in vielen Teams als „Overhead“ gilt und die man mit Agenten gern einspart. Mit Norman Seibert spreche ich darüber auf der OOP 2027, unter dem Stichwort „Teamwork Gap“: Alle reden über die Zusammenarbeit von Mensch und Agent, kaum jemand über die Zusammenarbeit der Menschen untereinander.

Christiane Floyd hat vor fast vierzig Jahren gesagt, dass Software im Lernen und im Gespräch entsteht. Agenten ändern daran nichts. Sie machen nur sichtbar, dass es nie anders war.

Quellen