Warum KI Softwareingenieure nicht ersetzt hat – und warum sie das auch künftig nicht tun wird
(normaltech.ai)- Software Engineering gehört zu den Berufsgruppen, in denen KI besonders schnell eingeführt wird, aber die Erzählung, dass Massenentlassungen stattfinden, sobald KI ein bestimmtes Fähigkeitsniveau erreicht, wird durch die derzeitigen Belege nicht gestützt
- In den Fällen von Block, Snap und Intuit wurde KI zwar als Begründung für Entlassungen genannt, der tatsächliche Hintergrund hing jedoch direkter mit finanziellem Druck, Anforderungen zur Kostensenkung und dem Abbau von Managementebenen zusammen
- Softwareentwicklung hat eine Sandwich-Struktur aus Entscheiden, Ausführen und Ausliefern; KI komprimiert die Ausführungsebene, aber die Ebenen, auf denen entschieden wird, was gebaut wird, und auf denen Ergebnisse verifiziert und verantwortet werden, widersetzen sich der Automatisierung stark
- „Vibe coding“ bezeichnet einen Ansatz, bei dem man Agenten ohne Aufsicht und Review arbeiten lässt; reale Ingenieure nutzen Agenten dagegen im Modus des agentic engineering, bei dem Menschen Kontrolle und Verantwortung behalten
- Wenn KI die Kosten der Softwareproduktion senkt, kann dadurch mehr Nachfrage nach Software entstehen; auch wenn einzelne Karrieren ins Wanken geraten können, dürfte die Gesamtnachfrage stark bleiben
Warum KI Softwareingenieure nicht ersetzt hat – und warum sie das auch künftig nicht tun wird
-
Coding agents as normal technology
- Die Angst und Unsicherheit darüber, ob KI Arbeitsplätze ersetzt, ist groß, aber um diese Frage zu betrachten, muss man auf den Bereich Software Engineering schauen, in dem KI-Fähigkeiten und Einführung besonders schnell vorangeschritten sind
- Die Erzählung, dass es zu Massenentlassungen kommt, sobald KI eine bestimmte Schwelle überschreitet, lässt sich anhand der verfügbaren Belege zurückweisen
- Wenn die Erzählung von Massenentlassungen nicht einmal in einem Bereich mit kaum regulatorischen Hürden trägt, dann haben andere Berufsgruppen wahrscheinlich noch stärkere Puffer
- Wissensarbeit und Softwareentwicklung lassen sich als decide-execute-deliver sandwich verstehen; KI komprimiert die Ausführungsebene, aber die Entscheidungs- und Auslieferungsebene werden nicht allein durch bessere Fähigkeiten automatisiert
- Für die Zukunft der Nachfrage nach Software Engineering ist vorsichtiger Optimismus möglich, auch wenn individuelle Karrieren instabil sein können, selbst bei gesunder Gesamtnachfrage
Fälle angeblich KI-bedingter Massenentlassungen in der Softwarebranche kommen typischem „AI washing“ sehr nahe
-
Der Fall Block
- Block kündigte im Februar die Entlassung von 4.000 Mitarbeitern an, und Jack Dorsey sagte, KI ermögliche „kleinere und flachere Teams“, wobei er auf Verbesserungen der Modellfähigkeiten bis Ende 2025 verwies
- Spätere Berichte zeichneten jedoch ein anderes Bild: Block stand nach einer Verdreifachung der Belegschaft während der Pandemie unter starkem finanziellem Druck
- Die Datenwissenschaftlerin Naoko Takeda aus dem Cash-App-Team schrieb, Block habe KI allen aufgezwungen, die Produktivitätsgewinne seien jedoch sehr begrenzt gewesen; sie lehnte eine 75%ige Bleibeprämie ab und kündigte
- Andere befragte Mitarbeiter hatten deutlich andere Vorstellungen davon, was KI bei Block tatsächlich leisten kann und ob Dorsey das Thema richtig verstanden hatte
- Aaron Levie wies darauf hin, dass CEOs leicht in Fehlvorstellungen über den Nutzen von KI geraten, weil sie zwar schnelle Prototypen sehen, aber nicht die 90% der Arbeit, die nötig sind, um daraus ein fertiges Produkt zu machen
-
Der Fall Snap
- Snap entließ im April rund 1.000 Mitarbeiter, und Evan Spiegel nannte KI in dem Entlassungsmemo als Hauptgrund
- Spiegel sagte, 65% des neuen Codes seien von KI erzeugt worden
- Tatsächlich erfolgten die Entlassungen nach einer Kampagne aktivistischer Investoren, die Kostensenkungen verlangten
- Snap schrieb seit dem IPO 2017 jedes Jahr Nettoverluste, und die Aktie fiel 2026 um mehr als 30%
- Der Charakter des Stellenabbaus bestand darin, 150 verschiedene Rollen im Augmented-Reality-Bereich zu streichen; das passt nicht zu den unternehmensweiten Kürzungen in Programmier- und KI-exponierten Rollen, die man erwarten würde, wenn KI die Ursache wäre
-
Der Fall Intuit
- Intuit kündigte im Mai den Abbau von 3.000 Stellen an; zugleich wurden Verträge mit Anthropic und OpenAI bekannt
- Medien stellten dies als KI-getriebene Restrukturierung dar, doch der CEO widersprach und sagte, die Entlassungen hätten nichts mit KI zu tun
- Betroffen gewesen seien laut Unternehmen Rollen mit viel „Koordination“ sowie zu viele Managementebenen
- Die Fälle Block, Snap und Intuit zeigen, dass KI zwar als vordergründige Begründung für Entlassungen dient, die eigentlichen Hintergründe aber direkter mit Organisationslage und Kostenstruktur zusammenhingen
-
AI washing ist ein gesamtwirtschaftliches Phänomen
- In jeder untersuchten Geschichte über angeblich KI-bedingte Entlassungen im Software Engineering zeigte sich dieselbe Diskrepanz zwischen Erzählung und Realität
- 59% der US-Hiring-Manager räumen ein, dass es bei Stakeholdern besser ankommt, wenn man Einstellungsstopps oder Entlassungen mit KI statt mit finanziellen Zwängen erklärt
- J. P. Gownder von Forrester sagt, dass neun von zehn Unternehmen, die sich angeblich auf KI-bedingte Entlassungen vorbereiten, weder reife noch validierte KI-Anwendungen haben und oft noch nicht einmal angefangen haben
- In einer HBR-Umfrage unter mehr als 1.000 Führungskräften weltweit hatten 21% in Erwartung von KI bereits umfangreiche Personalabbauten vorgenommen, weitere 39% geringe oder mittlere präventive Kürzungen
- Der Anteil, der bereits im Zusammenhang mit tatsächlicher KI-Implementierung umfangreiche Stellenkürzungen vorgenommen hatte, lag bei 2%; das zeigt die große Lücke zwischen erwartungsbasierten und implementierungsbasierten Kürzungen
-
WARN-Act-Daten
- Der WARN Act verlangt bestimmte Offenlegungen bei Betriebsschließungen und Massenentlassungen, die mehr als 100 Beschäftigte betreffen
- Der Bundesstaat New York ergänzte im März 2025 als erster US-Bundesstaat in den WARN-Act-Formularen ein Kontrollkästchen zur Offenlegung von KI-Bezug
- Im ersten Jahr reichten mehr als 160 Unternehmen WARN-Mitteilungen ein, aber kein einziges markierte das KI-Feld
- Bis Ende Mai hatte laut Bestätigung des New Yorker Arbeitsministeriums nur Nespresso das Kästchen ausgewählt
- Wenn die eingereichten Angaben korrekt sind, dann waren in diesem Zeitraum von rund 25.000 Entlassenen im Bundesstaat New York 46 Personen von KI betroffen, also etwa 0,2%
-
Entlassungen sind das falsche Signal, um KI-Produktivitätseffekte zu beobachten
- Forschungsergebnisse deuten darauf hin, dass KI-Produktivitätseffekte eher über langsamere Neueinstellungen wirken als über die Entlassung bestehender Mitarbeiter
- Wer bestehende Mitarbeiter entlässt, verliert stilles Wissen und Organisationskapital, die für den effektiven Einsatz von KI nötig sind
- Entlassungen sind außerdem teuer, etwa durch Abfindungen, sinkende Moral und das Risiko späterer Wiederanstellung
- Durch natürliche Fluktuation lässt sich innerhalb weniger Jahre oft dasselbe Ergebnis erreichen, weshalb Massenentlassungen meist unnötig sind
-
Daten zu Beschäftigungstrends
- Eine Studie von Ökonomen der Federal Reserve bündelt die relevanten Belege im US-Kontext
- Die Beschäftigung wächst weiterhin, aber seit ChatGPT etwa 3 Prozentpunkte pro Jahr langsamer als auf dem kontrafaktischen Pfad ohne KI
- Die Methodik der Studie erfasst Selbstständigkeit nicht, sodass ein Teil der Wachstumsverlangsamung durch Gründungen aufgefangen worden sein könnte
- Andere Studien liefern Hinweise darauf, dass KI Gründungen erleichtert
- Das tatsächliche Bild könnte also gesünder sein, als die Federal-Reserve-Studie zeigt
-
Reale, aber anders gelagerte KI-bedingte Arbeitsplatzverluste
- Arbeitsplatzverluste im Software Engineering können entstehen, wenn KI die Nachfrage nach einem Produkt senkt
- Chegg und Stack Overflow werden als Fälle genannt, in denen KI die Nachfrage nach Produkten für Hausaufgabenhilfe oder technische Hilfe reduzierte; beide Unternehmen entließen Mitarbeiter
- In solchen Fällen erledigte KI nicht direkt die Arbeit der Beschäftigten, sondern verringerte den Bedarf an dieser Arbeit
- Von den 270 Berufen in der US-Volkszählung von 1950 verschwand durch Automatisierung nur einer vollständig, nämlich der Fahrstuhlführer; mehrere andere, etwa der Telegrafist, wurden jedoch durch neue Technologien überflüssig
- Entlassungen bei Unternehmen wie IBM oder SAP, die KI verkaufen statt kaufen, ähneln eher gewöhnlichen Restrukturierungen, bei denen Personal aus bestehenden Funktionen in schneller wachsende Produktlinien verlagert wird, als einer direkten Ersetzung von Arbeitern
Warum Coding Agents nicht zu Arbeitsersatz geführt haben: das decide-execute-deliver sandwich
-
Der Anteil KI-geschriebenen Codes hat fast keinen Bezug zu Arbeitsersatz
- Manche Tech-Führungskräfte nennen den Anteil KI-geschriebenen Codes zusammen mit Entlassungen oder Prognosen künftiger Arbeitsplatzverluste
- Das verstärkt die simple Denkweise, dass man keine Coder mehr brauche, wenn KI allen Code schreibt
- Doch der Anteil KI-generierten Codes ist als zentrale Kennzahl für Arbeitsersatz nahezu irrelevant
- Das Schreiben von Code war nicht der Engpass und war es auch früher nicht
-
Code schreiben war nie der Engpass
- Eine Arbeit von 2019 kam nach Auswertung bestehender Forschung zu dem Schluss, dass Entwickler je nach Studie erstaunlich wenig Zeit fürs Codieren aufwenden, nämlich zwischen 9% und 61%
- Dieses Ergebnis deckt sich mit internen Daten von 6.000 Microsoft-Entwicklern
- Nachdem Coding Agents eingeführt wurden, wiesen Ende 2025 mehrere Texte darauf hin, dass das Schreiben von Code nicht der Engpass sei
- Entwickler erkennen, dass es auf die Gesamtproduktivität nur begrenzten Einfluss hat, selbst wenn Agenten den Großteil des Codes schreiben
-
Die drei tatsächlichen Engpässe
- Der tatsächliche Engpass liegt darin, zu entscheiden und zu spezifizieren, was überhaupt gebaut werden soll
- Auch das Verifizieren der gelieferten Ergebnisse und das Übernehmen von Verantwortung dafür ist ein zentraler Engpass
- Tiefes menschliches Verständnis von Codebasis, Geschäft und Umfeld ist sowohl für Entscheidungen als auch für Auslieferung notwendig
- Die Arbeit von Softwareingenieuren ist ein Sandwich aus Entscheiden, Ausführen und Ausliefern, und Verständnis ist die Voraussetzung für alle drei Ebenen
- KI hat die Mitte dieses Sandwiches komprimiert, aber die beiden Enden weitgehend unangetastet gelassen
-
Evidenz aus „Writing Code vs. Shipping Code“
- Writing Code vs. Shipping Code analysiert die Produktivitätseffekte von KI bei 100.000 GitHub-Entwicklern
- KI-Agenten erhöhten die Zahl geschriebener Codezeilen um das Achtfache, was zur These einer stark komprimierten Ausführungsebene passt
- Die Zahl der Releases stieg jedoch nur um 30%, was stark darauf hindeutet, dass menschliche Engpässe in Entscheidungs- und Auslieferungsebene weiterbestehen
-
Die Entscheidungsebene lässt sich kaum weiter ausdünnen
- Entwicklungsteams müssen entscheiden, was gebaut werden soll
- Eine wichtige Lektion für Junior-Softwareingenieure ist, dass die Spezifikation von Anforderungen länger dauert als erwartet
- Wer diese Ebene komprimiert, erzeugt in späteren Phasen größeren Schmerz
- Diese Ebene ist schwer zu automatisieren, weil sie Nutzerbedürfnisse, Marktsignale, organisatorische Prioritäten und teils regulatorische Vorgaben berücksichtigen muss
- Wenn KI-Fähigkeiten steigen, wächst zwar die Zahl der Entscheidungen, die man an KI delegieren kann, aber delegierbare Entscheidungen sind dann keine Quelle von Wettbewerbsvorteilen mehr
- Der Wert menschlicher Entscheidungen verschiebt sich nach oben, und da die Komplexität von Software mit der Zeit zunimmt, gibt es für diesen Prozess keine klare Obergrenze
-
Die Auslieferungsebene bleibt wegen Verantwortung und Verifikation bestehen
- Menschliche Teams müssen Verantwortung für das übernehmen, was sie ausliefern
- Irgendwann in der Zukunft könnten Teams mission-critical Code deployen, den sie nicht ausreichend getestet und verstanden haben
- Derzeit ist KI dafür jedoch viel zu instabil, und ein derart chaotischer Ansatz wäre eine existenzielle Bedrohung für Softwareteams und Kunden
- Selbst wenn technische Hürden verschwinden, gibt es keinen Zwang, die Kontrolle an KI abzugeben
- Über gemeinsame Normen, Gesetze und Richtlinien kann man sich dafür entscheiden, menschliche Verantwortung zu bewahren
- Haftungsrecht und branchenspezifische Regulierung wirken bereits als Geschwindigkeitsbarrieren und könnten weiter verschärft werden
-
Künftige Softwareingenieure werden eher Kranführer sein
- Je mehr die Ausführungsebene an KI delegiert wird, desto ähnlicher wird die Rolle des Softwareingenieurs der eines Kranführers
- KI-Agenten erledigen den Großteil der kognitiv schweren Arbeit, während die zentrale Aufgabe des Menschen darin besteht, die Agenten zu überwachen und zu steuern
- Manche behaupten, eine Zukunft mit menschlicher Kontrolle sei aus Kostengründen nicht tragfähig
- Fälle, in denen schlecht beaufsichtigte Coding Agents operative Datenbanken gelöscht oder andere Schäden verursacht haben, machten bereits Schlagzeilen
- Solche Fälle verbreiten sich eher wegen ihres Schockwerts als neuer Normalität und dienen als Lernanlass, vor zu starker KI-Abhängigkeit zu warnen
- Zu erkennen, ob der Einsatz schlecht beaufsichtigter KI bei risikoreichen Aufgaben zunimmt, ist nicht nur im Software Engineering, sondern in der gesamten Wirtschaft eine wichtige Datenlücke
-
Der Rückgang des Programmierens ist kein rein KI-spezifisches Phänomen
- Der Trend zum zusammengedrückten Sandwich ist neu, aber nicht ausschließlich ein Ergebnis von KI
- Schon seit mehr als 20 Jahren verfolgt das Bureau of Labor Statistics Programmierung und Software Engineering getrennt
- Grob gesagt übernehmen Programmierer nur die Ausführung, während Softwareingenieure größere Teile des Sandwiches steuern
- Programmierung ist geschrumpft und gilt als bloße Ausführungsarbeit, weshalb sie auch deutlich schlechter bezahlt wird
- KI beschleunigt einen alten Trend und senkt den Wert rein technischer Ausführungsfähigkeiten weiter
- Das Muster, dass Menschen tief in Entscheidungen und Auslieferung eingebunden bleiben, während KI die mittlere Ausführungsebene automatisiert, könnte sich breit auf Wissensarbeit insgesamt übertragen lassen
Vibe coding ist nicht agentic engineering
-
Begriffsverwirrung
- Der Begriff „vibe coding“ wird ungenau für ein breites Spektrum von Praktiken verwendet, was Verwirrung über den Wandel im Software Engineering stiftet
- Beim eigentlichen vibe coding sagt der Nutzer dem Agenten, was zu tun ist, beaufsichtigt die Ausführung aber nicht und überprüft den Code nicht
- Dieser Nutzer kann den Code womöglich gar nicht beurteilen und bewertet das Ergebnis außer bei offenkundigem Scheitern möglicherweise gar nicht
- Das unterscheidet sich von der Art, wie die meisten Softwareingenieure Agenten einsetzen
-
Agentic engineering
- Die meisten Softwareingenieure nutzen Agenten als Werkzeuge, während Menschen Kontrolle und Verantwortung für das Ergebnis behalten
- Als Begriff für diese Praxis verbreitet sich agentic engineering
- Je mehr sich agentic engineering als Standard etabliert, desto stärker stellen Ingenieure fest, dass die Überwachung von Coding Agents mehr Zeit kostet als erwartet
- Simon Willison sagte, dass er beim Beaufsichtigen von Agenten gegen 11 Uhr vormittags mental erschöpft sei; das deckt sich auch mit praktischen Erfahrungen
-
SWE-chat-Daten
- SWE-chat ist ein Datensatz zu Interaktionen mit Coding Agents von Open-Source-Entwicklern, die freiwillig ein Logging-Tool nutzten
- In dieser Studie überlebten 44% des vom Agenten erzeugten Codes bis zum Commit des Nutzers
- Vibe-coded Commits führten mit einer neunmal höheren Rate Sicherheitslücken ein als rein menschlich geschriebene Commits
- Die häufigste Nutzerabsicht war nicht die Erzeugung neuen Codes, sondern das Verstehen bestehenden Codes, mit 19% gegenüber 13%
- Da der Datensatz eine selbstselektierte Stichprobe ist, lassen sich daraus allein keine starken Schlüsse ziehen
- Dennoch stützt er andere Hinweise darauf, dass vibe coding und agentic engineering unterschiedliche Muster sind
-
Der zentrale Unterschied
- Vibe coding und agentic engineering sind keine zwei vollständig getrennten Kategorien, sondern die Endpunkte eines Spektrums
- Nicht jedes Projekt ist entweder ein einmaliges Projekt oder ein mission-critical Projekt
- Nicht jeder Workflow passt exakt in die linke oder rechte Spalte einer Tabelle
- Für die Jobfrage ist entscheidend, dass Unternehmen keine unvalidierten vibe coder anstelle von Softwareingenieuren einstellen können, um produktive Software in Produktion zu bringen
Was als Nächstes passieren könnte
-
Warum die Prognose von Massenentlassungen schwer haltbar ist
- KI-Befürworter können behaupten, dass Massenentlassungen einfach noch nicht eingetroffen seien
- Wenn das Sandwich-Modell stimmt, werden solche Vorhersagen jedoch nicht eintreten
- KI hat die mittlere Ebene des Sandwiches bereits stark komprimiert, und diese Kompression begann faktisch schon vor Jahrzehnten
- Selbst wenn die Ausführungsebene sofort und perfekt würde, wäre die Veränderung vom heutigen Stand aus klein
- Dass Entscheidungs- und Auslieferungsebene sich KI widersetzen, liegt nicht an Fähigkeitsgrenzen
-
Die Nachfrage nach Softwareingenieuren kann steigen
- Nicht nur könnten Software-Engineering-Jobs wegen KI nicht verschwinden, die Nachfrage könnte sogar steigen
- Wenn technologische Produktivitätsfortschritte die Kosten der Softwareerstellung senken, kaufen Menschen mehr Software
- Software ist ökonomisch betrachtet stark preiselastisch
- Wenn KI Softwareingenieure nicht ersetzt, dann führt mehr Softwarenachfrage zu mehr abgeleiteter Nachfrage nach Softwareingenieuren
- „Jevons’ paradox“ ist der in KI-Debatten häufig verwendete ökonomische Begriff zur Erklärung dieses Zusammenhangs
-
Historisches Muster
- Die Beschäftigung von Programmierern in den USA lag um 1950 fast bei null, heute zählt sie in die Millionen
- Das unterscheidet sich stark von Berufen wie der Landwirtschaft, in denen Mechanisierung und Automatisierung die Arbeitsnachfrage massiv reduziert haben
- Der Kalorienverbrauch von Menschen ist relativ konstant, aber die produzierte Menge an Software ist millionenfach gestiegen
- Ein modernes Auto enthält rund 100 Millionen Zeilen Code, die auf mehreren Bordcomputern laufen
- Selbst wenn es eine Obergrenze der Codenachfrage gibt, sind wir derzeit nicht in ihrer Nähe
- Fast jede kognitive Tätigkeit profitiert von Software, und weil KI die Kosten des Codierens senkt, entstehen einmalige Utilities für Arbeit und Privatgebrauch
-
Das bedeutet nicht nur Wachstum für Big Tech
- Dass es künftig viel mehr Software und möglicherweise auch mehr Softwareingenieure gibt, bedeutet nicht, dass große Tech-Konzerne einfach nur noch größer werden
- Schon heute arbeitet die Mehrheit der Softwareingenieure in internen Organisationen von Unternehmen außerhalb der Softwarebranche
- Dieser Anteil könnte weiter steigen
- „AI rollups“ bezeichnet die Idee, dass Venture Capital oder Private Equity Main-Street-Unternehmen wie Zahnarztpraxen oder Steuerkanzleien aufkauft und sie dann mit Softwareingenieuren oder KI-Ingenieuren AI-native neu aufstellt
- Diese Idee könnte sich auch als bloßer Hype erweisen; dafür ist es noch zu früh
-
Einwand gegen die Demokratisierungsprognose
- Manche prognostizieren, dass KI Software Engineering demokratisiert und dadurch die Nachfrage nach Software Engineering sinkt
- Nach dieser Sicht würden sowohl die produzierte Software als auch die dafür eingesetzte menschliche Zeit zunehmen, aber die Arbeit würde von Menschen ohne Software-Engineering-Hintergrund erledigt
- Die Idee wäre zum Beispiel, dass juristische Software leichter von jemandem mit juristischer Ausbildung als mit Software-Engineering-Ausbildung gebaut werden kann
- Solche Argumente tappen in die Falle, vibe coding und agentic engineering sowie die Ausführungsebene und das gesamte Sandwich zu verwechseln
- Auch frühere Sprachen wie FORTRAN, COBOL oder SQL gingen bei ihrem Erscheinen mit Erwartungen einer Demokratisierung des Programmierens einher, doch dazu kam es nicht
- Die eigentliche Hürde ist nicht das Erlernen von Syntax, sondern reifes Urteilsvermögen, um gute Entscheidungen unter Wahrung von Verantwortung zu treffen
-
Für individuelle Karrieren kann es tiefgreifende strukturelle Veränderungen geben
- Mit der Zeit wird wahrscheinlich mehr Zeit darauf verwendet werden, Menschen zu neuen Tätigkeiten mit Computern zu befähigen
- Diese Aktivität kann in Form von Softwarebau, Management komplexer Workflows mit Agenten oder in anderen Formen stattfinden
- Gefragt sein wird eine Kombination aus Softwarekompetenz, KI-Kompetenz und Domänenexpertise
- Ob heutige Softwareingenieure sich am besten an diese neuen Rollen anpassen werden, ist noch offen
- Auch wenn die Gesamtnachfrage nach Softwarearbeit stark bleibt, bedeutet das nicht, dass einzelne Arbeitskräfte unberührt bleiben
- KI erzeugt einen tiefgreifenden Strukturwandel in der Art, wie Software produziert wird, und welche Ingenieure profitieren oder verlieren, hängt von Unternehmensart, Region, Karrierestufe und Anpassungsgeschwindigkeit ab
1 Kommentare
Hacker-News-Kommentare
Während der gesamten Geschichte der Computerindustrie haben wir die Automatisierung des Software Engineerings aggressiv und mit großer Begeisterung vorangetrieben, und jedes Mal konnten wir dadurch schneller größere und bessere Dinge bauen.
Wenn die Produktivität stieg, stiegen auch der Wert der Arbeit und die Erwartungen mit an, und bisher schien die weltweite Nachfrage nach Software grenzenlos.
Der Grund, warum AI Software Engineers nicht ersetzt hat, ist, dass sich mit jedem Produktivitätssprung auch das Ziel verschoben hat.
Dieser Trend würde in zwei Fällen enden: Erstens, wenn die Produktivität schließlich hoch genug wird, um die weltweite Softwarenachfrage vollständig zu decken.
Dafür gibt es bislang keine Anzeichen, und man müsste klar erklären, warum es diesmal anders sein soll als in der gesamten bisherigen Geschichte der Computerindustrie.
Zweitens, wenn AI bei autonomem Handeln zu Software Engineers wird, die Menschen überlegen sind.
Also ein Zustand, in dem AI+menscliche Entwickler nicht besser sind als AI allein; bisher deuten die Belege jedoch darauf hin, dass AI ein Verstärker für Entwickler ist und für gute Ergebnisse Experten die Richtung vorgeben müssen, während AI vielleicht bis zu 90 % erledigt.
Es gibt in naher Zukunft keine starken Belege dafür, dass eines von beidem eintritt, daher dürften Software Engineers vorerst sicher sein.
Wer allerdings ein schmales Skillset hat und sich auf einen bestimmten Bereich konzentriert, etwa Frontend-Webentwicklung, sollte sich eher Sorgen machen.
Selbst wenn AI nicht alle Software Engineers ersetzt, ist die Wahrscheinlichkeit recht hoch, dass sie bestimmte Domänen vollständig absorbiert, gesteuert von Generalisten.
Insgesamt erstellen wir bereits mehr Software, als die Menschen wirklich wollen, und ein erheblicher Teil davon reicht von Müll über offensichtlichen Betrug bis hin zu fast schon bösartiger Software.
Am Ende wird wohl die eigene AI der Nutzer kleine Programme, die normale Menschen brauchen, individuell schreiben, etwa für To-do-Listen-Verwaltung oder Dateisynchronisation, und Software Engineers bleiben dann nur noch für große Unternehmensprojekte übrig.
Der überwältigende Trend kommerzieller Software in den letzten Jahrzehnten war extreme anti-user Unanpassbarkeit.
Es blieb nur noch ein einziger Happy Path übrig, und wenn der nicht zu den eigenen Bedürfnissen passt, heißt es sinngemäß: Pech gehabt.
Kommerzielle Software für gewöhnliche Menschen gibt es kaum noch, und selbst Open Source entfernt sich zunehmend von normalen Nutzern.
Bald werden gewöhnliche Menschen direkt Software erstellen können, die Probleme auf ihre eigene Weise löst.
In den meisten Fällen sind Qualität und Genauigkeit nicht besonders wichtig; wichtiger ist, dass sie angepasst, kostenlos und keine invasive Überwachungs- oder Werbeplattform ist.
Als Frontend-Entwickler sehe ich, dass aktuelle State-of-the-Art-Modelle die langweilige Arbeit an der Infrastruktur im Hintergrund, um die ich mich nicht kümmern will, ganz gut erledigen, aber bei der individuell gestalteten Designarbeit, die Kunden tatsächlich wollen, noch nicht besonders gut sind.
Das soll nicht heißen, dass jemand eindeutig recht oder unrecht hat; ich stimme nur zu, dass ein breiteres Skillset allgemein der beste Weg ist, um im neuen Zeitalter erfolgreich zu sein.
Aber so weit, dass LLMs irgendeinen Teil des Stacks vollständig dominieren und die Experten in diesem Bereich verschwinden, ist es noch nicht.
Jüngsten Analysen zufolge ist die Zahl veröffentlichter Apps stark gestiegen, während die Gesamtzahl der Reviews und Downloads stagniert.
Das heißt: Es gibt viel mehr Apps, aber nicht entsprechend mehr Nutzer, vielleicht sogar kaum mehr.
Siehe p40 / figure 12 in "WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS": https://www.nber.org/system/files/working_papers/w35275/w352...
Die Analyse steht auf den Seiten 42–43.
Man kann nicht beweisen, dass der Kuchen fix ist, aber umgekehrt auch nicht, dass der Kuchen unendlich ist.
Was Menschen bei Wachstumsnarrativen rund um Software oft übersehen, ist, dass das Geld von irgendwo kommen muss.
Damit es weiter wächst, muss irgendjemand, der heute noch nicht für Software bezahlt, neu damit anfangen; und man muss sich ansehen, wer diese Leute sind, wie viel Geld sie haben und mit welchen anderen Ausgaben das konkurriert.
Viele Unternehmen verlassen sich nach wie vor auf maßgeschneiderte Spreadsheets oder Technologien wie Microsoft Access.
Der Grund ist, dass diese Lösungen genau das tun, was gewünscht wird, die Kosten fix sind und kaum zusätzliche Änderungen oder Wartung nötig sind.
Wenn man aus der Blase herausgeht, in der wir stecken, merkt man, dass viele Menschen gar nicht an Upgrades interessiert sind, sondern einfach wollen, dass das alte Zeug, das sie schon kennen, weiter funktioniert.
Und ich sehe auch nicht wirklich, warum dieser Anteil nicht auf 99 % steigen sollte.
KI wird Softwareingenieure ganz klar ersetzen
Der fehlende Teil ist, wie im Text gesagt, Bereitstellung und Betrieb, und das ist eher der Bereich von DevOps-/SRE-/Cloud-Ingenieuren als von Softwareingenieuren.
Ich arbeite als Cloud-Ingenieur, und mehrere nichttechnische Freunde haben sich inzwischen bei mir gemeldet und erzählt, dass sie nun jeweils eigene Side Projects von Grund auf in mehreren Sprachen bauen und als lokale Anwendungen, Web-Apps und native Apps ausführen können.
Was ihnen fehlt, ist eine Plattform, auf der sie genauso leicht deployen und warten können wie ein „normaler Entwickler“.
Im Moment ist es ziemlich mühsam, dieses Fundament zu bauen, aber mit AGENTS.md, Skills und strengen End-to-End-Tests ist es durchaus möglich.
Wenn das einmal steht, können nichttechnische Nutzer weiterentwickeln, indem sie Claude/Codex sagen, was sie wollen, ohne dafür einen Softwareingenieur einstellen zu müssen.
Claude/Codex kann auf Basis einer vorher festgelegten Architektur Entscheidungen treffen und nichttechnische Nutzer anleiten.
In meinen anekdotischen Beispielen hat KI bereits mehrere Softwareingenieure ersetzt.
Wenn ein solches Fundament als Produkt verfügbar wird, könnten Greenfield-Projekte meiner Ansicht nach nur noch aus Produktsicht gesteuert werden, über Agent Coder und Platform Engineering.
Das ist der Stand heute; man muss sich nur vorstellen, wie es in fünf Jahren aussieht.
Dass Nichtingenieure mit selbstgebauten Apps ankommen, bedeutet nicht, dass KI Softwareingenieure ersetzt hat oder ersetzen wird.
Man kann Symptome mit Dr. Google nachschlagen und dann Lebensstiländerungen, Kräuterheilkunde oder rezeptfreie Medikamente ausprobieren und damit tatsächlich Erfolg haben, aber das heißt überhaupt nicht, dass Ärzte verschwinden.
Mit generativer KI kann man Musik machen, ohne Musiktheorie, musikalisches Gespür oder Kreativität zu haben, aber das bedeutet auch nicht, dass Menschen mit musikalischem Talent verschwinden.
Nur weil man mit KI-Hilfe DIY-Projekte im Haus erledigen kann, verschwinden Ingenieure nicht.
Wer hilft Domänenexperten dabei, durch Prototyp-Verbesserungs-Iterationen zu präzisieren, was tatsächlich gebraucht wird?
Wer schreibt und wartet die Betriebssysteme, Sprachen, Versionskontrollsysteme, Editoren und Terminal-Emulatoren, Wissens- und Dokumentationssysteme, PaaS-Plattformen usw., auf die Hobby-Softwarebauer angewiesen sind?
Haben sie das, was sie gebaut haben, wirklich so getestet, dass man es als robust bezeichnen kann?
Verstehen sie die möglichen Randbedingungen?
Ist die Sicherheit in Ordnung?
Per Prompt schnell irgendetwas zu erzeugen, ist nicht dasselbe wie Engineering.
Vielleicht sieht man das nicht, weil man irrtümlich annimmt, der Wert von Software Engineering liege hauptsächlich im erzeugten Code, also in den Bitmustern selbst.
Der eigentliche Wert eines Projekts liegt im Prozess des Aufbaus von Theorie und Abstraktionen: https://pages.cs.wisc.edu/~remzi/Naur.pdf
Es mag Ingenieure geben, die eine Zwei-Wochen-App bauen und sie danach nie wieder anfassen, aber ich kenne kaum jemanden, der damit seinen Lebensunterhalt verdient.
Dinge wie „eine WordPress-Seite für dein Unternehmen“ sind vielleicht machbar.
Das Problem entsteht, wenn es schon 432 Features gibt und man das 433. hinzufügen muss, ohne den Rest kaputtzumachen.
In manchen Fällen darf auch nur der kleinste Fehler nicht passieren, und manchmal erhöht schon ein einzelnes Feature die Komplexität schneller, als ein Ingenieur sie bewältigen kann, sodass das Projekt mit der Zeit eine unbeherrschbare Größe annimmt.
Es ging um kleine Anwendungsideen, die an große Systeme angebunden waren, und in 2–3 Tagen entstanden mit 3–4 Commits erste Proofs of Concept.
Das war beeindruckend, aber die Person, die sie gebaut hat, hat in den letzten drei Monaten weitere 400 Commits in dieses Projekt gesteckt, und durch die ständigen Änderungen ist das Bauen und Warten dieser App faktisch zu einem Teilzeit- oder Vollzeitjob geworden.
Diese Person ist zu einem ungeschulten Softwareentwickler geworden und versteht weder Sicherheit noch Best Practices.
Wenn Claude besser wird, könnte die Belastung sinken und vielleicht nicht mehr den ganzen Tag auffressen, aber in unserem Unternehmen sind all diese frühen „Vibe-Apps“ inzwischen zu Wartungsarbeit geworden und verschlingen immer mehr Zeit.
Offensichtlich wollen die Menschen nicht weniger, sondern mehr Software.
Traditionelles Software Engineering mag verschwinden, aber skalierendes Plattformmanagement, Sicherheit, Komplexität, Dokumentation und Business-Logik stehen in unserem Unternehmen weiterhin an.
Es stimmt zwar, dass man Projekte per Text erstellen kann, aber zumindest jenseits allereinfachster Software fühlt es sich nicht so an, als hätte es jemals ein „einrichten und vergessen“ gegeben.
Irgendjemand muss weiterhin das Ganze steuern.
Ganz gleich, ob diese Person in Software Engineering ausgebildet wurde oder nicht.
Ein erfahrener Entwickler wird es mit hoher Wahrscheinlichkeit weiterhin besser machen als jemand ohne Ausbildung.
Natürlich werden neugierige Builder schnell aufholen, aber traditionelle Entwickler haben einen großen Vorteil.
Denn wir wollten schon immer wissen, wie die Dinge im Inneren funktionieren.
Die aktuellen Vibe-Apps, für die sie Monate gebraucht haben, hätte ich mit KI in einer Stunde bauen können.
vercelauszuführen, und ein Agent kann das auf Anfrage ebenfalls problemlos erledigen.Die Bereitstellung von Desktop-Software ist je nach Plattform etwas schwieriger.
Trotzdem ist die Lücke zwischen Side Projects und großartiger Software weiterhin sehr groß, und ich kann nur schwer glauben, dass sie irgendwann geschlossen wird.
Ich verstehe nicht, warum nicht zuerst Probleme ersetzt würden, die schon vor KI gelöst waren.
Es fällt mir auch schwer zu glauben, dass persönliche Projekte komplexe Infrastruktur brauchen.
Ich würde keine Finanz-App, die unbegrenzt gewartet werden muss, per Vibe Coding bauen.
An Legacy-Systeme würde ich damit auch nicht gehen.
Dass KI einige Ingenieure ersetzt hat, steht außer Frage, aber die Beispiele von nichttechnischen Freunden mit Side Projects sind kaum relevant.
Sie haben sie gebaut, weil es jetzt möglich ist, nicht weil sie ursprünglich vorhatten, dafür jemanden zu beauftragen.
So wie sie es bisher eben auch nie beauftragt haben.
Ich arbeite in einer Entwicklungsagentur, und die meisten Kunden sind Startups, die schnell auf den Markt müssen
Seit etwa anderthalb Jahren nutzen wir agentenbasierte Entwicklung, und in dieser Zeit hat sich unsere Rolle stark verändert
Wie stark der Projekteingang zugenommen hat, kann ich ohne genaue Zahlen schwer sagen, aber sichtbar ist, dass sich die Erwartungen daran verändert haben, was wir in welchem Umfang liefern können
Projekte, für die früher 5 Personen nötig waren, werden jetzt meist von 1–2 Personen umgesetzt
Realistisch gesehen sind Greenfield-Projekte zu großen Teilen automatisiert
Viel manuelle Arbeit wie UX/UI-Design-Iterationen, Systemarchitektur-Iterationen oder das Ausprobieren mehrerer Ansätze für schwierige Probleme ohne klare Metriken passiert jetzt sofort
Wenn man es im Kopf durchdringen kann, kann man es gewissermaßen in einem Hundertstel der Zeit in die Welt bringen
In dieser Zeit hat sich auch stark verändert, wie wir arbeiten und wie wir über Systeme nachdenken
Wir leben jetzt in Symbiose mit LLMs, und ohne sie wäre es wirklich schwer
Das heißt aber nicht, dass ich den von LLMs geschriebenen Code nicht verstehe; ich verfolge weiterhin alle Änderungen und verstehe die Codebasis insgesamt viel besser als das LLM
Allerdings ist meine Fähigkeit, Code manuell zu schreiben, stark zurückgegangen, und ich finde das in Ordnung
Im Moment fühlt es sich eher so an, als wäre ich eine Übersetzungsschicht zwischen den Business-Zielen und der Technik, die diese am besten unterstützt
Es ist immer noch Problemlösung, aber auf einer viel höheren Ebene, und es ist immer noch interessant und macht Spaß
Die beste Strategie für Entwickler in dieser Ära scheint mir zu sein, kritisches Denken zu bewahren und die Werkzeuge zum eigenen Vorteil einzusetzen
Jetzt haben alle Superkräfte
Man muss nicht einmal zwingend in einem Unternehmen arbeiten, und weil Einzelentwickler Erstaunliches bauen können, ist man auch nicht mehr so sehr wie früher auf andere angewiesen
Vielleicht ist die Zukunft eine Makro-Produkt-Ökonomie, in der jeder der Welt etwas Eigenes bietet
Wenn Agent Coding gut genug wird, um Greenfield-Projekte zu bauen, dann betrifft das nicht nur Entwickler, sondern ganze Unternehmen und ganze Branchen
Das Geschäftsmodell von Entwicklungsagenturen existiert, weil Unternehmen mit schwacher technischer Kompetenz nicht wissen, wie sie mit Software umgehen sollen, und in manchen Fällen auch, weil sie opportunistisch die anfänglich arbeitsintensive Phase auslagern wollen
Aber wenn diese Technik nun bereits an den Fingerspitzen der Agenturkunden liegt, ist es nur eine Frage der Zeit, bis CEOs und Manager mit Vibe Coding anfangen und merken, dass sie nur „einen Entwickler mit etwas technischem Gespür“ brauchen
Das könnte sich auch auf viele SaaS-Geschäftsmodelle ausweiten
Viele kleine Unternehmen wollen immer noch individuelle Software, um manuelle Arbeit loszuwerden, aber ernsthafte Softwareentwickler waren dafür schon immer zu teuer
Deshalb nutzten sie oft den schlampigen Code eines Neffen oder ein SaaS-Produkt, das gerade so funktionierte
Jetzt können sie sich immer noch ziemlich holprige, aber eigene maßgeschneiderte Lösungen bauen und dabei mehr erreichen
Was Big Tech gerade tut, wirkt eher wie eine Neuausrichtung auf die Rezession; besorgniserregender ist das Chaos im kleinen und mittleren Technologiesektor
Sondern auch, dass ihnen das Netzwerk fehlt, um Kunden zu gewinnen
Die meisten Entwickler brauchen ein Unternehmen zumindest dafür, das Marketing zu übernehmen, damit sie sich auf das konzentrieren können, worin sie gut sind
Codegenerierung und Codebeurteilung sind unterschiedliche Fähigkeiten im Gehirn
Weil Programmierung hauptsächlich aus vielen kleinen syntaktischen Details besteht, kann man Schwierigkeiten beim Schreiben von Code haben und trotzdem gut im Review sein
https://xcancel.com/karpathy/status/2015883857489522876
Erfolgreiche Unternehmen in der realen Welt haben Burggräben in Form von Daten, Patenten/geistigem Eigentum, Netzwerkeffekten usw.
Nur weil Entwicklungszeit auf ein Hundertstel sinkt, heißt das nicht, dass man sofort ein neues Geschäft aufbauen kann
Wenn man sich die Technologiebranche heute anschaut, gibt es zwar viele Unternehmen, die so aussehen, als könnten sie von agilen, AI-basierten Buildern verdrängt werden, aber in der Praxis passiert das wegen Lock-in-Effekten nicht
Die Behauptung „Von den 270 Berufen in der US-Volkszählung von 1950 ist durch Automatisierung nur einer verschwunden, nämlich der Aufzugsführer“ ist irreführend
Im gleichen Zeitraum sind Arbeitsplätze in der Landwirtschaft von 15 % auf 2 % der Erwerbsbevölkerung gefallen
Dort wird gesagt, dass dies anders sei als Berufe wie in der Landwirtschaft, bei denen Mechanisierung und Automatisierung die Arbeitsnachfrage stark gesenkt haben
Der Unterschied sei, dass die von Menschen konsumierte Kalorienmenge relativ konstant ist und schon ein Anstieg um 25 % eine Adipositas-Epidemie auslöste, während die Menge produzierter Software um das Millionenfache gewachsen ist
Der Prozentwert übertreibt den Rückgang, weil die Gesamtzahl der Erwerbstätigen gewachsen ist
Betrachtet man jedoch die breitere Lebensmittelindustrie, ist die Beschäftigung dort deutlich gestiegen
Daher kann die Beschäftigung von „Codern“ zurückgehen, während die Beschäftigung in der breiteren „Software-/Technologie“-Industrie zunimmt
Rund 95 % dieser Arbeitsplätze sind bereits automatisiert worden, aber sie geben oft den Eulen die Schuld
Bei Fabriken und Fließbändern war es genauso
Jedes Mal, wenn Automatisierung eingeführt wird, verlieren Menschen weiterhin ihre Jobs, und wir „hoffen“ dann, dass sie etwas anderes finden, oder hören extreme und widersprüchliche Durchhalteparolen wie „Werde Generalist“, „Werde Spezialist“, „Geh in den Dienstleistungssektor“, „Lern coden“, „Bau Kohle ab“
Schon wenn man nur @pmarca zuhört, sieht man, wie orientierungslos und incoherent die technologische Führung ist
Auch das neueste Buch von Stripe Press zur industriellen Automatisierung ist dazu lesenswert: https://press.stripe.com/origins-of-efficiency
Die naivsten AI-Gläubigen waren meist Bastler
Das ist nachvollziehbar, weil LLM-unterstütztes Coding die Geschwindigkeit, mit der man an Dingen herumprobieren kann, erstaunlich erhöht hat
Basteln ist ein Prozess, und Menschen ziehen große Freude allein aus dem Akt des Bauens und Anpassens
Das Ergebnis ist nur eine zweitrangige oder drittrangige Überlegung
AI hat unsere Fähigkeit zu handeln und damit zu experimentieren stark erweitert, aber sie erzeugt nicht von selbst sinnvolle Wirkung, also „Engineering“
Wirkung ist wichtiger als Aktivität
Prototyping, Debugging und Testing sind keine Schein-Arbeit, nur weil sie schnell passieren
Ein Compiler erzeugt auch nicht von selbst Wirkung
Genauso wenig CI, IDEs, Frameworks oder Cloud-Infrastruktur
Sie erhöhen den Hebel der Menschen, die sie nutzen
Meine Frau wurde von AI ersetzt
Sie war Programmiererin, und die Firma hat ausdrücklich mit dem Ziel einen Agenten gebaut, meine Frau und einige andere zu ersetzen, und etwa einen Monat nachdem er zu funktionieren begann, wurde sie entlassen
Unser Team hat vor 18 Monaten einen neuen Chef bekommen, und es gab offene Bevorzugung; die einzige Person, die er mochte, war die einzige, die kein Teamplayer war
Er hat in 18 Monaten einen Weg gefunden, alle Remote-Mitarbeitenden zu entlassen, unabhängig von ihrer bisherigen Leistung
Eine davon hatte mehrfach Auszeichnungen auf höherem Level als der Chef selbst erhalten, aber er hat immer nur diese toxische Person anerkannt
Es war kein AI-Ersatz, aber die Atmosphäre, in der Menschen das Gefühl haben, wertlos zu sein, dürfte ähnlich sein wie wenn man durch AI ersetzt wird
Alle in diesem Team, einschließlich meiner Vorgesetzten, bewerben sich woanders
Meine Vorgesetzte ist hochfunktional autistisch und wird vom Chef oft verspottet
Ich hoffe wirklich, dass sie es um ihrer psychischen Gesundheit willen schaffen
Ich habe HR mehrmals auf das Problem hingewiesen und sogar Klauseln in den Arbeitsrichtlinien gefunden, gegen die der Chef verstößt, aber ich habe gelernt, dass solche Regeln zumindest hier nur auf dem Papier stehen
Dadurch habe ich eher selbst eine Zielscheibe auf den Rücken bekommen und musste gehen
Mehrere andere haben ebenfalls Bedenken geäußert, und die meisten davon haben sich danach andere Jobs gesucht
Zum Glück habe ich bald eine neue Stelle und freue mich darauf
Ich hoffe, es geht ihr gut
Mich würde interessieren, wie es danach weiterging, ob sie eine neue Stelle gefunden hat und ob sie noch im Software-Bereich ist
Dass Unternehmenskommunikation über AI-Entlassungen unehrlich ist, hebt das Risiko nicht auf
Selbst wenn das Gerede von Unternehmensseite gelogen sein sollte, können die Auswirkungen der Technologie real sein, und in diesem Kontext ist das nur Rauschen
Auch die Annahme wie in der Burger-Grafik des Artikels, dass die Umsetzungsphase schrumpft, aber alle anderen Phasen wachsen, sodass die Gesamtgröße des Burgers gleich bleibt, wirkt nicht besonders plausibel
Allerdings scheinen einige Bereiche des Software Engineerings noch sehr weit davon entfernt zu sein, bedroht zu werden
Besonders Bereiche, in denen Korrektheit entscheidend ist
In der Webentwicklung gibt es viel mehr Spielraum, sich irgendwie durchzuwursteln, aber bei Code für Raketensteuerung ist das anders
LLMs könnten vielleicht beides, aber ich glaube nicht, dass in absehbarer Zeit jemand Letzteres per Vibe Coding macht
AI hat buchstäblich bereits einen Teil ersetzt und wird das künftig noch mehr tun
Nicht alle Software Engineers werden ersetzt, aber nachdem die Büchse der Pandora geöffnet ist, werden Aufgaben mit geringem Aufwand und geringem Risiko von AI übernommen
Bei Diensten wie Lovable gibt es sehr viele tatsächlich produktiv eingesetzte Projekte, und die Alternative wäre gewesen, dass Menschen sie bauen
Es sind immer die Arbeitgeber, die Jobs ersetzen
Man sollte keine Bündel aus Grafikkarten vermenschlichen
Bei diesem Teil des Artikels bin ich nicht überzeugt
Es geht um die Behauptung: „Der eigentliche Engpass ist (1) zu entscheiden und zu spezifizieren, was gebaut werden soll, (2) das Gelieferte zu validieren und die Verantwortung dafür zu übernehmen, (3) ein tiefes menschliches Verständnis der Codebasis, des Geschäfts und des Umfelds“
Es könnte sein, dass so viel Aufwand sowohl vor- als auch nachgelagert betrieben wurde, weil Coding teuer war und als Engpass galt, damit die Eingaben stimmen und das Ergebnis nicht weggeworfen werden muss
Wenn Coding als schneller und billiger Schritt gilt, braucht es vorgelagert vielleicht nicht dieselbe Aufsicht, weil man Ergebnisse auch wegwerfen kann
Die Auswirkungen, wenn Software fehlerhaft arbeitet, und die Wahrung der Abwärtskompatibilität sind viel schlimmer