कोड अब और सस्ता हो गया है

• AI coding tools के फैलाव से code लिखने की लागत तेज़ी से घट गई है, लेकिन इसके बदले generated code को समझने की लागत और बढ़ गई है
• LLM nondeterministic हैं, original source को सुरक्षित नहीं रखते, और उनका output दायरा पूरे general software तक फैला है, इसलिए उन्हें compiler output के समान नहीं माना जा सकता
• LLM इंसान की समझने की गति से कहीं ज़्यादा तेज़ी से code generate करते हैं, इसलिए कोई भी न समझ सके ऐसे बड़े बदलावों को रोकने के लिए incremental उपयोग की सिफारिश की गई है
• जब code सस्ता हो जाता है, तब सबसे बड़ा जोखिम complexity होता है; यह system के आकार के साथ कम-से-कम geometrically बढ़ता है, जबकि LLM complexity के डर के बिना बहुत ज़्यादा code बनाने वाले coder हैं
• समाधान के रूप में code जोड़ने के बजाय उसे हटाने और सरल बनाने वाले subtractive engineer का विचार रखा गया है, और computer programming की कला को बनाए रखने पर ज़ोर दिया गया है

---

वह दौर जब code सस्ता हो गया

• पिछले 1 साल में AI ने काफ़ी अच्छी गुणवत्ता का code बहुत तेज़ी से और बड़े पैमाने पर बनाना शुरू किया है, जिससे code generation cost काफ़ी कम हो गई है
• "coding तो शुरू से ही समस्या नहीं थी" जैसी बातों के जवाब में कहा गया है कि coding भी समस्या का एक हिस्सा थी, और AI coding tools ने उस हिस्से को काफ़ी कम कर दिया है
• जो developer पहले अपनी coding क्षमता पर गर्व करते थे, उनके लिए यह सवाल उठता है कि pure coding के महत्व में आई गिरावट का मतलब क्या है

समझने की बढ़ती लागत (Understanding is Expensive(er))

• जब code programmer के हाथों मेहनत से निकलने के बजाय बड़े पैमाने पर generate होने लगता है, तब उस code के बारे में समझ अपने-आप मौजूद नहीं होती
  • अगर समझ चाहिए, तो code लिखे जाने के बाद उसे पढ़कर हासिल करनी होगी
  • आम धारणा यह है कि किसी और का लिखा code पढ़ना, अपना code लिखने से ज़्यादा कठिन होता है
• "क्या हम compiler output भी समझते हैं?" जैसे AI समर्थक तर्क को category error कहा गया है
  • compiler deterministic होता है, लेकिन LLM design के हिसाब से nondeterministic होते हैं
  • compiler workflow original source code को सुरक्षित रखता है, लेकिन LLM workflow आम तौर पर ऐसा नहीं करता
  • compiler output machine code जैसे एक सीमित domain तक ही रहता है, जबकि LLM output सामान्यीकृत software तक सीमित नहीं है
• ज़्यादातर मामलों में, ख़ासकर mission critical software में, LLM से बने code को भी developer को मूल code स्तर पर समझना ही होगा
• LLM ऐसी गति से code बना सकते हैं जिसे कोई इंसान पकड़ नहीं सकता, इसलिए समझने की गति को पार कर जाने का जोखिम है
  • इसलिए बहुत बड़े बदलावों की सूची एक साथ generate करने के बजाय incremental उपयोग की सिफारिश की जाती है
  • यह mechanical refactoring के लिए उपयुक्त हो सकता है, लेकिन codebase में नई semantics लाने के समय बेहद ख़तरनाक हो सकता है

