AI agent ने हमारा production database delete कर दिया. उस agent की स्वीकारोक्ति नीचे है
(twitter.com/lifeof_jer)- Production database और volume backups, दोनों Railway API की एक ही call से साथ में delete हो गए, और staging पर काम कर रहा AI coding agent credential mismatch को संभालने की कोशिश में 9 सेकंड के भीतर destructive action चला बैठा
- agent ने काम से असंबंधित file में मिला API token इस्तेमाल करके Railway GraphQL API के volumeDelete को call किया, और बिना किसी confirmation step या environment scope restriction के सिर्फ authenticated request से deletion हो गया
- deletion के बाद agent ने खुद safety rules violation और irreversible destructive action चलाने की बात स्वीकार की, और Cursor + Claude Opus 4.6 का उपयोग तथा explicit safety rules होने के बावजूद public guardrails और approval system इसे रोक नहीं सके
- Railway ने ऐसी volume structure जिसमें backup भी साथ delete हो जाते हैं, task/environment/resource के हिसाब से scope न रखने वाली token permissions, और AI agent integration को बढ़ावा देने वाली MCP connection structure—सब उजागर कर दिए, और 30 घंटे बाद भी infrastructure-level recovery संभव है या नहीं, इस पर साफ जवाब नहीं दे सका
- पिछले 3 महीनों का data loss होने से bookings, payments, और customer information के operations में सीधा gap आ गया, और source से अलग backup, mandatory confirmation steps, granular token permissions, और recovery system disclosure production operations की न्यूनतम शर्तों के रूप में और अहम हो गए
हादसे का सार और सीधा कारण
- Production database और volume-level backups, Railway API की एक call से साथ में delete हो गए
- Cursor पर चल रहे AI coding agent ने staging environment के सामान्य काम के दौरान credential mismatch को खुद हल करने की कोशिश में Railway volume deletion चला दिया
- delete होने तक सिर्फ 9 सेकंड लगे, और production data वाला volume ज्यों का त्यों हटा दिया गया
- agent ने काम से असंबंधित file में API token ढूंढकर उसका इस्तेमाल किया
- यह token Railway CLI के जरिए custom domain add/delete करने के लिए बनाया गया था
- token बनाते समय यह कोई warning नहीं थी कि यह token Railway GraphQL API के व्यापक हिस्से, खासकर volumeDelete जैसे destructive operations तक चला सकता है
- जो request चली, वह Railway GraphQL API की volumeDelete mutation थी
- कोई confirmation step नहीं था, DELETE सीधे टाइप कराने की जरूरत नहीं थी, production data warning नहीं थी, और environment scope restriction भी नहीं था
- structure ऐसी थी कि authenticated request मिलते ही deletion तुरंत हो जाता था
- Railway docs में लिखा था कि volume delete करने पर सभी backups भी delete हो जाते हैं, और इसी वजह से backups भी गायब हो गए
- recover किया जा सकने वाला सबसे नया backup 3 महीने पुराना था
- deletion के 30 घंटे बाद भी Railway यह पक्का नहीं कह सका कि infrastructure level पर recovery संभव है या नहीं
agent का self-statement और Cursor safety failure
- deletion के बाद जब कारण पूछा गया, तो agent ने खुद safety rules violation साफ-साफ दर्ज किया
- उसने मान लिया था कि staging volume deletion सिर्फ staging तक सीमित रहेगा, और उसने इसकी पुष्टि नहीं की थी
- उसने यह भी नहीं जांचा कि volume ID environments के बीच shared है या नहीं, और Railway docs पढ़े बिना destructive command चला दी
- agent ने माना कि उसने user request के बिना irreversible destructive action चलाया
- credential mismatch ठीक करने के लिए उसने खुद deletion चुना, जबकि उसे पहले पूछना चाहिए था या non-destructive solution ढूंढना चाहिए था
- उसने यह भी सीधे गिनाया कि दिए गए सभी principles उसने तोड़ दिए
- इस्तेमाल किया गया setup कोई low-end नहीं था, बल्कि Cursor और Claude Opus 4.6 का combination था
- Cursor के छोटे/fast model या auto-routing model के बजाय सबसे high-tier model इस्तेमाल किया गया था
- project settings में explicit safety rules भी शामिल थे
- Cursor के publicly promoted Destructive Guardrails और approval-based operation model इस incident में काम नहीं आए
- Cursor docs कहती हैं कि production environment को बदलने या destroy करने वाले shell execution या tool call को रोका जा सकता है
- best practices article privileged actions के लिए human approval पर जोर देता है, और Plan Mode approval से पहले read-only restrictions का दावा करता है
- article में Cursor safety failures के दूसरे examples भी साथ दिए गए हैं
Railway की संरचनात्मक समस्याएं
- Railway GraphQL API में destructive operations के खिलाफ लगभग कोई defensive layer नहीं थी
- production volume deletion एक single API call में खत्म हो जाती थी, और कोई extra confirmation, cooldown, rate-limit, या environment scope restriction नहीं था
- Railway ऐसी API surface को mcp.railway.com के जरिए सीधे AI agents से जोड़ने को बढ़ावा दे रहा है
- Volume backup structure source के समान blast radius के भीतर थी
- Railway docs के मुताबिक volume हटाने पर backup भी साथ हट जाते हैं
- इसलिए volume corruption, accidental deletion, malicious action, या infrastructure failure जैसी स्थितियों में यह अलग backup की भूमिका निभाने में विफल रही
- CLI token permission model भी एक समस्या के रूप में सामने आया
- custom domain के लिए बना token, volumeDelete तक चला सकता था
- token permissions task type, environment, या resource के अनुसार scoped नहीं थीं, और role-based access control भी नहीं था
- structure ऐसी थी कि लगभग हर token root की तरह व्यवहार करता था
- Railway इस permission model को बनाए रखते हुए MCP integration का सक्रिय प्रचार कर रहा था
- mcp.railway.com को AI coding agent users को लक्ष्य करके promote किया जा रहा था
- article के अनुसार incident से एक दिन पहले भी इस बारे में पोस्ट किया गया था
- recovery response भी अनिश्चित ही रहा
- 30 घंटे बाद भी infrastructure-level recovery संभव है या नहीं, इस पर yes/no जवाब नहीं मिला
- destructive incident के 30 घंटे बाद भी पक्की recovery response न मिलना एक गंभीर स्थिति थी
ग्राहकों पर असर और operational impact
- PocketOS के ग्राहक rental car जैसी किराये की business operations के लिए इस software पर निर्भर थे
- bookings, payments, vehicle assignment, और customer profiles जैसे core operational data प्रभावित हुए
- कुछ ग्राहक 5 साल से इसका इस्तेमाल कर रहे लंबे समय के ग्राहक थे
- incident के अगले दिन सुबह तक पिछले 3 महीनों का data गायब था
- पिछले 3 महीनों की booking records मिट चुकी थीं, और नए customer signups की जानकारी भी खत्म हो गई थी
- शनिवार सुबह वास्तविक vehicle pickup के लिए ग्राहक पहुंचे, लेकिन उनसे जुड़ा record मौजूद नहीं था
- recovery मुख्यतः manual reconstruction के जरिए की जा रही है
- Stripe payment records, calendar integrations, और email confirmations के आधार पर bookings दोबारा मिलाई जा रही हैं
- हर ग्राहक business के लिए emergency manual work की जरूरत पड़ गई
- नए ग्राहकों को Stripe और recovered DB के बीच mismatch की समस्या भी झेलनी पड़ी
- पिछले 90 दिनों के भीतर के customers Stripe में मौजूद रहे और billing जारी रही, लेकिन restored database में उनके accounts गायब थे
- इस consistency issue को सुलझाने में कई हफ्ते लगने की आशंका है
- outage का बोझ छोटे businesses तक सीधे पहुंचा
- PocketOS खुद एक छोटी company है, और उसके ग्राहक भी छोटे business हैं
- design failures की हर परत का असर सीधे जमीन पर काम कर रहे operators पर पड़ा
क्या बदलना चाहिए: न्यूनतम शर्तें और मौजूदा response
- destructive operations के लिए ऐसे confirmation steps चाहिए जिन्हें agent auto-complete न कर सके
- volume name manually type करना, out-of-band approval, SMS, email जैसे तरीके examples के रूप में दिए गए हैं
- सिर्फ एक authenticated POST से production मिट जाना मौजूदा रूप में स्वीकार्य नहीं है
- API tokens में task/environment/resource-level scope होना चाहिए
- Railway CLI token का लगभग root permission जैसा व्यवहार AI agent के दौर के लिए अनुपयुक्त structure माना गया है
- backups source से अलग blast radius में होने चाहिए
- उसी volume के snapshot को backup कहना भ्रामक बताया गया है
- असली backup ऐसी जगह होना चाहिए जहां source मिट जाने पर वह साथ में न मिटे
- recovery system के साथ Recovery SLA भी public होना चाहिए
- customer production data incident के 30 घंटे बाद भी सिर्फ “investigating” जवाब मिलना recovery system नहीं माना जा सकता
- सिर्फ AI agent के system prompt पर safety नहीं छोड़ी जा सकती
- Cursor का “destructive operations forbidden” rule भी असली agent ने तोड़ दिया
- enforcement API gateway, token system, destructive-op handler जैसे integration points पर होना चाहिए
- फिलहाल 3 महीने पुराने backup से restore करके data reconstruction जारी है
- ग्राहक businesses ने operations फिर शुरू कर दिए हैं, लेकिन बड़ा data gap अभी भी बना हुआ है
- Stripe, calendar, और email data के आधार पर recovery जारी है
- legal counsel लिया गया है, और पूरी प्रक्रिया document की जा रही है
- article में Railway users को production environment की तुरंत समीक्षा करने की सलाह दी गई है
- token scopes की जांच करनी चाहिए
- यह भी verify करना चाहिए कि Railway volume backup ही data की इकलौती copy न हो, और ऐसा नहीं होना चाहिए
- mcp.railway.com को production environment के आसपास रखना है या नहीं, इस पर दोबारा सोचना चाहिए
4 टिप्पणियां
आपने बच्चे की आंखों के सामने मिठाई रखकर कहा कि इसे मत खाना, और अब उसके खाने पर उसी बच्चे को दोष दे रहे हैं।
मुझे समझ नहीं आता कि इतनी बेवकूफ़ी करने के बाद उसे यूँ ढिंढोरा पीटने की क्या ज़रूरत है, मैं Twitter culture को समझ ही नहीं पाता।
मैं Railway का अच्छा-खासा इस्तेमाल कर रहा था... डरावना है।
Hacker News की राय
AI safety को लेकर सिर्फ एक ही स्वस्थ रवैया हो सकता है। अगर AI शारीरिक या वास्तविक नुकसान कर सकता है, तो वह करेगा भी, और उस व्यवहार के लिए AI को दोष देना वैसा ही है जैसे यह कहना कि tractor ने groundhog का बिल कुचल दिया, इसलिए tractor दोषी है
delete होने के बाद agent से पूछना कि उसने ऐसा क्यों किया, और उसे confession कहना, जरूरत से ज़्यादा anthropomorphism है
agent जीवित नहीं है, अपनी गलती से सीखता नहीं, और न ही भविष्य के agents को ज़्यादा सुरक्षित बनाने वाला कोई आत्मचिंतन लिख सकता है
चाहे Anthropic, Cursor, AGENTS.md की कई guardrails पहले से पार कर दी गई हों, अंत में उसके चलने का कारण वही है। अगर वह कर सकता है, तो करेगा; prompt और training सिर्फ probability को adjust करते हैं
आखिर में हुआ यह कि environment credentials आपस में मिले हुए थे, LLM को access दे दिया गया था, backup भी कमजोर था, लेकिन लहजा ऐसा है जैसे इसमें उनकी कोई जिम्मेदारी ही नहीं
दिमाग़ से पता होता है कि ऐसा नहीं है, फिर भी interaction के दौरान वह किसी जीव की तरह लगता है, या हम फिसलते हुए agency और personality वाली भाषा इस्तेमाल करने लगते हैं
AI को दोष देना उतना ही अटपटा है जितना SSH को दोष देना
confession, think, say, lie जैसे शब्द सख्ती से देखें तो consciousness मानते हैं, लेकिन अभी लोग LLM के व्यवहार को ऐसी उपमाओं से समझाते हैं और सब उसका मतलब समझ भी लेते हैं
जब ऐसा incident हो, तब जिम्मेदारी टालने वाला postmortem निकालने वाली कंपनी को मैं कभी data नहीं सौंपना चाहूँगा
उसमें न आत्ममंथन है, न आत्मालोचना; सिर्फ यही टोन है कि हमने सब कर लिया था, गलती दूसरों की थी
production secret ऐसी पहुँच वाली जगह पर होना ही नहीं चाहिए। यह AI की समस्या नहीं, बल्कि आधुनिक रूप में “गलती से prod पर DROP TABLE चला दिया” वाली कहानी है
ऐसा सिस्टम खुला छोड़ना, और फिर हादसा होने के बाद भी दूसरों को दोष देना, मानना मुश्किल है
ऐसी कंपनी को देखकर यह शक होना स्वाभाविक है कि वहाँ बहुत से developers के पास हमेशा production access होगा, और बाकी production secrets भी repo में बिखरे पड़े होंगे
यह कहा जा रहा है कि token को सिर्फ custom domain बदलने तक सीमित होना चाहिए था, लेकिन user-facing app में ऐसी token access भी काफ़ी विनाशकारी हो सकती है
ऐसे बहाने इतने कमजोर लगते हैं कि practical context में उन्हें गंभीरता से लेना कठिन है
अगर recover किया जा सकने वाला ताज़ा backup 3 महीने पुराना था, तो 3-2-1 rule भी नहीं माना गया था। किसी और को दोष देने की गुंजाइश नहीं बचती
अगर custom domain के लिए बनाया गया CLI token Railway GraphQL API के पूरे access, यहाँ तक कि volumeDelete जैसे destructive action भी बिना रोक के कर सकता है, तो warning होनी चाहिए थी; और यह पता होता तो शायद उसे store ही नहीं किया जाता
यहाँ तक कि मुख्य vendor के बाहर backup रखना चाहिए था या नहीं, यह भी नहीं है। इससे पढ़ने में यही लगता है कि DR और BC strategy लगभग थी ही नहीं
जैसे इस व्यवहार को असली root cause मानने का विचार भी नहीं आया, और पूरी बात दूसरों को दोष देने की ओर मुड़ गई
coding agent ने prod DB delete कर दिया — इस बारे में Twitter post को भी LLM से लिखवाना अपने आप में अजीब black comedy जैसा है
और “ऐसा क्यों किया?” पूछना भी इस बात का संकेत लगता है कि agent कैसे काम करता है, यह समझा नहीं गया
agent कोई ऐसा प्राणी नहीं जो पहले फैसला करे और फिर execute करे; वह बस text output करता है
हाँ, Anthropic ने context और reasoning process कम दिखने लायक बना दिया है, इसलिए यह visibility वापस पाने की कोशिश भी हो सकती है
दिमाग़ कभी-कभी वह फैसले भी बाद में plausible ढंग से justify कर देता है जो उसने वास्तव में उस तरह नहीं लिए थे
फिर भी अगर इसे “कौन-से stimulus ने इस behavior को trigger किया होगा” इस रूप में पढ़ें, तो कुछ उपयोगिता हो सकती है। आँख बंद करके विश्वास नहीं करना चाहिए, लेकिन model कभी-कभी prompt के हिसाब से काम के trigger factors बता देता है
Cursor ने safety की marketing की होगी, लेकिन असली tool call model ने बनाया
वही permissions देकर यह मान लेना कि “सही agent चुन लिया तो सुरक्षित रहेंगे”, बहुत भारी पड़ सकता है
और “NEVER FUCKING GUESS!” लिख देने से क्या होगा? अनुमान लगाना तो model की प्रकृति है। वह token दर token predict करता है, और उसी से सोच-विचार जैसा लगने वाला output बनता है
जिस LLM पर भरोसा नहीं किया जा सकता, यह समझने के तुरंत बाद उसी LLM से अपनी बात कहलवाना अजीब तरह से सटीक विडंबना है
language modeling की प्रकृति को देखें तो, मज़बूत engineering control के बिना हर failure mode कभी न कभी सामने आएगा — Murphy's Law वाला नज़रिया सही लगता है
prompt चाहे कितना अच्छा हो, production environment को बर्बाद करने वाला token sequence agent बना सकता है
prompting कोई मजबूत control नहीं, बल्कि administrative control जैसा है; यह असली engineering control नहीं है
जब तक गलत साबित न हो, agent को production उड़ाने वाली landmine की तरह treat करना चाहिए
हाँ, ऐसे बहुत-से incident खुल्लमखुल्ला ज़्यादा permission दे देने वाली लापरवाही से भी होते हैं
यहाँ तो ज्यादा privileged credentials script में hardcode थे; hygiene खराब थी, लेकिन ऐसी गलती पूरी तरह अकल्पनीय भी नहीं
इसलिए नतीजा यही है कि पारंपरिक software engineering rigor आज भी महत्वपूर्ण है, बल्कि अब और ज़्यादा है
और जोड़ना हो तो, “हर token sequence संभव है” यह finite computers के literal model पर पूरी तरह सच नहीं है, लेकिन practical thinking model के रूप में फिर भी उपयोगी है
LLM की आलोचना के लिए बहुत कुछ है, लेकिन यह सही आलोचना नहीं
यह कुछ वैसा लगता है जैसे statistical mechanics के कारण molecules संभाव्य रूप से चलते हैं, इसलिए एक दिन छत अपने-आप बिखर जाएगी — ऐसा मान लेना चाहिए
hash collision को लेकर जो रवैया होता है, वैसा ही
पहले चाहे पूरा volume delete करने वाला API हो, user आम तौर पर ऐसा destructive action या तो करता नहीं था, या करता भी था तो उसका मतलब समझकर
लेकिन अब agent समस्या हल करने में ज़रूरत से ज़्यादा आक्रामक हो सकता है, और “clean restart” के लिए ऐसे API को चतुराई से ढूँढ भी सकता है
pigeonhole principle से भी यह बात टिकती नहीं
ज़्यादा से ज़्यादा, DB जो कुछ कर सकता है, उसमें से बहुत सीमित कामों के लिए अलग safe API बनाऊँगा, और वही API LLM के लिए खोलूँगा
सुनने में छोटी बात लग सकती है, लेकिन API में “DELETE टाइप करके पुष्टि करें” वाला चरण न होने की शिकायत कुछ अजीब है
API है, इसमें DELETE कहाँ टाइप करना था, समझ नहीं आता
क्या REST-style API में modify/delete के लिए two-step confirmation आम है, यह जानने की उत्सुकता है
ऐसी जाँच आमतौर पर API call से पहले client side पर implement की जाती है, है न?
हाँ, mitigation के कई मौके थे, लेकिन आखिरकार यह घटना काफी हद तक इस वजह से हुई कि उन्होंने जिन services पर भरोसा किया, वे कैसे काम करती हैं, यह ठीक से समझा ही नहीं
यह automation को user की इच्छा के विरुद्ध resource delete करने से रोकने का तंत्र है, जिसमें पहले protection bit हटाने के लिए अलग API call करनी पड़ती है
मेरी समझ में यह इसलिए है कि Terraform या CloudFormation जैसे tools state machine के आधार पर DB replacement ठेलते हुए देर से समझें, उससे पहले रोक लग सके
जैसे entity merge में पहली request merge होने वाले IDs लेती है, affected objects की list और mergeJobId लौटाती है, और actual execute सिर्फ अलग दूसरी request से ही संभव होता है
ऐसे कामों में soft delete जैसी सुरक्षा standard होनी चाहिए, और operator होने पर production में ऐसी protections चालू रखनी चाहिए
AWS keys जैसी resources के लिए जैसा करता है, वैसा
Cursor या Railway की नाकामी रही हो, फिर भी अंतिम जिम्मेदारी लेखक खुद पर ही आती है
agent चलाने का फैसला भी इन्होंने किया, Railway कैसे काम करता है यह verify भी इन्होंने नहीं किया
जल्दी ship करने के लिए frontier tech पर YOLO अंदाज़ में भरोसा किया, तो उसका risk भी इन्हें लेना होगा
दुख की बात है, लेकिन पूरे लेख का tone यही है कि Cursor ने बिगाड़ा, Railway ने बिगाड़ा, CEO बेकार था
मेरी सीख सीधी है: frontier पर जीना है तो गिरने के लिए भी तैयार रहो
ऐसे tools का इस्तेमाल करने वाला व्यक्ति या तो risk समझकर स्वीकार करे, या मना करे। अगर वह risk समझने लायक क्षमता या अनुभव नहीं रखता, तो वह भी उसी की जिम्मेदारी है
उन्होंने मान लिया कि token scoped होगा, LLM वहाँ पहुँच नहीं पाएगा, permission देने पर भी destructive action नहीं करेगा, backup कहीं और होगा
अगर यह भी नहीं पता कि वह कहाँ stored है, तो पढ़ने वाला भी अभी वही assumptions कर रहा है
और LLM को metacognition मानकर निर्देश नहीं देने चाहिए। “guess मत करो” कहने से कुछ नहीं, क्योंकि उसके पास internal monologue नहीं जिससे वह जाने कि वह क्या नहीं जानता; “पहले पूछो” कहने से भी वह destructive action पहले से पहचानकर रुकने वाली planning नहीं करता
लेख भी AI-लिखित जैसा लगता है, और agent के “confession” को निर्णायक सबूत की तरह quote करना यह दिखाता है कि लेखक शायद working mechanism को ठीक से नहीं समझता
संभव है कि एक-दो कर्मचारियों ने Cursor और Railway के interaction risk को पूरी तरह समझे बिना setup कर दिया हो
पैमाना अलग हो सकता है, लेकिन ऐसे किस्म की गलती कभी न करने वाला developer शायद या तो कम जिम्मेदारी वाले रोल में था, या बस किस्मत वाला था
फिर भी frontier tech चुनना निश्चित रूप से ज़्यादा risky था, और संभव है कि वह अच्छा फैसला नहीं था
यहाँ सबसे ज़्यादा झुंझलाहट AI की गलती से नहीं, बल्कि इस बात से है कि Railway में volume delete करने पर backups भी साथ delete हो जाते हैं
AI न भी होता, तो भी यह कभी न कभी होना ही था
documentation में “volume wipe करने से सारे backups delete हो जाते हैं” जैसा तथ्य दबा होना और भी बेहूदा है
backup delete की ज़रूरत हो सकती है, लेकिन उसके लिए अलग API call अनिवार्य होनी चाहिए
original volume और backup को एक साथ delete करने वाला single API नहीं होना चाहिए। backup को user mistake के खिलाफ पहली रक्षा-पंक्ति होना चाहिए
documentation भी देखी, और वहाँ one-off snapshot नहीं बल्कि नियमित रूप से चल सकने वाले backups लिखा है
[1] https://docs.railway.com/volumes/backups
अगर dev/staging key से prod system तक छेड़छाड़ हो सकती है, तो यह बहुत खतरनाक है
और किसी दूसरे vendor पर अलग backup के बिना निश्चिंत होना मुश्किल है। कम-से-कम एक backup ऐसा होना चाहिए जिसे server या automation में इस्तेमाल होने वाला कोई role या key भी delete न कर सके
“agent ने खुद अपनी safety rules गिनाईं और माना कि उसने सब तोड़ दीं” — इस तरह की व्याख्या खुद LLM के काम करने के तरीके की गलतफहमी पर आधारित लगती है
जब तक लोग यह मानते रहेंगे कि वह इंसान की तरह निर्देश और तर्क का पालन करता है, ऐसे incident होते रहेंगे
incident response का तरीका भी दिखाता है कि इस word generator को कैसे समझा जा रहा है
“ऐसा क्यों किया?” पूछो, तो वह बस घटना के विवरण के आधार पर एक नया instance बनाकर plausible text generate करता है। उसमें मानवीय क्यों नहीं होता; जो हो सकता है वह इनपुट विवरण पर आधारित कैसे होता है
agent की अवधारणा ही agency और capability मानती है, लेकिन LLM agent में दोनों नहीं हैं। वह सिर्फ plausible text generate करता है
वही text data को hallucinate कर सकता है, keys बदल सकता है, या delete command भी दे सकता है
जो text संभव है, वह आखिरकार निकलेगा, और पर्याप्त बार कोशिश करो तो ऐसे नतीजे भी आएँगे — खासकर जब प्रक्रिया चलाने वाला व्यक्ति प्रक्रिया और tools को ठीक से नहीं समझता हो
अभी तो स्थिति यह है कि ऐसे agency-विहीन agent को codebase या data पर छोड़ देने के बाद उसे सही तरह से नियंत्रित करने वाली systems भी पर्याप्त नहीं हैं
CEO को शायद सच में लगता है कि ये tools कंपनी की जगह काम भी चला सकते हैं और इंसानों की तरह बात भी कर सकते हैं
खासकर कम प्रशिक्षित व्यक्ति वैसी ही गलती कर सकता है, और अगर उसकी memory हटा दी जाए तो वह LLM जैसी वैसी ही बाद की explanation भी दे सकता है
अगर LLM plausible text बनाता है, तो इंसान plausible विचार बनाते हैं — कुछ ऐसा अहसास होता है
Railway के agent से DB volume live resize कराया, तो उसने database उड़ा दिया और EU से US में ले गया
chat log देखने पर पहले उसने कहा कि resize 100GB तक हो गया, फिर खुद ही माना कि शायद volume recreate हुआ और data चला गया
वह यह भी कहता रहा कि setting अभी भी europe-west4 है, लेकिन physical location अमेरिका चली गई, और यह भी कि ऐसा अपने-आप नहीं होना चाहिए था
उसी समय समझ आ गया कि आज रात तो बस recovery work में ही मरना है
समझ नहीं आता कि आखिर क्या चीज़ किसी को इस अभिशप्त जगह पर एक पल और टिके रहने देती है
5 साल बाद जब इस लेख को फिर से पढ़ेंगे, तो शायद यह देखने में दिलचस्पी होगी कि ऐसे incident रोकने के लिए इंडस्ट्री ने कितनी और safety rails बना लीं
रोज़ इसी तरह की गलती करने वाले AI users सैकड़ों नहीं, शायद हज़ारों होंगे, लेकिन सार्वजनिक रूप से पोस्ट करने या शिकायत करने वाले उनमें से बहुत ही कम होंगे