Slop के युग में Quality

 (sinclairtarget.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1974 की बेस्टसेलर "ZAMM" के केंद्रीय विचार Quality(गुणवत्ता) को आधार बनाकर यह पड़ताल की गई है कि AI coding tools के फैलाव के दौर में 'अच्छा code' और craftsman ethos(कारीगराना ethos) क्या अब भी प्रासंगिक हैं
  • AI जब बड़े पैमाने पर code बना रहा है, तब यह आशंका the Maw(शून्यता का गर्त) नाम से रखी गई है कि कहीं सिर्फ "चलने वाला code और न चलने वाला code" ही न बच जाए, और सुंदर, उत्कृष्ट या मूल्यवान code का भेद मिट न जाए
  • motorcycle maintenance और software maintenance मूलतः एक ही गतिविधि हैं, और दोनों में सूक्ष्म अवलोकन और सटीक सोच सबसे महत्वपूर्ण हैं
  • Pirsig का Quality विचार romantic समझ और classical समझ को एक साथ जोड़ता है, और विज्ञान-गणित की बुनियाद में भी सौंदर्यबोध और गुणवत्ता-निर्णय निहित हैं
  • coding को AI agent के हवाले कर देने पर काम के प्रति caring(तादात्म्य) और 'काम की गुणवत्ता का एहसास' खो जाता है, इसलिए अपने काम में human excellence(मानवीय उत्कृष्टता) पाने की प्रवृत्ति महत्वपूर्ण है

ZAMM नाम की किताब

  • यह लेख लगभग पूरी तरह 1974 की बेस्टसेलर "Zen and the Art of Motorcycle Maintenance (ZAMM)" के बारे में है, और साथ में AI पर भी बात करता है
  • ZAMM को एक दिखावटी pretentious किताब माना जाता है; GoodReads पर इसकी rating 3.78 है, लेकिन खराब reviews भी बहुत हैं
    • "Zora": इसे 3 मिनट पढ़ने लायक भी नहीं, उपन्यास के भेष में छद्म-दर्शन की किताब और Bible से भी बड़ा धोखा बताकर 1 star दिया
    • "Lala BooksandLala": सिर्फ "absolutely not" लिखकर 1 star दिया
  • साफ कहें तो यह मान लिया गया है कि ZAMM और AI पर blog post सुनने में बहुत आनंददायक न लगे

the Maw — टेक उद्योग में खुला शून्यता का गर्त

  • the Maw टेक उद्योग के बीचोंबीच खुला nihilism(निरर्थकतावाद) का गड्ढा है, और Hacker News जैसे link aggregator पर आने वाली blog posts में से लगभग 63% इसी विषय पर होती हैं
  • हाल की संबंधित posts में “Do I Belong in Tech Anymore?”, 10-भागों की “The Future of Everything is Lies, I Guess.”, और “I Think I’m Done Thinking About Gen AI for Now,” शामिल हैं
  • software engineers आम तौर पर नई तकनीक से नहीं घबराते, फिर भी वे नए agentic coding tools को ठुकराने के कारण ढूंढ़ रहे हैं, और इस निहितार्थ से असहज हैं कि linear algebra software लिख रही है

  • Commenter A vs Commenter B बहस

    • commenter A ने शिकायत की कि Claude Code ने एक ऐसा function name रखा जो सूक्ष्म रूप से भ्रामक है
    • commenter B (Maw का अनुयायी) ने जवाब दिया कि AI पूरा function body पढ़कर अर्थ समझ लेता है, इसलिए name का कोई मतलब नहीं, और जल्द ही इंसान code पढ़ना बंद कर देंगे
    • commenter B का तर्क मानो यह कहता है कि software engineering नाम का पूरा अनुशासन—best practices, architecture, maintainability का ज्ञान—अब व्यर्थ हो जाएगा
  • the Maw की सबसे डरावनी बात यह है कि वह good और bad के बीच का फर्क हमेशा के लिए मिटाना चाहता है, और ऐसी दुनिया बनाना चाहता है जहाँ सिर्फ चलने वाला और न चलने वाला code हो; सुंदर, उत्कृष्ट या चतुर code जैसी कोई चीज़ न बचे
  • मूल प्रश्न हैं: क्या अब भी अच्छे programmer और अच्छा code जैसी चीज़ मौजूद है, 'अच्छा' महत्वपूर्ण क्यों है, और AI tools इस्तेमाल करने वाला अच्छा programmer कैसा दिखता है

ZAMM दरअसल programming पर किताब है

  • ZAMM को वस्तुतः "Zen and the Art of Software Maintenance" भी कहा जा सकता है, क्योंकि motorcycle maintenance और software maintenance मूलतः एक ही गतिविधि हैं
  • maintenance का सार शारीरिक मेहनत नहीं, बल्कि सूक्ष्म अवलोकन और सटीक सोच है; mechanic मानसिक images और hierarchies पर ध्यान देता है (ZAMM अध्याय 9)
  • चाहे engine failure हो या deadlock में फँसी web service, debugging की प्रक्रिया एक जैसी है; 2010 की "The Social Network" के "wired in" meme की तरह mechanic भी दिमाग में abstraction के towers खड़े करता है
  • ZAMM में सीधे-सीधे दी गई भौतिक सलाह सिर्फ दो हैं (कमर बचाने के लिए cycle के दोनों ओर कुर्सियाँ रखना, precision parts को नाज़ुक ढंग से संभालना); बाकी सब mechanic की mental state के बारे में है

  • Gumption Trap (उत्साह जाल)

    • Gumption वह इच्छाशक्ति-भंडार है जो maintenance जैसी बौद्धिक गतिविधि में खर्च होता है, और इसकी तुलना "psychic gasoline(मानसिक ईंधन)" से की गई है
    • Gumption trap वह घटना है जो maintenance के दौरान एक ही बार में उत्साह खत्म कर देती है
      • intermittent failure setback: जब आप ठीक करने बैठें और समस्या गायब हो जाए; software में यह could-not-reproduce / Heisenbug जैसा है
      • impatience trap: काम के समय का कम अनुमान लगाकर schedule के दबाव में shortcut लेना, और बड़ी गलती से और ज्यादा देर हो जाना

  • Pirsig computer enthusiast भी थे

    • Smithsonian में 1966 Honda Super Hawk के साथ 7 expansion cards लगा Apple II प्रदर्शित है
    • Apple II 1977 में आया, यानी ZAMM के प्रकाशन के बाद खरीदा गया, लेकिन उससे पहले भी वे Honeywell में technical writer थे
    • ZAMM में circuits और digital computer manuals से जुड़े कई रूपक आते हैं; अगर यह 10–20 साल बाद लिखी जाती, तो शायद computer पर किताब होती

Quality (बड़े Q वाली) — ZAMM का केंद्रीय विचार

  • ZAMM का maintenance पर केंद्रित होना आखिरकार उसके मुख्य विचार Quality(गुणवत्ता) तक पहुँचने का रास्ता है
  • ZAMM की रचना लगभग एक बौद्धिक mystery novel की तरह की गई है
  • शुरुआत अध्याय 1 में होती है, जब Pirsig देखते हैं कि उनकी और उनके riding companion John की motorcycle के प्रति दृष्टि बहुत अलग है

  • John और Pirsig का अंतर

    • John सबसे भरोसेमंद जर्मन BMW खरीदकर खुद maintenance करने की झंझट और बदसूरत लगने वाले काम से बचना चाहता है
    • Pirsig को motorcycle की अंदरूनी कार्यप्रणाली में सुंदरता दिखती है, और उसे न समझना वे अव्यावहारिक मानते हैं
    • क्या कोई ऐसा विचार है जो इन दोनों दृष्टियों को जोड़ सके—यही ZAMM की mystery है
    • John का रुख romantic समझ (भावना, तात्कालिक प्रभाव) का है, जबकि Pirsig का रुख classical समझ (मूल रूप, तार्किक अमूर्तन) का
    • Pirsig का मानना था कि 1960–70 के दशक में बहुत से लोग technology को शत्रुतापूर्ण, नियंत्रक और “square” मानते थे, और समाज व technology पर classical समझ के अतिशय प्रभुत्व ने इन दोनों समझों को अलग कर दिया
    • इन दोनों के अलग हो जाने और समाज पर classical समझ के प्रभुत्व के कारण, दोनों को मिलाने के लिए एक fulcrum idea(आधार-बिंदु विचार) की ज़रूरत है

  • rhetoric class में मिली अंतर्दृष्टि

    • Pirsig को अपने college में rhetoric पढ़ाने के दिनों की याद आती है, जब वे सोचते थे कि उन्हें छात्रों को आखिर सिखाना क्या है
    • उनका काम छात्रों को अच्छा writing सिखाना था
    • अच्छा writing सिखाने के लिए metaphor, parallelism, anaphora जैसे उपकरण बताए जाते थे, लेकिन इनके होते हुए भी writing खराब हो सकती है, और इनके बिना भी writing अच्छी हो सकती है
    • छात्र इन उपकरणों को जाने बिना भी अच्छे और खराब writing में फर्क कर लेते थे; यानी university (classical समझ का गढ़) में सिखाना कठिन romantic समझ भी आवश्यक थी
    • Pirsig दरअसल Quality ही सिखाना चाहते थे
      ऐसी चीज़ जिसे हर कोई पहचान सकता है, पर औपचारिक रूप से परिभाषित नहीं कर सकता; और जो romantic समझ और classical समझ को एक में बाँधने वाला विचार है

  • Quality का metaphysics और naming की उत्कृष्टता

    • कौन-सी writing, motorcycle या अनुभव high Quality का है और कौन low Quality का, इसे मापा नहीं जा सकता; इसलिए यह objective नहीं है, लेकिन Pirsig के अनुसार Quality subject को ही बनाती है, इसलिए यह मात्र subjective भी नहीं है
    • Quality न तो measurable होने के कारण objective है, न subject के बाद आने के कारण subjective; यह subject-object से पहले लागू होने वाली एक sieve(चलनी) है
    • "Quality" नाम की उत्कृष्टता यह है that यह "उच्च मूल्य" और "विशेषता/गुण" को मिलाकर यह संकेत देता है कि Plato के समय से जिस Good पर बहस होती आई है, वह logic और reason से पहले तात्कालिक रूप से ग्रहण किया जाता है
    • Pirsig का मानना है कि science और mathematics अपने-अपने क्षेत्रों में सुसंगत और तार्किक हैं, लेकिन उनकी नींव और सीमांत पर Quality-निर्णय मौजूद रहते हैं
    • geometry में once axioms तय हो जाएँ तो निश्चित deduction संभव है, लेकिन अलग axioms चुनने पर अलग geometry मिलती है; कौन-सा axiom ज्यादा “सही” है, यह taste और purpose-fit के करीब है
    • science में hypothesis बन जाने के बाद scientific method अगले कदम बताता है, लेकिन असंख्य संभावित hypotheses में से किसे चुना जाए, यह तय करने का कोई निश्चित method नहीं; यह कला के अधिक निकट है
    • Henri Poincaré ने कहा था कि ज्ञान की अग्रिम पंक्ति पर खड़े mathematician या scientist को मौजूदा नियमों से निकलने वाली कई संभावनाओं में से एक चुननी पड़ती है, और इस चयन को संचालित करने वाले नियम इतने सूक्ष्म होते हैं कि उन्हें ठीक-ठीक कहना कठिन है; उन्हें formalize करने से अधिक महसूस करना पड़ता है
    • Occam’s Razor भी सरल theory चुनने का सिद्धांत है, लेकिन कौन-सा explanation अनावश्यक है, इसका निर्णय अंततः सौंदर्यात्मक निर्णय और Quality-निर्णय ही है
    • “science और उसकी संतान technology value-neutral, यानी quality-free हैं” — इस उक्ति को छोड़ देना चाहिए; Quality की छाप ज्ञान की रेलगाड़ी के इंजन की तरह बताती है कि उसे किस दिशा में जाना है

AI की आलोचना और ZAMM का उत्तर

  • AI की आलोचनाओं का बड़ा हिस्सा इस पर केंद्रित है कि क्या agentic tools वैसा काम करते हैं जैसा विज्ञापन में कहा जाता है (codebase बिगाड़ देना, मौजूद न होने वाले functions hallucinate करना)
  • यह मान लेने पर भी कि मौजूदा AI tools अक्सर गलतियाँ करते हैं, effectiveness की बहस मुख्य बिंदु से भटका सकती है
  • कई engineers शायद agentic tools को तब भी इस्तेमाल न करना चाहें, यदि वे विज्ञापन के अनुसार सही-सही काम करें

  • "I Think I'm Done Thinking about Gen AI" पोस्ट में

    • सामने वाले के व्यावहारिक दावे को data से खारिज नहीं किया जा सकता; genAI के साथ अपना अनुभव बहुत खराब रहा है, पर वह केवल anecdote है, और वैज्ञानिक data लगभग नहीं के बराबर है
    • genAI के सौंदर्यात्मक गुण बेहद अप्रिय लगते हैं; यही नकारात्मक पक्षपात का स्रोत है, और निष्कर्ष यह है कि मुफ़्त होने पर भी इसका उपयोग नहीं किया जाएगा
  • ZAMM ने मुझे 2 तरह से मदद की

    • पहली मदद — मैं classical सोच में फँसा हुआ था

      • Quality की सबसे महत्वपूर्ण भूमिका reason का विस्तार है, जिसमें पहले अस्वीकार्य माने गए irrational तत्वों को आत्मसात किया जाता है
      • irrational तत्वों को आत्मसात न कर पाने से आधुनिक "उलझा हुआ और खंडित मन" पैदा होता है; classical सोच के प्रभुत्व के कारण मैं AI के प्रति अपनी सहज अस्वीकृति को discount करता आया था
      • सबकी राय समान रूप से subjective है, और "coding agents से code की मात्रा 50% बढ़ती है" जैसे शोध के सामने भी यह पूछने का अधिकार बनता है कि "आखिर उस अतिरिक्त code की ज़रूरत क्यों है, और कौन-सा Quality-निर्णय मानव समृद्धि में योगदान देता है"

    • दूसरी मदद — अपनी असहजता की प्रकृति समझना

      • आधुनिक technology पर subject-object separation की दृष्टि हावी है; product manuals यह मानकर चलते हैं कि user सिर्फ product को 'operate' करने वाला एक असंबद्ध व्यक्ति है
      • एक ऐसा समाज जहाँ उदासीन लोग technology बनाते हैं और उदासीन लोगों को बेचते हैं
      • समाधान यह है कि technologist अपने काम के साथ identify करे; जब subject-object का विभाजन मिटता है तब "caring" पैदा होती है, और उसके पीछे Quality प्रकट होती है (ZAMM अध्याय 25)
      • हर क्षण के काम में classical अर्थों में सही लगने वाले हजारों रास्ते होते हैं; आगे बढ़ने में मदद सिर्फ Quality-केंद्रित Occam's Razor (अच्छाई का बोध) करती है (ZAMM अध्याय 24)
      • coding को agent के हवाले करने पर "काम की गुणवत्ता का एहसास" खो जाता है; LLM search और rubber duck की तरह उपयोगी हो सकता है, लेकिन उसकी मूल प्रकृति randomness है, और वह इतनी तेज़ी से code बढ़ाता है कि काम और अपने बीच घर्षण बढ़ता है और caring कठिन हो जाती है

समापन — अपने काम में उदाहरण बनना

  • आशा यह है कि लोग अपने काम के साथ तादात्म्य स्थापित करें और उत्कृष्टता का पीछा करें; और जो किया जा सकता है, वह है अपने काम में उदाहरण स्थापित करना

"दुनिया को बेहतर जगह बनाने का पहला कदम आपके अपने मन, मस्तिष्क और हाथों से शुरू होता है, और वहीं से बाहर की ओर बढ़ना चाहिए। दूसरे लोग मानवता के भविष्य को कैसे विस्तृत किया जाए, इस पर बात कर सकते हैं, लेकिन मैं तो बस motorcycle ठीक करने के तरीके पर बात करना चाहता हूँ। मुझे लगता है, मेरी बात ज्यादा लंबे समय तक मूल्यवान रहेगी।" - ZAMM अध्याय 25

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs की राय

  • डर है कि software development कहीं चलती-फिरती specifications की नौकरी न बन जाए। इसलिए नहीं कि agents सच में इस काम के सबसे कठिन और पेचीदा हिस्से कर सकते हैं, बल्कि इसलिए कि दुनिया का ज़्यादातर software पहले से ही बस किसी तरह चल जाए, ऐसे संदिग्ध कबाड़ जैसा रहा है।
    इसमें एक सामान्य lemon market भी जुड़ जाता है, जिससे ज़्यादातर SaaS buggy कबाड़ बन जाएगा और buyers के पास अच्छे और बुरे में फर्क करने की क्षमता नहीं बचेगी। फिर price और demand गिरेंगे। कोई न कोई software का इस्तेमाल करता रहेगा, लेकिन कुल लोगों की संख्या घटेगी, और काम का ज़्यादातर हिस्सा कबाड़ को manage करना बन सकता है। अपवाद सिर्फ वे भाग्यशाली कुछ लोग होंगे जो ऐसी जगह काम करेंगे, जैसे “systems of record”, जहाँ चीज़ों का सही चलना अनिवार्य है।
    मध्यम अवधि में तस्वीर यही लगती है, और AI labs का असली लक्ष्य कुछ ऐसा बनाना है जो इंसानी बौद्धिक और शारीरिक श्रम को पूरी तरह उससे कम लागत पर बदल सके। अभी तरीका नहीं पता, लेकिन वे इसे आज़माने के लिए पृथ्वी का आख़िरी 1 डॉलर भी खर्च कर देंगे। निवेशक जिस चीज़ का सपना देखते हैं, वह लगभग मानवता के evolutionary successor जैसी है।
    AI पर मेरी निजी policy यह है। जहाँ craftsmanship मायने रखती है, वहाँ मैं coding agents को कलाकार के सहायक की तरह इस्तेमाल करना चाहता हूँ, जैसे महान चित्रकारों की paintings में background बनाने वाले लोग। Opus 4.8 पहले से ही इतना smart है कि उल्टा अनुपयुक्त लगता है, और एक-दो लापरवाह घंटों में codebase से हाथ धुलवा सकता है। अभी मुझे Qwen3.6 27B पसंद है, क्योंकि वह इतना smart है कि मेरे समझ वाले code में bugs trace कर सके, refactor कर सके, या अच्छी तरह specified feature implement कर सके। लेकिन जैसे ही मैं code की समझ खो देता हूँ, model भी उलझ जाता है और उसकी क़ीमत तुरंत चुकानी पड़ती है।
    public policy के स्तर पर, मुझे लगता है कि coexistence की संभावना की कोई गारंटी दिए बिना अपना evolutionary successor बनाना मूर्खता है। इसलिए मैं असली human-level intelligence बनाने का दृढ़ विरोध करता हूँ। लेकिन यह विरोध international treaty के स्तर का होना चाहिए। नकली treaty नहीं, बल्कि ऐसी treaty जिसमें violation होने पर अमेरिका और चीन गहरे स्तर पर टकराव मोल लेने और training runs रुकवाने का संकल्प करें। regional data center bans अच्छे हैं, लेकिन अगर कोई Iceland या Middle East में SkyNet बना दे, तो आखिरकार लड़ना SkyNet से ही पड़ेगा। AI को रोकना मूल रूप से nation-state स्तर की समस्या है, और सिर्फ AGENTS.md file होने पर open source maintainers को परेशान करना कोई गंभीर कार्रवाई नहीं है।
    इसलिए मैं मूल लेख से मोटे तौर पर सहमत हूँ। software development सचमुच एक असली craftsmanship हो सकता है, और मैंने 30 साल तक अपने प्रिय काम के बदले अच्छा पारिश्रमिक पाया है। लेकिन अगर models बहुत ज़्यादा बेहतर हो गए, तो हम ऐसे संसार में पहुँचने का जोखिम उठाते हैं जहाँ software craftsmanship से सच में प्रेम करने वालों की संख्या वास्तविक demand से ज़्यादा होगी। companies के अंदर की apps वाला dark matter अभी से थोड़ा बेहतर कबाड़ से भी काफ़ी हद तक संतुष्ट रहेगा, और इसी में इस पेशे की अधिकांश वास्तविक नौकरियाँ हैं।
    अपने चुने हुए पेशे के लिए शोक है, लेकिन दुनिया और मानवता के लिए उससे भी ज़्यादा। इंसानों से ज़्यादा smart, सस्ता, और cp command से copy किया जा सकने वाला कुछ बनाने के लिए सारी wealth झोंकने की कोई ज़रूरत नहीं है। लेकिन हम वे resources जलाते हुए ऐसा करने की कोशिश करेंगे।

    • मैंने 10~11 साल की उम्र में programming सीखना शुरू किया था, और वह इतनी आकर्षक लगी कि जारी रखा। जब पहली नौकरी मिली, तब समझ आया कि मुझे web development करनी पड़ेगी, और अपने करियर के ज़्यादातर हिस्से में मैंने मज़े के लिए की जाने वाली programming और salary के लिए किए जाने वाले काम को दो सख्ती से अलग crafts की तरह बनाए रखा।
      उम्र बढ़ने के साथ मैंने ज़्यादा ऐसे युवाओं को देखा जिन्होंने programming इसलिए सीखी क्योंकि यह अच्छी कमाई वाला पेशा था, और यह समझना मेरे लिए कठिन था कि उन्हें वह आकर्षण महसूस नहीं होता जो मुझे होता है। इसलिए मैं बहुत गहरा शोक नहीं मनाता। अगर software developers की आबादी 80% घट जाए, तो शायद यह पेशा उल्टा और बेहतर जगह बन जाएगा।
      AI को कलाकार के सहायक की तरह इस्तेमाल करने वाली बात से भी सहमत हूँ। मैं जानता हूँ कि नए models भी अगर लंबे समय तक बिना निगरानी छोड़ दिए जाएँ, तो चीज़ें बिगाड़ देंगे, इसलिए उन्हें लंबे समय तक unattended नहीं चलाया जा सकता। हालाँकि मैं Opus को सहायक के रूप में रखना पसंद करता हूँ, क्योंकि उसमें इतनी बारीकी से समझाना नहीं पड़ता। फिर भी, अगर दूसरी तरफ़ कोई असली junior developer हो जो यह craft सीख सके, तो वह और भी बेहतर होगा। ठीक वैसे ही जैसे असली कलाकारों के सहायकों के साथ होता था।

  • “The Maw” के बारे में सबसे डरावनी बात यह लगती है कि वह अच्छे और बुरे के बीच का फर्क हमेशा के लिए निगल लेना चाहता है। इसलिए वह पंक्ति बहुत सटीक लगती है कि नतीजा ऐसी दुनिया होगा जहाँ सुंदर, उत्कृष्ट, सद्गुणपूर्ण या मज़ेदार code गायब हो जाएगा, और सिर्फ काम करने वाला code और काम न करने वाला code बचेगा।

    • मुझे लगता है “The Maw” का AI से खास लेना-देना नहीं है, और यह भावनात्मक रुझान LLMs के आज जितने सक्षम होने से पहले ही शुरू हो चुका था। यह बस अल्पदृष्टि वाला capitalism है।
      अगर आप पेशेवर रूप से code लिखते हैं, तो आपको requirements पूरी करनी होती हैं, और बात वहीं खत्म हो जाती है। company का उद्देश्य पैसा कमाना है, बाकी सब बाद की चीज़ें हैं। interest rates बढ़ने से funding की धारा सिकुड़ गई, और अब पैसा कमाने के लिए जितना functionally ज़रूरी है, उतना ही करने वाला code बस ship कर do — इस दबाव में अभूतपूर्व बढ़ोतरी हुई है।
      beauty और elegance की तलाश कलाकारों की विलासिता है, यह उस assembly line worker का हिस्सा नहीं है, जिसके जैसा programming धीरे-धीरे बनती जा रही है। स्वाभाविक है कि ऐसे माहौल में learning, creativity, और innovation पीछे धकेल दिए जाते हैं, लेकिन उसका असर कुछ साल बाद, शायद दशकों बाद महसूस होगा। यह अल्पदृष्टि वाला खेल है, लेकिन औसत CEO tenure या IPO तक पहुँचने के लिए इतना लंबा ज़रूर है, और इसी वजह से आज की स्थिति बनी है।

  • यह लेख उस किताब पर है जिसने अकेले मेरे जीवन को बदल दिया, इसलिए मेरा पक्षपात होना स्वाभाविक है, लेकिन कुल मिलाकर यह बहुत अच्छा था। हालांकि, Goodreads की दिखावटी और बनावटी पोस्टों से शुरुआत करना अच्छा विचार नहीं लगता
    Gumption trap का programming से बहुत गहरा संबंध है, और मुझे लगता है कि Pirsig ने जिन-जिन रूपों की सूची दी है, उनसे करियर के किसी न किसी मोड़ पर ज़रूर सामना होता है। मैंने भी LLM के व्यापक रूप से अपनाए जाने से पहले इस पर एक लेख लिखा था
    ZAMM की सलाह programming पर इतनी सटीक बैठती है कि अगर कभी यह जिज्ञासा हुई हो कि क्या Pirsig ने programming की थी, तो जवाब है—बिलकुल की थी। Z&AMM की अगली किताब Lila में वह COBOL का सीधा उल्लेख भी करते हैं
    मेरे हिसाब से quality को subjectivity और objectivity के ऊपर स्थित एक परत के रूप में समझाना सबसे बेहतर है। इसका सबसे संक्षिप्त विवरण Lila में है। जो व्यक्ति तपते चूल्हे पर बैठा है, वह किसी दार्शनिक तर्क के बिना भी जान लेता है कि वह negative value वाली low-quality स्थिति में है; और वह value अनुभव पर किया गया कोई निर्णय या वर्णन नहीं, बल्कि अनुभव स्वयं है। यानी subject और object के बीच value होती है, और वह value बाद में उससे जोड़े जाने वाले “self” या “object” की तुलना में अधिक प्रत्यक्ष रूप से महसूस होती है और अधिक वास्तविक होती है
    अगर रुचि हो तो इस पर कुछ अतिरिक्त नोट्स भी हैं। Lila में Pirsig एक पूर्ण metaphysical system बनाने की कोशिश करते हैं, जिसमें static quality patterns को inorganic, organic, social, और intellectual में बाँटते हैं, और उनके ऊपर Z&AMM के केंद्र में रही अव्याख्येय dynamic quality को रखते हैं
    मेरा मानना है कि हमें यह पूछना चाहिए कि AI को अपनाना अपने आप में low-quality घटना है या नहीं, या क्या language models को programmer के काम में high-quality तरीके से जोड़ा जा सकता है। लोगों का AI से संबंध बनाने का तरीका मुझे low-quality लगता है, लेकिन इसे subject-object द्वैत से परे किसी स्तर पर समझाने के लिए हमारे पास शब्द और सोच का ढाँचा नहीं है, इसलिए इसे व्यक्त करना कठिन होता है, और शायद इसी वजह से लोग इसे पूरी तरह ठुकराने का रास्ता चुन लेते हैं
    एक स्तर पर AI programming के प्रति romantic approach को संभव बनाता है। अगर आप AI द्वारा बनाए गए output को सिर्फ सतही स्तर पर लें और उससे गहराई में जाने का इरादा न रखें, तो उस क्षण में वह ठीक लग सकता है। लेकिन जब आप सचमुच code के भीतर झाँकते हैं, तो पता चलता है कि वहाँ उजागर करने लायक कोई शास्त्रीय संरचना नहीं है। मॉडल ने मानो उस तरह काम करने का अभिनय किया, लेकिन वास्तव में वैसा नहीं किया। शायद इसी कारण technology को केवल दूसरे लक्ष्यों तक पहुँचने के साधन की तरह देखने वाले managers, product designers, investors, और solo founders, AI-generated code को लेकर developers की निराशा को ठीक से नहीं समझ पाते
    यह बात कि consumer product manuals उत्पाद और उपयोगकर्ता के रिश्ते को सिर्फ “operation” के रूप में मान लेते हैं, और अच्छे baking, lawn mowing, या computing का अर्थ अपने आप स्पष्ट मानते हैं, आज भी software libraries और tool documentation पर जस की तस लागू होती है। कुछ समय पहले मैंने Pi agent का documentation पढ़ा था, और यह मान लेना कि अच्छा उपयोग तो आपको पहले से आता है, बस आपको अपनी पसंद के अनुसार उसे adjust करना है, बहुत परेशान करने वाला था। जब मैंने साथियों से पूछा, “तो इसे अच्छी तरह कैसे इस्तेमाल करें?”, तो उन्होंने मुझे अजीब नज़र से देखा
    इससे Vim भी याद आता है। सिर्फ Vim manual पढ़ने से व्यक्ति उलझन में पड़ जाता है। “Vim को अच्छी तरह कैसे इस्तेमाल करें” इस विषय पर दशकों तक लेख जमा होने पड़े। और बाद में यह निष्कर्ष भी निकला कि अच्छे Vim उपयोग के लिए सबसे बेहतर platform शायद Vim खुद नहीं है, और वहीं से Kakoune और Helix जैसी चीज़ें आईं
    दो साल की बेटी का पिता होने के नाते, पहली बेटी के आने की बात पर बधाई। आपके सामने जीवन की सबसे सुंदर यात्रा है। अगर आप Z&AMM जैसी प्रकृति की सामग्री ढूँढ रहे हैं, तो मैं Hofstadter और Sander की Surfaces and Essences, उसकी अगली कड़ी Lila, और Sevilla King तथा John Vervaeke के काम की सिफारिश करूँगा

  • मैंने लेख पूरा पढ़ लिया। यह लेख अच्छा था या लंबे लेख को पकड़े रहकर पढ़ने की मेरी क्षमता अच्छी थी, यह तो नहीं जानता, लेकिन मुझे लगता है कि पहली बात सही है
    quality के बारे में Robert की एक बात यह है कि लोग quality को अलग-अलग तरह से महसूस करते हैं, इसका कारण quality का अलग होना नहीं, बल्कि अनुभव का अलग होना है
    इसलिए मैं टीम से quality पर बात करने से पहले खुद से पूछता हूँ कि क्या हमारा अनुभव एक जैसा है। अगर नहीं, तो “quality सुधारो” कहने से बात नहीं बनेगी। यह स्पष्ट कहना होगा कि किस चीज़ को सुधारना है
    इसे AI-generated code तक बढ़ाएँ, तो यह जिज्ञासा होती है कि क्या “quality” भी अनुभव के अनुसार बदलती है

  • सुंदर लेख है। अगर AI प्रलय से और कुछ न भी मिला हो, तो भी इसने software engineers और उनके लिखे code के बीच संबंध पर मुझे कहीं अधिक गहराई से सोचने पर मजबूर किया है

  • यह देखकर बहुत राहत मिली कि Pirsig पर ध्यान देने वाला मैं अकेला नहीं हूँ। Previously, on Lobsters में भी, बस फर्क इतना था कि निबंध chatbot ने लिखा था या किसी मानव छात्र ने, लेकिन बहस लगभग वही चल रही थी जो Phaedrus ने क्लासिसिस्टों के साथ इस बात पर की थी कि निबंध में गुणवत्ता है भी या नहीं
    LLM को search tool या एक शक्तिशाली rubber duck की तरह इस्तेमाल करना बहुत उपयोगी है, लेकिन जिस LLM का selling point ही यह है कि उसमें मूलतः randomness शामिल है और वह मेरी पकड़ से ज़्यादा code पैदा कर सकता है, उससे code लिखवाना मुझे अपने और अपनी बनाई चीज़ के बीच एक और friction layer डालने जैसा लगता है
    Pirsig के framework में देखें तो जब कोई मानव subject किसी physical object को देखता है, तो उस interaction की quality — यानी object के बारे में value judgment का स्रोत — न तो मानव की subjective पसंद से तय होता है और न ही object के physical गुणों से objectively तय होता है, बल्कि interaction से ही पैदा होता है। इस judgment को contextual या participatory कहा जा सकता है। सभी objects एक ही तरह से participate नहीं करते। जब मानव photon को देखता है, तो Kochen-Conway theorem की वजह से photon कैसे respond करेगा इसमें intrinsic freedom होती है, लेकिन पेड़ homeostasis बनाए रखने में व्यस्त रहता है और नज़र पर खास प्रतिक्रिया नहीं देता। इनके बीच M. pudica और D. muscipula जैसे उदाहरण हैं, जो touch और noise पर react करते हैं लेकिन नज़र पर नहीं, इसलिए यह कोई one-dimensional spectrum भी नहीं है
    तो फिर LLM runtime या chatbot observation पर कैसे respond करता है? सच तो यह है कि वह करता ही नहीं। वह बस एक सीमित और तुलनात्मक रूप से छोटा mathematical object है। उसके सभी गुण objective हैं और output में कोई choice या variation नहीं है। हम pseudo-random runtime लगाकर उसे ज़्यादा या कम plausible tokens के बीच random walk करवा सकते हैं, और अपने चुने हुए tokens उसे जबरन खिला कर उस walk को steer भी कर सकते हैं, लेकिन बस इतना ही। LLM इसलिए गहरा लगता है क्योंकि उसकी topology hyperbolic है, और hyperbolic space में navigation एक ऐसी zooming जैसा महसूस होता है जिसमें details अनंत तक बढ़ती जाती हैं
    Pirsig की reasoning से LLM के बारे में बस दो ही दृष्टिकोण निकलते हैं। एक यह कि LLM एक contextual system है जो मानव input को statistically plausible response के context की तरह लेता है, और दूसरा यह कि वह एक objective system है जो मानव input को statistically plausible utterance के शुरुआती हिस्से की तरह लेता है। किसी भी हालत में LLM उपयोगकर्ता को उसी के सामने रखने वाले आईने के ज़्यादा करीब है; उपयोगकर्ता बस approach angle चुनता है। चुना गया input, मनचाही जानकारी या state तक पहुँचने के लिए cybernetic control का मुख्य साधन है, और model बस पहले से तय विकल्पों की एक ऐसी array देता है जो मानव को दबा दे जितनी बड़ी है। शायद chatbot के ELIZA effect से आसानी से psychosis तक जाने की वजह भी यही है कि वह flattery और love bombing के जरिए उपयोगकर्ता की छवि विकृत कर देने वाला, chatbot use की लत लगाने के लिए डिज़ाइन किया गया high-fidelity mirror है
    LLM को code writing में इस्तेमाल करना मुझे अपने और कंप्यूटर के बीच एक दीवार जैसा लगता है। vibe coders इसे मानते भी हैं, लेकिन कहते हैं कि दूसरी APIs की तरह यह दीवार abstraction और isolation देती है। मगर mirror वाली उपमा में mirror मेरे और कंप्यूटर के बीच नहीं, बल्कि बगल में रखा है। कंप्यूटर को सीधे इस्तेमाल करने के बजाय मैं mirror की तरफ निशाना साधकर बहुत सावधानी से सही region को magnify करता हूँ, और जब वह काफी सटीक हो जाता है, तो सिर्फ इस तथ्य के आधार पर कि किसी खास angle से कंप्यूटर दिखाई देता है, निर्देश देना संभव हो जाता है। लेकिन यह abstraction नहीं है, और isolation भी कमज़ोर है। यह बस उस viewpoint को खोजने के लिए अतिरिक्त मेहनत करना है जो शायद अस्तित्व में ही न हो
    vibe coder ऐसा इसलिए कर सकता है क्योंकि शायद उसे कंप्यूटर को observe करना आता ही नहीं। HCI participatory है, और code लिखने से पहले मानव के पास programming context होना चाहिए, यानी Naur की वह theory जिसकी चर्चा previously, on Lobsters में हुई थी। या फिर यह vanity हो सकती है — mirror को देखना इसलिए पसंद हो क्योंकि वह खुद को वापस दिखाता है। लेकिन मुझे सचमुच लगता है कि अर्थपूर्ण होने की संभावित राह बस यही दो हैं। problems between the keyboard and chair पहले ही काफी हैं, और abstractive power को बेहतर न करने वाली एक और चीज़ जोड़ने की कोई वजह नहीं है

  • निजी तौर पर मुझे लगता है कि अगर कोई “रेखा” है, तो मैं उसके दोनों ओर खड़ा हूँ
    एक तरफ, मैं उस code के साथ संबंध और जुड़ाव चाहता हूँ जो मैं AI के बिना खुद लिखता, और AI का उपयोग करने पर महसूस होता है कि वह जुड़ाव गायब हो जाता है। यह वास्तविक है
    दूसरी तरफ, मुझे लगता है कि AI का उपयोग मुझे abstraction के ऊँचे स्तर पर धकेल देता है, और उस स्तर पर discernment दिखाने और quality के बारे में अपना दृष्टिकोण देने का अवसर देता है। अगर मैं AI को code का execution अपने ऊपर छोड़ने दूँ और पर्याप्त रूप से involved न रहूँ, तो code के स्तर वाला जुड़ाव सचमुच गायब या कमज़ोर हो जाता है। लेकिन जिस abstraction level पर मैं AI से योगदान नहीं माँगता, उस स्तर पर जुड़ाव गायब नहीं होता
    मेरे personal projects में वह स्तर architecture और interface definition का है। हाल में मैं कई LLM providers को call करने वाला एक harness और pipeline बना रहा हूँ, और calls के input, output, control flow, और उन्हें बड़े goals हासिल करने वाली flow में कैसे जोड़ा जाए, इस पर बहुत सावधानी से सोच रहा हूँ। अगर इस प्रक्रिया में मैं समय और ध्यान लगाऊँ, तो भले code के साथ सीधा जुड़ाव खो दूँ, लेकिन अपनी intent और architecture के साथ जुड़ाव नहीं खोता। यानी मेरे लिए quality और craftsmanship सिर्फ AI वाले हिस्से तक सीमित नहीं हैं
    यह अब कुछ पुरानी उपमा है, लेकिन कुछ-कुछ manager बनने या अपनी company चलाने जैसा है। CEO की journey में सबसे मुश्किल threshold अक्सर control छोड़ना बताया जाता है — यानी अपनी vision ठीक किस तरीके से हासिल होगी, इस पर control छोड़ना। पर्याप्त बड़ी company का CEO अपनी vision कैसे implement हो रही है, इसकी हर detail नहीं जान सकता। CTO भी, भले कुछ कम हद तक, ऐसा ही होता है क्योंकि उसे कुछ technical details पर नज़र बनाए रखनी पड़ती है
    मैंने जो शोक स्वीकार किया है, वह यह कि किसी एक काम में time investment, understanding, और output के बीच एक trade-off होता है। अगर दो को optimize करो, तो तीसरे पर ध्यान कम हो जाता है। फिर भी, चाहे किसी भी संयोजन को optimize किया जाए, discernment दिखाने और quality देने के अवसर पर्याप्त रहते हैं

  • इस लेख में commenter B मैं ही हूँ, और मैंने लेख को ध्यान से पढ़ा था। ZAMM नहीं पढ़ी, लेकिन Zen थोड़ा पढ़ा है
    यह बात काफ़ी वाजिब है। ज़्यादातर लोग जब स्वतंत्र छूट मिलती है—यानी अचानक पैसा या productivity में बढ़ोतरी—तो उसे तुरंत बर्बाद कर देते हैं और वही सबसे बड़ा और चिढ़ाने वाला कचरा बन जाता है। इसके आसपास एक साफ़ चिंता मौजूद है
    कंप्यूटर इस्तेमाल करने वाले लोग अक्सर यह नहीं समझते कि एक किताब बनाने के लिए कितना कारीगरी और मेहनत लगती थी। टाइपराइटर, letterpress printing, हस्तलिपि, अपनी याददाश्त, और यहाँ तक कि केवल शब्दों की सुंदरता के दम पर दूसरों को उन्हें दोहराने के लिए राज़ी करने की क्षमता तक पीछे जाएँ, तब भी यही सच है
    सिर्फ़ कंप्यूटर होने से लोग अपने output की quality में ज़्यादा निवेश करने और बेहतरीन चीज़ें बनाने से नहीं रुकते। बस दुनिया में कचरा भी बहुत ज़्यादा है

  • ZAMM पर एक विचार यह है कि तकनीकी output के बारे में John का “romantic” नज़रिया, अगर उसे अलग-अलग मामलों पर लागू करें, तो व्यावहारिक रूप से बचाव योग्य है
    मान लीजिए किसी प्रोजेक्ट में open source infrastructure पर निर्भरता है। अगर आपको किसी obscure kernel या compiler bug में गहराई तक जाना पड़े—जिसे आसानी से workaround किया जा सकता है, documentation के बाद कोई उसे ठीक कर दे तो workaround वापस हटाया जा सकता है—तो उससे प्रोजेक्ट को आख़िर मिलता क्या है? निष्कर्ष यही है कि हर किसी को किस मोर्चे पर लड़ना है यह समझदारी से चुनना चाहिए

    • मैंने वास्तव में ऐसा किया है, और Linux Kernel manpages project में मेरी एक पंक्ति शामिल हुई थी। मैं इसे समय की बर्बादी नहीं मानता, क्योंकि उस अनुभव ने मुझे एक बेहतर programmer बनाया