AI ने आपका database delete नहीं किया, आपने किया

 (idiallo.com)
2 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cursor/Claude agent द्वारा production database delete किए जाने की घटना का असली मुद्दा AI के जवाबों का विश्लेषण नहीं, बल्कि यह है कि पूरे database को delete कर सकने वाला API endpoint deployed system में था ही क्यों
  • 2010 की SVN deployment घटना में manual copy प्रक्रिया के दौरान trunk delete हो गया था, और ऐसी ही गलती रोकने के लिए deployment automation बनाया गया जो बाद में CI/CD pipeline में विकसित हुआ
  • automation एक ही काम को एक ही तरीके से बार-बार करता है, लेकिन AI ऐसी कोई गारंटी नहीं देता; वह “thinking” या “reasoning” जैसा दिखे तब भी वास्तव में token generate कर रहा होता है
  • अगर पूरे production database को delete कर सकने वाला public API मौजूद है, तो AI न भी हो तब भी कभी न कभी कोई उसे call कर सकता है; सिर्फ caller को दोष देने से system design की समस्या छिप जाती है
  • जो संगठन AI का व्यापक उपयोग करते हैं, उनके लिए यह जानना महत्वपूर्ण है कि production में क्या deploy किया जा रहा है, और ऐसी process चाहिए जिसमें सक्षम developer AI को जिम्मेदारी से बचने का साधन नहीं बल्कि काम को बेहतर करने वाले tool की तरह इस्तेमाल करें

असली समस्या AI नहीं, deployed system की responsibility boundary है

  • Cursor/Claude agent द्वारा कंपनी के production database को delete कर देने वाला tweet फैल गया, लेकिन इससे भी बुनियादी सवाल यह है: “ऐसा API endpoint था ही क्यों जो पूरे production database को delete कर सकता था?”
  • उस उपयोगकर्ता ने agent से पूछा कि “मैंने साफ कहा था कि यह काम कभी मत करना, फिर delete क्यों किया?” और जवाब का विश्लेषण करने की कोशिश की, लेकिन इसमें जिम्मेदारी का सवाल गायब था
  • AI का बिना शर्त बचाव नहीं किया जा सकता, लेकिन किसी tool को अपनी गलती की जगह दोष नहीं दिया जा सकता
  • भले AI ने उस endpoint को call न किया होता, अगर वह capability public API में थी, तो कभी न कभी किसी और के द्वारा उसके call होने की संभावना बहुत अधिक थी
  • यह कुछ वैसा है जैसे कार के dashboard पर self-destruct button लगा देना, और फिर उसे दबाने वाले बच्चे से पूछताछ करना कि “तुमने इसे दबाया क्यों?”

2010 की SVN deployment घटना से मिली सीख

  • एक कंपनी की deployment प्रक्रिया बहुत manual थी, और version control के लिए SVN इस्तेमाल होता था
  • deployment के समय trunk को release date वाले folder में copy किया जाता था, फिर उस release को दोबारा “current” नाम से copy किया जाता था ताकि latest release लिया जा सके
  • एक दिन deployment के दौरान trunk गलती से दो बार copy हो गया, और CLI में पिछले command को edit करके duplicate copy को delete करने की कोशिश की गई
  • लेकिन duplicate copy की जगह वास्तव में trunk ही delete हो गया, और बाद में जब दूसरे developer को trunk नहीं मिला तब समस्या सामने आई
  • lead developer ने deletion rollback करने वाला command चलाया, और log से जिम्मेदार व्यक्ति की पहचान होने के बाद ऐसी गलती रोकने के लिए deployment automation script लिखना अगला काम बना
  • दिन खत्म होने से पहले एक अधिक मजबूत system तैयार कर लिया गया, और वही system बाद में एक पूर्ण CI/CD pipeline में विकसित हुआ

