Amazon-Mitarbeitende blähen unter dem Druck zur AI-Nutzung unnötige Aufgaben auf, um den AI-Tokenverbrauch zu erhöhen
(fastcompany.com)- Während Amazon den AI-Tokenverbrauch seiner Mitarbeitenden verfolgt, erhöhen einige Beschäftigte die Nutzung künstlich, indem sie mit dem internen AI-Tool MeshClaw unnötige AI-Agenten erzeugen
- Mitarbeitende sagen, dass die Erfassung des AI-Tokenverbrauchs ein Umfeld geschaffen habe, in dem Nutzung wichtiger sei als Qualität, wodurch perverse Anreize entstehen
- Amazon bestreitet, dass es unternehmensweite Kennzahlen zur AI-Nutzung oder interne Leaderboards gebe, doch Mitarbeitende behaupten, es gebe ein wöchentliches Ziel von 80 % AI-Nutzung unter Entwicklern und ein Leaderboard zum Tokenverbrauch
- MeshClaw ist ein von OpenClaw inspiriertes Tool, das unabhängig auf der lokalen Hardware der Nutzer läuft und über ein hohes Maß an Autonomie verfügt
- Der Fall zeigt ein strukturelles Problem: Wenn die Einführung von AI über quantitative Kennzahlen erzwungen wird, werden Ressourcen verschwendet, ohne dass sich die tatsächliche Produktivität verbessert
Druck zur AI-Nutzung und der Einsatz von MeshClaw
- Amazon-Mitarbeitende stehen unter Druck, mehr AI in ihre Arbeitsabläufe einzubauen, doch wofür sie konkret eingesetzt werden soll, ist nicht klar, wodurch AI-Ressourcen leicht für unnötige Aufgaben verwendet werden
- Laut einem Bericht der Financial Times nutzen einige Amazon-Mitarbeitende das interne AI-Tool MeshClaw nicht zur Produktivitätssteigerung, sondern zum Erzeugen unnötiger AI-Agenten, um das AI-Aktivitätsvolumen zu erhöhen
- Ein Mitarbeiter sagte, der Druck, diese Tools zu verwenden, sei enorm, und einige nutzten MeshClaw, um den Tokenverbrauch zu maximieren
Widersprüchliche Aussagen zu Nutzungskennzahlen
- Mitarbeitende sagen, dass Amazons Verfolgung des AI-Tokenverbrauchs dazu geführt habe, dass einige Kolleginnen und Kollegen die Menge der Tool-Nutzung über deren Qualität stellen
- Mehrere anonyme Amazon-Mitarbeitende sagen, dass sich das Arbeitsumfeld mit steigenden Erwartungen an die AI-Nutzung verschlechtere
- Amazon habe den Mitarbeitenden offenbar mitgeteilt, dass AI-Nutzungsstatistiken nicht in Leistungsbeurteilungen einfließen, doch nicht alle glauben das
- Ein anderer Mitarbeiter sagte, die Erfassung der Nutzung schaffe verzerrte perverse incentives, die manche Beschäftigte zu stark wettbewerbsorientiertem Verhalten verleiteten
- Die interviewten Mitarbeitenden sagten, das Unternehmen verfolge das Ziel, dass jede Woche 80 % der Entwickler AI nutzen, und dass der Tokenverbrauch der Mitarbeitenden in internen Leaderboards erfasst werde
- Ein Amazon-Sprecher erklärte, es gebe keine unternehmensweiten Kennzahlen zur AI-Nutzung und auch keine internen Leaderboards, in denen Mitarbeitende miteinander verglichen würden
- Stattdessen könnten Mitarbeitende ihren eigenen AI-Verbrauch in einem persönlichen Dashboard einsehen
OpenClaw und die Risiken lokaler Ausführung
- MeshClaw, das einige Amazon-Mitarbeitende verwenden, um ihre AI-Nutzung aufzublähen, ist ein von einem anderen AI-Tool, OpenClaw, inspiriertes Werkzeug
- Im Unterschied zu anderen AI-Modellen laufen OpenClaw und MeshClaw lokal auf der Hardware der Nutzer, was ihnen ein hohes Maß an Unabhängigkeit verleiht
- Anfang dieses Jahres sorgte die Alignment-Direktorin von Meta Superintelligence Labs mit einem Vorfall für Aufsehen, bei dem OpenClaw beinahe ihren gesamten E-Mail-Posteingang gelöscht hätte, was die Risiken zeigt, wenn man AI zu weitreichende Zugriffsrechte gibt
4 Kommentare
Früher wurde die Entwicklungsfähigkeit von Entwicklern ja auch daran gemessen, wie viele Zeilen Code sie geschrieben haben, lol.
Da wurden dann völlig unnötig auf einmal Hunderttausende Zeilen geschrieben, und überall wimmelte es von Trash-Code mit gerade mal ein, zwei Funktionen.
Das erinnert mich auch daran, wenn die Leistung nur anhand der Arbeitszeit bewertet wird, haha.
Eine Situation, in der man selbst ohne Ergebnis hoch bewertet wird, solange man nur viele Überstunden macht, haha.
Die Nebenwirkungen übermäßiger Effizienz (2022)
Zufällige Auswahl ist notwendig, um ein stabiles meritokratisches System zu schaffen
Hacker-News-Kommentare
Nicht nur Amazon, sondern gefühlt die gesamte Big-Tech-Branche und sogar einige kleinere Firmen drehen gleichzeitig durch.
Das ist ungefähr so, als würde ein CEO eines Tages sagen: „Wir müssen mehr Reisekosten ausgeben, also bucht so viele Dienstreisen wie möglich und verprasst so viel Geld wie ihr könnt. Fliegt First Class, wenn ihr in ein Satellitenbüro müsst, nehmt statt Uber eine Limousine und esst in teuren Restaurants. Wenn ihr nicht genug Reisekosten verursacht, bekommt ihr in der Leistungsbewertung eine schlechte Note.“
Wir leben gerade in völlig absurden Zeiten.
Wäre ich Amazon-Vizepräsident, würde ich ein Übernahmeangebot prüfen, und eine Enterprise-Version mit Zusatzfunktionen ist auch in Arbeit.
Show HN: https://news.ycombinator.com/item?id=48151287
Er dachte, er bekäme Ärger, wurde stattdessen gelobt und sogar gebeten, in einem kurzen Vortrag den anderen zu erklären, wie er das geschafft hat.
Inzwischen bestehen 20 % unserer Infrastrukturausgaben aus Tokens, und die Zahl der Pull Requests pro Entwickler und Woche ist von 4,2 auf 5,1 gestiegen.
Ein großer Teil davon sind Agenten, die ein oder zwei Zeilen in einer Konfigurationsdatei ändern, deshalb wirkt das alles wie magisches Denken.
Bei anderen Airlines wäre First Class sogar billiger gewesen, aber laut Firmenrichtlinie durfte man nicht First Class fliegen.
Wir haben schon immer in absurden Zeiten gelebt.
Da das nicht eingetreten ist, scheinen sie nun anzunehmen, die Mitarbeiter hätten die magische AI einfach nicht oft genug benutzt.
Firmen, die ihre eigenen AI-Produkte bauen, wollen womöglich, dass Mitarbeiter möglichst viel AI nutzen, um Trainingsdaten zu sammeln, mit denen sie am Ende die meisten oder sogar alle Mitarbeiter ersetzen können.
Mitarbeiter dafür zu bestrafen, dass sie sich weigern, ihren eigenen AI-Ersatz zu trainieren, kann aus deren Sicht sinnvoll sein, wenn die heutigen Kosten durch spätere Einsparungen mehr als ausgeglichen werden.
Ich habe vor etwa sechs Monaten von einem AWS-Mitarbeiter eine Präsentation zu AI-Tools für unseren Anwendungsfall gesehen.
Mitten in der Präsentation zeigte er beim Screen-Sharing plötzlich: „Schaut mal, wie viele Tokens ich diesen Monat verbraucht habe. Ich jage ohne Ende Opus durch“, und die Zahl war geradezu beleidigend hoch.
Damals dachte ich: „Seltsamer Flex. Ist das nicht eher ein Warnsignal, wenn etwas so teuer ist und man so viel davon verbraucht?“
Er zeigte mehrere Claude-Code-Use-Cases zur Verwaltung und Anpassung von AWS-Infrastruktur, die für mich als grauhaarigen Sysadmin, der älter ist als das Internet, eher aussahen wie: „AI hat etwas gemacht, das auch ein einzelner Befehl erledigt hätte.“
Deshalb klingt diese Geschichte plausibel. Offenbar wurde schon vor sechs Monaten dazu ermutigt, es wahllos einzusetzen.
Wenn man aber
tabdrückt, zählt die Zeile als von AI bearbeitet.Ein großer Teil des Rests sind Dinge, die man mit Multi-Cursor, Vim-Navigation oder Makros schon längst ähnlich schnell hätte machen können.
In der Praxis habe ich das nur nie gelernt, weil ich nie so langsam war, dass das Tempo, mit dem ich Code auf den Bildschirm bekomme, der Engpass gewesen wäre.
Wahrscheinlich ist das keine Entweder-oder-Frage und hängt von vielen Faktoren ab, aber es ist schon seltsam, gleichzeitig so gegensätzliche Berichte zu sehen.
Dann lässt sich ausrechnen, wo solche Vorgaben herkommen und warum sie weder vorsichtig noch ausgewogen sind.
Das ist eine große Schwäche in der Systementwicklung und kann für Angreifer zu einer riesigen Angriffsfläche werden.
Ein erheblicher Teil des Werts von AI liegt genau darin.
Man muss diesen Befehl dann nicht mehr kennen, sondern nur noch den funktionalen Vertrag, um die nötige Arbeit zu erledigen.
Das ist eine enorme Veränderung.
Es tauchen viele Geschichten auf nach dem Motto: „Ich musste Tokens verbrauchen und habe sie daher für Nutzloses verbrannt“ — ein schwer zu glaubendes Verhalten in einer Klimanotlage.
Wenn wir so weitermachen, schaffen wir vielleicht sogar 3 Grad Erwärmung.
Es erinnert mich an die Geschichte, wie die Sowjetunion die Wale beinahe ausrottete, um Fangquoten für Walfleisch zu erfüllen, das niemand essen wollte.
Es gibt faktisch zentrale Planung, mitsamt all ihren Pathologien; der Unterschied zur Sowjetunion ist nur, dass bei uns ein paar Leute, die zufällig reich geworden sind oder die richtigen Leute bestochen haben, unseren GOSPLAN betreiben.
Nicht für „echte“ Produktivitätsgewinne, sondern einfach nur, um Tokens zu verbrauchen?
Wenn man keine Tokens verbrennt, verfehlt man die Metriken und bekommt vielleicht das Etikett Luddite angeheftet und wird rausgeworfen, noch bevor AI einem den Job wegnehmen kann.
Ich stimme zu, dass sowohl dieser Trend als auch Kriegstreiber den Planeten ruinieren.
Auch die Aussage „niemand wollte es essen“ ist nicht besonders gut belegt.
Zum Glück arbeite ich im App-Management und weiß, dass nur der letzte Nutzungstag sichtbar ist, also reicht eine Anfrage pro Tag.
Trotzdem bin ich diesen AI-Hype wirklich leid.
Ich arbeite bei einer FAANG-Firma, aber nicht bei Amazon, und ich habe intern wie extern viele solcher Geschichten gehört.
Allerdings habe ich es nie von den wirklich wichtigen Leuten, also der Führungsebene, offiziell sagen hören.
Es beginnt immer mit Gerüchten oder mit Dashboards bzw. Metriken, die irgendjemand intern gebaut hat, und schaukelt sich dann hoch.
Ich habe auch Führungskräfte sagen hören: „Das ist nicht das, worauf wir schauen, und teure Tokens zu verschwenden sollte man nicht.“
Natürlich wurden in der Vergangenheit auch dumme Metriken wie Zeilen Code oder Commit-Anzahl benutzt, ohne dass man das je ganz zugegeben hätte, aber ich glaube nicht, dass es so simpel ist wie je mehr Tokens, desto besser.
Wenn wir widersprechen, räumt die Führung zwar ein, dass Token-Ausgaben keine gute Metrik sind und leicht missbraucht werden können, fordert dann aber direkt wieder, dass wir die Token-Ausgaben unserer Teams erhöhen.
Es gibt ein Token-Tracking-Dashboard, das sich die Führung ansieht, und wir wissen das, weil es uns in Meetings direkt gezeigt wird.
Immerhin wird es noch nicht für alle wie eine Rangliste veröffentlicht.
Es gibt viele Gerüchte, dass Token-Ausgaben in Leistungsbewertungen einfließen werden, und die Führung widerspricht zwar, hält dann aber weitere Meetings darüber ab, wie wichtig höhere Token-Ausgaben seien, und bespricht die Defizite, die im Dashboard sichtbar werden.
In Firmen, die Ranglisten für Token-Nutzung erstellen oder andeuten, dass Ingenieure entlassen werden könnten, wenn sie AI-Tools nicht verwenden, explodiert das Problem.
Dann beginnt ein Wettbewerb darum, möglichst viele Tokens zu verbrennen, um zu überleben.
Besonders stark ist das unter Entwicklern, die viele soziale Medien lesen.
Auf Twitter, Threads, Mastodon, LinkedIn usw. werden virale Geschichten immer wieder recycelt, nach denen man AI-native werden müsse und Leute entlassen würden, wenn sie nicht genug AI nutzten; nervöse Entwickler glauben dann, sie müssten schneller als ihre Kollegen Tokens verbrennen, um bei unvermeidlichen Entlassungen verschont zu bleiben.
Danach wurde den Individual Contributors der Organisation gesagt, sie sollten für alles AI benutzen, sonst könnte das ihrer Karriere schaden.
Um AI im Arbeitsalltag zu „fördern“, gibt es Pflichtschulungen, Workshops und Hackathons am laufenden Band.
Selbst bei Dingen, die man leicht mit einem Shell-Skript erledigen könnte, heißt es dann: „Wie könnten wir daraus einen Agenten machen?“
Es wurde viel Geld für Copilot ausgegeben, also will man jetzt sehen, dass die Leute es auch benutzen.
Vielleicht ist das Ziel selbst, die Leute dazu zu bringen, Metriken zu gamen.
Wenn man sie dazu drängt, mehr AI zu nutzen, probieren sie es aus, experimentieren damit und „verschwenden“ Zeit, während sie lernen.
Genau das ist das eigentliche Ziel.
Im Moment werden Tokens für nutzlose Dinge verbrannt, um herauszufinden, wo es hilft, und wo es nicht hilft, lernt man eben auf dieselbe Weise.
Unsere Firma macht gerade genau dasselbe.
Es mag verschwenderisch sein, aber es ist der schnellste Weg, herauszufinden, wo AI im Unternehmen tatsächlich nützlich ist.
Selbst wenn 80 % der Mitarbeiter nur Tokens verschwenden, finden die übrigen 20 % inzwischen Wege.
Wenn man so viel Geld zum Verbrennen hat, fallen einem zwar noch schlechtere Arten der Verschwendung ein, aber ernsthaft betrachtet ist das einfach dumm.
Haben Unternehmen jemals bei irgendeinem anderen Werkzeug Millionen Dollar und die Zeit ihrer Mitarbeiter investiert, nur um herauszufinden, „wofür dieses Werkzeug nützlich sein könnte“?
Das ist die sprichwörtliche Lösung auf der Suche nach einem Problem.
Wenn am Anfang nicht klar ist, welches Problem dieses Werkzeug löst, sollte man es verwerfen und weitermachen.
Das übrige Geld wäre besser bei den Mitarbeitern und Aktionären aufgehoben.
Traurig, dass es für AI inzwischen ein Programm für universelle Grundbeschäftigung gibt, für Menschen aber noch nicht.
Firmen bezahlen AI dafür, Löcher zu graben, und andere AI dafür, sie wieder zu füllen.
[1] https://locusmag.com/feature/cory-doctorow-full-employment/
Die Sowjetunion erreichte schon vor langer Zeit 100 % Beschäftigung[0], mitsamt der dazugehörigen Armut.
Das ist nicht dasselbe, weil es nicht über Steuern finanziert wird.
Private Unternehmen experimentieren hier mit ihrem eigenen Geld und tragen das Risiko, später wegen höherer Kosten Kunden an andere zu verlieren.
Das ist immer noch viel besser, als Menschen per Zwangssteuer unabhängig von ihrer Produktivität Geld zu geben.
[0] https://nintil.com/the-soviet-union-achieving-full-employmen...
Intern bei Amazon wird die Token-Nutzung gamifiziert, wenn man Kiro verwendet.
Denn Teams werden dafür nicht wie bei AWS direkt belastet und müssen auch nicht wie im alten System ihre Kapazität begründen.
Ich habe schon vor jeder internen Sichtbarkeit glaubwürdige Geschichten darüber gehört, dass Leute diese Metrik gamen, und Power-User bauen und teilen zahlreiche interne Projekte.
Es stimmt sicher, dass Manager unter Druck geraten, nachdem sie in internen Präsentationen von N00% Produktivitätssteigerung und Ähnlichem gehört haben, aber dort, wo ich bin, würde man recht schnell merken, wenn jemand statt echter Arbeit nur Scheinaufgaben erzeugt.
Der Druck kommt eher von aggressiven Deadlines und davon, dass im jährlichen OP1-Prozess auf eine agilere Arbeitsweise umgestellt wurde.
Ich habe Ähnliches sowohl von AWS- als auch von anderen Nicht-AWS-FAANG-Mitarbeitern gehört.
Jede Token-Rangliste trägt zwar einen Haftungsausschluss nach dem Motto „Das fließt nicht in Leistungsbewertungen ein“, aber dahinter steckt gefühlt ein implizites Zwinkern und Nicken.
In einer Organisation, von der ich gehört habe, lässt jemand GasTown 24/7 laufen und frisst damit Tokens.
Er trägt wenig bei, liegt aber bequem auf Platz 1.
Er lässt GasTown laufen und Agenten quer durch die Codebasis fummeln, sodass am Tag rund 50 Commits herausfallen.
Kompatibilitätsversionen, Formatierung und solche Dinge.
Das Problem ist allerdings nicht die Technik, sondern die Person.
Er war schon vor LLMs so.
Er „refaktorisierte“ Repositories in kleinere Repositories, damit plötzlich überall sein Name am gesamten Code hing und es bei flüchtigem Hinsehen so aussah, als hätte er große Teile der Codebasis des Unternehmens gebaut.
Dinge, die ich tun wollte, lehnte er ab, nur um sie später selbst zu machen.
Er zerpflückt meine Pull Requests endlos oder sagt gleich, dass die Arbeit gar nicht gemacht werden solle, und dreht sich dann um und implementiert sie selbst.
Er kopiert meinen Code nicht direkt per Copy-and-paste, aber nachdem mein PR offen ist, setzt er dieselbe Idee um, die er zuvor abgelehnt hatte.
Er ist sehr klug, aber auch sehr unehrlich und gut darin, diese Unehrlichkeit zu verbergen.
Wenn man ihn darauf anspricht, sagt er Dinge wie: „Ich fand, so wirkt es aufgeräumter.“
Von außen kann man immer argumentieren, dass der eine Ansatz besser sei als der andere, sodass die Unehrlichkeit nicht eindeutig sichtbar ist, aber ich sehe zu 100 %, was er tut, und das Muster ist vollkommen klar.
Außerdem sagte ich einmal, ich würde in einer bestimmten Woche Urlaub nehmen; er lehnte das nicht ausdrücklich ab, fragte aber, ob ich den Urlaub verschieben könne, weil der Druck hoch sei, The Thing auszuliefern.
Ich sagte: „Nein, ich verschiebe ihn nicht“, woraufhin er zustimmte — und als die Woche kam, nahm er selbst in derselben Woche Urlaub.
Ich habe ihn darauf nicht angesprochen. Ich wusste schon mehr als genug darüber, dass er sich nicht schämt, von anderen Dinge zu verlangen, die er selbst niemals akzeptieren würde.
Wenn ein Amazon-Sprecher gesagt hat, es gebe keine unternehmensweiten AI-Nutzungsmetriken, keine internen Ranglisten zum Vergleich von Mitarbeitern und man könne nur die eigene Nutzung im persönlichen Dashboard sehen, dann ist das kompletter Unsinn.
Es gibt ein globales Dashboard, das die Kiro-/QuickSuite-Nutzung (früher Amazon Q) nach Mitarbeitern auf Basis von Tokens rankt.
Das Dashboard selbst liegt in QuickSight, und QuickSight ist inzwischen ohnehin Teil von QuickSuite.
Die Daten stehen nicht nur jedem offen, sondern lassen sich auch nach Rang, täglicher, wöchentlicher, monatlicher und jährlicher Nutzung sortieren.
Sowohl aktuelle als auch ehemalige Mitarbeiter sind anhand ihrer internen Aliasse enthalten.
Darüber hinaus gibt es sogar ein internes „Auszeichnungs“-System, das im PhoneTool-Profil angezeigt wird, wo Mitarbeiter Kiro-/AmazonQ-/QuickSuite-Titel wie „Blaze“ oder „Thunderstorm“ bekommen.
Man kann einfach anklicken, wer denselben Preis erhalten hat.
Zur Einordnung: PhoneTool ist das interne Profilverzeichnis, in dem man andere Mitarbeiter nachschlagen kann.
Gleichzeitig kenne ich mehrere Leute, die selbst keinen vernünftigen Code schreiben oder irgendetwas direkt integrieren können.
Leute, die ständig an die Hand genommen werden müssen, produzieren mit Kiro/AmazonQ riesige Mengen und stehen inzwischen in höheren Rängen als SDEs.
Es handelt sich dabei eher um SysDev, Support-Ingenieure oder TPMs als um SDEs.
Das ist an sich nicht automatisch gut oder schlecht, aber wenn man nach Token-Nutzung stackrankt, werden gute Ingenieure, die sich um knappe und elegante Lösungen bemühen, vermutlich schlechter bewertet als Leute, die das nicht tun.
Am Ende wird die Qualität sinken, und wenn die Führung versteht, was passiert ist, wird es zu spät sein.
Ich habe schon Ausfälle im Zusammenhang mit Amazon-Q/Kiro gesehen, und trotzdem wird weiter alles abgestritten.
Dieser Trend kommt auch zu uns an den Arbeitsplatz.
Wenn ich nicht jeden Tag Copilot in MS Office benutze, bekomme ich verärgerte Benachrichtigungen, also tippe ich einfach Hello ein.