कोड की मौत को बढ़ा-चढ़ाकर बताया गया है

परिचय — अंग्रेज़ी स्पेक का भ्रम

• "काफ़ी विस्तार से लिखी गई specification ही code है" वाली बात से प्रेरित होकर शुरुआत। अंग्रेज़ी specification सहज रूप से सटीक लगती है, लेकिन जब वास्तव में उसे implement करने की कोशिश करते हैं तो उसकी अस्पष्टता सामने आती है
• "हर चीज़ तब तक अस्पष्ट होती है, जब तक आप उसे सटीक बनाने की कोशिश नहीं करते।" — Bertrand Russell
• programming लिखने की तरह है: करते-करते उसे और अधिक पैना बनाने वाली एक आवृत्तिमूलक गतिविधि (यह निबंध भी अनगिनत drafts से गुज़रा)

vibe coding — यह काम क्यों करता है, और क्यों ख़तरनाक है

• AI अंग्रेज़ी→चलने वाला code रूपांतरण लगातार तेज़ और बेहतर करता जा रहा है, इसलिए अब अंग्रेज़ी-स्तर की "feeling(vibe)" से code बनाना संभव हो गया है
• AI द्वारा बनाए गए परिणाम पर प्रतिक्रिया देते हुए — "button को उधर ले जाओ, और ज़्यादा नीला करो" — धीरे-धीरे अधिक सटीक होने की प्रक्रिया
• "vibe coding" अभिव्यक्ति के बिल्कुल सही होने की वजह: अंग्रेज़ी-स्तर के vibe को बनाए रखते हुए AI output के ज़रिए सोच को और पैना करना
• मुख्य समस्या: vibe यह भ्रम देता है कि वह एक सटीक abstraction है। जैसे-जैसे features बढ़ते हैं या scale बड़ा होता है, abstraction leak होने लगती है और अनपेक्षित bugs पूरा दिन बर्बाद कर देते हैं

वास्तविक उदाहरण — Dan Shipper का vibe-coded app

• Dan Shipper ने vibe coding से एक text editor app बनाया, वह viral हो गया → server down
• कारण: "live collaboration" सहज रूप से सरल दिखता है, लेकिन वास्तव में दुःस्वप्न जैसी complexity है
• हम सबने Google Docs, Notion इस्तेमाल किया है, इसलिए "live collaboration" ऐसे महसूस होता है जैसे वह पहले से ही सटीक रूप से spec किया गया हो। ऐसा क्यों नहीं है, इसे पहले से समझ पाना बेहद कठिन है
• लेखक ने भी 10 साल पहले collaborative editor बनाते समय अनपेक्षित complexity का दुःस्वप्न झेला। क्या मुश्किल था? याद भी नहीं! यही समस्या का हिस्सा है — complexity उबाऊ होती है, उसके बारे में सोचना नहीं चाहते, और details व edge cases याद रखना मुश्किल होता है
• उदाहरण: Slack का यह तय करने वाला classic flowchart कि notification भेजना है या नहीं — "notification भेजना" जैसे साधारण शब्दों के पीछे भी इतनी complexity छिपी होती है

abstraction — complexity से निपटने का एकमात्र औज़ार

• मानव मस्तिष्क की बुनियादी सीमा: एक समय में केवल 7±2 चीज़ें संभाल सकता है
• 7 से ज़्यादा चीज़ों को संभालने का एकमात्र तरीका: कई चीज़ों को compress करके एक बना देना। इसे recursively अनंत बार दोहराया जा सकता है, इसलिए मनुष्य अनंत complexity संभाल सकता है। compression का यही चरण abstraction है
• "abstraction का उद्देश्य अस्पष्ट होना नहीं, बल्कि अर्थ के ऐसे नए स्तर रचना है जहाँ कोई पूर्णतः सटीक हो सके।" — Dijkstra
• Sophie Alpert ने Slack के बदनाम notification flowchart को चतुर abstraction के ज़रिए बहुत सरल रूप में refactor किया
• programming का सबसे अच्छा हिस्सा: लगातार बेहतर abstractions बनाकर complexity पर विजय पाना। जैसे ReactJS या TailwindCSS ने अपने-अपने क्षेत्र में किया
• collaborative text editor का मूल रूप से complex होना सिर्फ़ इतना बताता है कि हमें लगातार बेहतर abstractions ढूँढ़ते रहना चाहिए

