AI हमें 'glue' बना रहा है

• AI tools डेवलपर के कुछ मुख्य कामों की जगह ले रहे हैं, और इंसान ‘problem solver’ से खिसककर ‘connector’ की भूमिका में जा रहा है
• "vibe coding" की तरह ऐसा भविष्य दिखाया जा रहा है जहाँ implementation AI करेगा और इंसान सिर्फ ideas देगा, लेकिन हकीकत अभी भी जटिल है
• डेवलपर AI की आँख और हाथ बनकर defects पहचानने या settings छेड़ने वाले 'plumber' तक सिमट सकते हैं
• समय के साथ यह काम भी AI ले सकता है, और इंसान भौतिक दुनिया और AI को जोड़ने वाले 'glue' तक सिमट सकता है
• यह लेख उस भविष्य को लेकर बेचैनी और संदेह व्यक्त करता है जहाँ रचनात्मकता और स्वायत्तता खो चुका मानव श्रम ‘glue’ जैसी मौजूदगी में बदल जाता है

---

शायद बात ऐसी नहीं होगी

मैं AGI से डरना छोड़कर उससे प्यार करना सीखने की कोशिश कर रहा हूँ, लेकिन सच कहूँ तो मन थोड़ा उदास है।

मैं software बनाता हूँ, और इस समय मेरे जानने वाले लगभग हर व्यक्ति की तरह मैं भी LLM का इस्तेमाल करके अपने काम की रफ्तार बढ़ा रहा हूँ.
कल o3 रिलीज़ हुआ, और उसने पहले ही एक जटिल bug सुलझाने में मेरी बहुत मदद की।
पहले यह ऐसा मसला होता जिसमें मुझे बहुत trial and error करना पड़ता, लेकिन इस बार मैं बहुत कम भटका और हल तक पहुँच गया।
ऊपरी तौर पर यह अच्छी बात लगती है। लेकिन समस्या क्या है?

समस्या यह है कि मुझे ऐसे जटिल bugs सुलझाना पसंद है!
यह किसी puzzle जैसा होता है, और उसमें गहराई तक जाते हुए कंप्यूटर के वे हिस्से सीखने को मिलते हैं जो आम तौर पर नज़र नहीं आते।
Refactoring भी ऐसा ही है—जब वह अच्छी चल रही हो, तो मैं अपने system की बनावट को और गहराई से समझता हूँ और उसे structure में ढालता जाता हूँ।
ऐसी समस्याएँ सुलझाना दिमाग को खुजला देने वाली सुखद उत्तेजना जैसा है।
पता नहीं यह मेरे काम का सबसे rewarding हिस्सा है या नहीं, लेकिन यह मेरा सबसे पसंदीदा हिस्सा ज़रूर है।

हम अभी उस बिंदु तक नहीं पहुँचे हैं, लेकिन माहौल पहले ही तय हो चुका है।
बहुत conservative अंदाज़े से भी देखें, तो अगले 10 सालों में ज़्यादातर 'ठोस समस्याओं पर गहराई से सोचने' वाला काम कंप्यूटर मुझसे बेहतर करने लगेगा।

जब इस काम से उस भूमिका को काटकर अलग कर देते हैं, तो दो ऐसे हिस्से बचते हैं जो लगभग एक-दूसरे को छूते ही नहीं।
जहाज़ चलाने वाला, और पाइप जोड़ने वाला (रूपक गड़बड़ा गए हों तो माफ़ कीजिए)।
AI को लेकर उत्साहित लोगों की बातें सुनो, तो लगभग हर कोई पहले वाला बनने को लेकर रोमांचित है।
“vibe coding”[1] का वादा यही है—काम की सबसे ऊपरी layer, यानी taste, ideas, design, philosophy जैसी चीज़ों पर ही ध्यान देना होगा, और बाकी सब machine खुद कर देगी।
तर्क यह है कि तब इंसान सिर्फ वही काम कर पाएगा जो इंसान ही कर सकता है।

