टावर लगातार ऊँचा होता जा रहा है

• Vibe-coded software का बेतरतीब और अप्रत्याशित ढंग से बदलना उस बाबेल के टावर जैसा लगता है, जहाँ साझा भाषा खो जाने से निर्माण रुक गया था, लेकिन AI युग में फर्क यह है कि समझ टूट जाने के बाद भी निर्माण जारी रहता है
• बड़े पैमाने के software की सीमा सिर्फ किसी व्यक्ति की code उत्पादन गति पर नहीं, बल्कि concepts, boundaries, invariants, ownership और design के कारणों को लेकर साझा समझ को कितनी अच्छी तरह समन्वित किया जाता है, इस पर भी निर्भर करती है
• code exploration, सवालों, reviews और teams के बीच चर्चा में होने वाला friction एक तरफ waste था, तो दूसरी तरफ एक-दूसरे की समझ को synchronize करने और system पर consensus की पुष्टि करने की प्रक्रिया भी था
• Agents OAuth जोड़ने, caching लगाने, database को फिर से बनाने जैसे काम बिना बातचीत के parallel में करते हैं, और हर बदलाव तार्किक हो व tests pass कर जाए, तब भी इंसानों का shared model कमजोर हो सकता है
• AI-assisted engineering में agents हर area की व्याख्या करके उसे modify करते हैं और बिना तुरंत failure के निर्माण जारी रखते हैं, इसलिए इंसानों द्वारा साथ मिलकर system पर reason करने वाली architecture language के खो जाने को पहचानना मुश्किल हो जाता है

---

बाबेल के टावर की ताकत technology से ज़्यादा coordination में थी

• कुछ vibe-coded software का कुछ हद तक बेतरतीब और अप्रत्याशित तरीके से बदलना Bruegel की The Tower of Babel की याद दिलाता है
• बाबेल के टावर की कहानी को अक्सर अहंकार और महत्वाकांक्षा, और लोगों के अलग-अलग भाषाएँ बोलने लगे होने के कारण के रूप में समझा जाता है, लेकिन साथ ही यह technical progress को संभव बनाने वाली एकजुटता भी दिखाती है
• Genesis 11:3–6 (KJV) में लोग पत्थर की जगह पकी हुई ईंटों और mortar की जगह bitumen का इस्तेमाल करने जैसी technical improvement हासिल करते हैं और आसमान तक पहुँचने वाला शहर और टावर बनाना चाहते हैं
• ईश्वर ने समस्या ईंटों या manufacturing knowledge में नहीं देखी, बल्कि इस बात में देखी कि लोग एक हैं और एक ही भाषा साझा करते हैं, इसलिए उन पर कोई चीज़ रोक नहीं लगाती
• साझा भाषा के जरिए अपने-अपने काम को जोड़ने पर लोग वह बना सकते हैं जो कोई भी अकेले नहीं बना सकता
• ईंटें या manufacturing method नहीं, बल्कि एक-दूसरे को समझने की क्षमता गायब हुई, तो coordination असंभव हो गया और निर्माण भी रुक गया

AI agents friction हटाने के बाद भी ऊपर चढ़ता टावर

• AI-assisted programming व्यक्ति को अधिक शक्तिशाली tools देती है, और agents इस्तेमाल करने वाला developer codebase में कहीं बड़े स्तर के बदलाव कर सकता है
• लेकिन बड़े projects की सीमा सिर्फ इस बात से तय नहीं होती कि कोई व्यक्ति code कितनी तेजी से produce करता है, बल्कि इस बात से भी कि लोग जिस system को बदल रहे हैं, उसकी समझ को कितनी अच्छी तरह coordinate करते हैं
• software project की common language English या Python खुद नहीं, बल्कि इन बातों की साझा समझ है
  • हर concept का क्या मतलब है
  • system boundaries कहाँ हैं
  • कौन-से invariants महत्वपूर्ण हैं
  • कौन किस चीज़ का owner है
  • system की मौजूदा structure के पीछे क्या कारण है
