Die Anforderung ist immer dieselbe: mehr Features, kürzere Zyklen, gleiche Ressourcen – oder weniger. Wer das noch nicht täglich hört, hat wahrscheinlich gerade Urlaub. Die Reaktion der Branche ist dabei seit Jahrzehnten ziemlich vorhersehbar: noch effizienter werden, noch schneller deployen, noch mehr automatisieren. Nicht falsch – aber endlich. Und ich glaube, wir nähern uns gerade dieser Grenze schneller als die meisten wahrhaben wollen.
Dafür muss ich etwas ausholen. Und ich verspreche, dass am Ende ein konkreter Punkt steht.
Es begann mit Handarbeit
Assembler. Wer damals Software schrieb, meißelte jeden Stein von Hand. Jede Speicheradresse, jede Registeroperation – explizit, bewusst, mühsam. Software war kein Produkt für den Massenmarkt. Es war ein Luxusgut, das sich nur Großkonzerne, Militärbehörden und Forschungseinstitute leisten konnten. Und wer die Software schrieb, war gleichzeitig Architekt, Statiker und Maurer in einer Person.
Das klingt nach mittelalterlichem Bauwesen – und das ist kein Zufall. Eine gotische Kathedrale entstand nicht nach einem Plan, der in einer Woche auf dem Tisch lag. Sie wuchs über Generationen, jeder Stein von Menschenhand gesetzt, jedes Maß mit handwerklichem Urteil abgewogen. Großartig im Ergebnis. Brutal langsam im Prozess.
Hochsprachen: Die Fertigteile kommen
Mit C, später Pascal und den frühen Hochsprachen änderte sich das Bild. Abstraktion hielt Einzug – und das war eine echte Befreiung. Plötzlich musste ein Entwickler nicht mehr jeden Takt der Maschine im Kopf haben. Er konnte in Konzepten denken.
Wieder das Bau-Bild: Fertigteile und standardisierte Maße verkürzten die Bauzeit dramatisch und demokratisierten das Handwerk. Plötzlich konnten mehr Menschen bauen – und mehr Menschen konnten sich Gebäude leisten. Software wurde zugänglicher, die Zielgruppen wuchsen. Und mit dem Wachstum kam die Arbeitsteilung: Programmierer, Systemarchitekt, Tester – Rollen, die sich zu differenzieren begannen, weil die Komplexität es erzwang.
Frameworks: Systembau mit vorgefertigten Modulen
Spring, Ruby on Rails, Django. Das war der nächste Sprung – und ein gewaltiger. Niemand hat mehr jede Schraube selbst gedreht. Wer eine Webanwendung bauen wollte, hat nicht mehr das HTTP-Protokoll von Grund auf implementiert. Er griff auf erprobte Strukturen zurück, die tausende Entwickler vor ihm validiert hatten.
Die Produktivität explodierte. Und damit auch der Appetit. Software wurde so erschwinglich, dass sie plötzlich für Nischenmärkte wirtschaftlich wurde – für kleine Nutzergruppen, spezialisierte Branchen, individuelle Workflows. Was früher ein Großprojekt war, wurde zum Startup. Was früher ein Startup war, wurde zur Solo-App eines Wochenend-Projekts.
Klingt erstmal nur gut. Ist es aber nur zur Hälfte.
Denn die Anforderungen wuchsen schneller als die Werkzeuge. Mehr Nutzer bedeuteten mehr Erwartungen. Mehr Spezialisierung bedeutete mehr Komplexität. Mehr Systeme bedeuteten mehr Abhängigkeiten, mehr Sicherheitsanforderungen, mehr regulatorische Auflagen. Die Fertigbauweise hatte die Produktion demokratisiert – aber die steigende Komplexität einfach wegabstrahieren konnte sie nicht.
Wenn mehr Maurer nicht mehr hilft
Hier wird’s interessant. Das Bauwesen kennt dieses Phänomen genau: Ein Wolkenkratzer wird nicht schneller fertig, wenn man die doppelte Anzahl an Arbeitern einsetzt. Ab einem bestimmten Punkt behindern sie sich gegenseitig. Fred Brooks hat das für Software schon 1975 präzise formuliert: Adding manpower to a late software project makes it later. Brooks‘ Law ist keine historische Kuriosität – es ist eine strukturelle Wahrheit, die heute genauso gilt wie damals.
Günstigere Entwickler lösen das Problem nicht. Mehr Entwickler lösen es ab einem gewissen Komplexitätsniveau auch nicht mehr. Bessere Frameworks allein auch nicht. Die Koordinationskosten steigen, die technische Schuld akkumuliert, und das System selbst wird zur größten Bremse seiner eigenen Weiterentwicklung.
Ich glaube, wir stehen gerade an diesem Punkt. Nicht vor einem Effizienzproblem, das sich wegoptimieren lässt – sondern vor einem strukturellen Wandel. Und solche Momente hat die Geschichte der Softwareentwicklung schon erlebt.
Der Chirurg betritt den Saal
Hier möchte ich die Metapher wechseln – vom Bauwesen in den OP.
Die Medizin kennt eine andere Art von Sprung. Nicht die Optimierung einer Methode, sondern ihre fundamentale Erweiterung. Als Narkose eingeführt wurde, wurden Operationen nicht nur schneller – es wurden Eingriffe möglich, die vorher schlicht undenkbar waren. Als sterile Operationsmethoden kamen, sank die Sterblichkeit nicht graduell – sie fiel. Als Bildgebung in den OP einzog, eröffneten sich neue Räume der Präzision. Als Robotersysteme kamen, konnte ein Chirurg Eingriffe vornehmen, die die menschliche Hand alleine nie geleistet hätte.
Und jedes Mal dasselbe Muster: Der Chirurg wurde nicht ersetzt. Es wurde erweitert, was ein Chirurg leisten kann. Der Appetit auf komplexere Eingriffe stieg. Die Erwartungen auch. Und die Frage, wer im Schadensfall geradestehen muss, war nie fraglich: der Chirurg. Immer.
Genau so sehe ich KI in der Softwareentwicklung. Nicht als nächste Version eines Frameworks. Sondern als Technologiesprung der Kategorie Narkose – ein Enabler für Eingriffe, die bisher zu aufwendig, zu teuer oder zu komplex waren. Was Assembler zu Hochsprachen war, was die Eigentwicklung zu Spring oder Rails war, das ist KI zu spezialisierten Softwareanwendungen heute: der nächste notwendige Schritt, der möglich macht, was vorher nicht wirtschaftlich war.
Also: Rettung oder Fluch?
Ich wäre unehrlich, wenn ich hier eine klare Antwort liefern würde. Denn die Frage hat wirklich zwei Seiten – und beide sind überzeugend.
Die optimistische Lesart: KI demokratisiert Softwareentwicklung weiter. Noch kleinere Nischen, noch spezialisiertere Produkte werden wirtschaftlich. Entwickler können sich auf das konzentrieren, was Maschinen nicht übernehmen können – Urteilsvermögen, Architekturentscheidungen, das Verstehen von Kontext und Konsequenz. Der Paradigmenwechsel, den die Branche braucht, findet genau jetzt statt.
Die pessimistische Lesart: Der Appetit wächst mit dem Werkzeug. Wenn KI die Entwicklung beschleunigt, werden Releasezyklen nicht länger – sie werden kürzer. Die Erwartungen steigen, die Fehlertoleranz sinkt, der Druck wächst. Und die Komplexität, die KI aus der Implementierung heraushält, verschwindet nicht. Sie verlagert sich – in Anforderungsmanagement, Review-Prozesse, Qualitätssicherung, Systemkontrolle. Wer glaubt, ein Unternehmen könne künftig Prompts eingeben und fertige, verantwortungslos deploybare Software erhalten, hat das Grundproblem nicht verstanden.
Und dann ist da noch die Frage, die ich in vielen Diskussionen vermisse: Wer haftet, wenn der KI-Assistent operiert und etwas schiefgeht? Die Antwort ist dieselbe wie im OP. Der Entwickler. Immer.
Der Architekt unterschreibt den Plan
Zurück zum Bauwesen für das Schlussbild. Der Architekt, der heute mit parametrischer Software arbeitet, ist produktiver als sein Kollege mit dem Reißbrett – um Größenordnungen. Er kann Varianten in Stunden durchspielen, die früher Wochen gedauert hätten. Er kann Strukturen simulieren, visualisieren und optimieren, bevor der erste Stein gesetzt wird.
Aber er unterschreibt den Plan immer noch selbst. Mit seinem Namen. Mit seiner Zulassung. Mit seiner persönlichen Haftung.
Das ist kein bürokratisches Relikt. Es ist die strukturell richtige Antwort auf ein System, das zu komplex ist, um Verantwortung zu diffundieren.
Softwareentwicklung steht vor demselben Prinzip. KI macht Entwickler nicht überflüssig – sie macht sie zu etwas Wertvolleren: zu denjenigen, die verstehen, was sie reviewen, was sie deployen und wofür sie geradestehen. Die eigentliche Frage war nie „Kann die KI das?“ Sie lautet: „Wer versteht das System – und wer steht dafür gerade?“
Die Branche, die das versteht, wird von diesem Wandel profitieren. Die, die KI als reinen Kostensenkungshebel begreift und die Verantwortungsfrage ausklammert, wird die nächste Krise nicht durch bessere Werkzeuge verhindern.
Sie wird sie damit beschleunigen.
Schreibe einen Kommentar