मेरे पास भी कुछ ideas हैं, और सच कहूँ तो ऐसा संसार इतना बुरा भी नहीं लगता.[2]
लेकिन मेरे अनुभव में, यह कहानी जटिल हकीकत का सिर्फ आधा हिस्सा बताती है।
उदाहरण के लिए, अगर मैं किसी agent को tools के साथ इस्तेमाल कर भी रहा हूँ, तब भी जो समस्याएँ system नहीं देख पाता, उन्हें आखिरकार इंसान ही देखता है।
मान लीजिए मैं एक web application बना रहा हूँ। Claude Code ने मेरे निर्देशों के अनुसार style लिख दिया।
लेकिन वह असली browser में कैसा दिखता है, यह देखना आखिरकार मुझे ही पड़ता है।
और स्वाभाविक है कि कुछ न कुछ अजीब दिखता है। क्योंकि CSS ऐसी ही होती है।
और क्योंकि वह style मैंने खुद नहीं लिखी, वह मुझे अपरिचित लगती है, इसलिए सबसे आसान समाधान फिर वही होता है कि उसे वापस Claude के पास ले जाकर फिर चलाया जाए।
फिर request करो, फिर बदलाव करवाओ। Bug report लिखना, bug ठीक करने से कहीं कम मज़ेदार है,
और अंत में मैं सिर्फ Claude को अपने कंप्यूटर के आसपास देखने के लिए “आँख” देने वाली भूमिका में रह जाता हूँ।

बेशक कोई इस पर आपत्ति कर सकता है: “ऐसी cyber-plumbing वाली भूमिका भी जल्द गायब हो जाएगी।”
हाँ, frontier labs अभी भी पूरे कंप्यूटर को संचालित कर सकने वाले agents बना रही हैं।
वे browser tabs खोलने और स्क्रीन देखने जैसे काम शायद मेरे जितने अच्छे से करने लगेंगी।
लेकिन अभी AI की spatial reasoning काफ़ी खराब है, इसलिए ईमानदारी से कहूँ तो फिलहाल थोड़ा-सा safety moat[3] महसूस होता है।
फिर भी, plumbing वाला काम कुछ समय तक बना रहेगा।
जैसे एक platform से दूसरे platform तक logs की pipeline बनाना,
या storage bucket की access policy सेट करना ताकि agent ठीक से files लिख सके।
ऐसे काम मेरी job security के लिए तो अच्छे हैं, लेकिन सच कहूँ तो मुझे ज़्यादा पसंद नहीं हैं।
मैं प्रोजेक्ट के core idea पर सोचना पसंद करूँगा, न कि किसी nवीं cloud service का 2FA code ढूँढ़ता फिरूँ।
लेकिन आगे चलकर यह समय भी “glue-जैसे काम” के मुकाबले justify करना मुश्किल होता जाएगा।

अच्छी (…क्या सच में?) ख़बर यह है कि ऐसी भूमिकाएँ भी जल्द AI को सौंप दी जाएँगी।
जब वह समय आएगा, तो मैं AI और वास्तविक दुनिया[4] के बीच एक कड़ी जैसा रह जाऊँगा।
कुछ समय तक, अगर मैं hardware projects करूँ, तो jumper wires को breadboard में लगाना या antenna से छेड़छाड़ करना अभी भी मेरा काम होगा।
मुझे इस तरह का हाथ से किया जाने वाला काम पसंद है, लेकिन अगर पूरे game plan को कंप्यूटर ही जानता हो… तो उसमें मज़ा कम रह जाएगा।
किस्मत अच्छी रही तो शायद मैं जहाज़ का “idea captain” बन सकूँ।
लेकिन अगर वह captain भी ऐसा हो जिसे जहाज़ कहाँ जाना चाहिए, यह AI से पूछना पड़े, तो वह भूमिका भी ज़्यादा दिन नहीं टिकेगी।
और सच कहूँ तो, मुझे नहीं लगता कि हर इंसान अपने-अपने जहाज़ का captain बनकर रोज़ी-रोटी कमा सकेगा।