• यह समझ किसी एक जगह पूरी तरह दर्ज नहीं होती, और docs व code के साथ-साथ code reviews, बातचीत, बहस और दूसरे लोगों को बदलाव समझाने के अनुभवों में भी जमा होती है
• agents से पहले, किसी और की storage layer बदलनी हो तो अक्सर code पढ़ना, सवाल पूछना और dependent services चलाने वाली दूसरी team से बात करनी पड़ती थी
  • इस process में waste भी था, लेकिन यह एक व्यक्ति की समझ को दूसरे तक पहुँचाने और यह जाँचने का काम भी करता था कि दोनों पक्ष अभी भी system के काम करने के तरीके पर सहमत हैं या नहीं
  • ऐसा friction लोगों की समझ को synchronize करता था
• agents इस friction को काफी कम कर देते हैं, जिससे कई लोग एक-दूसरे से बात किए बिना अलग-अलग बदलाव request कर सकते हैं
  • एक व्यक्ति OAuth जोड़ता है, दूसरा caching डालता है, और कोई तीसरा database को शुरू से फिर बनाकर UI को pink कर सकता है
  • हर बदलाव अपने-आप में तार्किक हो सकता है, code compile हो सकता है, tests pass हो सकते हैं, और जरूरत पड़ने पर explanation भी generate हो सकती है
  • किसी को भी किसी दूसरे से बात करने या उस shared model के किसी हिस्से को हासिल करने की जरूरत नहीं रहती, जिसे पहले बदलाव की प्रक्रिया में सीखा जाता था
• agents दर्द महसूस नहीं करते, दर्द सिर्फ इंसान महसूस करते हैं, और अब ऐसे system areas व codebase भी बदले जा सकते हैं जहाँ पहले किसी और की मदद चाहिए होती थी
• scale बढ़ने पर vibe-coding projects बाबेल के टावर जैसे codebase इसलिए नहीं बनते कि लोग communicate नहीं कर सकते, बल्कि इसलिए कि communicate करने की जरूरत ही नहीं रह जाती
  • हर developer के पास एक अथक translator होता है जो टावर के किसी खास हिस्से को समझाता है और इच्छित local change कर देता है
  • बदलाव लगातार लागू होते रहते हैं, लेकिन वह architecture language गायब हो सकती है जो इंसानों को साथ मिलकर system पर reason करने देती थी
• Bible के बाबेल टावर में common language के खो जाने से निर्माण रुक गया था, लेकिन AI-assisted engineering में shared understanding के ढह जाने के बाद भी निर्माण जारी रह सकता है
• टावर गिरता नहीं और न ही तुरंत failure होता है, इसलिए यह समझना मुश्किल होता है कि क्या खो गया है, और टावर लगातार ऊँचा होता जाता है

[GN⁺]

Hacker News की राय

