Bei Amazon sagen einige Entwickler, ihre Arbeit beginne der Arbeit im Lager zu ähneln

• Amazon-Entwickler erleben seit der Einführung von KI Druck auf das Arbeitstempo und eine Vereinfachung ihrer Aufgaben
• Führungskräfte empfehlen die Nutzung von KI-Tools nachdrücklich und begründen das mit höherer Produktivität
• Einige sehen die Qualität der Arbeit verbessert, weil sich repetitive Aufgaben verringert haben, doch es gibt auch die Sorge, dass Junior-Entwickler Wachstumschancen verlieren
• Programmieren verlagert sich von direkter Schöpfung hin zu Überprüfung und Bestätigung, wodurch manche das Gefühl haben, es sei nicht mehr ihre eigene Arbeit
• Interne Gruppen wie Amazon Employees for Climate Justice teilen dazu Stress im Job und Ängste mit Blick auf die Zukunft

---

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

Auch beim Coden zählt jetzt vor allem Tempo

• Das seit der Industriellen Revolution immer wieder auftretende Phänomen der Vereinfachung von Tätigkeiten durch Mechanisierung zeigt sich nun auch im Coding
• KI vernichtet Jobs nicht unbedingt, sondern wandelt bestehende Tätigkeiten in eine einfachere und schnellere Ausführung um
• Laut einer Microsoft-Studie stieg die Produktivität von Entwicklern mit dem KI-Assistenten Copilot um mehr als 25 %
• Amazon greift das auf und verlangt mit KI schnelleres und effizienteres Arbeiten; im Aktionärsbrief wird dies als Schlüssel für Kostensenkung und Wettbewerbsfähigkeit hervorgehoben
• So arbeitet ein Entwicklungsteam etwa mit halb so vielen Leuten wie im vergangenen Jahr und soll dennoch die gleiche Menge Code liefern

Ein unternehmensübergreifender Trend

• Shopify erklärt die Nutzung von KI zur Grundanforderung für alle Mitarbeitenden und hält fest, dass dies auch in Leistungsbewertungen einfließt
• Google setzt bei internen Hackathons auf das Thema Entwicklung von KI-Tools zur Steigerung der täglichen Produktivität. Bereits mehr als 30 % des Codes entstehen durch KI-Vorschläge

Positive Seiten und Bedenken

• Einige Manager argumentieren, dass durch KI langweilige und repetitive Aufgaben wegfallen und man sich stärker auf kreativere Arbeit konzentrieren könne
• Amazon erklärt, dank KI 4.500 Personenjahre an Entwicklungsarbeit eingespart zu haben
• Der Harvard-Ökonom Lawrence Katz weist jedoch darauf hin, dass für Einsteiger in die Entwicklung Wachstumschancen verschwinden können
• Ähnlich wie frühere Fabrikarbeiter im „Geschwindigkeitsregime“ stehen auch Entwickler unter Druck, schneller zu arbeiten und mehr zu erledigen

Wie Entwickler den Wandel erleben

• Ähnlich wie in Amazons Logistiklagern erleben auch Entwickler Automatisierung und Arbeitsteilung durch KI
• Die Nutzung von KI ist zwar „optional“, wirkt aber faktisch zwingend, wenn Leistungsziele erreicht werden sollen
• Funktionen, deren Entwicklung früher Wochen dauerte, müssen nun innerhalb weniger Tage abgeschlossen werden; dafür werden Meetingzeiten reduziert und KI-generierter Code stärker genutzt
• KI kann inzwischen ganze Programme erzeugen, doch das Lesen und Prüfen von Code nimmt zu, während Spaß und Konzentration sinken

Weniger Karrierewachstum und geringere Identifikation

• Junior-Entwickler könnten durch automatisierte Tests die Gelegenheit verlieren, Code wirklich tief zu verstehen
• KI unterstützt bei vielen Aufgaben wie der Erstellung von Konzeptdokumenten oder beim Testen von Code, doch die Bewertung verschiebt sich zu einer werkzeugzentrierten statt menschenzentrierten Umgebung
• Harper Reed, früher CTO der Obama-Kampagne, sagt, wir lebten in einer Zeit, in der man nicht mehr jeden Teil im Detail verstehen müsse, und beschreibt das als eine Entwicklung ähnlich der Fertigungsindustrie
• Simon Willison bewertet KI dagegen positiv, weil sich Ideen damit schneller umsetzen lassen