उसके बाद क्या होगा, मुझे बिल्कुल नहीं पता।
अस्तित्वगत जोखिम को अभी एक तरफ़ भी रख दें, तब भी यह साफ़ दिखता है कि बहुत-सी नौकरियाँ गायब हो जाएँगी।
आशावादी परिदृश्य यह है कि हम ऐसे नए काम बनाएँगे जिनकी अभी हम कल्पना भी नहीं कर सकते,
और उनके ज़रिए लोग पहले से कहीं ज़्यादा आत्मसिद्धि हासिल करेंगे।
लेकिन ऐसी दुनिया में जहाँ superintelligence एक commodity की तरह उपलब्ध हो,
मुझे डर है कि वे नए काम भी आखिरकार 'सिर्फ जोड़ने वाले glue जैसे काम' ही लगने लगें।

---

1. अलग से कहूँ तो, "vibe coding" वाला मुहावरा थोड़ा खटकता है।
   लेकिन अब जब इसका Wikipedia article भी है, तो लगता है यह अब industry term बन चुका है।

2. इस तरीके के फायदे इतने स्पष्ट हैं कि उन्हें अलग से समझाने की ज़रूरत भी नहीं।
   अभी बहुत-से लोग ऐसी चीज़ें बना रहे हैं जिनकी पहले कल्पना भी नहीं की जा सकती थी।

3. ईमानदारी से कहूँ तो, मैंने कभी यह नहीं सोचा कि ‘arrows जोड़ना’ मेरी मुख्य विशेषज्ञता है।

4. थोड़ा और सामान्य रूप से कहें तो, screen के अंदर की intelligence की तुलना में robotics की प्रगति अपेक्षाकृत धीमी है,
   इसलिए कुछ समय तक इंसान का ‘भौतिक शरीर वाला अस्तित्व’ मशीनों पर एक बड़ा advantage बना रह सकता है।
   शाब्दिक अर्थ में plumber (विडंबना यह है कि उनका काम ऊपर बताई गई ‘digital plumbing’ की तुलना में bug fixing के ज़्यादा करीब हो सकता है)
   अभी कुछ समय तक ठीक रहेंगे, और दूसरे skilled trades भी।
   और कुछ पेशों में, भले वे ‘glue role’ में बदल जाएँ, वे ज़रूरी नहीं कि वैसे ही अर्थहीन लगें जैसा मैं यहाँ बयान कर रहा हूँ।
   उदाहरण के लिए, वकील फ़ैसले का मुख्य लेखक होने के बजाय उसे jury तक पहुँचाने वाली भूमिका में बदल सकते हैं,
   और डॉक्टरों में diagnosis से ज़्यादा मरीज़ के प्रति उनका व्यवहार या empathy महत्वपूर्ण हो सकती है।
   (रचनात्मक काम के बारे में मैं यहाँ लंबी बात नहीं करूँगा, लेकिन मुझे लगता है कि शायद वही वह क्षेत्र होगा जिसे सबसे बड़ा लाभ भी मिलेगा और सबसे बड़ा दर्द भी झेलना पड़ेगा।)

[treestae]

मुझे लगता है कि अभी का AI शायद लगभग 10% ही पूरा हुआ है।
आमतौर पर मैंने देखा है कि जब कोई चीज़ singularity को पार कर जाती है, तो बहुत जल्दी 70% से ज़्यादा हिस्से को भर देती है। ऐसा होने पर कई नौकरियाँ खत्म हो सकती हैं, लेकिन processing cost को देखें तो अगर इंसान ज़्यादा सस्ते रहे, तो काफी नौकरियाँ फिर भी बनी रह सकती हैं।

[yinn27]

वाकई बहुत मुश्किल है..

[kandk]

कोई पंच कार्ड इस्तेमाल करने की वकालत करना चाहता है क्या..

[reagea0]

मुझे नहीं लगता कि बात वो है, हाहा