• मैं लंबे समय से सोचता आया हूं कि software की composability में Tetris की तरह लाइने मिटती रहनी चाहिए। अपरिपक्व ढंग से agent इस्तेमाल करने वाले या कम अनुभव वाले engineer अक्सर ऐसी सफाई से चूक जाते हैं और tower को बस लगातार ऊंचा करते जाते हैं।
  Agents को मौजूदा elements को बेहतर abstractions में बार-बार integrate करने के लिए बनाया जा सकता है, लेकिन Fable या 5.6 Sol तक में software के सूक्ष्म evolution का अनुमान लगाने वाली high-level architectural sense अभी भी इंसानों से काफी पीछे है। मौजूदा systems शायद इंसानों द्वारा संभाले जाने वाले high-quality, sparse और zoom-in/zoom-out हो सकने वाले world model को पर्याप्त रूप से maintain नहीं कर पाते, लेकिन यह तथ्य अपने-आप में उम्मीद देता है कि अब फर्क इतने सूक्ष्म स्तर तक घट गया है।

  • मैं साबित तो नहीं कर सकता, लेकिन मेरा मजबूत विश्वास है कि future changes को ध्यान में रखकर abstraction बनाने के लिए जरूरी logic और intuition को सिर्फ prediction tokens की sequence से implement नहीं किया जा सकता। कोई ऐसी चीज missing है जिसे मापा नहीं जा सकता।
  • पहले मानव मस्तिष्क की क्षमता ही program complexity की upper limit थी, लेकिन vibe coding उस barrier को तोड़ सकती है। इसलिए नहीं कि समस्या वाकई उतनी complex है, बल्कि इसलिए कि development process concise abstractions की ओर converge नहीं करती।
    यह Brooks द्वारा 《The Mythical Man-Month》 में चर्चा की गई scaling problem का AI version है: scale बढ़ने पर combinatorial explosion और खराब हो जाता है, और project में जगह-जगह लगभग वही functionality implement करने वाला duplicate code बन जाता है। हमें ऐसा तरीका चाहिए जिससे AI-based coding conciseness को pursue करे।
  • इंसान की context window आज के LLMs से कहीं छोटी हो सकती है। यह constraint काम को दिमाग में रखने लायक modules और abstractions में बांटने के लिए मजबूर करता है, जो एक फायदा है; लेकिन LLMs, जो एक साथ कहीं ज्यादा चीजें रख लेते हैं, उनमें वैसा incentive नहीं होता, इसलिए agents unorganized spaghetti code बना देते हैं।
  • अंततः यह समय की बात है। gpt2 या llama2 आज के models की तुलना में चौंकाने वाले ढंग से खराब थे और उस समय भी असल में लगभग बेकार थे, फिर भी हम प्रभावित हुए थे।
    कभी hype में रहे GPT3.5 और gpt4 भी अब qwen27b या gemma31b से काफी पीछे हैं। पर्याप्त समय और सही reinforcement learning (RL) मिले तो models भी अपने भीतर अच्छे software system models बना लेंगे।
  • क्या यह इसलिए नहीं है कि LLMs को छोटी time-horizon वाली tasks हल करने के लिए reinforcement-learn किया गया है? Tests pass कराने वाली tasks के उलट, सालों की मेहनत, साफ architecture और अच्छी intuition को benchmarks में maximize करना आसान नहीं है।

• इस लेख का core argument Lisp Curse और Bipolar Lisp Programmer की याद दिलाता है। तर्क यह था कि Lisp में व्यक्ति जो चाहता है उसे बनाना इतना आसान है कि programmers के पास मिलकर general-purpose और complex outputs बनाने की motivation कम हो जाती है, और जिन languages में काफी effort चाहिए उनके मुकाबले public software ecosystem कमजोर रह जाता है।
  लगता है Armin भी AI coding को लेकर बहुत मिलता-जुलता argument दे रहे हैं: Lisp Curse, Bipolar Lisp Programmer

  • Assembly programmers भी यही तर्क देते थे। software engineering में जब-जब paradigm shift आता है, यह दोहराई जाने वाली common belief है, और कुछ लोगों के लिए transition दूसरों से ज्यादा मुश्किल होता है।
  • संदेह है कि क्या यह सचमुच वही तर्क है। अब काफी लोग मानते हैं कि साथ आकर collaborate करने की जरूरत नहीं, सिर्फ agents की टोली लगा दीजिए और आप कल्पना किया हुआ कोई भी complex software बना सकते हैं।
  • बल्कि अगर TypeScript और Rust ने market पर कब्जा न किया होता, तो अभी Lisp के लिए LLM operator बनने का अच्छा समय होता। आजकल agents लगभग hallucination के बिना अधिकांश चीजें explain कर सकते हैं, इसलिए अगर समझने की इच्छा हो तो समझ की barrier असल में खत्म हो जाती है—और यही लेख का core भी है।
  • यह premise साफ नहीं है कि वही result पाने के लिए दूसरी languages “कहीं ज्यादा effort” मांगती हैं। कई non-Lisp developers syntax को महत्व देते हैं, लेकिन Lisp developers नहीं; और Lisp के जरिए सोच के expand होने का experience करने के बाद भी कई लोग Lisp को prefer नहीं करते।
    इन दोनों groups के बीच शायद अलग-अलग cognitive processing styles हों। Lisp को दूसरी languages जितना productive होने के लिए homoiconicity का सक्रिय इस्तेमाल करना पड़ता है, और इसके परिणामस्वरूप serious Lisp programs अक्सर domain-specific languages (DSLs) के ऐसे collection बन जाते हैं जिन्हें सिर्फ एक-दो लोग ही समझते हैं।

