Als Black Swan bezeichnet man Ereignisse, die erst unvorstellbar erscheinen, dann die Welt verändern und im Nachhinein unvermeidlich wirken: Man hätte es doch wissen müssen.
LLMs in der Softwareentwicklung fühlen sich wie so ein Ereignis an, wenn man sich die Geschwindigkeit und Breite der Adaption und ihre Auswirkungen anschaut. Die Erwartung war: Robotik übernimmt erst körperlich schwerere Aufgaben, Automatisierung übernimmt dann die mühsamen, repetitiven Aufgaben und irgendwann wird Programmierung durch No-Code-Werkzeuge verborgen. Was stattdessen passiert, ist das Gegenteil von No-Code: eine Maschine, die unendlich viel Code ausspuckt und den Programmierer als quasi „den“ White-Collar-Beruf imitiert. Aus No-Code wird More-Code. Dadurch wird ausgerechnet zuerst der Programmierer zur Zielscheibe: Die teuren Positionen geraten unter Druck - und das auch noch zuerst.
Anders gefordert
Wer mit diesen Tools arbeitet, merkt schnell: Man kommt schneller zu Ergebnissen. Auch bei komplexen Anfragen, auch auf bestehenden Codebases.
Die kognitive Arbeit verschiebt sich dabei, sie verschwindet nicht. Früher hat man während des Schreibens ein mentales Modell aufgebaut und die Lösung entstand beim Denken in Code.
Heute bekommt man Code, den etwas anderes gedacht hat. Man muss dieses fremde Modell verstehen, beurteilen und einordnen. Das fordert nicht weniger, nur anders.
Vicki Boykis beschreibt es gut: es wird immer wichtiger, „in Form“ zu bleiben. Datenstrukturen, Pattern, Basics, weil das Urteilsvermögen über Code wichtiger wird als das Schreiben von Code. Wer die Grundlagen versteht, kann bewerten, und wer nur prompten kann, navigiert blind.
Beschleunigung in alle Richtungen
Die zweite Auswirkung ist einfacher zu beschreiben: Mehr. Von allem.
Das gilt nicht nur für die produktive Seite: Softwareprojekte werden zunehmend von KI-generierten Security-Reports und Exploits überschwemmt, weil – Überraschung – LLMs sich auch für die Schwachstellensuche einsetzen lassen. Kombiniert man das noch mit einem finanziellen Anreiz, entstehen Auswüchse, die jetzt wieder mühselig eingefangen werden müssen.
Das ist kein Randphänomen, Daniel Stenberg beschreibt es ganz gut. Zusammen mit den beobachteten Lieferkettenangriffen sind die AI Reports vermutlich eines der dominantesten Themen der IT-Sicherheit und des Open-Source-Ökosystems dieses Jahr. Die Beschleunigung trifft nicht nur die produktive und konstruktive Seite.
Wer LLMs als Werkzeug demokratisiert, demokratisiert auch Angriffsfähigkeit. Das ist keine Nebenwirkung. Das ist dasselbe Werkzeug, dasselbe Tempo. Die Last tragen die sowieso schon wenigen Maintainer, Entwickler und Admins, die das verarbeiten müssen.
Die Messlatte steigt
Entwickler waren teuer. Nicht aus Willkür, sondern weil die Arbeit schwer und das Angebot knapp ist. Die naive Annahme wäre: Wenn das Werkzeug die Arbeit erleichtert, sinkt der Druck. Das Gegenteil passiert.
Coding-Agents senken nicht die Schwierigkeit der Kernarbeit. Verstehen, beurteilen, verantworten – das bleibt schwer. Was sie verschieben, ist die Erwartung. Du hast doch jetzt die Werkzeuge. Die Benchmark ist nicht mehr der gute Entwickler, sondern der gute Entwickler mit Agenten. Also muss jeder für mehr getane Arbeit geradestehen. Gleiche kognitive Last, höheres Volumen obendrauf. Das ist kein neues Muster: Werkzeuge entlasten selten, sie heben die Norm.
Und genau deshalb heizt es sich an. Die Arbeit verdichtet sich auf weniger Schultern. Hiervon kann man fast schon täglich an vielen Stellen lesen, auch wenn KI dabei eher als Korrelation denn als Kausalität erscheint. Trotzdem setzt sich eine Erzählung fest: Jetzt gebe es KI und wer was reißen wolle, müsse jetzt mehr umsetzen. Näher ans Produkt, näher an den Kunden, näher an die Verantwortung.
Und teuer bleibt es ohnehin. Die Ersparnis, die man sich von den Werkzeugen versprach, taucht als neue Rechnung wieder auf: Was an Stellen wegfällt, fließt ins Token-Budget. „Tokenmaxxing“ nennt man das. Nur schrumpft diese Stelle nicht, sie wächst – weil billiger pro Anfrage eben nicht weniger Anfragen heißt, sondern mehr. Das Unternehmen spart nicht, es zahlt woanders, und meist mehr. Der Druck, der dabei entsteht, landet wieder bei denen, die noch da sind.
Was bleibt: die eigentliche Arbeit
Die eigentliche Frage ist nicht, was Maschinen übernehmen. Die Frage ist, was danach noch zählt. Bei Open Source zum Beispiel kann es nicht mehr nur die Verfügbarkeit von Funktionalität oder Alternativen zu proprietären Lösungen sein. Code generieren kann man sich selber. Was bleibt, ist das Projekt als kuriertes Ganzes: konsistentes Design, wenig Bugs, eine klare Vision, Vertrauen in die Maintainer. Das sind Gründe, warum man zu einem Projekt greift.
Und das gilt auch für den Beruf selbst. Die Essenz der Informatik war nie das Tippen. Sie war die Transformation: Ein Problem verstehen, eine Lösung entwerfen, die Umsetzung verantworten. Requirements Engineering und Implementierung sind zwei Seiten davon. Anforderungsanalyse erzeugt den erwarteten Zielzustand, der implementiert werden soll: aus Widersprüchen, impliziten Erwartungen und organisatorischen Realitäten. Das ist schwer zu formalisieren.
Wer erkennt die Anforderungen? Wer definiert das Problem, bevor es gelöst werden kann? Wer prüft, ob die Lösung das richtige Problem löst?
Das wird weiterhin Menschen brauchen. Doch sie werden viel mehr umsetzen müssen, daher stellt sich die Frage: Zu welchem Preis? Den werden wir in den nächsten Monaten sehen.