Unzufriedenheit und organisierte Reaktionen

• Wegen der KI-Nutzung und des dadurch ausgelösten Wandels vieler Tätigkeiten teilen zahlreiche Entwickler in der Gruppe Amazon Employees for Climate Justice ihre Ängste und ihren Stress
• Besonders groß sind die Sorgen um sinkende Arbeitsqualität und unsichere Karriereperspektiven; das erinnere an den Stress durch das Geschwindigkeitsregime, den frühere Autoarbeiter erlebten
• Zwar gibt es bislang keine Bewegung zur Gründung einer Entwicklergewerkschaft, doch die interne Solidarität und das gemeinsame Problembewusstsein wachsen

Historischer Kontext und Ausblick

• Wie schon beim GM-Streik 1936 könnten Fragen von Arbeitstempo und Autonomie zum Auslöser kollektiven Handelns werden
• Früher konnten Einzelne Arbeitsweise und Tempo selbst steuern, heute ist der gesamte Prozess überwacht und auf Geschwindigkeit ausgerichtet

[GN⁺]

Hacker-News-Kommentare

• Geteilter Link zu archive.ph/HVZRL
• Für mich fühlt sich LLM-basierte Entwicklung wie ein übertriebener Hype an, ähnlich wie Krypto oder VR. Nachdem ich kürzlich Bugs in einer per Vibe Coding geschriebenen Codebasis beheben musste, hatte ich den Eindruck, dass dabei unstrukturierte Geschäftsprobleme einfach ohne klare Struktur in Code gegossen werden – ein einziger chaotischer Klumpen. Verbesserungsbedürftige Stellen werden mit engen Patches notdürftig geflickt, was am Ende komplexen und unorganisierten Code erzeugt. Sobald man an die Grenzen des Context Window stößt, kann sich das LLM nicht einmal mehr an seine eigenen Patches erinnern. Englisch – oder menschliche Sprache allgemein – ist zu vage, um den gewünschten Code präzise zu beschreiben, und die unzähligen Erfahrungen und Fehlversuche, die Senior-Entwickler im Code eingebettet haben, vollständig in Prompts auszudrücken, ist extrem aufwendig. Im Unterschied zu der Frage „Warum wurde es so gebaut?“ braucht man eine gewaltig konkrete und endlose Liste der Art „In dieser Situation mach nicht das, sondern jenes“
  • Eine Beobachtung, die ziemlich genau auf die Beschreibung fast jeder Codebasis passt, die ich in den letzten 30 Jahren gesehen habe – mit genau einer Ausnahme
  • Gegenrede: AI hat mir auch schon geholfen, in rund 30 Stellen Code-Muster zu finden, aus denen Struktur extrahiert werden musste. Das Problem bei Vibe Coding ist aus meiner Sicht die Haltung. Wer das eigentliche Programmieren vermeiden will, konzentriert sich oft nur auf die unmittelbare Bequemlichkeit statt auf langfristige Struktur oder Qualität – eine Art Verstärker für Faulheit
  • In Wirklichkeit besteht viel Production-Code aus zusammengeflickten Snippets, die irgendwie funktionieren. Traurigerweise laufen solche Programme in der Realität einfach, weil CPUs inzwischen viel zu schnell sind
  • Ich stimme dem Punkt zu, dass menschliche Sprache nicht eindeutig ist. Am Ende wurde schon mehrfach versucht, Software klar über natürliche Sprache zu steuern, und wie im Recht entstehen dabei ständig Grauzonen in der Auslegung. Wenn Entwickler in Zukunft vor dem Kompilieren erst über die Bedeutung von Programmen streiten müssen, ist das eine düstere Zukunft
  • AI wirkt tatsächlich genauso überhypt wie Krypto oder VR. Trotzdem wird Automatisierung am Ende auch hoch technische Berufe wie Software Engineering treffen. In den letzten zehn Jahren haben viele Menschen in der Tech-Branche so getan, als hätten die Probleme anderer Arbeiter nichts mit ihnen zu tun, aber mit der Kultur aus Reorgs und Entlassungen beginnt nun die echte Lohndämpfung. Selbst wenn AI nicht sofort alles ersetzt, reicht es schon, wenn Arbeit von fünf Leuten künftig von vier Leuten mit AI erledigt wird: eine Person wird abgebaut, und die übrigen trauen sich kaum noch, Gehaltserhöhungen zu fordern. Auch Tech-Berufe sind letztlich Arbeiterschaft – das muss man begreifen
