GDD - "Gaslight-driven development" का युग

 (tonsky.me)
12 पॉइंट द्वारा GN⁺ 2025-07-21 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल के वर्षों में कंप्यूटर उपयोगकर्ता अपनी इच्छा से अलग, बेमतलब के कई काम बार-बार करते रहे हैं और कंप्यूटर जो कहता है वही मानते रहे हैं
  • LLM डेवलपर्स के API design करने के तरीके को प्रभावित कर रहे हैं, और अब ऐसी भविष्यवाणियां भी सामने आ रही हैं कि AI द्वारा सुझाए गए features को डेवलपर्स अपना रहे हैं और जल्द ही ज़्यादातर code AI ही लिखेगा
  • उदाहरण के तौर पर, Soundslice ने ChatGPT द्वारा गलत तरीके से बताए गए feature को वास्तव में जोड़ दिया
  • इसकी वजह यह है कि LLM कई APIs का विश्लेषण करके डेवलपर के दिमाग में सबसे पहले आने वाली intuitive design सुझाते हैं
  • नई ideas या अनोखे approaches विकसित करने में LLM उपयुक्त नहीं हैं, लेकिन ज़्यादातर मामलों में सबसे स्वाभाविक design का पालन करना प्रभावी हो सकता है
  • अब हम ऐसे दौर में प्रवेश कर चुके हैं जहां AI सिर्फ tools का उपयोग नहीं, बल्कि tools को design करने के तरीके को भी lead कर रहा है

Gaslight-driven development

रोज़मर्रा के बेमतलब काम

  • पिछले 10 वर्षों में कंप्यूटर इस्तेमाल करने वाले लोग sign up, email verification, cookie consent, CAPTCHA भरने जैसे मूल रूप से अनावश्यक काम बार-बार करते रहे हैं
  • उपयोगकर्ता यह सब चाहते नहीं थे, फिर भी उन्हें कंप्यूटर के कहे अनुसार चलना पड़ा
  • इन दोहराए जाने वाले कामों के ज़रिए हम पहले ही कुछ हद तक मशीन जो कहे वैसा करने वाली ज़िंदगी के आदी हो चुके हैं

LLM से बदलती development की हकीकत

इस घटना का अर्थ

  • इस बदलाव को सकारात्मक मानें या नकारात्मक, यह तय करना आसान नहीं है
  • एक तरफ, LLM ने असंख्य APIs सीखी हैं, इसलिए वे डेवलपर की नज़र से 'सबसे intuitive' तरीका सुझाने का असर पैदा करते हैं
  • यह newbie’s POV से API को test करने का एक नया तरीका भी है
    • पहले डेवलपर गलती होने पर खुद documentation देखकर उसे ठीक करता था, लेकिन अब LLM लगातार गलत usage examples देकर डेवलपर को भी समस्या जल्दी पहचानने में मदद कर सकता है

सीमाएं और दुविधाएं

  • innovative कामों के लिए यह approach उपयुक्त नहीं है
    • जिन patterns या बिल्कुल नए concepts से LLM परिचित नहीं हैं, उन्हें वे समझ नहीं पाते
  • आखिरकार API जैसे क्षेत्रों में 'साधारणपन' ही सबसे अच्छा हो सकता है
    • ज़्यादातर स्थितियों में जटिल design करने की बजाय, ऐसा रूप बेहतर है जिसे AI और डेवलपर दोनों सहज रूप से समझ सकें

निष्कर्ष: एक नए युग की शुरुआत

  • AI अब सिर्फ दिए गए tools का उपयोग करने तक सीमित नहीं है, बल्कि tools को कैसे design किया जाना चाहिए इस पर भी राय रखने लगा है
  • और यह राय अक्सर डेवलपर्स और संगठनों को gaslighting करते हुए, मानो "हमेशा से ऐसा ही था", उस दिशा में धकेल देती है
  • आगे चलकर AI की expectations और उसकी common sense के अनुरूप development एक स्वाभाविक standard बन सकता है

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

6 टिप्पणियां

 
ffdd270 2025-07-21

कभी-कभी ऐसा लगता है कि path dependency की बड़ी अवधारणा में LLM dependency नाम की एक ताकतवर कील ठोकी जा रही है। 'क्योंकि हम पहले से यही इस्तेमाल करते आए हैं' से 'क्योंकि LLM को यही पसंद है' में जो बदलाव हो रहा है, उसका आखिर नतीजा क्या होगा...
 
kandk 2025-07-21

