- Amazon कर्मचारियों पर अपने काम में AI को और शामिल करने का दबाव है, लेकिन इसे कहाँ लागू करना है यह स्पष्ट नहीं है, जिससे बेकार के काम पैदा हो रहे हैं
- कुछ कर्मचारी आंतरिक टूल MeshClaw का उपयोग productivity बढ़ाने के बजाय AI activity की मात्रा बढ़ाने वाले agents बनाने में कर रहे हैं
- कर्मचारियों का मानना है कि AI token consumption की tracking ने ऐसा माहौल बना दिया है जहाँ गुणवत्ता से अधिक उपयोग की मात्रा को प्राथमिकता मिल रही है
- Amazon ने कहा है कि कंपनी-व्यापी AI metrics या आंतरिक leaderboard नहीं हैं, लेकिन कर्मचारियों का कहना है कि 80% usage target और tracking मौजूद है
- OpenClaw और MeshClaw local execution के कारण अधिक स्वतंत्र हैं, लेकिन इन्हें जरूरत से ज्यादा access permissions देने पर जोखिम बढ़ सकता है
AI इस्तेमाल का दबाव और MeshClaw का उपयोग
- Amazon कर्मचारियों पर अपने workflow में अधिक AI शामिल करने का दबाव है, लेकिन इसे कहाँ लागू करना है यह स्पष्ट नहीं है, इसलिए AI resources के अनावश्यक कामों में खर्च होने की गुंजाइश बढ़ जाती है
- Financial Times की रिपोर्ट के अनुसार, Amazon के कुछ कर्मचारी आंतरिक AI टूल MeshClaw का उपयोग productivity बढ़ाने के बजाय AI activity की मात्रा बढ़ाने वाले अनावश्यक AI agents बनाने में कर रहे हैं
- एक कर्मचारी ने कहा, “इन टूल्स का इस्तेमाल करने का दबाव बहुत ज़्यादा है,” और बताया कि कुछ लोग token usage को अधिकतम करने के लिए MeshClaw का उपयोग करते हैं
उपयोग metrics को लेकर विरोधाभास
- कर्मचारियों का कहना है कि Amazon द्वारा AI token consumption की tracking किए जाने से कुछ सहकर्मी तकनीक के उपयोग की गुणवत्ता के बजाय मात्रा को प्राथमिकता देने लगे हैं
- Amazon के कई गुमनाम कर्मचारियों का मानना है कि AI उपयोग को लेकर बढ़ती अपेक्षाओं से कार्यस्थल का माहौल खराब हो रहा है
- Amazon ने कर्मचारियों से कहा है कि AI usage statistics को performance evaluation में शामिल नहीं किया जाता, लेकिन सभी कर्मचारी इस बात पर भरोसा नहीं करते
- एक अन्य कर्मचारी का कहना है कि usage tracking विकृत incentives पैदा करती है और कुछ कर्मचारियों को बहुत प्रतिस्पर्धी ढंग से व्यवहार करने के लिए प्रेरित करती है
- साक्षात्कार देने वाले कर्मचारियों ने कहा कि कंपनी का लक्ष्य हर हफ्ते 80% developers द्वारा AI का उपयोग सुनिश्चित करना है, और कर्मचारियों के token consumption को एक आंतरिक leaderboard पर track किया जाता है
- Amazon के एक प्रवक्ता ने कहा कि AI उपयोग के लिए कोई कंपनी-व्यापी metric नहीं है और न ही कोई ऐसा आंतरिक leaderboard है जहाँ कर्मचारियों की एक-दूसरे से तुलना की जाती हो
- Amazon के अनुसार, कर्मचारी अपने व्यक्तिगत dashboard में अपना AI usage देख सकते हैं
OpenClaw और local execution के जोखिम
- कुछ Amazon कर्मचारी AI usage को बढ़ा-चढ़ाकर दिखाने के लिए जिस MeshClaw का उपयोग कर रहे हैं, वह OpenClaw नामक एक अन्य AI टूल से प्रेरित है
- OpenClaw और MeshClaw, अन्य AI models से अलग, उपयोगकर्ता के अपने hardware पर local execution के साथ चलते हैं, इसलिए इनमें अधिक स्वतंत्रता होती है
- इसी साल की शुरुआत में Meta Superintelligence Labs की alignment director से जुड़ी यह घटना, जिसमें OpenClaw ने लगभग उनका पूरा email inbox delete कर दिया था, चर्चा में रही और इसने दिखाया कि AI को जरूरत से ज्यादा access permissions देने पर क्या जोखिम हो सकते हैं
1 टिप्पणियां
Hacker News की राय
सिर्फ Amazon ही नहीं, पूरे बड़े tech sector और कुछ छोटी कंपनियाँ भी एक साथ पागल होती दिख रही हैं
यह कुछ वैसा है जैसे CEO एक दिन कहे, “travel expense बढ़ाने हैं, इसलिए जितनी हो सके उतनी business trips बुक करो और जितना हो सके उतना पैसा खर्च करो। satellite office जाते समय first class में उड़ो, Uber की जगह limousine लो, और महंगे restaurants में खाओ। अगर तुमने पर्याप्त travel expense नहीं किया तो performance review में low rating मिलेगी।”
अभी का समय पूरी तरह असामान्य है
अगर मैं Amazon का VP होता तो acquisition offer पर भी विचार करता, और extra features वाला enterprise version भी बन रहा है
Show HN: https://news.ycombinator.com/item?id=48151287
उसे डाँट पड़ने की उम्मीद थी, लेकिन उल्टा उसे शाबाशी मिली, और दूसरे कर्मचारियों के साथ अपनी सफलता का तरीका साझा करने के लिए एक छोटा presentation देने को भी कहा गया
अब infra spend का 20% tokens पर जा रहा है, और प्रति developer साप्ताहिक pull requests की संख्या 4.2 से बढ़कर 5.1 हो गई है
उनमें से काफी ऐसे हैं जहाँ agent बस config file की एक-दो lines बदलता है, इसलिए यह सब किसी magical thinking जैसा लगता है
दूसरी airlines पर first class सस्ती पड़ती, फिर भी company policy के कारण उसमें नहीं जा सकते थे
हम हमेशा से ही असामान्य समय में जीते आए हैं
जब ऐसा नहीं हुआ, तो लगता है वे मान रही हैं कि वजह यह है कि कर्मचारी उस जादुई AI का पर्याप्त बार इस्तेमाल नहीं कर रहे
जो कंपनियाँ अपना AI product बना रही हैं, वे शायद चाहती हों कि कर्मचारी जितना हो सके उतना AI इस्तेमाल करें ताकि अंततः वे वह training data पा सकें जो अधिकांश या सभी कर्मचारियों को replace कर दे
जो कर्मचारी अपने ही AI replacement को train करने से मना करें, उन्हें सज़ा देना उनके नज़रिए से समझ में आ सकता है, अगर वे मानते हों कि अभी की लागत बाद की बचत के सामने बहुत छोटी है
करीब 6 महीने पहले मैंने एक AWS कर्मचारी से हमारे use case के हिसाब से AI tools पर presentation सुना
presentation के बीच उसने अचानक screen share में कहा, “देखो इस महीने मैंने कितने tokens इस्तेमाल किए हैं। मैं Opus बहुत चलाता हूँ,” और संख्या अपमानजनक रूप से बड़ी थी
तब मैंने सोचा, “यह अजीब डींग है। यह इतना महँगा है कि इसका बहुत ज़्यादा इस्तेमाल होना अपने-आप में red flag नहीं है क्या?”
उसने AWS infra को manage और tune करने के लिए Claude Code के कई use cases दिखाए, लेकिन internet से भी पुराना greybeard sysadmin होने के नाते मुझे यह सब ऐसा लगा जैसे “AI से वह काम किया गया जो एक ही command से हो सकता था”
इसलिए यह कहानी समझ में आती है। यानी 6 महीने पहले से ही धड़ल्ले से इस्तेमाल करने के लिए प्रोत्साहित किया जा रहा था
लेकिन अगर आप
tabदबा दें, तो उस line को AI-edited line मानकर गिना जाता हैबाकी में से भी काफ़ी काम multi-cursor, vim movement, और macros सीखकर लगभग उसी speed से पहले ही किया जा सकता था
असल में मैंने वे चीज़ें सीखी ही नहीं, क्योंकि बिना उनके भी कभी स्क्रीन पर code लाने की speed bottleneck बनने जितनी धीमी नहीं थी
शायद मामला binary नहीं है और कई factors पर निर्भर करता है, लेकिन एक-दूसरे से इतनी अलग reports का एक साथ दिखना अजीब है
तब यह समझ आता है कि ऐसे निर्देश कहाँ से आ रहे हैं, और वे इतने सावधान या संतुलित क्यों नहीं हैं
यह systems development की बड़ी कमजोरी है, और विरोधियों के लिए एक विशाल attack surface बन सकती है
AI की बहुत-सी value यहीं है
अब आपको वह command जानने की ज़रूरत नहीं, सिर्फ functional contract पता होना चाहिए, और आप ज़रूरी काम कर सकते हैं
यह बहुत बड़ा बदलाव है
“tokens खर्च करने थे इसलिए बेकार में जला दिए” जैसी कहानियाँ बहुत आ रही हैं, और climate emergency के दौर में यह यक़ीन करना मुश्किल है
और ज़ोर लगाया तो शायद 3 degree warming भी हासिल कर लें
इससे सोवियत संघ की वह कहानी याद आती है जहाँ quota पूरा करने के लिए, जबकि whale meat कोई खाना नहीं चाहता था, उन्होंने whales को लगभग विलुप्ति तक पहुँचा दिया था
हमारे पास व्यवहार में central planning आ चुकी है, और उस system की सारी pathologies भी वैसी ही हैं; बस Soviet Union से फ़र्क इतना है कि हमारा GOSPLAN कुछ ऐसे लोग चला रहे हैं जो या तो संयोग से अमीर हो गए या सही लोगों को रिश्वत दे पाए
कोई “वास्तविक” productivity gain भी नहीं, बस tokens खर्च करने के लिए
अगर आप tokens नहीं जलाएँगे, तो metrics पूरे नहीं होंगे, और आपको Luddite कहकर AI से नौकरी जाने से पहले ही बाहर निकाला जा सकता है
मैं इस पूरे रुझान और war hawks द्वारा धरती को बर्बाद करने वाली सोच, दोनों से सहमत हूँ
“कोई whale meat खाना नहीं चाहता था” यह दावा भी ज़्यादा ठोस नहीं है
अच्छी बात यह है कि मैं app management side पर काम करता हूँ, और मुझे पता है कि सिर्फ last-used date देखी जा सकती है, इसलिए दिन में एक query डाल दूँ तो काम चल जाता है
लेकिन इस AI hype से मैं सच में थक चुका हूँ
मैं FAANG की एक कंपनी में काम करता हूँ, Amazon में नहीं, और ऐसी बातें मैंने अंदर और बाहर दोनों जगह बहुत सुनी हैं
लेकिन अहम लोग, यानी leadership, ने इसे कभी आधिकारिक तौर पर नहीं कहा
यह हमेशा अफ़वाहों या किसी insider द्वारा बनाए गए dashboards/metrics से शुरू होकर फैलता है
मैंने leaders को यह कहते भी सुना है कि “हम यह नहीं देख रहे, और महंगे tokens बर्बाद नहीं करने चाहिए”
हाँ, पहले code lines या commit count जैसे बेवकूफ़ metrics इस्तेमाल करने की बात कभी-कभी खुलकर मानी गई है, लेकिन यह इतना सरल है कि जितने ज़्यादा tokens उतना बेहतर, इस पर यक़ीन नहीं होता
जब हम पलटकर कहते हैं, तो leadership मान भी लेती है कि token spend कोई अच्छा metric नहीं है और लोग उसका दुरुपयोग करेंगे, लेकिन तुरंत फिर टीम का token spend बढ़ाने के लिए कहती है
leadership जो token tracking dashboard देखती है, वह मौजूद है, और बैठकों में सीधे दिखाया जाता है, इसलिए मुझे पता है
अभी तक उसे सबके लिए leaderboard की तरह public नहीं किया गया, यही थोड़ा सुकून है
बहुत अफ़वाहें हैं कि token spend performance review में जाएगा, और leadership इसका इनकार करती है, लेकिन फिर तुरंत meetings बुलाकर बताती है कि token spend बढ़ाना कितना ज़रूरी है और dashboard पर दिख रही कमियों पर चर्चा करती है
जहाँ कंपनियाँ token usage leaderboards बनाती हैं या यह संकेत देती हैं कि AI tools इस्तेमाल करने से इनकार करने वाले engineers को निकाला जा सकता है, वहाँ समस्या फट पड़ती है
फिर बचने के लिए जितने ज़्यादा हो सकें उतने tokens खर्च करने की होड़ लग जाती है
खासकर उन developers में यह ज़्यादा दिखता है जो social media बहुत पढ़ते हैं
Twitter, Threads, Mastodon, LinkedIn वगैरह पर AI-native बनने और पर्याप्त AI न इस्तेमाल करने वालों को निकालने की viral कहानियाँ बार-बार recycle होती रहती हैं, और चिंतित developers सोचते हैं कि अगली layoffs से बचने के लिए उन्हें अपने साथियों से तेज़ी से tokens जलाने होंगे
उसके बाद org के individual contributors से कहा गया कि हर काम में AI इस्तेमाल करो, वरना career पर बुरा असर हो सकता है
रोज़मर्रा के कामों में AI इस्तेमाल करवाने के नाम पर अनिवार्य training, workshops और hackathons कराए जा रहे हैं
जो काम shell script से आसानी से हो सकते हैं, उन पर भी पूछा जाता है, “इसे agent कैसे बना सकते हैं?”
Copilot पर इतना पैसा खर्च किया गया है कि वे देखना चाहते हैं लोग उसे इस्तेमाल कर रहे हैं
हो सकता है असली लक्ष्य ही लोगों को metrics game करने पर मजबूर करना हो
जब AI ज़्यादा इस्तेमाल करने के लिए दबाव डाला जाता है, तो लोग कोशिश करते हैं, experiment करते हैं, और “समय बर्बाद” करते हुए सीखते हैं
शायद यही अंतिम लक्ष्य है
अभी लोग बेकार की चीज़ों पर tokens खर्च कर रहे हैं ताकि पता चले कहाँ यह काम आता है
और कहाँ काम नहीं आता, यह भी शायद ऐसे ही सीखा जाएगा
हमारी कंपनी भी यही कर रही है
यह wasteful हो सकता है, लेकिन AI business में वास्तव में कहाँ उपयोगी है, यह खोजने का शायद सबसे तेज़ तरीका यही है
अगर 80% कर्मचारी सिर्फ tokens बर्बाद भी कर रहे हों, तो बाकी 20% कुछ काम की राह निकाल रहे हैं
अगर पैसे जलाने लायक बहुत पैसा है, तो और भी खराब तरीके सोचे जा सकते हैं, लेकिन गंभीरता से देखें तो यह मूर्खता है
क्या कभी कंपनियों ने किसी tool पर लाखों dollars और लोगों का समय इसलिए खर्च किया है कि “देखें यह tool आखिर किस काम आ सकता है”?
यह solution in search of a problem वाली बात है
अगर शुरुआत में ही साफ़ नहीं कि यह tool कौन-सी समस्या हल करता है, तो उसे छोड़कर आगे बढ़ जाना चाहिए
बचा हुआ पैसा कर्मचारियों और shareholders को देना बेहतर होगा
अफ़सोस की बात यह है कि AI के लिए अब universal basic jobs प्रोग्राम आ गया है, लेकिन इंसानों के लिए अभी तक नहीं
कंपनियाँ AI को गड्ढा खोदने के पैसे दे रही हैं, और दूसरी AI को वही गड्ढा भरने के
[1] https://locusmag.com/feature/cory-doctorow-full-employment/
Soviet Union ने बहुत पहले 100% employment हासिल कर लिया था[0], और उसके साथ गरीबी भी आई थी
यह tax-funded नहीं है, इसलिए बिल्कुल वही बात नहीं है
private कंपनियाँ अपने पैसों से experiment कर रही हैं, और बाद में लागत बढ़ने से customers के कहीं और चले जाने का जोखिम भी खुद उठा रही हैं
productivity से कटे हुए mandatory taxes के सहारे लोगों को पैसा बाँटने से तो यह कहीं बेहतर है
[0] https://nintil.com/the-soviet-union-achieving-full-employmen...
Amazon के अंदर Kiro इस्तेमाल करने पर token usage का gamification हो चुका है
वजह यह है कि teams पर AWS की तरह cost charge नहीं होती, और न ही पुराने systems की तरह capacity justify करनी पड़ती है
अंदरूनी rankings को कोई देखने लगे, उससे पहले ही लोग इस metric को game कर रहे थे—ऐसी बातें मैंने विश्वसनीय रूप से सुनी हैं, और power users कई तरह के internal projects बनाकर share भी कर रहे हैं
internal presentations में N00% productivity increase जैसी बातें सुनकर managers दबाव डालते हैं, यह तय है, लेकिन जहाँ मैं हूँ वहाँ अगर कोई असली काम की जगह नकली काम बनाए, तो वह जल्दी पकड़ा जाएगा
दबाव ज़्यादा aggressive deadlines और annual OP1 process के अधिक agile style में बदलने से आता है
AWS और गैर-AWS FAANG कर्मचारियों से भी मैंने ऐसी ही बातें सुनी हैं
हर token leaderboard पर यह disclaimer लगा होता है कि “इसे performance review में नहीं गिना जाएगा,” लेकिन उसके बाद एक अनकहा wink-wink जैसा माहौल बना रहता है
एक org के बारे में मैंने सुना, वहाँ कोई व्यक्ति GasTown को 24x7 चलाकर tokens खपा रहा है
योगदान कम है, लेकिन वह आराम से नंबर 1 पर बैठा है
वह GasTown चलाता है और agent से पूरे codebase में चीज़ें छुआता है, जिससे दिन में करीब 50 commits निकलते हैं
compatibility versions, formatting जैसी चीज़ें
लेकिन असली समस्या technology नहीं, वह व्यक्ति है
वह LLMs से पहले भी ऐसा ही था
वह repos को छोटे repos में “refactor” करके अचानक पूरे code पर अपना नाम चिपका देता था, और ऊपर-ऊपर देखने पर लगता था जैसे company codebase का बड़ा हिस्सा उसी ने बनाया हो
वह मुझे कुछ काम करने से मना कर देता, और बाद में खुद वही काम कर देता
मेरे pull requests पर अंतहीन नुक्ताचीनी करता, या कहता कि यह काम होना ही नहीं चाहिए, फिर मुड़कर खुद उसे implement कर देता
वह मेरा code copy-paste नहीं करता, लेकिन मेरे PR खुलने के बाद उसी idea को, जिसे पहले ठुकरा चुका होता है, फिर खुद implement करता है
वह बहुत बुद्धिमान है, लेकिन बहुत बेईमान भी, और अपनी बेईमानी को अच्छी तरह छिपाता है
पूछो तो जवाब देगा, “मुझे लगा यह तरीका ज़्यादा साफ़-सुथरा लगेगा” जैसी कोई बात
बाहर से देखने पर अक्सर यह दावा किया जा सकता है कि एक तरीका दूसरे से बेहतर है, इसलिए बेईमानी साफ़-साफ़ पकड़ में नहीं आती, लेकिन मैं उसका 100% व्यवहार देखता हूँ, इसलिए pattern पूरी तरह स्पष्ट है
ऊपर से, एक बार मैंने कहा कि मैं एक खास हफ़्ते में छुट्टी लूँगा, तो उसने साफ़ मना तो नहीं किया, लेकिन कहा कि The Thing deliver करने का बहुत दबाव है, क्या मैं छुट्टी टाल सकता हूँ
मैंने कहा, “नहीं, मैं नहीं टालूँगा,” तब उसने approve कर दिया, लेकिन जब वह हफ़्ता आया तो उसने खुद भी उसी हफ़्ते छुट्टी ले ली
मैंने इस पर बात नहीं बढ़ाई। मुझे पहले से ही काफ़ी पता था कि उसे दूसरों से वह माँगने में कोई शर्म नहीं, जिसे वह खुद कभी स्वीकार न करे
अगर Amazon के spokesperson ने कहा कि company-wide AI usage metrics या कर्मचारियों की आपसी तुलना वाले internal leaderboards नहीं हैं, और लोग अपने personal dashboard में सिर्फ अपना usage देख सकते हैं, तो यह पूरी तरह बकवास है
Kiro/QuickSuite (पहले Amazon Q) usage को tokens के आधार पर कर्मचारी-दर-कर्मचारी rank करने वाला global dashboard मौजूद है
dashboard खुद QuickSight में है, और QuickSight भी वैसे QuickSuite का हिस्सा बन चुका है
data सिर्फ खुला ही नहीं है, बल्कि ranking, daily/weekly/monthly/yearly usage के हिसाब से sort भी किया जा सकता है
इसमें मौजूदा और पूर्व, दोनों तरह के कर्मचारी internal aliases के आधार पर शामिल हैं
ऊपर से PhoneTool profile में दिखने वाला एक internal “awards” system भी है, जिसमें हर कर्मचारी को Kiro/AmazonQ/Quicksuite titles जैसे “Blaze” और “Thunderstorm” मिलते हैं
उसी award वाले बाकी लोगों को भी सिर्फ क्लिक करके देखा जा सकता है
जानकारी के लिए, PhoneTool एक internal profile directory है जिससे दूसरे कर्मचारियों को lookup किया जा सकता है
दूसरी ओर, मैं कई ऐसे लोगों को जानता हूँ जो अपने दम पर ठीक-ठाक code लिख भी नहीं सकते या किसी चीज़ में सीधे integrate भी नहीं कर सकते
वे लोग जिन्हें लगातार hand-holding चाहिए, Kiro/AmazonQ के साथ भारी output निकाल रहे हैं और इन दिनों SDEs से ऊपर rank कर रहे हैं
वे SDE कम, SysDev, support engineer, या TPM ज़्यादा लगते हैं
इसे अपने-आप में सिर्फ अच्छा या बुरा कहना सही नहीं होगा, लेकिन अगर token usage से stack ranking होगी, तो “अच्छा” code लिखने की कोशिश करने वाला अच्छा engineer ऐसे व्यक्ति से नीचे आंका जा सकता है जो concise solution पर मेहनत नहीं करता
अंततः quality गिरेगी, और जब leadership समझेगी कि क्या हुआ है, तब तक बहुत देर हो चुकी होगी
Amazon-Q/Kiro से जुड़ी failures मैं पहले ही देख चुका हूँ, फिर भी लोग इनकार करते जा रहे हैं
हमारे workplace में भी यह ट्रेंड आ रहा है
अगर मैं रोज़ MS Office का Copilot इस्तेमाल नहीं करूँ, तो गुस्सैल notifications आते हैं, इसलिए मैं बस Hello टाइप कर देता हूँ