• बड़े software projects की सीमा इस बात में नहीं है कि कोई व्यक्ति कितनी तेज़ी से code produce करता है, बल्कि इस बात में है कि system बदलने वाले लोग उस system की साझा समझ को कितनी अच्छी तरह coordinate करते हैं। यह कहना सही है कि 30 नवंबर 2022 के बाद सब कुछ और जटिल हो गया

  • software परत-दर-परत चढ़कर हद से ज़्यादा जटिल हो गया है, और इसे संभालने के लिए हम ऐसे tools इस्तेमाल कर रहे हैं जो उससे भी ज़्यादा complexity बना देते हैं। 1990s और 2000s की शुरुआत में formal education के बिना भी Visual Basic या PHP से शक्तिशाली applications बनाए जा सकते थे, लेकिन आज web या desktop development बेहद जटिल है, और React तक ठीक से इस्तेमाल करने के लिए बहुत कुछ जानना पड़ता है
    इसमें AI लाना मौजूदा complexity के ऊपर एक और complexity चढ़ाने जैसी गलती के करीब है। अच्छे-से-अच्छे में भी यह भारी hardware waste है, और बुरे में agents जितने bugs ठीक करेंगे उतने ही नए bugs बनाएंगे, vulnerable घटिया software बढ़ेगा, साथ ही लोग skills नहीं सीखेंगे और पूरी मानवता की क्षमता कमजोर हो सकती है। software को मूल रूप से इतना जटिल होने की ज़रूरत नहीं है; इसे सुलझाने के लिए craftsmanship को महत्व देना होगा
  • किसी system को बदलने से पहले उसे समझना ज़रूरी है, यह कोई नई बात नहीं है। Peter Naur का Programming as Theory Building 1980s में ही आ चुका था, और भले ही किसी ने उसे न पढ़ा हो, अनुभवी developers के बीच यह common sense था कि system की समझ अनिवार्य है
  • ऐसा नहीं है कि हर चीज़ सिर्फ और जटिल ही हुई है। प्रमुख databases में practical high-availability tools शामिल हो गए हैं, microservices पीछे हट रहे हैं, और NoSQL की जगह structured databases वापस आ रहे हैं
    HTML और pre-rendering भी HTMx, LiveView के साथ वापस आए हैं, और CSS भी पुराने अजीब workarounds से आगे निकल गया है। जब किसी युवा colleague को IE6 में web page debug करने का तरीका समझाते हैं, तो पीढ़ियों का अंतर महसूस होता है। कुछ चीज़ें जटिल हुई हैं, लेकिन कुछ और चीज़ें पर्याप्त mature होकर simpler हो गई हैं
  • “30 नवंबर 2022 के बाद” नहीं, कहना चाहिए कि 2022 ईसा पूर्व के बाद सब कुछ और जटिल हुआ है। complexity का बढ़ना ही मानव सभ्यता का इतिहास है
    20,000 ईसा पूर्व का इंसान खाने की तलाश करता और ठंड व predators से बचता था, लेकिन 5,000 ईसा पूर्व का इंसान खेती करता, बारिश और बीमारी की चिंता करता, और community व land manage करने की व्यवस्था बनाता था। आज अधिकतर लोग अपना खाना खुद नहीं उगाते, बल्कि विशाल समाजों की complexity manage करते हैं। 1970–80s के developers की नज़र से LLM से पहले का software भी बेहद जटिल था, और अब लगभग कोई भी abstraction layers के बिना सीधे hardware पर code नहीं लिखता। encryption में भी libraries complexity छिपाती हैं और “खुद implement मत करो” सिखाया जाता है। अब मुख्य सवाल यह है कि LLM बदले जाने वाले system की समझ को कितनी तेज़ी से coordinate कर सकता है

