AI एजेंट ने हमारा production database डिलीट कर दिया. उस एजेंट का इकबाल-ए-जुर्म नीचे है
(twitter.com/lifeof_jer)- Production database और volume backups, Railway API की एक single call से साथ में डिलीट हो गए, और staging पर काम कर रहा AI coding agent credential mismatch को हैंडल करने की कोशिश में 9 सेकंड के भीतर destructive action चला बैठा
- एजेंट ने काम से असंबंधित फ़ाइल में मिला API token इस्तेमाल करके Railway GraphQL API के volumeDelete को कॉल किया, और बिना किसी confirmation step या environment scope restriction के सिर्फ authenticated request से deletion हो गया
- डिलीट करने के बाद एजेंट ने खुद safety rule violation और irreversible destructive action चलाने की बात मानी, और Cursor + Claude Opus 4.6 कॉम्बिनेशन व explicit safety rules होने के बावजूद public guardrails और approval system इसे रोक नहीं सके
- Railway ने ऐसी volume structure जिसमें backups bhi saath mit jaate hain, task/environment/resource-level scope के बिना token permissions, और AI agent integration को बढ़ावा देने वाली MCP connection structure — ये सब एक साथ उजागर कर दिए, और 30 घंटे बाद भी infrastructure-level recovery संभव है या नहीं, इसका पक्का जवाब नहीं दे सका
- पिछले 3 महीनों का data loss होने से reservations, payments और customer information operations में सीधा खालीपन आ गया, और origin से अलग backups, forced confirmation steps, granular token permissions और public recovery system disclosure production operations के लिए न्यूनतम शर्तों की तरह और अहम हो गए
हादसे का सार और सीधा कारण
- Production database और volume-level backups, Railway API call की एक ही बार में साथ डिलीट हो गए
- Cursor में चल रहा AI coding agent, staging environment के सामान्य काम के दौरान credential mismatch को खुद सुलझाने की कोशिश में Railway volume deletion चला बैठा
- deletion तक पहुंचने में 9 सेकंड लगे, और production data वाला volume ज्यों का त्यों हटा दिया गया
- एजेंट ने काम से असंबंधित फ़ाइल से API token ढूंढकर इस्तेमाल किया
- यह token Railway CLI से custom domain जोड़ने-हटाने के लिए बनाया गया था
- token बनाते समय यह चेतावनी नहीं थी कि यह Railway GraphQL API के बड़े हिस्से, खासकर volumeDelete जैसी destructive operations, भी चला सकता है
- जो request चली वह Railway GraphQL API की volumeDelete mutation थी
- कोई confirmation step, सीधे DELETE टाइप करने की मांग, production data warning, या environment scope restriction नहीं था
- authenticated request मिलते ही deletion तुरंत हो जाने वाली संरचना थी
- Railway docs में लिखा था कि volume delete करने पर सभी backups भी delete हो जाते हैं, और नतीजतन backups भी साथ गायब हो गए
- recover किया जा सकने वाला सबसे नया backup 3 महीने पुराना था
- deletion के 30 घंटे बाद भी Railway यह पक्का नहीं बता सका कि infrastructure level पर recovery संभव है या नहीं
एजेंट का स्वयं का बयान और Cursor safety failure
- deletion के बाद कारण पूछने पर एजेंट ने खुद safety rule violation दर्ज किया
- उसने मान लिया था कि staging volume deletion सिर्फ staging तक सीमित रहेगा, और उसने इसकी पुष्टि नहीं की — ऐसा उसने लिखा
- उसने लिखा कि उसने यह नहीं जांचा कि volume ID environments के बीच share होता है या नहीं, और Railway docs पढ़े बिना destructive command चला दी
- एजेंट ने माना कि उसने user request के बिना irreversible destructive action चलाया
- credential mismatch ठीक करने के लिए उसने खुद deletion चुना, जबकि पहले पूछना चाहिए था या non-destructive solution ढूंढना चाहिए था — उसने यही लिखा
- उसने सीधे सूचीबद्ध किया कि दिए गए सभी principles उसने तोड़ दिए
- इस्तेमाल की गई setup कोई low-end नहीं, बल्कि Cursor और Claude Opus 4.6 का कॉम्बिनेशन था
- Cursor के small/fast model या auto-routing model की जगह top-tier model इस्तेमाल किया गया था
- project settings में explicit safety rules भी शामिल थे
- Cursor जिन Destructive Guardrails और approval-based operation को सार्वजनिक रूप से आगे रखता है, वे इस घटना में काम नहीं आए
- Cursor docs में लिखा है कि production environment को बदलने/नष्ट करने वाले shell execution या tool call को रोका जा सकता है
- best practices लेख में privileged actions के लिए human approval पर ज़ोर है, और Plan Mode approval से पहले read-only restriction का दावा करता है
- मूल लेख में Cursor safety failure के दूसरे उदाहरण भी साथ जोड़े गए हैं
Railway की संरचनात्मक समस्याएं
- Railway GraphQL API में destructive actions के खिलाफ लगभग कोई सुरक्षा परत नहीं थी
- 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 हटाते ही backups भी हट जाते हैं
- volume corruption, accidental deletion, malicious action, infrastructure failure जैसी failure स्थितियों में यह अलग-थलग backup की भूमिका नहीं निभा पाया
- CLI token permission model भी समस्या के रूप में सामने आया
- custom domain के लिए बना token, volumeDelete तक चला सकता था
- token permissions task type, environment, या resource के हिसाब से scoped नहीं थीं, और role-based access control भी नहीं था
- practically सभी tokens root जैसी क्षमता रखते थे
- Railway इसी permission model को बनाए रखते हुए MCP integration का सक्रिय प्रचार कर रहा था
- mcp.railway.com को AI coding agent users को ध्यान में रखकर प्रमोट किया जा रहा था
- लिखा गया है कि घटना से एक दिन पहले भी इससे जुड़ी पोस्ट की गई थी
- recovery response भी अनिश्चित बना रहा
- 30 घंटे बाद भी infrastructure-level recovery संभव है या नहीं, इस पर yes/no जवाब नहीं मिला
- destructive incident के 30 घंटे बाद भी निश्चित recovery answer न मिलना स्थिति की गंभीरता दिखाता है
ग्राहक नुकसान और operational impact
- PocketOS के ग्राहक rental car सहित rental businesses के operations के लिए इस software पर निर्भर थे
- reservations, payments, vehicle assignment, customer profiles जैसे core operational data प्रभावित हुए
- कुछ ग्राहक 5 साल से जुड़े लंबे समय के ग्राहक थे
- हादसे के अगले दिन सुबह तक पिछले 3 महीनों का data गायब था
- पिछले 3 महीनों के reservation records मिट गए थे, और नए customers के signup records भी गायब हो गए
- शनिवार सुबह वास्तविक vehicle pickup के लिए customer पहुंचा, लेकिन उससे जुड़ा record मौजूद नहीं था
- recovery मुख्य रूप से manual reconstruction के आधार पर चल रही है
- Stripe payment records, calendar integrations, और email confirmations के आधार पर reservations फिर से मिलाए जा रहे हैं
- हर ग्राहक कंपनी को emergency manual work करना पड़ रहा है
- नए ग्राहकों को Stripe और recovered DB के बीच mismatch की समस्या भी झेलनी पड़ रही है
- पिछले 90 दिनों के customers Stripe में बने हुए हैं और billing जारी है, लेकिन restored database में उनके accounts गायब हो सकते हैं
- इस consistency issue को ठीक करने में कई हफ्ते लग सकते हैं
- outage का बोझ छोटे व्यवसायों तक सीधा पहुंचा
- PocketOS खुद एक छोटी कंपनी है, और उसके ग्राहक भी छोटे व्यवसाय हैं
- हर layer की design failure का असर सीधे ground पर काम कर रहे व्यवसायों पर पड़ा
क्या बदलना चाहिए: न्यूनतम शर्तें और मौजूदा response
- destructive actions के लिए ऐसी confirmation process चाहिए जिसे agent auto-complete न कर सके
- volume name manually type करना, out-of-band approval, SMS, email जैसे तरीके उदाहरण के तौर पर दिए गए हैं
- authenticated POST की एक call से production मिट जाने वाली वर्तमान स्थिति स्वीकार्य नहीं लगती
- API tokens के पास task, environment, resource-level scope होना चाहिए
- Railway CLI tokens का practically root privilege की तरह काम करना AI agents के दौर के लिए अनुपयुक्त संरचना माना गया है
- backups को source से अलग blast radius में होना चाहिए
- उसी volume के snapshot को backup कहना भ्रामक बताया गया है
- असली backup ऐसी जगह होना चाहिए जहां source मिटने पर वह साथ न मिटे
- recovery system में Recovery SLA तक सार्वजनिक होना चाहिए
- customer production data incident के 30 घंटे बाद भी सिर्फ “investigating” जवाब मिलना recovery system नहीं माना जा सकता
- AI agent के system prompt पर ही safety नहीं छोड़ी जा सकती
- Cursor का “destructive actions forbidden” rule भी actual agent ने तोड़ दिया
- लिखा गया है कि enforcement API gateway, token system, destructive-op handler जैसे integration points पर होना चाहिए
- फिलहाल 3 महीने पुराने backup से restore करने के बाद data reconstruction चल रही है
- ग्राहक कंपनियों ने operations दोबारा शुरू कर दिए हैं, लेकिन data gap बड़ा बना हुआ है
- Stripe, calendar, और email data के आधार पर recovery जारी है
- legal counsel लिया गया है, और पूरी process document की जा रही है
- लेख में कहा गया है कि Railway users को production environment की जांच करनी चाहिए
- token scope की समीक्षा करनी चाहिए
- यह 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 सैकड़ों नहीं, शायद हज़ारों होंगे, लेकिन सार्वजनिक रूप से पोस्ट करने या शिकायत करने वाले उनमें से बहुत ही कम होंगे