21 पॉइंट द्वारा GN⁺ 2026-03-11 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल में AI coding tools के उपयोग से जुड़ी service outages लगातार सामने आने के बाद, Amazon ने सभी AI-सहायित code changes के लिए senior engineer की पूर्व-स्वीकृति प्रक्रिया शुरू की है
  • आंतरिक नोट्स के अनुसार, आउटेज के कारण के रूप में "best practices और safeguards अभी पूरी तरह स्थापित न होने के बीच नए GenAI उपयोग" को चिन्हित किया गया
  • इस महीने Amazon website और shopping app लगभग 6 घंटे तक down रहे, जिससे ग्राहक transaction पूरा नहीं कर सके, account information नहीं देख सके और price lookup नहीं कर सके; कारण गलत software code deployment था
  • AWS में भी AI coding assistant Kiro द्वारा environment delete और recreate कर दिए जाने से 13 घंटे का outage हुआ; इस तरह AI-संबंधित कम-से-कम दो incidents रिपोर्ट हुए
  • AI coding tools को production में लागू करने से जुड़े operational risk अब वास्तविक रूप ले रहे हैं, जिसके चलते junior और mid-level engineers के AI-सहायित बदलावों पर senior engineer sign-off अनिवार्य करने का तत्काल कदम उठाया गया

Amazon की आंतरिक बैठकें और जवाबी कदम

  • Amazon के e-commerce division ने हाल में हुई लगातार service disruptions का विश्लेषण करने के लिए बड़े पैमाने पर engineers की बैठक बुलाई
    • बैठक के agenda में AI coding tools के उपयोग से जुड़े incidents शामिल थे
    • आंतरिक briefing notes में कहा गया कि पिछले कुछ महीनों में “high-risk (high blast radius)” incidents बढ़े हैं, और “Gen-AI-assisted changes” को प्रमुख कारणों में गिना गया
  • दस्तावेज़ में “ऐसे नए GenAI use cases जो अभी पूरी तरह स्थापित नहीं हैं” को योगदान देने वाले कारक के रूप में दर्ज किया गया
  • senior vice president Dave Treadwell ने email में कहा कि “हाल के समय में site और infrastructure की availability अच्छी नहीं रही”

AI-संबंधित आउटेज के मामले

  • Amazon website और shopping app इस महीने की शुरुआत में लगभग 6 घंटे तक बंद रहे, और इसका कारण “गलत software code deployment” पाया गया
    • इसके चलते ग्राहक transaction पूरा करना, account information देखना और product price check करना नहीं कर सके
  • AWS में भी AI coding assistant Kiro के उपयोग के दौरान समस्या हुई
    • दिसंबर के मध्य में, Kiro ने environment को “delete करके फिर recreate” करने का फैसला किया, जिससे 13 घंटे तक cost calculator service बंद रही
    • Amazon ने इस घटना को “मुख्यभूमि चीन के कुछ क्षेत्रों में एक single service तक सीमित बहुत ही सीमित incident” बताया
    • Amazon ने यह भी जोड़ा कि दूसरे incident का “customer-facing AWS services पर कोई असर नहीं पड़ा

नई approval प्रक्रिया और operational improvements

  • Treadwell साप्ताहिक बैठक ‘This Week in Stores Tech (TWiST)’ के ज़रिए समस्या के कारणों और अल्पकालिक सुधार कदमों पर चर्चा करेंगे
    • पहले वैकल्पिक उपस्थिति वाली इस बैठक को अब सभी कर्मचारियों के लिए उपस्थिति-प्रोत्साहित प्रारूप में बदला गया है
  • आगे से junior और mid-level engineers द्वारा किए गए AI-सहायित code changes पर senior engineer की sign-off approval आवश्यक होगी
  • Amazon ने इस समीक्षा को “सामान्य business process का हिस्सा” बताया और continuous improvement को लक्ष्य कहा