• Zu Harper Reeds Aussage, man müsse „Code nicht tief verstehen“, wirkt so eine Bemerkung eher wie eine hastig zusammengebastelte Logik nach dem Motto „Wenn es kompiliert, deployen wir es“. In einer Automatisierungslinie wird Qualität zwar ständig gemessen, aber reale Maschinen halluzinieren nicht fortlaufend falsche Winkel oder absurde Schweißnähte – bei LLM-basierter Software wiederholen sich solche kleinen Fehler dagegen ständig
• Ich frage mich, ob LLM-basierte Tools die Produktivität von Entwicklern wirklich dramatisch gesteigert haben, oder ob Organisationen nur herausgefunden haben, dass sie mit weniger – und weniger privilegierten – Entwicklern auskommen. Selbst in großen Tech-Unternehmen sehe ich kaum Beispiele für „revolutionäre Produktivitätssteigerung“; bislang gibt es eher nur leichte Zuwächse, die gerade so die Investitionen ausgleichen
  • Vieles ist eine Wahrnehmungsfrage. Früher galt Entwicklung als schwierig, aber seit dem Aufkommen von AI-Tools wird der Einstieg ins Coding als niedriger wahrgenommen. Softwareentwicklung fühlt sich zunehmend wie Fabrikarbeit an, und die intellektuelle Befriedigung nimmt ab
  • Zweifel an der langfristigen Wartbarkeit von Codebasen. Vibe Coding häuft schrittweise Komplexität, subtile Bugs und Abstraktionsprobleme an und erhöht am Ende die Schwierigkeit von Wartung und Entwicklung neuer Features. Man könnte sich in kurzfristigen Produktivitätsgewinnen verfangen und langfristige Qualitätsverluste in Kauf nehmen
  • Organisationen versuchen schon lange per Bürokratie eine „Enttechnisierung“, also den Ersatz qualifizierter Kräfte durch standardisierte, weniger qualifizierte Arbeitskräfte. Langfristig kann das giftig sein, aber solange es konsistent ist, gibt man sich mit „durchschnittlich brauchbaren Lösungen“ zufrieden
  • Damit diese Logik überzeugt, müsste man annehmen, dass das Amazon-Management kurzfristige Gewinne stärker gewichtet als langfristige Qualität – und da bin ich mir nicht sicher
• Kurz vor dem Ruhestand empfinde ich die jüngsten Veränderungen als ernüchternd. Als ich in den 90ern anfing, hatte man noch die Freiheit, lange in Experimente und Kreativität einzutauchen. Heute sind Arbeitseinheiten, Statusberichte und ständige Rechtfertigung Pflicht. Es wird auch künftig interessante Entwickler geben, aber solche Gelegenheiten werden seltener. Eigentlich ist das nur derselbe Weg, den andere Berufe durch Automatisierung schon gegangen sind – insofern ein gerechtes Ergebnis
  • Alltägliche Stand-ups und ähnliche Statusrituale kosten Zeit und sind letztlich nur formale Reaktionen, um noch einen weiteren Tag Ruhe vor Leuten zu haben, die meine Arbeit nicht verstehen – sie entwerten die Arbeit
  • Ich bin auch jemand, der in den 90ern eingestiegen ist, und kann die JIRA-basierte Mikrokontrolle nachvollziehen. Trotzdem glaube ich nicht, dass früher automatisch das goldene Zeitalter war. Da spielt wohl auch Nostalgie mit hinein, die nur die guten Erfahrungen erinnert. Aber auch heute gibt es genug anspruchsvolle und gute Arbeit und viel zu lernen
  • Weniger die Automatisierung von Engineering-Jobs als vielmehr ein Trend, Managementfunktionen faktisch durch AI-zentrierte Überwachung zu ersetzen
