Als ich in den 90er-Jahren als Software Engineer angefangen habe, habe ich COBOL auf dem IBM Mainframe programmiert. Später kamen Client/Server-Applikationen dazu. Vieles war damals einfacher. Nicht die Technik, aber die Organisation. Ich habe mit den Kunden gesprochen, die Anforderungen aufgenommen, die Architektur und das Design gemacht, den Code geschrieben und dafür gesorgt, dass die Applikation in Produktion läuft. Alles aus einer Hand.

Heute, über 30 Jahre später, habe ich das Gefühl: Wir sind zurück. Und das ist eine gute Nachricht.

Wie wir die Rollen verloren haben

Mit der Zeit wurden die Projekte grösser und die Teams auch. Also haben wir spezialisiert. Der Business Analyst schreibt die Anforderungen. Der Architekt macht die Architektur. Die Entwickler implementieren. Die Tester testen. Und Ops bringt alles in Produktion.

Das hat auf dem Papier gut ausgesehen. In der Praxis hatte es einen grossen Nachteil: Bei jeder Übergabe geht Wissen verloren. Der Entwickler hat nie mit dem Kunden gesprochen. Der Architekt sieht nie, wie das System in Produktion läuft. Und der Kunde bekommt am Ende nicht ganz das, was er eigentlich wollte.

Agile Methoden haben versucht, dieses Problem zu lösen. Cross-funktionale Teams, kurze Iterationen, enge Zusammenarbeit mit dem Product Owner. Das hat geholfen. Aber die Rollen sind geblieben, nur die Übergaben wurden kürzer.

Was sich mit AI ändert

Mit AI Coding Agents fällt ein grosser Teil der Implementierungsarbeit weg. Code schreiben, Tests schreiben, Boilerplate, Migrationen, Mappings: Das kann die AI heute sehr gut und sehr schnell.

Damit hat eine einzelne Person plötzlich wieder Zeit für das Ganze:

  • mit dem Kunden reden und das Problem wirklich verstehen
  • die Anforderungen sauber beschreiben
  • Architektur und Design festlegen
  • die Implementierung durch die AI steuern und prüfen
  • schauen, dass die Applikation sicher und stabil in Produktion läuft

Das ist genau das, was ich in den 90ern gemacht habe. Nur schneller.

Der Unterschied zu damals

Ganz gleich wie früher ist es aber nicht. Zwei Dinge sind heute anders.

Erstens: Die Spezifikation ist jetzt Input, nicht nur Dokumentation.

Früher habe ich die Anforderungen oft im Kopf gehabt. Ich habe mit dem Kunden gesprochen und dann direkt programmiert. Das ging, weil ich selbst der Entwickler war.

Heute ist der „Entwickler“ eine AI. Und die AI war nicht im Meeting mit dem Kunden. Sie weiss nur das, was ich ihr sage. Darum wird die Spezifikation plötzlich zum wichtigsten Artefakt im Projekt. Wer gut spezifiziert, bekommt guten Code. Wer schlecht spezifiziert, bekommt schnell viel schlechten Code.

Eigentlich ist das eine alte Idee. COBOL wurde so entworfen, dass es fast wie Englisch aussieht. Auch Fachleute ohne Programmierkenntnisse sollten den Code lesen können. Heute sind wir einen Schritt weiter: Wir schreiben wirklich in natürlicher Sprache, und die AI macht daraus Code.

Das ist der Kern von Spec-Driven Development: Die Anforderungen stehen am Anfang, und alles andere wird daraus abgeleitet. Im AI Unified Process arbeiten wir deshalb mit Requirements, Use Cases und einem Entity Model, bevor die erste Zeile Code entsteht.

Zweitens: Die Systeme sind komplexer geworden.

In den 90ern hatte ich einen Mainframe mit COBOL-Programmen und Terminals. Später dann Client/Server: ein Datenbankserver und eine Applikation auf dem PC. Das war überschaubar. Heute gibt es Cloud, Container, Security, Compliance, Observability und vieles mehr. Der Allrounder von heute braucht also sehr breites Wissen.

Und er muss etwas können, was früher weniger wichtig war: beurteilen, ob das Resultat stimmt. Die AI liefert Code, der gut aussieht. Aber ist er auch richtig? Ist er sicher? Passt er zur Architektur? Das kann nur jemand beurteilen, der das ganze System versteht.

Die neue Rolle: Der Architekt, der wieder selbst Hand anlegt

Wenn ich diese Rolle beschreiben müsste, würde ich sagen: Es ist ein Architekt, der wieder selbst Hand anlegt. Er versteht das Business, er kennt die Technik, und er steuert die AI wie ein erfahrener Entwickler ein Team steuert.

Das bedeutet auch: Die wichtigsten Skills sind nicht mehr Syntax und Frameworks. Die wichtigsten Skills sind:

  • Zuhören und verstehen, was der Kunde wirklich braucht
  • Klar schreiben, damit Mensch und AI dasselbe verstehen
  • Strukturiert denken, damit Architektur und Design stimmen
  • Kritisch prüfen, damit nur guter Code in Produktion kommt

Diese Skills waren schon immer wichtig. Jetzt sind sie entscheidend.

Was heisst das für Teams?

Braucht es dann keine Teams mehr? Doch, natürlich. Grosse Systeme baut niemand alleine. Aber die Teams werden kleiner, und die einzelnen Personen haben wieder mehr Verantwortung für das Ganze. Weniger Übergaben, weniger Wissensverlust, schnellere Feedback-Zyklen.

Für Firmen heisst das: Investiert in Leute, die das ganze Bild sehen. Und investiert in saubere Spezifikationen. Sie sind die Grundlage für alles, was die AI baut.

Fazit

Ich finde diese Entwicklung sehr spannend. Nach 30 Jahren Spezialisierung kommen wir zurück zu dem, was Software Engineering eigentlich ist: ein Problem verstehen und eine gute Lösung bauen. Von Anfang bis Ende.

Die Werkzeuge sind neu. Das Prinzip ist alt. Keep IT simple.