• software project की shared language English या Python नहीं, बल्कि concepts के meaning, boundaries, invariants, ownership, और system अपने मौजूदा रूप में क्यों आया—इन सबकी common understanding है। Christopher Alexander की Pattern Language इसी समस्या से जुड़ी है, और हर domain के लिए अपनी pattern language बनाने की उनकी सलाह ही आगे चलकर प्रसिद्ध GoF Design Patterns तक पहुँची
  मैं projects में business, product और technical domains के लिए तीन pattern languages AI से maintain कराने वाला feature experiment कर रहा हूँ, और यह बहुत अच्छा काम कर रहा है। planning के समय इन्हें reference करने और implementation व review के दौरान इन्हें व्यवस्थित करने को कहने से, 100% AI से coded projects भी structured, domains के बीच अच्छी तरह aligned और संभालने में आसान हो गए

  • असली example देखने की इच्छा है। code के mature होने की प्रक्रिया शहर के natural growth जैसी होती है, यह बात कई बार सुनी है, लेकिन concrete results कभी नहीं देखे
  • क्या कोई public GitHub example है, यह जानना चाहूँगा

• Babel के tower में common language खोते ही construction रुक जाता है, लेकिन AI-assisted development में shared understanding टूट जाने के बाद भी construction चलता रहता है। लेखक ने अच्छा-बुरा साफ़ नहीं कहा, लेकिन मैं इसे साफ़ तौर पर बुरी बात मानता हूँ
  अगर यह जानना कि tomato fruit है intelligence है, और उसे fruit salad में न डालना wisdom है, तो AI wisdom के बिना intelligence का अंतिम रूप है—असल में intelligence के भ्रम के करीब। अगर यह समझने वाला कोई नहीं है कि AI क्या कर रहा है, तो हमें रुकना चाहिए और मानना चाहिए कि हम जो बना रहे हैं उसे control करने की wisdom की कमी है

  • अच्छा लगा कि लेखक ने sermon देने के बजाय image को खुद meaning convey करने दिया। इतिहास में बिल्कुल वही repetition नहीं होता, लेकिन rhyme हमेशा मिलती है
  • “tomato fruit है यह जानना intelligence है” जैसे बचकाने clichés से बचना बेहतर है, अगर मकसद mislead करना नहीं है। classification और dependency relationships को समझना ही काफी कठिन समस्या है, और supermarket या Nix v. Hedden के tax criteria में tomato vegetable है

• मुझे भी Babel और Bruegel की painting याद आती है, लेकिन मैं इसे कहीं कम optimistic तरीके से देखता हूँ। shortsighted छोटे agents किसी अकल्पनीय रूप से विशाल whole के अपने-अपने हिस्से develop कर रहे हैं; एक तरफ 50 battlements हैं, दूसरी तरफ अजीब निकला हुआ tower है, और बिना वजह courtyard के ऊपर adobe roof व उसके बगल की landing पर thatched roof वाला tower खड़ा किया जा रहा है
  individual design level पर यह ठीक लगता है, लेकिन पूरे project को integrate करने वाली कई layers की policy और judgement न होने से यह design का विशाल monster बन जाता है। पर्याप्त बड़े organizations में common language बनाना और maintain करना discipline मांगता है—यह successful companies और militaries की विशिष्ट terminology में भी दिखता है। “Gastown Mayors” और उनके नीचे के “polecats”, और उनसे नीचे के golems तक सभी सोचते हैं कि वे same language बोल रहे हैं, लेकिन सब कुछ पूरा होने के बाद ही throne पर बैठा व्यक्ति समझेगा कि जो understanding उसने पूरी तरह convey मान ली थी, वह वास्तव में shared थी ही नहीं