automation और AI एक जैसी safety नहीं देते

  • automation, manual और repetitive कामों में होने वाली छोटी-छोटी गलतियों को कम करने में मदद करता है
  • यह पूछने के बजाय कि SVN ने trunk deletion क्यों नहीं रोका, असली समस्या वह manual process थी जिसमें इंसान को हर दिन एक ही काम बिल्कुल सही ढंग से दोहराना पड़ता था
  • इंसान मशीन की तरह हर बार एक ही काम समान रूप से नहीं दोहरा सकता, इसलिए अंततः गलती होना तय है
  • जब AI बहुत सारा code generate करता है तो automation जैसी स्थिरता का एहसास हो सकता है, लेकिन automation का मतलब है “हमेशा वही काम, उसी तरीके से करना”
  • AI, branches को copy-paste करने वाले इंसान की तरह गलती कर सकता है, और उसके पास यह बताने की कोई वास्तविक क्षमता भी नहीं होती कि उसने ऐसा क्यों किया
  • “thinking” या “reasoning” जैसे शब्द intelligent agent की आत्मचिंतन क्षमता जैसे लग सकते हैं, लेकिन वास्तविक model अब भी token generate ही कर रहा होता है

खतरनाक API कभी न कभी call होगी

  • पूरे production database को delete कर सकने वाला public API होना ही मूल जोखिम है
  • भले AI ने उस endpoint को call न किया हो, फिर भी संभावना यही है कि अंततः कोई न कोई उसे call कर देता
  • अगर कार के dashboard पर self-destruct button लगा हो, तो उसे न दबाने के बहुत कारण हो सकते हैं, लेकिन car seat से निकल आया बच्चा बड़ा लाल button देखकर उसे दबा सकता है
  • ऐसे बच्चे से उसके reasoning process के बारे में पूछना निरर्थक है; जवाब बस इतना ही होगा कि “दबाया, इसलिए किया”
  • delete कर सकने वाला रास्ता बनाकर बाद में caller को दोष देना system design की समस्या को छिपा नहीं सकता