जादूगर के शिष्य का जाल (The Sorcerer's Apprentice Trap)

• Disney फ़िल्म Fantasia के "The Sorcerer's Apprentice" दृश्य को AI युग के लिए उपयुक्त रूपक के तौर पर पेश किया गया है
  • शिष्य सफ़ाई की मेहनत कम करने के लिए झाड़ू पर जादू कर देता है, लेकिन झाड़ू लगातार और उग्र रूप से सफ़ाई करती जाती है और हालात नियंत्रण से बाहर हो जाते हैं
  • आख़िर में जादूगर फिर से लौटता है, स्थिति पर क़ाबू पाता है, शिष्य की मूर्खता को डाँटता है और अव्यवस्था को संभालता है
• इस रूपक का सबक यह है कि शिष्य नहीं, जादूगर बनना होगा, और जादूगर को code समझना आना चाहिए

complexity अब भी बुरी है (Complexity: Still Bad)

• इंसान geometric और exponential curves को अच्छी तरह नहीं समझते, और compound interest जैसी चीज़ों पर अक्सर परीकथा जैसा भरोसा करते हैं
• जब code सस्ता हो जाता है, तब सबसे बड़ा जोखिम complexity होता है; दावा किया गया है कि यह system के आकार के साथ कम-से-कम geometrically और कई बार exponentially बढ़ता है, हालाँकि इसका कोई औपचारिक प्रमाण नहीं दिया गया
• LLM से पहले भी prolific coder मौजूद थे
  • complexity से न डरने वाले prolific coder मौजूदा समस्याओं के ऊपर लगातार code जोड़ते जाते हैं, और system को ऐसे ठहरे हुए हालात में पहुँचा देते हैं जहाँ हर बदलाव उतने ही bug पैदा करता है जितने ठीक करता है
• LLM complexity से नहीं डरते और साथ ही prolific coder भी हैं, इसलिए वे ख़तरनाक हैं

हटाने और सीमित करने वाला engineer (The Subtractive, Constraining Engineer)

• LLM-generated code के जोखिम से निपटने के लिए subtractive, constraining engineer का विचार दिया गया है
  • ऐसा engineer "नहीं" कहता है, LLM output की बारीकी से समीक्षा करता है, simplification सुझाता है, और मज़बूती से नियंत्रण बनाए रखता है
  • वह अपने बनाए code पर नहीं, बल्कि system से हटाए गए या अंदर आने से रोके गए code (और layers) पर गर्व करता है
  • यह रवैया builder की तुलना में sculptor के ज़्यादा क़रीब है
• builder वाला रवैया system design स्तर पर अब भी उपयोगी है
  • अच्छे engineer को components को प्रभावी ढंग से जोड़कर system बनाना आना चाहिए
  • लेकिन इस स्तर पर भी अनावश्यक components और system boundaries हटाकर deployment और interaction को सरल बनाने वाली हटाने वाली सोच उपयोगी रहती है
• subtractive engineer, अतीत के ज़्यादातर coder से अलग तरह का व्यक्तित्व है; यह "नहीं" कहने और heroic rewrite के बजाय मौजूदा system को तराशने वाली सोच के अधिक अनुकूल है
• यह दृष्टिकोण इस दोहरी वास्तविकता को स्वीकार करता है कि code सस्ता हो गया है और complexity अब भी apex predator है, और यही computer programming की कला को बचाए रखने का एक उत्पादक तरीका है

[GN⁺]

Lobste.rs की राय

• Peter Naur का 1985 का लेख Programming as Theory Building आजकल कई बार फिर से पढ़ने लायक लगता है

• यह कहना कि “LLM जटिलता से डर नहीं सकता” मुझे कुछ बढ़ा-चढ़ाकर कहा गया लगता है
  असफलता के पैटर्न सचमुच मौजूद हैं। निर्देश बहुत खुले छोड़ दिए जाएँ तो LLM परतें जोड़ता है, abstractions बना देता है, और समस्या की तुलना में अक्सर ज़रूरत से ज़्यादा कोड लिख देता है। लेकिन उस व्यवहार को देखना आसान है, review करना आसान है, और हैरानी की बात यह है कि दिशा बदलवाना भी आसान होता है। AGENTS/CLAUDE.md फ़ाइलों से आप मनचाहा software style सेट कर सकते हैं
  बस उससे सबसे छोटा बदलाव माँगिए, पूछिए क्या हटाया जा सकता है, और पूछिए कि वह abstraction अपनी कीमत वसूल भी कर रहा है या नहीं। invariants, coupling points, और cognitive load के बारे में भी पूछिए, और cleverness हटाने के लिए second pass माँगिए, तो आमतौर पर वह उस दबाव का पालन करता है। इसे prompt में डाल दें तो शुरुआत से ही उससे बचाया जा सकता है
  जोखिम इस बात में नहीं है कि LLM कभी भी जटिलता का सम्मान नहीं कर सकता, बल्कि इस बात में है कि आसपास की process जिस तरह के code shape को reward करती है, वह खुशी-खुशी वही बना देता है। जो टीमें quantity को reward करती हैं उन्हें quantity मिलती है, और जो simplicity को reward करती हैं उन्हें आम तौर पर वह भी मिल सकती है
  आज के model ज़्यादातर इंसानों से बेहतर हैं और आगे और बेहतर होंगे। अगर code अच्छा नहीं है, तो AI labs पर feedback के ज़रिए दबाव डालना चाहिए। उदाहरण के लिए, मेरी राय में GPT सीरीज़ अच्छे documentation लिखने में बहुत खराब है

  • बात सही भी है और पूरी तरह सही भी नहीं। मुद्दा capability से ज़्यादा training style और objective का लगता है। अभी चलन में “पूरे project को vibe coding से बना दिया” जैसी चीज़ें हैं, और LLM शुरुआत से कुछ बनाने की तुलना में मौजूदा code को बदलने में बहुत कमजोर हैं। इसकी बड़ी वजह training method हो सकती है, और statistical bias भी दिखता है। बड़े और जटिल codebase का code छोटे और सरल project से कहीं ज़्यादा है, इसलिए training में उसका weight भी ज़्यादा रहा होगा
    इसलिए “असंभव है” कहना शायद सबसे अच्छा शब्द नहीं है, लेकिन मुझे लगता है कि default रूप से जटिलता की तरफ झुकाने वाले कई bias मौजूद हैं
    और “कुछ न करने” की तुलना में कुछ कर देने का bias भी है। अच्छे programmer किसी manager के सीधे request से कहीं ज़्यादा context इस्तेमाल करते हैं, और विकल्प भी सुझाते हैं। LLM भी शायद ऐसा कर सकता है, लेकिन अभी के LLM “planning के दौरान सवाल पूछना” या repetition detection code होने पर भी सही सवाल पूछने में बहुत अच्छे नहीं हैं। संभव है कि ऐसा training data भी आम न हो
    कुछ मायनों में prompt engineering, इस पूरे problem bundle के चारों ओर की गई एक भयानक hacking जैसी लगती है
  • मैं नहीं जानता कि मैं उस वाक्य से पूरी तरह सहमत हूँ या नहीं, लेकिन वहाँ निश्चित ही कुछ है। एक तरफ, मैंने ऐसा “आम तरह का complexपन” देखा है जहाँ single-target Makefile काफ़ी होता, फिर भी वह default में एक विशाल CMake project बना देता है
    दूसरी तरफ, मुझे “मैं इसे एक महीने के project के लिए recommend नहीं करूँगा। इसे इसी हालत में commit करके demo के तौर पर छोड़ दें, कैसा रहेगा?” जैसे जवाब मिले हैं, और फिर मुझे LLM को मनाना और आश्वस्त करना पड़ा। जबकि मुझे पता था कि दोनों ही एक घंटे से कम में हो जाएँगे। लेकिन अगर आप कहें “ठीक है, कुछ बिल्कुल नया करके देखो। तरीका तुम खुद ढूँढो,” तो वह कोशिश करता है, तो उस अर्थ में यह भी कहा जा सकता है कि उसमें डर नहीं है
  • Lobsters पर “vibe coding” को लेकर इतना nuanced discussion? लगता है नरक जम गया /s
    मज़ाक अपनी जगह, मैं सहमत हूँ। यह मेरे अनुभव से भी मेल खाता है

• “कोड को समझने की लागत और महँगी हो गई है” इस बात से मैं सामान्य रूप से सहमत नहीं हूँ
  बिना सोचे-समझे generate किया गया LLM code हो तो यह सही हो सकता है, लेकिन सही guidance मिले तो LLM पढ़ने में आसान और अच्छी तरह layered code भी बना सकता है। हाँ, उस स्थिति में architecture के ज़्यादातर फ़ैसले इंसान ही करता है, और मेरा मानना है कि वैसे भी ऐसा ही होना चाहिए
  उलटे उदाहरण के तौर पर, मुझे लगा कि किसी अनजाने व्यक्ति द्वारा लिखे गए code को समझने में LLM बहुत सक्षम है। आप Claude Code से किसी खास code का गहराई से analysis कराकर, हर हिस्से को समझाने वाला Markdown document बनवा सकते हैं, और यह सुझाव भी ले सकते हैं कि review या समझना किस क्रम से शुरू करना चाहिए
  यह सच में बहुत मूल्यवान है

  • अनजान code पर LLM इस्तेमाल करने का मेरा अनुभव आम तौर पर अच्छा रहा है, लेकिन जो हिस्से conventions से हटकर होते हैं वहाँ यह रचनात्मक ढंग से बातें गढ़ता है और झूठ बोलता है। समस्या यह है कि code अनजान होने की वजह से इन दोनों में फर्क करना मुश्किल होता है

• “इंसान आम तौर पर exponential curve को अच्छी तरह नहीं समझते। इसलिए वे compound interest जैसी परियों की कहानियों पर विश्वास करते हैं” — क्या इसका मतलब compound interest भी परियों की कहानी है? या मैं कुछ गलत समझ रहा हूँ?