AGI — फिर भी अच्छा code गायब नहीं होगा

• 1 साल, 2 साल, 5 साल, 10 साल, 100 साल बाद की कल्पना करें: AI लगातार बेहतर/तेज़/सस्ता होता जाएगा, और किसी बिंदु पर मशीन बुद्धिमत्ता मनुष्यों से अलग न पहचानी जा सकेगी (AGI)
• AGI की दुनिया vibe की दुनिया जैसी लग सकती है। अगर आप $1000/माह पर Kapathy-स्तर के 100 जीनियस इस्तेमाल कर सकते हों, तो झंझट भरे details की परवाह क्यों करेंगे?
• "यह सचमुच हास्यास्पद बात है।" ऐसा सोचना तभी संभव है जब तकनीक अभी पहुँची न हो और बात सिर्फ़ अमूर्त रूप में की जा रही हो
• अगर उस स्तर की बुद्धिमत्ता तक पहुँच हो, तो उसे और ज़्यादा slop उगलवाने में लगाने वाले लोगों की संख्या 0% होगी। बिल्कुल नहीं
• हम भ्रमित इसलिए होते हैं क्योंकि हम (ग़लती से) मान लेते हैं कि code सिर्फ़ software production के लिए है। code स्वयं भी एक केंद्रीय output है। अगर उसे अच्छी तरह बनाया जाए, तो वह कविता है
• "कोई भी 'vibe writing' की बात नहीं करता, है न?" — writing में कोई नहीं मानता कि ChatGPT महान उपन्यासकारों या पत्रकारों की जगह ले लेगा। code के साथ भी वही बात है, लेकिन चलने वाले code के "रहस्य" की वजह से भ्रम पैदा होता है
• AI (हालाँकि पहले से कम) घटिया code बनाता है। हम सब यह जानते हैं। AI का इस्तेमाल हम ख़राब code के बावजूद करते हैं, उसके कारण नहीं
• Simon Willison का उद्धरण: "AI को बेहतर code बनाने में मदद करनी चाहिए"
• AGI आने पर सबसे पहले किया जाने वाला काम: सबसे कठिन abstraction समस्याओं को हल करना। बेहतर abstractions बनाकर complexity को और अच्छी तरह समझना और जीतना
• AI जितना ज़्यादा स्मार्ट होगा, उतना ही अच्छे code की ज़रूरत ख़त्म हो जाएगी? यह वैसा ही है जैसे कहना कि ChatGPT से बस और ज़्यादा slop उगलवाया जाएगा
• वास्तविक उदाहरण: Opus 4.6 ने Val Town के full-stack React framework (vtrr) को बनाते समय एक unsolved problem को one-shot में हल कर दिया। 50-पंक्तियों वाले single-file full-stack app demo उसी का नतीजा था

निष्कर्ष — code की शुरुआत अब हुई है

• ऐसा लगता है कि समाज के 99% लोग "code मर चुका है" से सहमत हो चुके हैं। कल ही podcaster Sam Harris को आत्मविश्वास से कहते सुना कि "सब मानते हैं coding मर चुकी है, किसी को coding सीखने की ज़रूरत नहीं है"
• "यह दुखद है। यह printing press के आविष्कार पर 'storytelling मर चुकी है' कहने जैसा है। मूर्खों, code की शुरुआत अब हुई है। AI coding के लिए एक बहुत बड़ा आशीर्वाद होगा।"
• समापन उद्धरण:
  • "औपचारिक symbols के इस्तेमाल की बाध्यता को बोझ की तरह नहीं, बल्कि एक विशेषाधिकार की तरह देखना चाहिए। इसी की बदौलत छात्र वे काम कर पाते हैं जो पहले केवल जीनियस कर सकते थे।" — Dijkstra
  • "अपनी मातृभाषा को 'स्वाभाविक रूप से' इस्तेमाल कर पाने का मतलब बस इतना है कि आप ऐसे वाक्य आसानी से बना सकते हैं जिनका बेतुकापन तुरंत साफ़ न हो।" — Dijkstra, "On the foolishness of natural language programming"
  • "software design के दो तरीके हैं: एक, उसे इतना सरल बनाओ कि defects स्पष्ट रूप से न हों; दूसरा, उसे इतना complex बनाओ कि defects स्पष्ट रूप से दिखें ही नहीं।" — Tony Hoare
  • "बीजगणितीय symbols में बहुत कम जगह में भरा गया अर्थ, उनके माध्यम से किए जाने वाले हमारे reasoning को आसान बनाता है।" — Charles Babbage