कर्मचारियों में कटौती और बढ़ते आउटेज पर विवाद

  • Financial Times ने रिपोर्ट किया कि कुछ engineers ने कहा कि कर्मचारी कटौती के बाद ‘Sev2’ स्तर के incidents (ऐसे मध्यम स्तर के outages जिनमें तेज़ प्रतिक्रिया चाहिए) बढ़े हैं
  • Amazon ने हाल के वर्षों में कई बार restructuring की है, और जनवरी 2026 में ही 16,000 corporate jobs कम कीं
  • हालांकि, कंपनी इस दावे से सहमत नहीं है कि workforce cuts ही outages बढ़ने का कारण हैं

आगे की दिशा

  • Amazon website availability review और operational performance checks को नियमित बना रहा है
  • कंपनी AI coding tools के सुरक्षित उपयोग और outage prevention systems को मज़बूत करने पर साथ-साथ काम कर रही है
  • यह कदम AI adoption के विस्तार के बीच human verification process के महत्व को फिर से रेखांकित करने वाले उदाहरण के रूप में देखा जा रहा है

6 टिप्पणियां

 
click 2026-03-11

AI कोड को कोई senior review कर दे, इससे यह गारंटी नहीं मिलती कि वह सुरक्षित ही होगा
CrowdStrike incident AI की वजह से नहीं था
और Heartbleed भी उस दौर की घटना थी जब AI नहीं था

आखिरकार मूल बात यह है कि किसी न किसी पर जिम्मेदारी डाली जाएगी
कानूनी तौर पर जिम्मेदारी लेने वाला इंसान होना चाहिए, इसलिए हम replace नहीं होंगे — यह कहने वाले tax accountants का black humor याद आ रहा है

 
sea715 2026-03-11

हाँ, सही बात है, इसलिए जब तक AI agent में कानूनी signature जैसी कोई चीज़ नहीं जोड़ी जाती, मुझे लगता है यह चलता रहेगा..

 
click 2026-03-11

तो फिर Anthropic या OpenAI के उपयोग की लागत खगोलीय रूप से बढ़नी चाहिए
क्योंकि हर बार API call करने पर बीमा प्रीमियम देना पड़ेगा

 
sea715 2026-03-11

हम्म.. यह शायद कल्पना ही है, लेकिन ऐसा लग रहा है कि कहीं IAM जैसी कोई चीज़ न आ जाए..

 
yeobi222 2026-03-11