• Wenn man Softwareentwicklung radikal beschleunigen will, gibt es auch die Methode, einfach den Open-Source-Code anderer zu kopieren, Spuren von Copyright und Lizenz zu entfernen und ihn so einzusetzen. Falls man Sorge hat, direkt erwischt zu werden, kann man eine externe Firma zum Reinwaschen einsetzen – oder heute billig und schnell AI dafür nutzen. Google hat sich früher mit so etwas zurückgehalten und war nicht mutig genug. Kleine Startups dagegen setzen auf schnellen Erfolg mit AI, indem sie das Risiko von Urheberrechtsverletzungen ignorieren
  • In meiner Branche ist nicht das Fehlen von Code das eigentliche Problem, sondern die Definition davon, was und wie etwas gebaut werden soll. Viele einzigartige Probleme lassen sich weder mit Stackoverflow noch mit GitHub lösen
  • Google hat Inhalte von Websites schon immer abgeschöpft und direkt in Suchergebnissen angezeigt, also fremde Inhalte ohne Traffic genutzt. Diesmal sind sie einfach nur spät dran
  • Ironischerweise wünschen sich manche sogar, dass Großunternehmen Open-Source-Code plagiiert. Denn aus Nutzersicht ist das immer noch besser, als von ihnen zu den kalten und ineffizienten Lösungen gezwungen zu werden, die sie selbst bauen
  • Ich stimme den Grenzen davon zu, Code in Open Source zu veröffentlichen. Große Unternehmen fördern Open Source oft als Mittel, um kostenlose Arbeitskraft zu bekommen. Selbst wenn kurzfristig weniger Beiträge entstehen, wäre die Branche langfristig womöglich gesünder
  • Kritik an der Verantwortungslosigkeit rund um das Aufkommen von ChatGPT und Sam Altmans Führung
• Beeindruckend fand ich Simon Willisons Aussage, dass Lesen schwerer und weniger unterhaltsam ist als Schreiben von Code, sowie den Fall eines Amazon-Entwicklers, bei dem AI viel von der Nebentätigkeit wie Dokumentation und Testing übernimmt. Die Rolle verschiebt sich nun weg vom Coding hin zu Review vorhandenen Codes und Bugfixing
  • Ich denke an die frühe Zeit zurück, als das Schreiben von Code Spaß gemacht hat. Heute ist Bugfixing interessanter, und LLMs übernehmen das einfache repetitive Coding, sodass ich mich auf Herausforderungen konzentrieren kann. Dank LLM bleibt ein Teil des Spaßes an Entwicklung erhalten
  • Die Stimmung, die aus diesem Text spricht, ist ziemlich negativ