[plumpmath]

हाहाहाहाहा

[GN⁺]

Hacker News राय

• यह लेख पढ़कर सच में बहुत मज़ा आया

  • अस्तित्वगत जोखिमों को अलग रख दें, तो मुझे ऐसा भविष्य नहीं दिखता जहाँ बहुत-सी नौकरियाँ गायब न हों
  • व्यक्तिगत रूप से मैं LLMs के ठहराव वाले प्रभाव पर दांव लगा रहा हूँ
  • मुझे लगता है कि दो तरह के ठहराव आएँगे: खुद LLMs का ठहराव और इंसानों का ठहराव
  • LLMs पहले से ही ऐसे संकेत दिखा रहे हैं कि नए मॉडल और खराब हो रहे हैं (उदाहरण: Sonnet 3.5, 3.7 से coding में बेहतर है)
  • इंसान AI पर निर्भर होते हुए अपनी skills खोते जाएँगे, और programming के नए रूप बनाने या उन्हें दस्तावेज़ करने की प्रेरणा भी कम होगी
  • अल्पकाल में शायद ऐसा न हो, लेकिन लंबी अवधि में यह डरावनी बात होगी
  • AI की वजह से अनजाने में टूटे हुए systems को ठीक करना या बदलना ही भविष्य का काम होगा
  • या तो आप "AI समस्या-समाधानकर्ता" बनेंगे, या "हस्तनिर्मित software" बनाने वाले उद्यमी
  • मुझे लगता है, दोनों ही काफ़ी profitable होंगे

• समझ नहीं आता कि ऐसे लेख हमेशा यह क्यों कहते हैं कि "LLMs का उपयोग करके काम जल्दी पूरा किया", जबकि फिर यह भी बताते हैं कि LLMs ने ज़्यादा समय और पैसा लगवाकर और खराब नतीजा दिया

  • LLMs के बिना भी standards गिराने की अपनी क्षमता हमारे पास पर्याप्त थी

• "गोंद" वाली टिप्पणी मुख्य रूप से software का काम करने वाले लोगों के नज़रिए को दिखाती है

  • ऐसा तो पहली mechanized production lines बनने के समय से ही रहा है
  • इंसानों का काम सीधे मेहनत करना नहीं, बल्कि मशीनों की निगरानी करना, उन्हें फिर से चालू करना और ठीक करना है
  • power room शायद ऐसे सेटअप का पहला उदाहरण रहा होगा
  • production line में कई stations होते हैं, और drill bit टूट जाए, lens पर धूल जम जाए, या consumables खत्म हो जाएँ तो सब रुक जाता है
  • exceptions को automate करना मुश्किल है, और factory design का ज़ोर exceptions को कम करने और अटके हुए cells को bypass करने पर होता है
  • software development कैसे बदल रहा है, यह समझने के लिए factory के काम करने के तरीके को समझना मददगार है
  • "vibe coding" शब्द दो महीने पहले ही बना है
  • दो साल बाद यह कितना फैल चुका होगा, यह सोचने वाली बात है

• AI के software engineers की jobs छीन लेने की संभावना कम है

  • software में, cars, food, या housing की तरह, लोगों द्वारा consume की जा सकने वाली मात्रा की कोई प्राकृतिक ऊपरी सीमा नहीं है
  • software engineers आख़िरकार वे लोग हैं जिनमें "बनाने की इच्छा" होती है
  • code और tools तो बस साधन हैं

• "मुझे complex bugs ठीक करना पसंद है"

  • मुझे नहीं
  • कोई भी tool जो समाधान जल्दी ढूंढ दे, हमेशा स्वागत योग्य है
  • AI उबाऊ हिस्सों को अच्छी तरह संभालता है