• Anakin: “agents इस्तेमाल करने वाले developers की codebase बदलने की क्षमता नाटकीय रूप से बढ़ जाएगी”
  Padmé: “बेहतर दिशा में, है न?”
  Anakin: चुप्पी
  Padmé: “बेहतर दिशा में, है न?”

• vibe coding शायद इसलिए generated code पढ़ने से मना करती है क्योंकि Python file के भीतर छिपा खौफ एक बार देख लिया तो भुलाया नहीं जा सकता। broad sense में वह requested चीज़ करता है, लेकिन goal हासिल करने का तरीका चुनते समय हर बार inconsistent decisions लेता है
  कुछ user inputs पर ही अजीब validation लगाता है, बिना वजह तीन stages में data को बार-बार sort या lowercase करता है, और input CSV की पहली row में मौजूद column names तक सारे strings hardcode कर देता है। आधा हिस्सा data classes लेने वाले global functions बनाता है और बाकी classes के रूप में implement करता है। यह सोचकर कि किसी दिन इसे खुद update और maintain करना होगा, इसे ठीक किए बिना रहना मुश्किल है; लेकिन ऐसा सुधार करते-करते बचाए गए समय का बड़ा हिस्सा गायब हो जाता है

• एजेंट-आधारित programming असल programming की तुलना में management काम के कहीं ज़्यादा करीब है। manager को individual contributors के काम की सिर्फ high-level समझ होती है, और कई बार उनके पास हर detail समझने का समय, cognitive bandwidth या क्षमता नहीं होती
  जितना ज़्यादा software agents से लिखा जाएगा, software engineer की भूमिका technical role से ज़्यादा management role जैसी होती जाएगी

  • programmer के साथ भी यही है। ज़्यादातर individual contributors को यह नहीं पता होता कि जिस layer पर वे काम कर रहे हैं, उसके नीचे क्या हो रहा है, और वे libraries, frameworks, remote APIs, system calls की internal implementation तक नहीं समझते
    सब कुछ समझने का समय और bandwidth नहीं होता, इसलिए वे बस अपनी abstracted layer में ज़रूरी काम करते हैं
  • यह पूरे दिन junior developer का code review करने जैसा लगता है, इसलिए मैं इसे लगभग इस्तेमाल नहीं करता; मुख्य रूप से इसे सिर्फ उन चीज़ों को खोजने के लिए इस्तेमाल करता हूँ जो मुझसे छूट गई हों

• पहले बड़े पैमाने की refactoring में बहुत मेहनत लगती थी, इसलिए उसके लिए पर्याप्त कारण चाहिए होता था। अब prompt थोड़ा भी अस्पष्ट हो और result की ठीक से review न की जाए, तो agent code का आधा हिस्सा फिर से लिख सकता है, जिससे program की आत्मा हर दिन बड़े पैमाने पर बदल सकती है। यह शानदार भी है और साथ ही बिल्कुल नहीं भी

  • बड़े पैमाने की refactoring की सबसे बड़ी बाधा असल में workload नहीं, बल्कि bug risk को कम करना, functionality को सुरक्षित रखना, और मौजूदा ecosystem के साथ compatibility सुनिश्चित करना था। AI के दौर में यह इसलिए आसान हो गया है क्योंकि हमने इन चीज़ों की परवाह करना ही छोड़ दिया है