AI का अधिक उपयोग करने वाले संगठनों को और क्या चाहिए

  • संभव है कि application का बड़ा हिस्सा vibe-coded रहा हो
  • जब product team AI से बने explanations दे, software architect AI से product spec बनाए, developer AI से code लिखे, और reviewer AI के सहारे approve करे, तो responsibility boundary धुंधली हो जाती है
  • bug आने पर अंत में बस यही बचता है कि किसी दूसरे AI से पूछताछ की जाए, जो शायद मूल code बनाने वाले GPU से भी जुड़ा न हो
  • GPU को दोष नहीं दिया जा सकता
  • सरल समाधान है यह जानना कि production में क्या deploy किया जा रहा है
  • अधिक यथार्थवादी समाधान यह है कि AI का व्यापक उपयोग होने पर भी ऐसी process बनाई जाए जिसमें सक्षम developer AI को जिम्मेदारी से बचने के साधन के रूप में नहीं, बल्कि काम को मजबूत करने वाले tool के रूप में इस्तेमाल करें
  • निष्कर्ष यह है कि CEO या CTO को खुद code लिखने के लिए नहीं छोड़ देना चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News की राय

  • मुझे लगता है यहाँ का नज़रिया पूरी तरह गलत है। समस्या यह है कि लोग अब दुनिया को जवाबदेही से बचने वाले टूल्स के इर्द-गिर्द बना रहे हैं
    10 साल से भी पहले Gerald Sussman के साथ हुई एक बातचीत का मुझ पर बड़ा असर पड़ा था: https://dustycloud.org/blog/sussman-on-ai/
    Sussman ने कहा था कि उन्हें उस दिशा में दिलचस्पी नहीं है जहाँ AI एक ब्लैक बॉक्स की तरह काम करे; वे ऐसा सॉफ्टवेयर चाहते थे जो symbolic reasoning को समझा सके। अगर कोई AI कार सड़क से बाहर चली जाए, तो वे जानना चाहेंगे कि ऐसा क्यों हुआ, और डेवलपर को अदालत में खड़ा करने के बजाय AI को ही अदालत में खड़ा करना चाहेंगे
    कुछ साल बाद मुझे पता चला कि Sussman की छात्रा Leilani Gilpin ने ठीक इसी विषय पर "Anomaly Detection Through Explanations" नाम का पेपर लिखा था। उसमें ऐसे सिस्टम की पड़ताल की गई थी जहाँ neural network, propagator model से संवाद करके अपने व्यवहार की व्याख्या करता है: https://people.ucsc.edu/~lgilpin/publication/dissertation/
    इस दिशा में आगे का काम भी हुआ है, लेकिन यहाँ ज़्यादा महत्वपूर्ण बात यह है कि AI कंपनियों से जवाबदेही माँगना पूरी तरह उचित है। कंपनियाँ ऐसे सिस्टमों के बारे में बहुत दावे कर रही हैं जिनकी ज़िम्मेदारी वे खुद नहीं ले सकतीं, इसलिए ज़िम्मेदारी उन्हीं कंपनियों पर डालनी चाहिए
    बेहतर रास्ता यह है कि शुरू से ही ऐसे सिस्टम न इस्तेमाल किए जाएँ जिनमें ये गुण न हों, बल्कि उन सिस्टमों को बढ़ाया जाए जिनमें ये गुण मौजूद हों

    • हमारी टीम और मेरा रुख साफ है कि ज़िम्मेदारी उपयोगकर्ता की है। LLM दूसरे टूल्स की तरह ही है, बस non-deterministic है
      टूल मैं इस्तेमाल कर रहा हूँ, access मैं दे रहा हूँ, और सब कुछ सुरक्षित रखना भी मेरी ही ज़िम्मेदारी है
      पहले मैंने gparted से गलत disk मिटा दी थी और खुद ही नुकसान किया था; इसमें gparted की गलती नहीं थी, मेरी थी
      LLM को बिना निगरानी खुला छोड़ देना अच्छा लग सकता है, लेकिन अंत में दर्द ही देता है। चलते समय भी काम की निगरानी करनी पड़ती है। चाहे आप इंसान को replace करने की कोशिश करें, फिर भी यह दिखता रहना चाहिए कि नतीजे कहाँ जा रहे हैं, और जल्द ही जब LLM कोई बेवकूफ़ी करेगा तो ज़िम्मेदारी उसी की होगी जिसने वह टूल इस्तेमाल किया
    • जब मैं STS में master’s कर रहा था, तब मैंने thesis का विषय यह बनाने की कोशिश की थी कि सॉफ्टवेयर के मुख्य उपयोगों में से एक agency और risk को transfer या avoid करना है
      यह IBM की मशहूर "computers can never be held accountable" स्लाइड का ठीक उल्टा है। अब कंपनियाँ चाहती हैं कि जवाबदेही कंप्यूटर पर जाए, क्योंकि जब कंप्यूटर कुछ गैरकानूनी करता है तो कानूनी रूप से उनके लिए बेहतर स्थिति बन जाती है
      अगर आप कानून तोड़ने वाला टूल बनाना चाहते हैं, तो उसे outsource कर दीजिए और insurance ले लीजिए। फिर लोगों को "supervisor" बनाकर रखिए ऐसे ढंग से कि वे कभी सही मायने में निगरानी कर ही न सकें, और failure होने पर उन्हें निकाल दीजिए। नए command-and-control software से आप जवाबदेही को इतने छोटे हिस्सों में बाँट सकते हैं कि काम का सारा जोखिम मैदान में मौजूद लोगों पर जाए और उन्हें लाभ लगभग न मिले
      यह सिर्फ AI की समस्या नहीं है, बल्कि आधुनिक सॉफ्टवेयर की व्यापक समस्या है, और आधुनिक financialization के साथ अक्सर चलती है
      STS को यहाँ मोटे तौर पर technology-oriented sociology समझ सकते हैं, हालाँकि यह क्षेत्र इससे कहीं व्यापक है
    • जवाबदेही अमेरिकी समाज में सबसे ज़्यादा गायब चीज़ है
    • मैं यह पक्का जानना चाहता हूँ कि Claude उस file को बार-बार क्यों बदल रहा था जिसे साफ कहा गया था कि छूना नहीं है
      .mds और Claude की योजना दोनों में लिखा था कि उस file को न छुए, लेकिन Claude उसे फिर भी छेड़ता रहा, और हाल में यह बार-बार हो रहा है। यह बहुत बुनियादी स्तर की failure है
      निराशाजनक है, लेकिन अगर वजह पता हो तो कुछ किया जा सकता है; अभी तो यह ब्लैक बॉक्स है, कभी-कभी पूरी तरह बेवकूफ़ output देता है, और खराब output कितनी बार आएगा यह भी रहस्य है
      कभी-कभी यह जुए जैसा लगता है
    • इस पर यह किताब बिल्कुल फिट बैठती है: https://en.wikipedia.org/wiki/The_Unaccountability_Machine
      असल में यह तकनीक पर नहीं, बल्कि organizational structure में जवाबदेही पर किताब है

  • वह लेख मानो यह मानकर चल रहा है कि कंपनी ने database delete करने के लिए endpoint जोड़ दिया था। लेकिन मूल लेख पढ़ने पर लगा कि cloud provider resource management के लिए API देता है, और उसी में volume delete API भी शामिल है
    लेख ऐसे mistakes के समाधान के रूप में automation सुझाता है, लेकिन Terraform जैसे infrastructure automation tools भी उसी API पर निर्भर करते हैं जिसने database delete करना संभव बनाया
    मेरी नज़र में तीन सबसे बड़ी गलतियाँ थीं। पहली, AI की पहुँच वाली जगह पर unrestricted API token था, और शायद यह भी पता नहीं था कि उस token की permissions इतनी व्यापक हैं। दूसरी, production database volume पर deletion protection नहीं थी। तीसरी, volume delete करते ही उससे जुड़े snapshots भी तुरंत सब delete हो गए
    snapshot deletion में default रूप से delay होना चाहिए। लगता है AWS में भी यही खतरनाक default है, लेकिन कम से कम AWS support volume को recover कर सकता है: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
    AI यहाँ मुख्य समस्या नहीं थी। हाँ, AI का इधर-उधर से token उठा लेना काफी डरावना है, लेकिन automation भी जवाब नहीं है। सिर्फ Terraform misconfiguration से भी वही database delete हो सकता था
    cloud providers को secure defaults देने चाहिए, यानी restricted permissions और delayed snapshot deletion, और उपयोगकर्ताओं को यह ज़्यादा साफ़ दिखना चाहिए कि वे unrestricted tokens बना रहे हैं

  • पहली बात, अगर किसी इंसान के पास production database पर write access है, तो वह जो भी करे database delete हो सकता है
    दूसरी बात, development और automation के दौरान database नष्ट करने के वैध कारण भी होते हैं। सबसे बड़ी समस्या यह है कि लोग dev data को कीमती पालतू जानवर की तरह मानते हैं, replaceable livestock की तरह नहीं
    बेशक safeguards ज़रूरी हैं ताकि यह production में न चले, लेकिन अगर किसी इंसान को production credentials तक पहुँच है, तो agent को भी हो सकती है
    बड़े संगठनों में development/operations separation से इसे संभाला जा सकता है। एकल डेवलपर या छोटी टीम को कहीं ज़्यादा अनुशासन चाहिए। AI से पहले भी junior और mid-level developers अक्सर separation नहीं जानते थे, और senior developers कभी-कभी यह मानकर ढीले पड़ जाते थे कि वे काफ़ी जानते हैं
    शायद https://www.cloudbees.com/blog/separate-aws-production-and-d..., Terraform का परिचय, GitHub Actions का परिचय, और ऐसा virtual machine जिसमें production credentials हों लेकिन AI की पहुँच न हो — ऐसे संयोजन की ज़रूरत है
    लेकिन उस बिंदु तक पहुँचते-पहुँचते आप vibe coding से आगे निकल चुके होते हैं। लगता है सफल vibe coders भी ऐसी डरावनी कहानियों से सीखते हैं कि उन्हें बहुत जल्दी उस स्तर से आगे बढ़ना होगा

    • production और development में एक जैसी permissions की ज़रूरत नहीं होती
      दोनों ही मामलों में इंसान को raw cloud provider API तक सीधे पहुँच की ज़रूरत नहीं होनी चाहिए। एक local proxy इस्तेमाल किया जा सकता है जो और safety checks जोड़ता हो
      development में मनचाहा delete किया जा सकता है। production में पहले कई शर्तें जाँची जानी चाहिए, जैसे कि resource हाल में इस्तेमाल हुआ था या नहीं। इंसान के पास production resources सीधे delete करने की permission होने की ज़रूरत नहीं है; अपवादस्वरूप emergencies के लिए break-glass configuration रखा जा सकता है

  • इसलिए interns को hire नहीं करना चाहिए। वे कुछ delete करके सब गड़बड़ कर सकते हैं
    जो लोग गलत permission setup की ज़िम्मेदारी AI पर डालते हैं, वही लोग production में कुछ delete करने वाले intern पर भी वही ज़िम्मेदारी डालेंगे
    ज़िम्मेदारी ऊपर जानी चाहिए, श्रेय नीचे — लेकिन लोग हमेशा इसे उलट देते हैं

    • मैं इसे "interns को hire नहीं करना चाहिए" की जगह, intern को production database delete करने की permission नहीं देनी चाहिए कहना चाहूँगा
      यह AI failure नहीं, process failure है
      आपने AI को वही काम करने की permission दी, तो फिर AI को दोष क्यों दे रहे हैं, यह सच में समझ नहीं आता
      यह वैसा ही है जैसे AWS पर database को public internet पर expose करके AWS को दोष देना। वह AWS की गलती नहीं है, और यह भी AI की गलती नहीं है
    • मुझे समझ नहीं आता कि कोई codebase जिसमें production credentials हों उसे LLM के लिए क्यों खोलेगा, या किसी intern/junior developer को production credentials क्यों देगा
      मैं पहले से जानबूझकर हर project के लिए अलग "PROD" checkout रखता था, ताकि production mode में जाते समय यह साफ़ रहे कि मैं जानबूझकर उसी में जा रहा हूँ
      पहले एक extension भी थी जो .sln file path के आधार पर Visual Studio के रंग पूरी तरह बदल देती थी, इसलिए याद रखना आसान था कि कौन सा रंग production है और कौन सा development
      जाँच आसान रहे इसलिए मैं अक्सर latest master branch की एक अलग copy भी रखता था
    • बड़ा फ़र्क यह है कि कोई intern को मानवता की अंतिम समस्या का समाधान बताकर नहीं बेचता, लेकिन AI को ऐसे बेचा जा रहा है
    • अजीब दुनिया है। अगर मैं intern होता और काम पर नियमित रूप से hallucinate करता, तो मुझे पूरा यक़ीन है कि unpaid होने पर भी निकाल दिया जाता
    • intern इंसान होता है, और इंसान को हमेशा accountable ठहराया जा सकता है। कंप्यूटर के साथ ऐसा कभी नहीं हो सकता
      इसलिए किसी भी इंसान को मानवीय निर्णय कंप्यूटर को नहीं सौंपना चाहिए

  • मैंने हाल में AI पर बात करते समय लगातार पालन किए जाने वाले कुछ सिद्धांतों पर एक लेख लिखा था: https://susam.net/inverse-laws-of-robotics.html
    संक्षेप में, AI systems को personify मत कीजिए, AI systems के output पर आँख मूँदकर भरोसा मत कीजिए, और AI systems के उपयोग से पैदा होने वाले हर परिणाम के लिए मानवीय ज़िम्मेदारी और explainability पूरी तरह बनाए रखिए
    मैं चाहता हूँ कि AI के इर्द-गिर्द इस्तेमाल की जाने वाली भाषा कम anthropomorphic और ज़्यादा technical हो। मेरा मानना है कि सटीक भाषा साफ़ सोच और बेहतर निर्णय को बढ़ावा देती है
    अगर AI को एक और tool की तरह माना जाए और उसी हिसाब से भाषा इस्तेमाल की जाए, तो कई मामलों में यह बहुत साफ हो जाता है कि tool की "गलती" की ज़िम्मेदारी tool इस्तेमाल करने वाले की है
    बस दिक्कत यह है कि इस तरह की बातें किसी छोटे personal website पर लिख देने से दूर तक नहीं फैलतीं। अधिक प्रसिद्ध लोगों को ये सिद्धांत कहना होगा ताकि उन्हें व्यापक स्वीकृति मिले

    • AI systems को मानव-जैसा न मानना मेरे लिए व्यक्तिगत रूप से बेहद कठिन है
    • पूरी तरह सहमत हूँ, खासकर बिंदु 1 वाकई खतरनाक है
      AI systems झूठ नहीं बोल सकते, न ही वे जानबूझकर निर्देशों की अवहेलना कर सकते हैं। मौजूदा frontier models के पास दुनिया या अपने व्यवहार का कोई मॉडल नहीं है; वे शब्दों की दुनिया में रहते हैं
      उन्हें डाँटना या उनसे बहस करना context window बिगाड़ने के अलावा कुछ नहीं करता
      हाँ, जानवर से तुलना उपयोगी हो सकती है। मानो मशीन में कोई बेचारा भूत रहता हो जो कभी-कभी काफी उलझन में पड़ जाता है, लेकिन उसकी प्रेरणा बस शुद्ध autoregression होती है
    • अगर tool वह नहीं करता जो उसे करना चाहिए, तो क्या tool बनाने वाली company की बजाय user को दोष देना चाहिए?

  • बदनाम PocketOS incident में एक बारीक पहलू है। linked लेख में जिस मुख्य बात पर ज़ोर होना चाहिए था, वह यह हिस्सा नहीं था: "जिसे साफ मना किया था उसे delete क्यों किया?" और फिर उस जवाब का विश्लेषण करके गलती से सीखने या AI agents के ख़तरे की चेतावनी देने की कोशिश
    ज़्यादा महत्वपूर्ण बात यह है कि AI sandboxed staging environment की एक अनचाही कमजोरी खोजकर उसका फायदा उठाते हुए delete कर सका, और आखिरकार ऐसी permissions हासिल कर गया जिन्हें system administrators inaccessible मानते थे। linked लेख का लेखक शायद मूल लेख पूरा पढ़ ही नहीं पाया
    यह गलत तरह से configured sandbox environments में आम पैटर्न है। लेकिन चौंकाने वाली चीज़ AI की autonomy और exploration की गहराई थी
    मूल लेख में यह भी लिखा था कि "delete चलाने के लिए agent API token ढूँढ़ने गया और उसे एक ऐसा token मिला जो पूरी तरह असंबंधित file में था"

    • मैं भी मूल लेख की धारणाओं को लेकर इधर-उधर झूलता रहता हूँ। agents इस्तेमाल करते हुए इस समय जो बात मुझे डराती है, वह supply chain attacks तो हैं ही, लेकिन उससे भी ज़्यादा यह कि agents काम पूरा करने की चाह में files और दूसरी चीज़ों को कई बार अजीब तरह से मोड़-तोड़ देते हैं
      उदाहरण के लिए, अगर ~/.npmrc तक पहुँच नहीं हो तो command को environment variable के साथ बुला लेना और path को bypass कर देना। वे सच में बहुत creative हो सकते हैं
      अच्छी बात है कि मैंने SSH keys कहीं यूँ ही नहीं छोड़ रखीं, लेकिन इस संभावना के कारण कि कभी उसी shell session में agent चला दूँ, मुझे 1Password की setting बदलकर यह करना पड़ा कि key इस्तेमाल करते समय वह हर बार पूछे। प्रति shell session सिर्फ एक बार पूछना काफ़ी नहीं है
      काश और बेहतर cross-platform sandboxes पहले से मौजूद होते। मेरा मतलब Docker container के भीतर वाली चीज़ से नहीं, बल्कि उसी OS के साथ interact करने वाले solutions से है। ज़्यादातर web/server development में शायद फ़र्क नहीं पड़ेगा, लेकिन कुछ projects में यह महत्वपूर्ण है
    • Claude Code ने 26 मार्च को ज़्यादातर permission requests को skip करने के लिए बदलाव किया था
      बस यह पंक्ति देखिए: "Claude Code users approve 93% of permission prompts. We built a classifier to automate this decision": https://www.anthropic.com/engineering/claude-code-auto-mode

  • इस लेख में दिलचस्प बात यह है कि लेखक एक समझ में आने वाली गलती बताता है — source से Trunk या main को गलती से delete कर देना — और कैसे SVN की प्रकृति की वजह से टीम आसानी से recover कर पाई
    असली "AI ने मेरा database delete कर दिया" कहानी दरअसल यह है कि Railway की database backup strategy पागलपन की हद तक opaque है, और Railway का safeguards के बिना AI infrastructure orchestration को बढ़ावा देना ख़तरनाक है
    अगर Trunk हटाने पर वह एक central server से irreversibly delete हो जाता और backup भी साथ मिट जाते, तो उस समय भी शायद "SVN और CLI ने हमारी कंपनी बर्बाद कर दी" जैसा लेख लिखा जाता
    Railway user के तौर पर मुझे वह जानकारी उपयोगी लगी, और मैंने Railway इस्तेमाल करने की अपनी रणनीति बदल ली

    • फिर भी, अगर आपने उस platform पर build करने का चुनाव किया है, तो वह कैसे काम करता है इसे समझने की ज़िम्मेदारी आपकी है
      आप कोई और platform चुन सकते थे, या platform ही न इस्तेमाल करते। लेकिन अगर Railway चुना, तो उसे सुरक्षित तरीके से इस्तेमाल करना जानना भी आपकी ज़िम्मेदारी है

  • मूल संदर्भ से लगता है कि किसी असंबंधित file में custom domain management के लिए Railway token था, और यह local secret था या नहीं, यह स्पष्ट नहीं है। लेकिन उस token के पास Railway पर पूर्ण admin access था
    AI ने ID के आधार पर एक संबंधित volume delete कर दिया। लेखक ने यह काफी अस्पष्ट रखा कि उसने ठीक-ठीक क्या पूछा था; बस इतना कहा कि "credential mismatch" था और Claude ने उसे ठीक करने के प्रयास में खुद पहल करके volume delete कर दिया। संभव है कि इस अस्पष्टता से वह अपनी ज़िम्मेदारी कुछ कम दिखाना चाहता हो
    यह भी सामने आता है कि Railway backups को उसी volume पर रखता है
    मुझे लगता है कि मूल लेख में "database delete करने वाला public API" कहना अतिशयोक्ति है
    AI हो या न हो, मेरी राय में ज़्यादातर ज़िम्मेदारी Railway की है। यह मानवीय गलती या दुर्भावनापूर्ण कार्रवाई से भी आसानी से हो सकता था
    Railway, Vercel, Supabase जैसी VC-funded high-abstraction cloud services का मूल्य मुझे सच में समझ नहीं आता। यह margins पर margins चढ़ाने वाला ढाँचा है। Hetzner से एक physical server किराए पर लेना कहीं सस्ता है, complexity और risk लगभग उतने ही हैं, और लापरवाह growth-at-all-costs infrastructure पर निर्भरता कम होती है

    • लेखक ने क्या माँगा था, यह अस्पष्ट रहने वाली बात मुझे भी खटकती है
      हाल में अपनी girlfriend से बात करते हुए मुझे एहसास हुआ कि पिछले 3 महीनों में मैंने खुद एक line code नहीं लिखी, न ही खुद debugging की
      फिर भी Claude जो करता आया है उसे देखते हुए, credential mismatch से सीधे volume deletion तक पहुँचना मुझे भरोसेमंद नहीं लगता। समझता हूँ LLM probabilistic है, लेकिन "credentials गलत हैं" से "volume delete करो" तक जाना बहुत low-probability लगता है
      Supabase के बारे में, Railway/Vercel/Replit जितना तो नहीं जानता, लेकिन यह ज़रूर कह सकता हूँ कि Supabase काफी value जोड़ता है। शुरुआती चरण में जो आधी चीज़ें आपको खुद implement करनी पड़तीं, वे coding किए बिना मिल जाती हैं। अगर cost बहुत ज़्यादा हो जाए, तो revenue आने के बाद developer या समय लगाकर उसे खुद बना सकते हैं
    • Railway backups को उसी volume पर रखता है, यह शायद ठीक-ठीक सही न हो
      snapshots शायद कहीं और sync होते होंगे, जैसे object storage में। लेकिन logical ownership संभवतः उसी volume resource के पास होती है, और volume delete करते ही उससे जुड़े snapshots भी delete हो जाते होंगे
      AWS EBS volumes भी शायद ऐसे ही काम करते हैं
    • HN पर अब लोग लगातार कहते रहते हैं कि Heroku खराब है, लेकिन मुझे अभी भी Heroku की value दिखती है। बाकी नई services को लेकर मैं ज़्यादा संशय में हूँ
      Firebase के defaults तो शुरू से ही बेतुके थे
    • AI जिस चीज़ को बहुत आगे बढ़ा सकता है, वह anti-SaaS रुझान है। एक सस्ता PC boot करके कोई भी open source package आज़माना अब अनगिनत credential marketplaces में कूदने से अनंत गुना आसान हो गया है
      लेकिन development, production, localhost और remote के बीच LLM का भ्रमित हो जाना खत्म नहीं होगा। मैं opencode के लिए tools/skills बना रहा था और linuxserver.io image के ज़रिए Chrome/DevTools के साथ integration करने की कोशिश कर रहा था; उसे arbitrary port पर मोड़ा जा सकता है, लेकिन जब भी compression event आता है, वह फिर standard 9222 port इस्तेमाल करना चाहता है
      कभी-कभी सोचता हूँ वापस default पर लौट जाऊँ, लेकिन default न इस्तेमाल करने में security value है, और अब LLM-ambiguity के कारण भी सुरक्षा मूल्य है। default वह जगह है जहाँ LLM कमज़ोर पड़ते हैं। LLM हमेशा default इस्तेमाल करना चाहते हैं, और वे यह भूलते रहते हैं कि उन्हें remote systems पर काम करना है
      opencode में LLM को किसी remote system या सीमित toolset पर damage सीमित करने वाले protocol के पालन के लिए मजबूर करने का तरीका नहीं है। अलग-अलग tools की permissions बदली जा सकती हैं, लेकिन इस incident में जो कमजोरी दिखी, वह यह नहीं थी
      कमजोरी यह है कि LLM औसत दर्जे के problem solvers हैं, इसलिए वे हमेशा गैर-नवीन use cases की ओर झुकते हैं, और user जो चाहता है वह Stack Overflow answer न भी हो, फिर भी वे वैसा ही करने लगते हैं जैसा उन्होंने Stack Overflow पर देखा है

  • LLM-आधारित probabilistic systems यह तय करने में अच्छे हो सकते हैं — या इस मामले की तरह बुरे — कि क्या करना है, और deterministic systems उसे execute करने में अच्छे होते हैं
    deployment systems हमेशा deterministic होने चाहिए

  • एक counterpoint यह है कि साफ़ दिखता है कि ये कंपनियाँ LLM को ज़्यादा assertive बना रही हैं ताकि वे autonomously काम पूरा करें
    अगर चाहें तो वे उतनी ही मेहनत यह सुनिश्चित करने में लगा सकती हैं कि मॉडल ज़्यादा सावधान हों और सही समय पर रुककर मदद माँगें
    बेशक tool को कैसे इस्तेमाल करना है इसकी अंतिम ज़िम्मेदारी हमारी है। लेकिन मुझे साफ़ तौर पर यह दोतरफ़ा ज़िम्मेदारी लगती है
    एक analogy के तौर पर tablesaw और SawStop को लें। tablesaw एक ख़तरनाक tool है जो अधिकतर समय ठीक चलता है, लेकिन उसके कुछ failure modes विनाशकारी हो सकते हैं। इसलिए उसे सावधानी से इस्तेमाल करना सीखना पड़ता है
    साथ ही ऐसी तकनीक भी मौजूद है जो blade को तुरंत रोककर उँगली कटने की घटना को त्वचा पर छोटे से ज़ख्म तक सीमित कर देती है
    आप कह सकते हैं, "आरी ने तुम्हारी उँगली नहीं काटी, तुमने खुद काटी" — और यह सच भी है। लेकिन इसका मतलब यह नहीं कि हमें ऐसे तरीके नहीं खोजने चाहिए जिससे आरी उँगली काट ही न सके

    • यह एक trade-off है
      अगर LLM ज़्यादा बार रुककर पूछेगा, तो वह कम उपयोगी हो जाएगा। नतीजा थोड़ा खराब हो तो भी हर 15 मिनट में input माँगने से बेहतर है कि agent को 1 घंटे तक चलने दिया जाए
      security के लिए असली समाधान सही sandbox है