• मेरा अनुभव अलग रहा है

  • Claude से बार-बार bugs ठीक करने को कहना झुंझलाहट भरा लगता है
  • इसलिए मैं अब भी bugs खुद ठीक करता हूँ, "एक बार में एक टुकड़ा समझते हुए"
  • दरअसल मैं LLM का उपयोग करके छोटे libraries बना रहा हूँ ताकि production app में LLM की ज़रूरत से बचा जा सके
  • यह StackOverflow के एक बेहतर version जैसा लगता है
  • मैं गोंद नहीं हूँ; मेरे पास बस ज़रूरी जानकारी जल्दी पाने का एक बेहतरीन tool है

• इन सब बातों को लेकर मैं अब भी काफ़ी निराशावादी हूँ

  • आज मुझे लगा था कि LLM coding assistant एक साफ़-सुथरी जीत दिलाएगा
  • मैं एक बहुत लंबे struct को दूसरे बहुत लंबे struct में बदलने वाला go function लिख रहा था
  • conversion लगभग पूरी तरह पहले struct के fields को wrappers में लपेटने जैसा था
  • LLM यह काम नहीं कर पाया
  • मैंने fields पहले से भरकर दिए और कहा कि बाकी भर दे, लेकिन उसने नए fields कल्पना से बना दिए, एक-दो भरने के बाद मेरे जोड़े हुए fields हटा दिए, और 'बाकी करो' जैसा comment जोड़ दिया
  • मैंने कई अलग-अलग prompts आज़माए
  • मुझे दिखता है कि कुछ vibe coders इससे उपयोगी चीज़ें बना सकते हैं, लेकिन मेरे ज़्यादातर प्रयास बस निराशा की श्रृंखला रहे हैं

• Stanislaw Lem की एक कहानी है

  • "कहीं और Tichy एक परिपूर्ण समरसता चाहता है और खुद को मशीनों के हवाले कर देता है, और मशीनें उन्हें चमकदार डिस्क में बदलकर पूरे ग्रह पर सुखद patterns में सजा देती हैं"
  • (गोंद तो नहीं, लेकिन काफ़ी करीब है)

• मज़े के लिए complex bugs ठीक करने से आपको कोई नहीं रोक रहा

  • hobby computing आज पहले से कहीं ज़्यादा सुलभ है
  • जब आप दूसरों के लिए कुछ बनाते हैं, तो AI typing और debugging का ज़्यादातर हिस्सा हटा देता है
  • इससे आप इस पर अधिक गहराई से सोच सकते हैं कि आप क्या बना रहे हैं और उसे सबसे उपयोगी कैसे बनाया जाए
  • आम तौर पर काम जल्दी पूरा हो जाता है, इसलिए उसे users तक जल्दी पहुँचा सकते हैं और iterations बढ़ जाते हैं
  • यह सबके लिए फ़ायदेमंद है

• बहुत अच्छी तरह लिखा गया लेख

  • मैं इसके मूल विचार की premise से सहमत हूँ
  • मुझे लगता है कि बदलाव इससे कहीं ज़्यादा नाटकीय होगा
  • बहुत-से लोग ठहरे हुए हैं और सोचते हैं कि उनके आसपास की दूसरी चीज़ें automate हो जाएँगी, लेकिन वे खुद नहीं
  • वे सोचते हैं, "मैं खास हूँ", लेकिन बहुत-से लोगों को पता चलेगा कि वे उतने खास नहीं हैं

[mhj5730]

प्रोडक्शन लाइन में कई स्टेशन होते हैं, और अगर drill bit टूट जाए, lens पर धूल जम जाए, या consumables खत्म हो जाएँ, तो वह रुक जाती है
exceptions को automate करना मुश्किल होता है, और factory design का फोकस exceptions को कम करने और blocked cell को bypass करने पर होता है
जब हम देखते हैं कि software development कैसे बदल रहा है, तो factory के काम करने का तरीका समझना मददगार होता है
vibe coding जैसा expression दो महीने पहले बना था
दो साल बाद यह कितना व्यापक होगा, यह सोचकर उत्सुकता होती है

<- यहाँ की यह उपमा सच में कमाल की है। मैं प्रभावित हुआ।