Die CEOs der grossen KI-Firmen werden nicht müde zu behaupten, KI werde bis zu 40 Prozent aller Jobs vernichten. Die Schlagzeile wirkt. Steffen wird von Schulabgängern gefragt, ob sich ein Tech-Studium überhaupt noch lohnt, und eine deutsche Hochschule hat inzwischen davon abgeraten, Computer Science zu studieren.
In Folge 4 von Prompt & Proper nehmen Steffen Ochsenreither von der Post und ich diese Zahl auseinander. Was danach übrig bleibt, ist eine Verschiebung, die deutlich unspektakulärer klingt und praktisch mehr verändert.
Wer die 40 Prozent in die Welt setzt, verkauft Lizenzen#
Wenn der CEO eines solchen Start-ups auf die Bühne geht und uns erklärt, wie die Welt funktioniert, hat er sich das nicht dort oben spontan überlegt. Das ist ein Marketing-Pitch, abgestimmt mit seinem Marketing-Team. Mich nervt dabei weniger der Pitch als die Tatsache, dass wir darauf hereinfallen. Die KI-Echokammer ist gross, und in ihr wird die Zahl so lange weitergereicht, bis sie wie ein Befund klingt.
Die Ökonomie dahinter ist simpel. KI ist schweineteuer, es muss massiv in Infrastruktur investiert werden, und die Ausgaben sind um Faktoren grösser als die Einnahmen. Steffen hat die Zahlen mitgebracht: Google, Microsoft, Meta und Amazon geben 2026 zusammen zwei Milliarden Dollar pro Tag aus. Weltweit nutzen rund 1,3 Milliarden Menschen KI, der absolute Grossteil davon kostenlos. Damit diese zwei Milliarden gedeckt wären, müsste jeder von ihnen etwa 600 Dollar im Jahr zahlen. Davon sind wir weit entfernt.
Von privaten Investoren und VCs bekommen sie diese Summen nicht mehr. Also gehen sie an den Aktienmarkt. Und dort verkauft sich eine Produktivitätsrevolution besser als eine Infrastrukturrechnung. Dass es echte Produktivitätsgewinne gibt, bestreiten wir beide nicht, ich merke sie jeden Tag selbst. Der Sprung von “es macht mich schneller” zu “40 Prozent der Jobs verschwinden” steht aber in keinen Daten.
Die Zinsen erklären die Entlassungen besser als die KI#
Schauen wir uns das grosse Bild an. Als Covid kam, senkten die Zentralbanken die Leitzinsen, Geld wurde günstig. Gleichzeitig hatten wir einen Fachkräftemangel, und viele Firmen mussten die verschlafene Digitalisierung nachholen. Also wurde eingestellt, teils weit über den Bedarf hinaus. In dieser Notlage war das richtig.
Jetzt erhöhen die Zentralbanken die Leitzinsen wieder. Geld wird knapper, Investitionen werden teurer, und dann baust du Überkapazität ab. Genau das passiert gerade.
Wenn ein CEO nun Entlassungen verkünden muss, weil zu viel eingestellt wurde oder ein Produkt nicht mehr rentiert, ist das eine schlechte Nachricht. Er setzt sich mit dem Marketing-Team zusammen, und da ist sie: die KI, dazu die Tech-Bros mit ihren 40 Prozent. Aus “wir haben schlecht geplant” wird “wir sind dank KI produktiver geworden”, und der Aktienkurs steigt, statt zu fallen.
Steffen hat die Zahl, die dazu passt. Der Grossteil der Layoffs hat sechs Monate vor dem Release von ChatGPT begonnen, lange vor Agentic Coding. Entweder können all diese Firmen hellsehen, oder es steckt etwas anderes dahinter. Dazu kommt: Über die Jahre hinweg werden ungefähr gleich viele Software-Entwickler eingestellt wie vor 2022, auch bei den Grossen. Sie erzählen, sie könnten 20 bis 40 Prozent der Belegschaft entlassen, und stellen parallel weiter ein.
Steffen hat noch einen Punkt ergänzt, der besonders für produzierende Unternehmen zählt. Das Kerngeschäft ist dort das Produkt, die Schraube. Data Science und KI kommen on top, um die Produktion zu optimieren. In den Hype-Jahren 21 und 22 wurden dafür viele Leute eingestellt, viele dieser Initiativen sind unterwegs gestorben. Wenn das Geld knapper wird, geht man zuerst an das, was on top sitzt. Das Ergebnis sieht aus wie ein Jobverlust durch KI und ist keiner.
Was die Studien sagen#
Untersucht wurde das inzwischen. Yale und Brookings sehen bis Mitte 2025 keine Anzeichen für einen durch KI ausgelösten Massenjobverlust. Die KOF in der Schweiz sieht zwar, dass KI Spuren hinterlässt, findet aber keine Belege dafür, dass Menschen wegen KI ihren Job verloren haben.
Was man sieht, hat Stanford herausgefunden: Unternehmen stellen weniger juniore Leute ein. Das beobachte ich bei Zühlke genauso. Wir stellen weniger Junioren ein, weil unsere Kunden weniger Junioren wollen. Das hat Folgen, und über die reden wir zu wenig.
Warum es zuerst die Junioren trifft#
Steffens Erklärung: KI augmentiert den Nutzer, und diese Augmentation verläuft nicht linear, sondern exponentiell. Bei einem Senior kommt entsprechend mehr heraus als bei einem Junior.
Dazu kommt das Verhalten. Junioren arbeiten stark mit dem Agenten und hinterfragen den generierten Code selten. Copy und paste gab es mit Stack Overflow auch, nur musstest du das Schnipsel damals noch in dein Gesamtkonstrukt einpassen. Heute sagst du “go fix” und gibst dir nicht einmal mehr Mühe mit dem Prompt. Die Erwartung an einen Senior ist, dass er das Ergebnis hinterfragt und bewerten kann.
In Teams haben wir das Muster schon gesehen: Junioren generieren viel Code, und die Seniors sind mehr damit beschäftigt, ihn zu reviewen, als selbst zu entwickeln. Produktiver wird das Team dadurch nicht.
Das Studium muss sich wandeln#
Ich doziere an Fachhochschulen, und dort ist die Frage angekommen, was ein Abschluss noch wert ist und was man überhaupt studieren soll. Als Steffen und ich studiert haben, standen Programmieren und Algorithmen im Vordergrund. Nach dem, was ich mit anderen Dozenten und Professoren diskutiere, rückt etwas anderes nach vorne: ganze Applikationen end-to-end entwickeln und betreiben.
Wer rauskommt, sollte entlang der gesamten Wertschöpfungskette ein Produkt fertig bauen, betreiben, monitoren und beurteilen können, ob es taugt. Damit hebst du den Junior direkt auf das, was heute als Expert gilt. Sobald die Ersten davon auf den Arbeitsmarkt kommen, wird die interessante Frage sein, was dann der neue Expert ist.
Rollen werden breiter, Teams kleiner#
Was KI generell macht, sagt Steffen, ist die Eintrittshürde senken, egal wofür. Ich kann mich plötzlich mit einem Juristen unterhalten und klinge zumindest wie einer. Über Business-Analyse, Entwicklung und Product Management hinweg wird man überall ansatzweise gut, ohne irgendwo der Experte zu sein. Damit lassen sich Jobprofile zusammenlegen, und die Übergaben zwischen den Rollen fallen weg. Das Produkt entsteht aus einem Kopf und aus einem Guss.
Sein Bild dafür ist der Schreiner. Der hat das Möbel im Kopf, bevor er anfängt. Früher hat er gehobelt, heute nimmt er elektrische Werkzeuge und ist damit viel schneller. Das grosse Ganze braucht er weiterhin, und inzwischen macht er Marketing, Vertrieb und Spedition gleich selbst.
Das deckt sich mit dem, was wir in Projekten beobachten. Die Rollen entlang des Wertstroms werden breiter. Der PO behält seine Produktvision und codet die ersten Features gleich selbst, gerade dort, wo alles Source Code ist und weder Jira noch Confluence im Weg stehen. Der Button, der grün werden soll, ist in dieser Welt kein Ticket mehr. Der Software-Engineer wächst gleichzeitig Richtung Architektur, Quality Assurance und DevOps.
Meine Hypothese, die ich in Keynotes immer wieder formuliere: Produkt- und Serviceteams kollabieren auf 3 plus minus 2 Personen, unterstützt durch Agenten. Die Agilität hatte 7 plus minus 2 formuliert. Im agentischen Zeitalter werden es 3 plus minus 2, und es kann durchaus eine einzelne Person sein, die ein komplettes Produkt end-to-end entwickelt.
Steffen hält das für machbar, weil vieles, was heute Zeit frisst, verschwindet. Tickets schreiben, Dokumentation, Requests annehmen, Mockups bauen. Ein Agent, der bei jedem Crash oder User-Request automatisch ein Ticket samt Bugfix-Vorschlag erzeugt, existiert heute schon rudimentär. Du schaust einmal pro Woche ins Backlog und gehst durch. Das ist eine andere Qualität als das, was wir bisher machen konnten.
Die neuen Engpässe#
Interessant wird die Frage, wo der Engpass dann sitzt. Coding ist es nicht mehr. Der erste sitzt beim Review. Viele meiner Kollegen sagen, sie verbringen die Hälfte des Tages oder mehr mit Pull Requests, die von Agenten oder von Junioren mit Agenten erzeugt wurden.
Den zweiten finde ich fast noch interessanter, er sitzt ganz am Anfang. Mit dieser Technologie können wir alles bauen. Nur ist nicht alles sinnvoll. Die Teamgrössen bleiben aktuell bestehen, und die Budgets sind jährlich und bleiben ebenfalls gleich. Also produzieren wir für dasselbe Geld einfach mehr Features. Der Engpass ist die Entscheidung, welche davon es überhaupt wert sind.
Wie man validiert, bevor man baut#
Etwas startet meistens mit einer Idee, und hinter jeder Idee steckt eine Hypothese. Die musst du herauskristallisieren: Für welchen Kunden entsteht hier welcher Wert? Wenn der Button grün sein soll und dahinter eine Kalkulation erscheint, was genau ist der Mehrwert?
Ist die Hypothese formuliert, kommen die Leading Indicators. Damit meine ich wirklich vor dem Bauen: Woran erkennen wir, dass diese Hypothese stimmt? Das kann ein schneller Prototyp mit einem Agenten sein. Es kann genauso gut ein Interview mit potenziellen Kunden oder Stakeholdern sein. Klassische UX-Techniken werden dadurch wichtiger, sonst bauen wir sehr viel und häufen technische Schulden an.
Steffen hat sofort nachgehakt: Die Einstiegshürde für den PO ist niedrig, also wird er das wirklich alles validieren? Wird er nicht. Und ja, das persönliche Gusto gewinnt gerade regelmässig. Aktuell wird gebaut, ohne dass gross nachgedacht wird. Man könnte den Agenten fragen, ob ein Feature sinnvoll ist. Macht keiner. Mehr liefern gilt als besser, und das wird uns noch auf die Füsse fallen. Wir sehen mehr Output, der Outcome kommt nicht nach, und die Maintenance-Kosten gehen durch die Decke.
Was ihr stattdessen messen solltet#
Steffen ist bei den heute üblichen KPIs deutlich: Tokenverbrauch ist kein KPI. Anzahl Pull Requests ist kein KPI. Anzahl abgearbeiteter Jira-Tickets ist erst recht keiner. Sauber messbar wäre nur, dasselbe Projekt einmal mit und einmal ohne KI zu bauen, und das macht aus guten Gründen niemand. Bis dahin bleibt viel subjektives Empfinden der Entwickler.
Meine Empfehlung ist ein Buch aus dem Jahr 2018: “Accelerate: The Science Behind DevOps” mit den vier DORA-Metriken. Das sind die einzigen Metriken für Software-Delivery-Performance, die wissenschaftlich hinterlegt sind, und sie funktionieren im KI-Zeitalter unverändert gut:
- Lead Time. Die Zeit vom Code-Commit bis in die Produktion.
- Deployment-Frequenz. Wie oft deployst du in die Produktion? Deployment ist dabei ungleich Release, dafür brauchst du ein sauberes System mit Feature Toggles.
- Mean Time to Recovery. Wenn du oft deployst, fallen Systeme auch mal aus. Wie lange dauert es, bis du wieder online bist?
- Change Failure Rate. Der Prozentsatz an Deployments, der einen Ausfall verursacht hat.
Wenn ich Software-Delivery-Performance messe, nehme ich zusätzlich Kundenzufriedenheit und Team Satisfaction dazu. Wie glücklich das Team ist, verrät einiges über den Rest.
Das Take-away#
Steffens Fazit ist der Satz, den sich Führungsetagen aufschreiben sollten:
„Mehr Outcome ist nicht gleich mehr guter Outcome."
KI nimmt dir den Job nicht. Sie verbreitert ihn. Die End-to-End-Sicht wird wichtiger, die Rollen wachsen zusammen, und die Engpässe wandern ans Review und an den Anfang der Kette. Und manchmal lohnt der Schritt zurück zu einem Buch von 2018, das nach acht Jahren immer noch trägt.
Wenn euch die Folge gefällt, abonniert Prompt & Proper auf Spotify, Apple Podcasts, Amazon Music oder YouTube und schreibt uns, mit welchem KI-Thema ihr gerade kämpft. Alle Folgen: promptandproper.ai.