[silveris23]

सहयोगी editing की बात तक जाने से पहले, अकेले इस्तेमाल होने वाला एक editor भी ठीक से implement करना हो तो cursor handling, undo/redo stack, IME input जैसी अप्रत्याशित जटिलताएं ही जटिलताएं सामने आती हैं। जैसा लेख में बताया गया है, "सहज लगने के साथ-साथ सटीक महसूस होने वाली specification" का जाल editor जितनी स्पष्टता से शायद ही किसी और software में दिखता हो। आखिरकार जो चीज़ आसान दिखती है, वह सच में आसान नहीं होती; बल्कि उसकी जटिलता को अच्छी तरह abstract करके छिपाया गया होता है.

[botplaysdice]

असल में Anthropic ने डेमो के तौर पर C compiler बनाया, इसकी वजह भी शायद यही रही होगी कि compiler की specification सटीक होती है और test cases भी अच्छी तरह तैयार होते हैं। साथ ही, यह देखने में बेहद कठिन भी लगता है।

[runableapp]

मैंने कुछ compiler बनाए हैं और एक पर अभी काम भी कर रहा हूँ। vibe coding के नज़रिए से editor भी आज़माया था, लेकिन compiler ज़्यादा आसान लगा। जैसा आपने लिखा, इसमें spec कम सटीक होती है और user की वजह से variables भी ज़्यादा लगते हैं। test करना भी ज़्यादा मुश्किल होता है.

spec की अहमियत बढ़ती है, लेकिन मुझे पहले से ही लगता रहा है कि spec को शुरू से पूरी तरह विस्तार में लिखकर हर स्थिति को cover करना असंभव है। मुझे अभी भी यही बेहतर दिशा लगती है कि spec को भी code की तरह काम करते-करते refine किया जाए, हालांकि यह भी लगता है कि शायद कई agents को आपस में ऐसा करने दिया जा सकता है। लेकिन आखिरकार, इंसानी दखल के बिना सीखी हुई परिस्थितियों और ज्ञान से बाहर निकलना संभव नहीं है, इसलिए बिल्कुल नई स्थितियों और features को संभालना कठिन ही होगा।

जब robot vacuum पहली बार आए थे, तो ऐसा लगता था जैसे robot के लिए फ़र्श पर पड़ी चीज़ें हटाकर एक "सरल सफ़ाई" पहले करनी पड़ती है। AI के लिए भी विस्तार से spec लिखना अपने आप में काफ़ी बड़ा काम है, इसलिए लगता है जैसे हम AI के लिए काम कर रहे हों।

[kurthong]

IDE, PR सब मर गए थे, लेकिन code फिर से ज़िंदा हो गया क्या?

[kandk]

कोड सरल प्रणालियों में तार्किक रूप से सबसे सटीक specification है.
लेकिन असली दुनिया के complex system होने में ही पेंच है.. आखिरकार data ही वह चीज़ है जो फिर भी सबसे सटीक specification के सबसे करीब है

[vk8520]

ऐसा लगता है कि यह देखना होगा कि क्या इसे दूसरे verification तरीकों से बदला जा सकता है। जितना यह front के करीब होगा, उतना ही browser behavior के आधार पर सिर्फ E2E से भी यह verify किया जा सकेगा कि यह ठीक से काम कर रहा है। लेकिन back, और infrastructure के करीब के code के लिए code review अनिवार्य लगेगा। नहीं तो transaction का दिखे बिना खुलना-बंद होना या API call चले जाना जैसी side effects को verify करना मुश्किल होगा।

[moregeek]

ब्राउज़र में ऐसी बहुत-सी समस्याएँ हैं जिन्हें E2E से भी पकड़ा नहीं जा सकता।

[roxie]

क्या हो सकता है?