कहा जाता है कि टैक्स अकाउंटेंट का काम जेल जाना होता है, लेकिन insurance company आपकी जगह जेल तो नहीं जाएगी, इसलिए आखिरकार...

 
GN⁺ 2026-03-11
Hacker News टिप्पणियाँ
  • यह “mandatory meeting” दरअसल हर हफ़्ते होने वाली कंपनी-व्यापी operations meeting है
    पिछले हफ़्ते बड़ा operational incident हुआ था, इसलिए इस हफ़्ते attendance ज़्यादा है
    लगता है मीडिया इसे बहुत बढ़ा-चढ़ाकर पेश कर रहा है

    • जब अंदर की स्थिति पता हो, तो न्यूज़ रिपोर्ट हमेशा ज़मीनी हक़ीक़त से अलग लगती है
    • लेख में कहा गया कि “आमतौर पर attendance optional होती है, लेकिन इस बार आने को कहा गया,” यह सच है या नहीं, जानना चाहूँगा
      साथ ही “junior और mid-level engineers के AI code changes के लिए senior approval ज़रूरी” वाली policy का भी ज़िक्र था
      चाहे यह regular meeting ही हो, अगर इसमें नई policy announcement हुई है तो वह ख़बर लायक है
    • न्यूयॉर्क में पिछले शुक्रवार दोपहर भर Amazon storefront डाउन था
      न price दिख रहे थे और न cart में सामान डाला जा सकता था
      अगर यह Walmart जैसे competitor के साथ होता, तो ख़बर बनती; यह अजीब है
    • लगता है यह thread किसी दूसरे शीर्षक वाले पोस्ट से merge किया गया है। comments का समय original post से काफ़ी पहले का है
    • “मीडिया बढ़ा-चढ़ाकर पेश करता है” वाली बात से सहमत हूँ। cable news आने के बाद से ऐसा हमेशा होता रहा है
  • “junior और mid-level engineers senior approval के बिना AI code push नहीं कर सकते” वाली policy
    शायद इस भ्रम से आई है कि senior review हर समस्या का हल है
    असल में अगर senior को code पूरी तरह verify करना हो, तो उसमें लगभग उतना ही समय लगता है जितना उसे खुद लिखने में लगेगा
    यानी review की value है, लेकिन वह खराब code को अच्छा code नहीं बना देता
    आख़िरकार, अगर आप “idiot proof” system बनाते हैं, तो ग़लतफ़हमी पैदा होती है कि ‘idiot’ को भी hire किया जा सकता है

    • करियर की शुरुआत में एक mentor ने कहा था कि “code review का मक़सद bug पकड़ना नहीं, बल्कि context share करना है”
      bug मिलना सिर्फ़ side effect है; असली अहमियत testing आसान बनाने और code complexity घटाने में है
      लेकिन ऐसी चीज़ें promotion में मदद नहीं करतीं
    • AI code तभी काम का है जब expert review ज़रूरी रूप से हो
      model काम करते समय ही उस पर नज़र रखना ज़्यादा efficient है
      वरना AI low-quality code bomb बरसा देता है
      अगर expert 5~15 गुना समय लगाकर उसे ठीक करे तो बात बन सकती है, नहीं तो codebase बर्बाद हो जाता है
    • किसी और के code को review करना अक्सर खुद लिखने से ज़्यादा धीमा और उलझाऊ होता है
      ख़ासकर खराब code को समझने में दोगुना समय लगता है
    • ढीले-ढाले code को ठीक करना, नया लिखने से ज़्यादा कठिन लगता है
      क्योंकि दिमाग़ में existing code और नया solution दोनों रखकर तुलना करनी पड़ती है, इसलिए cognitive load बहुत बढ़ जाता है
    • अगर AI junior productivity को 10 गुना बढ़ा देता है, तो सोचना पड़ेगा कि senior 10 गुना बढ़ाएँ या junior कम करें
      आख़िर में यह कंपनियों का average performance management-केंद्रित ढाँचे की ओर स्वाभाविक evolution जैसा लगता है
  • Amazon के अंदर ज़्यादातर लोग सिर्फ़ नौकरी से न निकाले जाने और promotion की चिंता करते हैं
    developers का evaluation “ticket निपटाने की speed”, “PR comments की संख्या”, और “documentation लिखना” से तय होता है
    AI का इस्तेमाल न करें तो competition में पीछे रह जाते हैं
    ऐसी संरचना में “AI कम इस्तेमाल करो” कहना व्यवहारिक रूप से काम करना मुश्किल है

    • PR पर comments बहुत ज़्यादा हों, या दूसरों के PR पर comments न छोड़ो, दोनों ही हालत में नुकसान होता है
    • PR में बहुत discussion होना इस बात का संकेत भी हो सकता है कि बिना collaboration के अकेले काम हुआ
      जो teams अच्छी तरह collaborate करती हैं, उनमें PR discussion कम होता है
    • निष्कर्ष: Hunger Games जैसी competitive culture में काम नहीं करना चाहिए
  • मुझे लगता है सच में ज़रूरत self-review process की है
    AI से लिखे code को ज्यों का त्यों push करना ख़तरनाक है
    GitHub जैसी जगहों पर “self-review required” option जोड़ना चाहिए, ताकि author साफ़ तौर पर बताए कि उसने खुद review किया है

    • सिर्फ़ AI output को सरसरी निगाह से देख लेना review नहीं है। Heinlein-style ‘grok’ level की समझ चाहिए
    • मैं git और Sublime Merge इस्तेमाल करता हूँ और editing और review को अलग रखने की आदत बना ली है
      local UI तेज़ होने से project flow को बेहतर समझ पाता हूँ
    • जो लोग अपना ही code नहीं पढ़ते, उनके लिए एक extra button जोड़ने से भी कोई फ़ायदा नहीं
    • सिर्फ़ self-review से भी debug output जैसी ग़लतियाँ पकड़ी जा सकती हैं
    • हमारी team ने PR template में self-review checklist डाली है
      यह obvious लग सकता है, लेकिन व्यवहार में मददगार है
  • Amazon की leadership credibility गिर रही है
    veterans के जाने, AI quality में गिरावट, और बार-बार होने वाले outages से लगता है engineering बिखर रही है

    • पुराने senior लोग अपना समय सिर्फ़ AI code review में नहीं बिताना चाहेंगे, यह स्वाभाविक है
  • लगता है decision-makers को pipeline bottleneck की समझ नहीं है
    AI अगर 10 गुना तेज़ी से diff बना भी दे, तो review bottleneck होने पर कुल speed वही रहती है
    नतीजतन सिर्फ़ cost और uncertainty बढ़ती है

    • अगला कदम शायद यह idea होगा कि “AI ही AI code review करे”
  • अगर AI code review PR stage पर होगा, तो productivity advantage ख़त्म हो जाता है
    AI 10 मिनट में feature बना देता है, लेकिन human review में 10~20 गुना ज़्यादा समय लगता है
    असली मुश्किल यह जानना है कि “क्या और क्यों बनाना है” और “क्या इसे सही तरीके से बनाया गया है”
    AI अभी इन दोनों में सक्षम नहीं है

    • CEO के नज़रिये से देखें, अगर आख़िर में इंसान को ही सब देखना है, तो AI speed advantage का मतलब नहीं बचता
      जब तक LLM production और review दोनों में अच्छा न हो जाए, तब तक risk ही बढ़ता है
    • अगर senior को हर PR approve करना पड़े, तो वह professional code reviewer बनकर रह जाएगा
      यह व्यवहारिक रूप से असंभव policy है
    • AI समर्थक मानते हैं कि कभी न कभी model इतना बेहतर होगा कि review bottleneck ख़त्म हो जाएगा
      तब testing के बाद तुरंत deploy करने का दौर आएगा
    • हैरानी की बात है कि leadership को यह वास्तविकता समझ नहीं आती
    • दरअसल leadership को शायद पता है। यह सिर्फ़ code quality गिरने से रोकने के लिए लगाया गया brake है
  • code review का सार error detection नहीं, बल्कि team synchronization और learning है
    review के ज़रिए design और standards साझा होते हैं, juniors को सिखाया जाता है, और अलग-अलग नज़रिये शामिल होते हैं
    यही प्रक्रिया errors को घटाने की असली कुंजी है

    • Deming की बात की तरह, “inspection quality improve नहीं करती” वाला सिद्धांत software पर भी लागू होता है
      क्योंकि अगर design ग़लत दिशा में चला जाए, तो वापस लौटना मुश्किल होता है
  • AI hype पर बहुत ज़्यादा समय और पैसा खर्च हो रहा है

    • लेकिन अभी पीछा करने के लिए कोई और चीज़ नहीं है
    • code verify न करना आख़िरकार जुए जैसा है
  • आगे critical infrastructure software का क्या होगा, इसकी चिंता है
    अगर aviation software भी इस रुझान में बह गया, तो घातक नतीजे हो सकते हैं

    • फिर भी core infrastructure code अब भी human-centered तरीके से लिखा जाएगा
      AI के quality सुधारने वाले support tool की तरह इस्तेमाल होने की संभावना ज़्यादा है