• Wenn neue Produktivitätstechnologien auftauchen, holen sich Unternehmen die Effekte schnell und standardisieren sie. Um mitzuhalten, muss man ständig lernen, und irgendwann sollte man vielleicht überlegen, in ein Umfeld zu wechseln, in dem man den eigenen Wachstumsgewinn selbst abschöpfen kann, etwa in die Selbstständigkeit. Aber allein zu arbeiten bedeutet eben auch, mit Leuten zu konkurrieren, die im Umgang mit AI geübt sind – eine einfache Lösung ist das nicht
  • Drei mögliche Zukunftsszenarien. 1) Codebasen kollabieren nach und nach in Chaos und Instabilität, und am Ende muss man erfahrene Entwickler teuer wieder einkaufen. 2) AI erzeugt Code, der gerade brauchbar genug ist; Qualität und Zuverlässigkeit sind niedrig, aber es kommt nicht zum großen Desaster. 3) AI wird rapide so viel intelligenter, dass das Konzept einer Codebasis selbst verschwindet und Software bei Bedarf dynamisch erzeugt und weiterentwickelt wird. Aktuelle LLMs sind davon noch weit entfernt. Unternehmensführer glauben an Szenario 3, aber realistisch sind derzeit eher 1 bis 2. Mit guter Steuerung könnte man auch zu einer ausgewogenen Version von 2 gelangen
  • Es gibt auch Modelle, in denen Produktivitätsgewinne fairer verteilt werden, etwa durch Arbeitszeitverkürzung wie früher in Europa. Heute scheinen sogar Arbeiter selbst an merkwürdigen Beschäftigungen zu hängen, nur um beschäftigt auszusehen
  • Du beschreibst im Grunde eine marxistische Perspektive, und interessant ist, dass dein Fazit merkwürdigerweise in Selbstentfremdung endet. Mit etwas gemeinsamem Handeln ließe sich durchaus etwas verbessern, aber das geschieht nicht
  • Statt zu akzeptieren, dass man ständig an sich arbeiten und sich endlos weiterentwickeln muss, kann man sich auch mit anderen zusammenschließen und gemeinsam Forderungen an Arbeitgeber stellen. Die Fünftagewoche, der Achtstundentag und das Verbot von Kinderarbeit wurden ebenfalls durch kollektives Handeln erreicht. Man muss sich nicht nur auf die eigene Arbeit und den Erfolg anderer konzentrieren
• Ich bin immer wieder überrascht, wie kindisch unsere Branche geworden ist. Wer Erfahrung mit Großunternehmen und großen Codebasen hat, weiß, dass das Erzeugen neuen Codes nur ein kleiner Teil der Entwicklung ist
  • Tatsächlich sind auch die anderen Teile jenseits von neuem Code in Großunternehmen ineffizient. Vielleicht ändert AI auch das und reduziert endlose Meetings oder abstrakte Diskussionen
  • Viele der heutigen Enthusiasten sind in Wahrheit Leute, denen das Schreiben von Code durch aktuelle Paradigmen selbst schwergefallen ist. Mit LLM-Tools wie Copilot bauen sie schnell ein POC und bringen es bis in Production, ohne über Qualität oder Skalierbarkeit wirklich tief nachzudenken. Und genau diese Leute bewerben dann jede Produktivitätssteigerung durch AI bedingungslos und wiederholen nur Argumente, die den Interessen großer Unternehmen entgegenkommen. Wer die Tools im Alltag wirklich nutzt, kennt auch ihre deutlichen Schwächen
  • Ich selbst verbringe nur etwa 20 % meiner Zeit mit Coding; der Rest geht für Anforderungserhebung, Design, Testing und Terminplanung drauf. Wenn sich diese 20 % Codearbeit halbieren, könnte ich die gewonnene Zeit vielleicht stärker in Tests oder Dokumentation investieren
• Es gibt die Illusion, dass LLM-Hilfe die Entwicklungseffizienz massiv erhöht. Tatsächlich ist ein Produktivitätsschub ohne Qualitätsverlust nur möglich, wenn bereits solide Grundfähigkeiten vorhanden sind. Für Erfahrene wirkt es also als Produktivitätsverstärker, aber wenn man nur eine vergrößerte Armee von Anfängern mit LLMs ausstattet, wird gute Software schwierig
  • Dieses Argument wird oft wiederholt, aber entscheidend ist, wo die Schwelle für „Qualität“ liegt. Ich kenne tatsächlich ein junges Entwicklerteam mit einem SRE-Freund, der wöchentliche Reviews macht und LLMs aktiv nutzt; die Codequalität und Skalierbarkeit sind völlig ausreichend. Es ist langsamer, aber das Ergebnis ist nicht schlecht
  • Orte, an denen wirklich „gute“ Software nötig ist, sind nur ein Teil des Marktes, und wenn man sich die Erlösmodelle von Deloitte oder Accenture ansieht, merkt man: Den meisten Unternehmen ist Qualität nicht einmal wichtig. Für die Mehrheit reicht Software, die nur „gut genug aussieht“