यह तो पहले से लिखा/इस्तेमाल किया जा रहा था, और LLM ने उसी को सीख लिया था..
 
jujumilk3 2025-07-21

"अब आप कंप्यूटर की पावर बंद कर सकते हैं"
 
rosen 2025-07-21

एकदम परफेक्ट उपमा!!
 
GN⁺ 2025-07-21
Hacker News राय
  • LLM ऐसी API endpoints सुझा रहा है जो असल में मौजूद ही नहीं हैं—ऐसी स्थिति में मैंने सोचा कि उन endpoints को जानबूझकर implement कर दिया जाए और फिर इरादतन 421: Misdirected Request status code लौटाया जाए, या फिर असली 501: Not Implemented भी इस्तेमाल किया जा सकता है; अगर 501 का nuance ठीक न बैठे, तो 513: Your Coding Assistant Is Wrong जैसा नया status code प्रस्तावित किया जा सकता है
    HTTP status code wiki देखें
    • 513: Your Coding Assistant Is Wrong वाला आइडिया बहुत मज़ेदार लगा, इससे काफ़ी आनंद आया; साथ ही मैं HTTP 407 Hallucination भी सुझाना चाहूँगा, यानी server request को समझता है लेकिन तय करता है कि यह वास्तविकता से मेल नहीं खाती
    • यह बात मुझे उस मज़ेदार warning sign की याद भी दिलाती है जो बताता है कि GPS ग़लत है
      GPS is wrong उदाहरण
    • मैं 513 status code लाने के पक्ष में वोट देता हूँ; जब 418 code पहले से है, तो 513 न होने की कोई वजह नहीं लगती
    • अगर ऐसा मज़ाक करना ही है, तो कृपया 418 response इस्तेमाल करें, अच्छा होगा अगर उसका उपयोग और फैले
  • कई users को एक ही page देखता हुआ real time में देखना दिलचस्प है, लेकिन बार-बार अंदर-बाहर आते users के indicators की वजह से पढ़ना बहुत मुश्किल हो गया
    • मेरे bookmarks bar में एक bookmarklet है जो ऐसे fixed या sticky elements को एक साथ हटा देता है; इसे चलाने पर page के ऊपर के सारे fixed/sticky elements गायब हो जाते हैं और scroll भी वापस आ जाता है, इसलिए मैं इसे अक्सर इस्तेमाल करता हूँ
      (JavaScript code दिया गया है)
    • मुझे भी इसी तरह असुविधा हुई थी, इसलिए right-click करके Inspect से developer tools खोला, और नीचे वाला code console में paste करने पर वह user indicator area हट जाता है 
      document.getElementById("presence")?.remove();
      अगर आप सोच रहे हैं कि दिमाग़ इस movement पर इतना संवेदनशील क्यों प्रतिक्रिया देता है, तो इसका संबंध predator detection instinct से है
      science paper link, neuroscience wiki देखें
    • इससे मुझे Chess Royale game याद आ गया; avatars और flags के साथ वैसा ही अनुभव हुआ था, और वह सचमुच बहुत अच्छी तरह बनाया गया game था, लेकिन Ubisoft ने अक्सर की तरह उसकी service बंद कर दी—देखकर अफ़सोस होता है Chess Royale screenshot
    • क्या यह वही page नहीं है जिसकी background में ढेर सारे cursors हुआ करते थे? इस स्तर पर तो यह जानबूझकर distract करने वाला joke-like design concept लगता है
    • uBlock जैसे tools से page elements हटाने की कोशिश करते हुए whack-a-mole जैसा तेज़ी से दोहरता हुआ अनुभव हुआ
  • Instant में tx.update function entity insert और update दोनों संभालता है, लेकिन LLM बार-बार tx.create code लिखता रहा, इसलिए अंत में मैंने tx.create function भी बना दिया; ऐसे भ्रमित करने वाले हिस्सों में शायद सिर्फ़ LLM ही नहीं, असली developers भी बेकार में बहुत समय गंवाते होंगे
    • अगर tx.create पहले से था ही नहीं, तो किसी का समय बर्बाद कैसे होता?
  • अगर कोई function insert और update दोनों support करता है, तो उसका नाम update की जगह put होना चाहिए; update ग़लतफ़हमी पैदा कर सकता है
    • ऐसे case में upsert सही लगता है
    • put नाम मौजूदा content को overwrite करने का संकेत देता है, जबकि upsert insert/update दोनों का अर्थ देता है
  • सिर्फ़ इसलिए कि LLM ने ग़लत text output किया, मुझे code की एक line बदलने से पहले ऐसा लगता है मानो ब्रह्मांड heat death तक पहुँच जाएगा; इतने बेहूदे कारण से code बदलना पड़े, यह विचार मुझे हास्यास्पद भी लगता है और स्वीकार्य भी नहीं
  • मैं post के दावे से सहमत नहीं हूँ; सबसे पहले तो यही सवाल है कि क्या हमें सचमुच computer की इच्छानुसार चलना चाहिए
    users email verification या sign-up इसलिए नहीं करते कि computer ने कहा, बल्कि यह इंसानों द्वारा किया गया design choice था
    • इसे thesis कहना भी मुझे काफ़ी उदार व्याख्या लगता है; वह हिस्सा देखते ही मैंने page बंद कर दिया
  • हाल ही में team के साथ future coding principles पर एक दिलचस्प बातचीत हुई
    आगे चलकर code readability, SOLID principles, या complexity पर ध्यान देने से ज़्यादा महत्वपूर्ण शायद यह होगा कि मेरा agentic IDE code context को कितनी अच्छी तरह index कर सकता है, और model उस code पर कितना अच्छा generation कर सकता है
    code change की speed बहुत तेज़ होने वाली है, इसलिए code maintainability उल्टा एक core metric बन सकती है, और prompt तथा code की alignment या संयोग से अच्छी तरह मेल खा जाने वाले code की usability पर ज़्यादा ध्यान जाएगा—ऐसी दुनिया आने की संभावना लगती है
  • अगर कोई व्यक्ति लगातार आत्मविश्वास के साथ नया—जबकि झूठा—development advice मेरे बनाए product के बारे में फैलाए, तो क्या कोई company सच में उन काल्पनिक features को बस जोड़ देगी और फिर हैरानी जताती हुई blog post लिखेगी—इस पर मुझे संदेह है
    • अगर मैं खुद LLM की तरह बर्ताव करूँ, अजीब ग़लतियाँ करूँ, और फिर भी पूरे confidence से अड़ा रहूँ, तो क्या लोग मुझे भी बस समझ लेंगे?
    • सच कहूँ तो कभी-कभी लगता है कि “Clean Code” के लेखक Mr Martin की शैली कुछ ऐसी ही नहीं है
    • अगर वह व्यक्ति मेरे 90% customers को प्रभावित करता हो, तो शायद मैं सच में वह काल्पनिक feature जोड़ दूँ
    • ज़्यादातर companies शायद पूरे confidence से कहेंगी कि वह बेकार feature वास्तव में ज़रूरी है
  • यह LLM के साथ एक शानदार दोस्ती की शुरुआत जैसा भी लगता है; fractional CTO के रूप में काम करते हुए सबसे निराशाजनक बात यह है कि अलग-अलग clients में environment names जैसे छोटे naming conventions भी पूरी तरह अलग होते हैं
    उदाहरण के लिए AWS में dev, prod हैं, जबकि Expo में test, production हैं; कई projects के बीच आते-जाते हुए इसमें उम्मीद से ज़्यादा दिमाग़ लगाना पड़ता है
    LLM भी शायद इसी समस्या का बहुत बड़े पैमाने पर सामना करता होगा
    अगर API naming/behavior की ऐसी अनावश्यक उलझनों में खर्च होने वाले दिमाग़ी synapses को किसी सचमुच अर्थपूर्ण काम में लगाया जा सके, तो वही सबसे अच्छा होगा
    • computer science में एक मशहूर मज़ाक है कि मुश्किल समस्याएँ तीन हैं—cache invalidation, naming things, और off-by-one errors
      LLM चाहे जितना भी बुद्धिमानी से नाम रखे, चूँकि वह एक incoherent stochastic process पर आधारित है, इसलिए समस्या बनी रहती है
      और मैं यह भी पूछना चाहूँगा कि क्या आपने कभी गंभीरता से सोचा है कि environment naming एक जैसी क्यों नहीं है
      एक पूर्व CTO के रूप में मुझे यह संगठन के भीतर communication, standards की कमी, और सुधार की ज़रूरत का संकेत लगता है
      क्योंकि यह ऐसी चीज़ है जिसे आसानी से सुधारा जा सकता है और इससे culture व टीम की जागरूकता वास्तव में बेहतर हो सकती है, इसलिए इसे LLM पर छोड़ने के बजाय सीधे ध्यान देना चाहिए
  • संबंधित लिंक
    पिछली Hacker News चर्चा देखें
 
dkmin 2025-07-21

Soundslice की वायरल सफलता