आने वाला लूप

 (lucumr.pocoo.org)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • coding agent के बाहर, जहाँ work queue और harness iteration को मैनेज करते हैं, वह harness-level loop agent engineering का नया केंद्रीय पैटर्न बनकर उभर रहा है
  • मॉडल जितनी देर तक autonomously चलता है, उतना ही strong invariant की बजाय local defense और fallback जोड़ना आसान हो जाता है, जिससे long-term maintenance वाले code में design understanding और control कमजोर पड़ सकते हैं
  • इसके उलट, code porting, performance experiment, security scan और research जैसे क्षेत्रों में, जहाँ नतीजों को verify करना या फेंक देना आसान है, वहाँ mechanical iteration पहले से ही बहुत प्रभावी ढंग से काम कर रहा है
  • जब attacker और reporter loop चलाते हैं, तो maintainer पर भी triage, reproduction और response के लिए मशीनों का उपयोग करने का दबाव बढ़ता है; curl का मामला AI-generated report से पैदा होने वाले बोझ को दिखाता है
  • आगे की चुनौती यह नहीं है कि loop का उपयोग करना है या नहीं, बल्कि यह है कि उसके भीतर भी मानवीय निर्णय, engineering नियम, जिम्मेदार supervision और समझ में आने वाली architecture को कैसे बनाए रखा जाए

coding agent के बाहर चलने वाले loop

  • coding agent के भीतर पहले से ही एक agent loop मौजूद है, जहाँ मॉडल tools call करता है, नतीजों को reflect करता है, files पढ़ता और बदलता है, tests चलाता है और फिर जवाब देता है
  • नया उभरता हुआ पैटर्न उसके बाहर का harness-level loop है
    • task queue में जाता है
    • मशीन task उठाकर उसे करने की कोशिश करती है
    • रुकने के बाद harness तय करता है कि काम सचमुच पूरा हुआ या नहीं
    • अगर पूरा नहीं हुआ, तो वही session में message inject किया जाता है, बदले हुए context के साथ नया session शुरू किया जाता है, या task किसी दूसरी मशीन को दे दिया जाता है
  • यह बाहरी loop काम को उस बिंदु के बाद भी ज़िंदा रखता है, जहाँ मॉडल आमतौर पर कहता कि “काम हो गया”
  • loop खुद नया नहीं है, लेकिन हाल में agent engineering और Twitter की चर्चाओं में यह ज्यादा दिखने लगा है
  • Pi पर भी इस तरह का कुछ प्रवाह दिखाई देता है, और क्योंकि Pi एक harness है, इसलिए वह ऐसे प्रयोगों के केंद्र में है

लंबे समय तक maintain होने वाले code में पैदा होने वाली असहजता

  • जिस code की गहराई से परवाह हो, उसके लिए यह तरीका अभी बहुत अच्छा फिट नहीं बैठता
  • असली बात पसंद और control की है
    • आप उस code को समझना चाहते हैं जिसे आप deploy करते हैं
    • दबाव की स्थिति में या दूसरों से चर्चा करते समय, आपको सिस्टम कैसे काम करता है यह मशीन से पहले खुद समझा पाना चाहिए
    • अभी भी code की समझ महत्वपूर्ण है
  • हाथ हटाकर generated code, खासकर loop से निकला code, बार-बार कुछ समस्याएँ दिखाता है
    • यह जरूरत से ज्यादा defensive होता है
    • बहुत जटिल होता है
    • local reasoning तक सीमित रहता है
    • strong invariant से बचता है
    • गलत state को असंभव बनाने की बजाय fallback जोड़ता है
    • duplicate code और खराब abstraction बनाता है, और अस्पष्ट design को और चीजों से ढक देता है
  • Claude Code और Fable जैसी जोड़ियाँ एक ही समस्या पर 30 मिनट से ज्यादा बिना रुके काम कर सकती हैं, जिससे पहले की तुलना में human in the loop कम हो जाता है
  • अभी हाथ हटाकर harness-आधारित तरीके से बनने वाले code की गुणवत्ता इतनी खराब लगती है कि यह पिछले पतझड़ से भी बदतर महसूस होती है; कम-से-कम इस पसंद के हिसाब से सुधार बहुत कम दिखता है

loop मॉडल की आदतों को बढ़ा देता है

  • मॉडल local failure देखकर local defense जोड़ने की ओर झुकता है
  • Andrej Karpathy ने कहा है कि मॉडल exception से “घातक रूप से डरते” हैं
  • जिन systems में महत्वपूर्ण invariant होते हैं, खासकर persistent data format या core infrastructure में, वहाँ “हर malformed case को handle करो” वाला तरीका सही fix नहीं भी हो सकता
    • बेहतर दिशा यह हो सकती है कि malformed case को व्यक्त ही न किया जा सके, या शुरू से लिखा ही न जा सके
    • LLM, बहुत manual steering के बावजूद, ऐसा code स्वाभाविक रूप से निकालने में कठिनाई महसूस करता है, और वह उन errors को भी handle करने की कोशिश कर सकता है जिन्हें असंभव बना दिया गया हो
  • जब इस आदत को loop के पीछे रखा जाता है, तो समस्या बढ़ जाती है
    • हर iteration एक छोटा defense और जोड़ता है
    • system ज्यादा robust दिखता है, लेकिन उसे समझना लगातार मुश्किल होता जाता है
    • जितना ज्यादा हाथ हटता है, यह प्रवृत्ति उतनी बढ़ती है
  • अगर किसी junior को बिना स्पष्ट guidance के ऐसे tools दे दिए जाएँ, तो वे खराब practices सीख सकते हैं
    • और वजह पूछने पर वे अपने चुनाव का भरोसेमंद बचाव भी कर सकते हैं

जहाँ loop अच्छी तरह फिट बैठता है

  • loop pattern कुछ क्षेत्रों में पहले से ही बहुत अच्छी तरह काम कर रहा है
  • code porting इसका प्रतिनिधि उदाहरण है
  • performance exploration में भी यह उपयुक्त है
    • मशीन experiment आजमाती है
    • benchmark चलाती है
    • failure को फेंक देती है
    • और खोज जारी रखती है
  • security scan और लगभग हर तरह की research में भी यह स्वाभाविक रूप से फिट बैठता है
    • जटिल problem space को explore कराया जा सकता है और results report कराए जा सकते हैं
    • जरूरी नहीं कि लंबे समय तक रहने वाला code commit ही करना पड़े
  • सफल उदाहरणों में एक समान बात यह है कि output को लंबे समय तक maintain करने की जरूरत नहीं होती, या वह existing code का transformation होता है, या वह proof of concept, idea, discovery, या mechanical transformation के ज्यादा करीब होता है
  • harness को पूरी तरह objective या binary signal की जरूरत नहीं होती, बल्कि ऐसे signal की जरूरत होती है जो अगली iteration को आगे बढ़ाने लायक उपयोगी हो
    • कई सफल उदाहरणों में दूसरा LLM judge या orchestrator की तरह इस्तेमाल होता है
    • mechanical translation को binary test case से verify किया जा सकता है, या LLM से judge कराया जा सकता है
  • Claude Code पूरे experiment workflow को बनाने और चलाने में लगातार ज्यादा सक्षम हो रहा है
    • generated code भले messy हो, पर वह harness की judgment क्षमता से ज्यादा मॉडल की समस्या है

software को मशीन की बजाय जीवधारी जैसा मानने की ओर बदलाव

  • जो code टिकेगा, उसे उसी loop तरीके से लिखना अभी सहज नहीं लगता
  • पुराना आदर्श software को एक deterministic machine की तरह समझने के करीब था
    • एक layer हटाने पर आप और गहराई से समझ पाते थे
    • जो machine non-deterministically दिखे, उसे आदर्श नहीं माना जाता था
    • architecture का ज्यादा determinism की ओर जाना वांछनीय समझा जाता था
    • यह अच्छी design मानी जाती थी कि नया engineer भी जटिल codebase को explore कर सके
  • अच्छी तरह designed system में ऐसे engineer होते थे जो जानते थे कि invariant कहाँ हैं, कौन-से हिस्से load-bearing हैं, और कौन-से बदलाव सुरक्षित हैं
  • बड़ा software पहले से ही किसी एक इंसानी दिमाग में पूरा नहीं समाता, और distributed system का diagnosis कभी-कभी वैसे होता है जैसे डॉक्टर symptoms देखकर hypothesis बनाता है और और tests लिखता है
  • LLM इस दिशा को और तेजी से आगे धकेल रहा है
    • production issue होने पर मशीन logs पढ़ती है
    • root cause सुझाती है
    • patch भेजती है
    • दूसरी मशीन review करती है, और कभी-कभी बिना human supervision के main में मिला भी देती है
  • यह तरीका शक्तिशाली और आकर्षक है, लेकिन संभव है कि इंसान पूरे system को पहले जैसी तरह न समझ पाएँ
    • वे उसे संभालें, monitor करें, stabilize करें, लेकिन जरूरी नहीं कि पूरी तरह समझें
  • हर code को human authorship की जरूरत नहीं होती, और पहले भी इससे खराब code लिखा गया हो सकता है

पूरी तरह बाहर निकलना मुश्किल करने वाला दबाव

  • पूरी तरह machine-driven future से opt out करना मुश्किल हो सकता है
  • security इसका सबसे स्पष्ट उदाहरण है
    • भले आप खुद loop से software न बनाते हों, दूसरे लोग उसी software पर loop चला रहे होते हैं
    • attacker मशीनों को लगातार चलाते हैं
    • attacker न भी हों, तो security researcher automated काम करते हैं
    • नतीजतन, असली issue और noise साथ-साथ आने लगते हैं
  • Daniel Stenberg की curl पर लिखी summer of bliss post दिखाती है कि maintainer पहले से किस दबाव में हैं
    • ऐसा नहीं लगता कि curl के core development में AI की बहुत बड़ी भूमिका है
    • फिर भी maintainer reports से दब रहे हैं, और उनमें से ज्यादातर AI-generated reports हैं
  • जब attacker और reporter loop चलाते हैं, तो defender को भी साथ चलना पड़ता है
    • जरूरी नहीं कि सीधे patch लिखने के लिए
    • लेकिन triage, reproduction और response के दबाव के कारण मशीनों का उपयोग करना पड़ सकता है
  • competitive pressure भी कुछ ऐसा ही है
    • कुछ teams सिर्फ speed के दम पर दूसरी teams से ज्यादा बना सकती हैं
    • अगर कोई छोटा group मशीनों को अच्छी तरह orchestrate करे, तो project अचानक बहुत तेज हो सकता है
    • कुछ startup अब वह काम 5 लोगों से कर सकते हैं जिसके लिए पहले 50 लोग चाहिए होते
    • कोई आपके product पर loop चलाकर उसे “कुछ और जैसा बना दो” भी कह सकता है
  • हर software एक जैसा प्रभावित नहीं होगा
    • कुछ क्षेत्रों में लापरवाही की सजा मिलती है और trust व accountability की मांग होती है
    • बहुत-से software में speed, तेज experimentation और व्यापक coverage बहुत महत्वपूर्ण हैं

loop से बनती नई dependency

  • loop से बने tools सिर्फ एकबारगी लागत नहीं हैं, वे लगातार चलने वाली cognitive dependency बना सकते हैं
  • पहले software development compiler जैसे costly tools पर निर्भर था, लेकिन आज के tools ऐसे system के ज्यादा करीब हैं जिन तक लगातार पहुँच चाहिए
  • अगर codebase loop से बनता है, loop से review होता है, loop से patch होता है और loop से maintain होता है, तो वैसी ही system access रुकने पर समस्या होगी
    • trade restriction के कारण सबसे शक्तिशाली model तक पहुँच खत्म हो सकती है
    • लागत असहनीय हो सकती है
    • team मशीन के बिना code समझने की अपनी आखिरी क्षमता खो सकती है
  • ऐसे codebase बन सकते हैं जो सिर्फ इंसानों के लिए maintain करना कठिन नहीं, बल्कि जिनका maintenance model ही मशीन की भागीदारी को मानकर चलता है
  • कुछ बदलाव अभी से दिख रहे हैं
    • ऐसे लोग बढ़ रहे हैं जो ऐसा code merge कर देते हैं जिसे वे पूरी तरह समझा नहीं सकते
    • issue report या chat discussion को मशीन द्वारा दिए गए context से मजबूत या rewrite किया जाता है
    • summary और context-setting के लिए मशीन पर निर्भरता बढ़ रही है
    • लोग LLM के जरिए बात करने लगे हैं
  • यह जरूरी नहीं कि पूरी तरह गलत हो, लेकिन यह पुराने तरीके से बहुत बड़ा बदलाव है

आगे किन harness और tools की जरूरत है

  • सिर्फ और ज्यादा loop orchestrate करना काफी नहीं होगा
  • changes, orchestration और agent को बेहतर visualise कर देने भर से understanding अपने-आप वापस नहीं आ जाएगी
  • जरूरत की दिशा दो में से एक है
    • या तो इंसान को फिर से जोरदार तरीके से loop में वापस लाया जाए और loop के बदलावों को लंबे समय तक पढ़ने योग्य बनाया जाए
    • या फिर बढ़ती जटिलता वाले system को बेहतर ढंग से compose करने के तरीके खोजे जाएँ
  • Pi को लेकर सोच भी बदल रही है
    • Pi सतर्क था, और वह सतर्कता अच्छी है
    • ऐसा भविष्य नहीं चाहिए जहाँ हर interaction ऐसे machine swarm के बदलाव में बदल जाए जिसे follow करना मुश्किल हो
    • यह भी नहीं चाहिए कि Pi, खुद लिखे जाने वाले software की competition जीतने के लिए unmaintainable chaos बन जाए
    • और यह भी नहीं चाहिए कि Pi ऐसी engineering को बढ़ावा दे
  • फिर भी Pi एक harness है, और harness ऐसे नए experiments के केंद्र में है
  • coding task queue, agent orchestration, subagent, durable session लगातार अधिक महत्वपूर्ण होते जाएँगे
  • जो लोग loop को आँख बंद करके स्वीकार नहीं करना चाहते, उन्हें भी experiment शुरू करना होगा
    • क्योंकि यह समझना जरूरी है कि इस future को सीमा के भीतर रखकर सहने योग्य कैसे बनाया जाए

loop को control करने का सवाल

  • अगर harness loop को स्वीकार कर लिया जाता है, तो काम कब खत्म हुआ यह harness तय करता है
  • agent loop में मॉडल आखिरकार “done” कहता है और इंसान review करता है
    • उससे पहले भी आमतौर पर इंसान बीच में steering करता है
    • इंसान शामिल रहता है, और उसी प्रक्रिया में सीखता भी है
  • harness द्वारा चलाए जाने वाले loop में इंसान की भूमिका अस्पष्ट हो जाती है
    • “done” signal भी अपना अर्थ खो देता है और दूसरी मशीन के लिए judgment message बन जाता है
    • इंसान की भूमिका messenger जैसी रह सकती है
  • अभी इस तरह बने code का बड़ा हिस्सा पसंद नहीं आता, और AI-assisted software के साथ interaction भी सुखद नहीं लगता
  • loop शक्तिशाली है, लेकिन वह जिम्मेदारी को धीरे-धीरे हटाता है, और फिलहाल उसमें मशीन के आगे झुक जाने को बढ़ावा देने वाला पहलू है
  • फिर भी loop का भविष्य आता हुआ लगता है
    • बहुत छोटी teams के ऐसे उदाहरण पहले से दिख रहे हैं जो असंभव लगने वाली गति से निर्माण कर रही हैं
    • codebase ज्यादा अस्पष्ट और अव्यवस्थित जीवधारी जैसे बनते जा रहे हैं
    • ऐसे codebase एक साथ उपयोगी भी हैं और messy भी
  • आगे का सवाल “क्या loop चलाया जाएगा” नहीं, बल्कि कुछ ऐसा है
    • loop के भीतर judgment छोड़े बिना कैसे काम किया जाए
    • अच्छी engineering rules को कैसे बनाए रखा जाए
    • जिम्मेदार इंसान supervision कैसे जारी रख सकें
    • और code architecture को इस तरह कैसे फिर से सोचा जाए कि मानसिक संतुलन बना रहे

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • Loop तब काम करता है जब आप पहले से यह समझने में पर्याप्त समय लगाते हैं कि आप वास्तव में क्या चाहते हैं। इसकी पूर्वशर्त स्पष्टता है, और वह भी इतनी कि आप ऐसी सावधानीपूर्वक specification लिख सकें जिसे किसी junior सहकर्मी को सौंपा जा सके।
    आम तौर पर उस समझ तक पहुँचने के लिए 5~6 टूटी-फूटी, अधपकी versions से गुजरना पड़ता है। ये 5~6 trial-and-error चरण तेज़ नहीं किए जा सकते, और कोई भी agent तकनीक इंसानी दिमाग के सोचने में लगने वाला समय टाल नहीं सकती। इसलिए ज़्यादातर समय “मुझे नहीं पता कि मैं क्या चाहता हूँ, मुझे code पढ़कर, लिखकर, छेड़छाड़ करके देखना होगा” और “अब काफ़ी समय बीत गया है, शायद अब मुझे पता है कि मैं क्या चाहता हूँ” के बीच आता-जाता बीतता है। खुद को धोखा देना बहुत आसान है, लेकिन आप Loop तभी इस्तेमाल कर सकते हैं जब आपको सच में पता हो कि आप क्या चाहते हैं। बहुत से लोग सोचते हैं कि वे agent के सहारे इस चरण को पार कर सकते हैं, लेकिन समझ और स्पष्टता की नकल नहीं की जा सकती, और जो लोग इस चरण को छोड़ते हैं, वह दर्दनाक रूप से साफ़ दिखाई देता है

    • मैंने Codex से मेरे सारे pi sessions निकालने वाला एक tool बनवाया। मुझे prompts और sub-agent बातचीत को filter करना पड़ा, फिर उससे उन patterns का analysis करवाया जो मैं बना रहा था, और उसे बाहरी guide generation prompt के flowchart में बदलवाया।
      मुझे लंबे समय तक यह सोचने की ज़रूरत नहीं थी कि मैं क्या चाहता हूँ; मैं बस चाहता था कि वह यह करे। नतीजा अभी भी मिला-जुला है, और मैं अभी इतना भरोसा नहीं करता कि इसे किसी नाज़ुक codebase पर छोड़ दूँ, लेकिन जिस game पर मैं काम कर रहा हूँ उसमें verification पर लगने वाला समय पहले का 1/5 रह गया है। यह पूरी तरह अच्छी बात भी नहीं है। कम समय लगाने की वजह से शायद मैं अच्छे ideas मिस कर रहा हूँ। लेकिन पहले prompts यांत्रिक रूप से #now-do-this, #now-review-that बन गए थे और 90% सही सुझावों की अवस्था में अटके हुए थे। अब यह अपने-आप याद दिलाता है कि “पहले कठिन चीज़ें करो, और चलते-चलते organize/refactor करो”, और पहले return के बाद “काम पर दोबारा नज़र डालो”, ताकि बची हुई समस्याएँ उगलवाई जा सकें; फिर उन्हें guide generation prompt में डालकर नए tasks बाँटे जा सकते हैं
    • मैं पूरी तरह सहमत हूँ कि 5~6 टूटी versions से गुजरना पड़ता है। लेकिन एक बार मुझे ऐसा harness (prompt + skill + model) मिल गया जिस पर भरोसा हो कि वह ज़्यादातर चीज़ें मेरे पसंदीदा तरीके से संभाल लेगा, तो इस प्रक्रिया का coding और exploration वाला हिस्सा तेज़ हो गया।
      iteration तेज़ हुई है, लेकिन उन अधपकी versions से गुजरने में लगने वाली मेहनत लगभग उतनी ही है। क्योंकि अभी भी यह समझना पड़ता है कि कौन-सा idea, principle, design समाधान पर फिट बैठता है, अगला क्या आज़माना है, और अपने mental model को कैसे adjust करना है। कुल मिलाकर ऐसा लगता है कि कम समय में ज़्यादा mental effort लग रही है, और code लिखने में बस थोड़ी-सी बचत हो रही है। जब आप अनुभवी हो जाते हैं, तो code टाइप करना शुरू से ही काम का बड़ा हिस्सा नहीं था। आप “बस” prompt लिखते हैं और code पढ़ते हैं, फिर भी उतनी ही थकान होती है, या compressed iteration cycle की वजह से कभी-कभी उससे भी ज़्यादा

  • मैं अब यह हर दिन देख रहा हूँ, और यह निराशाजनक और चिंताजनक है। मेरा मानना है कि हम ज़्यादा ऐसा code merge कर रहे हैं जिसे हम पूरी तरह समझा नहीं सकते, क्योंकि पहले जो mental model हम code लिखने और collaborative technical planning से बनाते थे, उसे अब code review पर छोड़ दिया गया है।
    code review इस उद्देश्य के लिए उपयुक्त नहीं है। हाँ, मुझे लगता है कि pedagogy से प्रेरित structured exercises को code review के साथ जोड़कर friction और understanding के बीच बेहतर संतुलन बनाया जा सकता है। मैं ऐसे exercises को test करने में मदद ढूँढ़ रहा हूँ

    • प्रभावी code review करना, code लिखने से कहीं अधिक कठिन skill है। अगर आपके पास यह अच्छा map नहीं है कि किसी बदलाव का system के दूसरे हिस्सों पर क्या असर होगा, तो यह लगभग औपचारिक मुहर लगाने जैसा अनुष्ठान बन जाता है।
      GitHub का कमजोर PR UI भी मदद नहीं करता। उन हिस्सों की खोज करने के tools सीमित हैं जो सीधे बदले नहीं गए, लेकिन फिर भी प्रभावित हुए हैं, ताकि वहाँ समस्याएँ ढूँढ़कर highlight की जा सकें
    • https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • मैं जानना चाहता हूँ कि आपका product क्या है। मैं ज़रूर देखना चाहूँगा कि ऐसा product कैसा दिखता है जिसे agents की फौज ने इंसानी baseline से 100x स्तर पर develop किया हो। वह शानदार लग रहा है
    • ऐसा code अक्सर security vulnerabilities से भरा होता है। यह hacks पर hacks चढ़ाने जैसा होता है, और जो काम 1,000 lines में ज़्यादा स्थिरता से हो सकता था, वह 100,000 lines के code में खत्म होता है जो अजीब alternate paths से भरा पड़ा होता है।
      मूल लेख की यह बात बहुत महत्वपूर्ण है कि गलत boundary conditions को alternate paths से handle करने के बजाय असंभव बना देना चाहिए। alternate-path तरीका alternate paths के ऊपर और alternate paths बनवाता है, और हर alternate path code की मात्रा को घातीय रूप से बढ़ाता है और किसी न किसी तरह हमेशा नई समस्याएँ पैदा करता है। इसे लगभग “system design का general law” कहा जा सकता है। alternate paths failure risk तो घटाते हैं, लेकिन जब failure सच में होता है, तो उसे और ज़्यादा complex और हानिकारक बना देते हैं। एक software engineer के रूप में मुझे AI द्वारा बनाया जा रहा नया coding environment पसंद है। क्योंकि Big Tech ने मेरे लिए अनंत काम पैदा कर दिया है। human developers code execution के core component बन गए हैं, और उन्हें लगभग अनंत कठिन unhandled exceptions से निपटने के लिए हमेशा standby रहना पड़ता है, जो कभी-कभी ज़रूर सामने आएँगे। अब software engineer मज़दूर से ज़्यादा, उस security guard जैसा हो गया है जो ज़्यादातर समय डेस्क पर बैठकर कॉफ़ी पीता है और बीच-बीच में समस्या आने पर दखल देता है

  • यह कई महीनों से मैं जो कह रहा हूँ, उसी की निरंतरता है। LLM काम पूरा करने में शानदार हैं, लेकिन aesthetics और taste में कमज़ोर हैं।
    काम दो तरह का होता है। एक है goal-oriented work, जिसमें हासिल करने के लिए एक लक्ष्य होता है और वहाँ तक पहुँचने का तरीका बहुत मायने नहीं रखता। security इसका बेहतरीन उदाहरण है। अगर आपको किसी system को exploit करना है, तो exploit सुंदर है या नहीं, इसकी आपको लगभग परवाह नहीं होती; आप बस top-secret nuclear plan तक पहुँचना चाहते हैं। research भी कुछ ऐसा ही है, इसलिए “research quality” code AI युग से पहले भी बदनाम रूप से बेतरतीब था। दूसरा है taste-oriented work। जब आप किसी बड़े codebase में feature जोड़ते हैं, तो लगता है कि लक्ष्य वही feature जोड़ना है, लेकिन अक्सर ऐसा नहीं होता। असल में उस codebase को भविष्य के बदलावों को अच्छे से स्वीकार करने लायक बनाए रखना उस खास feature से कहीं ज़्यादा महत्वपूर्ण होता है, और इसके लिए taste चाहिए। maintainability और code quality एक ही चीज़ नहीं हैं; code quality सिर्फ़ एक साधन है, और उसका उद्देश्य maintainability है

    • बहुत-सी organizations तेज़ी से ऐसी दुनिया की ओर बढ़ रही हैं जहाँ code quality और maintainability को कोई प्राथमिकता ही नहीं दी जाती। अगर Claude code लिखने वाला है, तो क्या यह मायने रखता है कि वह code “maintainable” है या “high quality”? इस नज़रिए से जवाब है नहीं। बस काम करे और तेज़ हो, इतना काफ़ी है

  • LLM का उन मामलों को भी स्वाभाविक रूप से संभालने की कोशिश करना, जहाँ वह गलत है, कई PR reviews में लंबे समय से संघर्ष का विषय रहा है। खासकर एक बार कोड लिखे जाने के बाद, यह समझाना बहुत मुश्किल होता है कि ज़रूरत से ज़्यादा null checks हानिकारक हैं
    बेहतर modeling, और sum types की अनुमति देने वाली भाषा के बिना, इस तरह की “shotgun parsing” के खिलाफ कोई सार्वभौमिक रूप से असरदार दलील मुझे अब तक नहीं मिली। शायद यह वास्तव में कोई बहुत बड़ी समस्या न हो। लेकिन जब codebase को सच में पढ़ना और refactor करना पड़ता है, तब ऐसी गैर-ज़रूरी checks को संभालना हमेशा परेशान करने वाला रहा है। एक बार ये अंदर आ जाएँ, तो logging या व्यापक investigation पहले जोड़े बिना इन्हें सुरक्षित रूप से हटाना लगभग असंभव हो जाता है

    • एक तर्क जो अक्सर काम करता है, वह यह है कि optional values असल में program की possible state space को branch कर देती हैं। state space जितनी बड़ी होती है, code के बारे में तर्क करना और उसका maintenance करना उतना कठिन हो जाता है
      यही उस बात का सार भी है कि अवांछित states को व्यक्त ही न किया जा सके
    • AI code review हद से ज़्यादा और भ्रमपूर्ण defensive paranoia को बढ़ावा देता है। किसी function के गहरे भीतर triple null check करना तकनीकी रूप से वास्तविक risk हो सकता है, लेकिन व्यवहार में वह अक्सर ऐसा case होता है जहाँ उस function को call करने वाले, या call कर सकने वाले, सभी functions में null check पहले ही हो चुका होता है, इसलिए वहाँ पहुँचना ही नहीं चाहिए, और शायद उसकी रक्षा करना मूल्यवान भी नहीं है
    • यह मायने रखता है कि आप कितने असंभव cases की बात कर रहे हैं। मैं खुद काफ़ी defensive programming करता हूँ
      भले ही अभी इस function को कुछ भी negative न भेजता हो, future code changes से उस assumption का टूटना कितना मुश्किल होगा? मुझे हमेशा लगा है कि स्पष्ट error सबसे अच्छा है। इससे codebase से अपरिचित व्यक्ति भी समझ सकता है कि input की valid range के बारे में कौन-सी assumptions हैं, और असंभव outliers पर विचार करने की ज़रूरत नहीं रहती

  • मेरी bottleneck specification में है। agent loop अब मेरे लिए अपेक्षाकृत कम महत्वपूर्ण समस्या रह गया है
    अगर मैं जो बनाना चाहता हूँ उसकी स्पष्ट समझ हासिल कर लूँ, और Claude Code के planning mode में implement की जा सकने वाली specification लिखने का लक्ष्य देकर सौंप दूँ, तो agent जब implementation में जाता है तो ज़्यादातर बहुत अच्छे नतीजे देता है। लेकिन इस रणनीति की प्रभावशीलता specification लिखने का बड़ा बोझ मुझ पर डाल देती है। agent आम तौर पर हर specification को बेहतरीन ढंग से संभालता है, और code review आधारित follow-up भी अक्सर 2–3 बार में हो जाता है, लेकिन फिर जल्दी ही हम वापस उस चरण में आ जाते हैं जहाँ नई specification चाहिए। और जब मैं दूर होता हूँ, तब agent ने अपना काम पूरा कर लिया हो, और files overlap न होने से conflict-मुक्त किसी मौजूदा specification को शुरू भी कर सकता हो, तब भी उसे यह नहीं पता होता कि वह नई branch बनाकर शुरू कर सकता है। मैं अक्सर सोने से पहले कहता हूँ, “task X करो, उसे complete करके push करो, फिर task Y शुरू करो,” लेकिन उससे आगे बात नहीं बढ़ती। कई बार Y शुरू करते समय कोई सवाल आ जाता है, और फिर agent बाकी समय रुका रहता है। आख़िरी समस्या ऊपर वाली बात से जुड़ी dependency है। उदाहरण के लिए, आज मैंने एक background job processor लिखा, और स्वाभाविक रूप से बाद के कामों के jobs को उस system की ज़रूरत होगी। ऐसा काफ़ी बार होता है। implementation के दौरान तय हुई details को दर्शाने के लिए specification को implementation के बाद update भी करना पड़ता है। फिर भी, अब लगता है कि outer loop की ज़रूरत पड़ने ही वाली है। bottleneck लगभग पूरी तरह specification writing और PR review में है। जहाँ वह bottleneck महत्वपूर्ण नहीं है, वहाँ मैं चाहता हूँ कि agent चलता रहे। और साथ ही, मुझे मज़बूती से लगता है कि हमें ऐसे tools इस्तेमाल करने शुरू कर देने चाहिए जो हमारे लिए भले कम अच्छे हों, लेकिन LLM के लिए बेहतर हों। उदाहरण के लिए, Rust का compiler मेरे लिए बहुत सख़्त होने के कारण झुंझलाहट भरा है, लेकिन LLM के लिए शानदार है

    • यही तरीका होना चाहिए। शानदार। पिछले 20 वर्षों में “जल्दी बनाओ” वाली प्रवृत्ति के बीच system engineering का यह सबसे महत्वपूर्ण हिस्सा सिमटता गया था
      अब जब बनाना अधिक automated हो गया है, तो specification और system design फिर से महत्वपूर्ण अग्रणी भूमिका निभा सकते हैं। हो सकता है engineering और quality वापस आएँ
    • यह मेरे coding अनुभव से भी मेल खाता है, और उस अपेक्षा से भी, जिसे मैं वर्षों से कहता आया हूँ कि AI को coding सच में solve करने में अभी लंबा रास्ता तय करना है। programming का कठिन हिस्सा keyboard दबाकर file में code भरना नहीं है, बल्कि समस्या को समझना और एक साफ़, scalable, अच्छा समाधान सोचना है
      AI तकनीकी रूप से काम करने वाले ठीक-ठाक solutions बनाने में बहुत अच्छा है, लेकिन solution के लिए अच्छी vision रखने में काफ़ी कमज़ोर है। विचारों का आदान-प्रदान करके और खोजबीन के ज़रिए समझ बढ़ाने में यह अब भी बहुत उपयोगी है, लेकिन ऐसा अच्छा specification लिखना जिसे LLM implement कर सके, खुद code लिखने से बहुत आसान नहीं है
    • नीचे दिया गया चीज़ उस समस्या को हल कर सकता है
      https://www.aihero.dev/skills-handoff
      /handoff अब मेरी नई सबसे पसंदीदा skill है
      https://www.youtube.com/watch?v=dtAJ2dOd3ko
    • मैं जानना चाहता हूँ कि “बहुत अच्छे नतीजे” को कैसे परिभाषित किया जा रहा है। क्या सफलता की परिभाषा में साफ़ और maintainable code शामिल है? मुझे लगातार loop के भीतर रहना पड़ता है। मेरा code हज़ारों users तक deploy होता है, इसलिए कोई भी समस्या बढ़ जाती है
    • “specification लिखना” programming की मूलभूत जटिलता है। अंत में बात यही है कि कोई silver bullet नहीं है
      agent हो या न हो, punch cards हों या interpreter, आख़िरकार programming तो programming ही है

  • LLM की सबसे बड़ी code smell यह है कि वह “हर गलत case को handle” करने की कोशिश करता है, और अब तो ऐसे errors भी handle करने लगता है जो हो ही नहीं सकते। पता नहीं इसे ऐसी धुन क्यों सवार रहती है
    Python में यह अक्सर ऐसे दिखता है कि पूरी तरह type-checked codebase में, ऐसे type पर hasattr check लगा दिया जाता है जिसमें वह property पहले से defined है। ऐसा क्यों होता है? सोचता हूँ क्या यह pretraining की वजह से है, या reinforcement learning की वजह से। अगर दूसरा कारण है, तो अच्छा होगा कि labs इसे ठीक करें

    • शायद इसलिए कि missing error handling की तुलना में अनावश्यक error handling की तरफ गलती करना चुना जाता है। संभव है training में runtime errors पर कड़ा penalty लगाया जाता हो
    • मेरा मानना है कि इसकी सबसे बड़ी वजह training data है। मैं भी “गलत state को represent करना असंभव बना दो” वाली टीम में हूँ
      HN पर यह बात बहुत आती है, लेकिन open source हो या नौकरी, मेरे अलावा किसी और के लिखे codebase में जब यह सचमुच अच्छे से किया हुआ दिखता है तो आज भी हैरानी होती है। ज़्यादातर programmers ऐसा सिस्टम बनाने के बजाय जिसमें errors आ ही न सकें और data उसी हक़ीक़त को reflect करे, वहीं जाकर टुकड़े जोड़कर ठीक करते हैं जहाँ error message फूटकर बाहर आता है। मैंने “ज़्यादातर” इसलिए कहा क्योंकि मुझे लगता है कि आज की AI में भी यही सोच अपने-आप में समस्या है। किसी codebase को उस आख़िरी स्तर पर समझना, जहाँ guarantees का पूरा प्रवाह समझ में आए, अभी AI को देना मुश्किल है। raw code स्तर पर ऐसी guarantees अक्सर इतने code में फैली होती हैं कि context window आसानी से भर जाती है। memory-style files में summaries बनाकर भी समस्या हल नहीं होती। guarantees के बारे में text लिखा होने का मतलब यह नहीं कि AI सही जानकारी निकाल लेगा; इंसान भी सिर्फ code पढ़कर हमेशा ऐसा नहीं कर पाते। मैं यह नहीं कहूँगा कि AI को ऐसी समझ देना “असंभव” है, लेकिन मान लें कि ऐसी समझ दे भी दी जाए, तब भी AI के काम करने का तरीका अक्सर उसी समझ के खिलाफ काम करता है। मेरा समाधान ज़्यादातर यह रहा है कि AI से यह समझने की उम्मीद ही छोड़ दो। आम लोग जैसे problems को solve करते हैं, उसी तरह solution को prompt में बदलो, और अगर खराब invalid states को represent करना असंभव बनाना है, तो AI से ज़रूरी refactoring step by step करवाओ। अगर बहुत छोटा काम हो तो खुद कर लो। maps/dictionaries, arrays, strings, और integers से भरे code को धीरे-धीरे ज़्यादा सख़्ती से typed बनाने का काम यह वास्तव में काफ़ी अच्छा करता है। कितना भी विस्तार से लिखो, एक single prompt से अच्छा design बहुत कम निकलता है। इसे दो अलग tasks की तरह लेना ज़्यादा बेहतर बैठता है। और types के फर्क पर बहुत ध्यान देना पड़ता है। AI को .JustSetItAndIgnoreAllThePreAndPostConditions(string) जैसी methods चुपके से घुसाना बहुत पसंद है। लगता है field में ऐसा training data बहुत है जिसमें “error states को represent करना असंभव बनाने के लिए अच्छी तरह structured types” में बाद में कोई maintainer आकर सब तोड़ देता है और JustEffingDoIt method जोड़ देता है। सबसे अच्छा बचाव यह है कि ऐसे types को अलग files में रखो, और जो भी methods जोड़ी जाएँ उन्हें आसानी से skim करके तुरंत पकड़ लो। documentation में यह न करने की चेतावनियाँ और बनाए रखे जाने वाले pre/post-conditions भर देने पर भी बहुत कम फर्क पड़ा
    • क्योंकि training set में मौजूद codebases का भारी बहुमत या तो पूरी तरह type-checked नहीं था, या बिल्कुल clean नहीं था। या फिर वे Stack Overflow snippets थे, जहाँ आसपास का context नहीं होता, इसलिए यह मान नहीं सकते कि null check बेकार है
    • पूरी तरह सहमत हूँ। हर dataclass पर getattr इस्तेमाल करना बहुत अजीब चुनाव है
    • क्योंकि यह सीखे हुए patterns से मेल खाता है। AI code को समझता नहीं है। वह असली logical flow पर reasoning नहीं कर सकता, सिर्फ patterns से काम चलाता है

  • code किसी information system के बारे में साझा और समय के साथ जमा हुई समझ का हिस्सा है
    अगर ऐसे loops हम सबको लगातार टूटकर आती software की लहरों के बीच आगे बढ़ाते रहेंगे, तो सबसे ऊँचे स्तर की logical information system design में आखिरकार इंसानी judgment और business requirements के बीच संतुलन ही सब कुछ होगा। company या market के किसी खास niche में फिट होने के लिए हर programmer को business analyst, market researcher, और entrepreneur बनना पड़ेगा। बस उन खास niches को छोड़कर जहाँ AI tools ठीक से “खड़खड़” नहीं पाते, या तब जब subsidized AI token का यह दौर खत्म हो जाए और ये सारे loops बहुत महँगे पड़ने लगें। यह expert systems और Symbolics Lisp machine के दोहराव जैसा लगता है। कुछ समय के लिए हमारे सामने यह सच आया था कि code खुद इतना सीमित नहीं है, बल्कि company की organizational structure आखिरकार software में जस की तस उतर जाती है; इसलिए अगर company की संरचना नहीं बदल सकते, तो software की flexibility की भी सीमा होगी। data flow diagrams, domain knowledge, domain modeling, और ubiquitous language वह metalanguage बन सकते हैं जिनसे हम quality, features, और non-functional standards व conventions तय करें। “loop चलाने वाले clanker” जब “done” कहें, उससे पहले उन्हें data, behavior, और performance contracts पूरे करने होंगे। अब “done” का मतलब सिर्फ compile होने वाला code, build होने वाला code, deploy होने वाला code, या यहाँ तक कि production में चलने वाला code नहीं है। उसका मतलब ऐसा code है जो users, operators, और maintainers—तीनों की requirements पूरी करे। इसलिए जो language इस्तेमाल की जाएगी, वह हम सबको सिर्फ syntax जानने वालों से ज़्यादा business analysts और software architects के करीब ला सकती है। क्या यह UML का बदला और declarative/logical design/BDD की वापसी है?
    spelling check gemma4-12b से किया था, लेकिन message बदलने नहीं दिया

  • मैं लगातार सोचता रहता हूँ कि कब से मुझे इस loop के भीतर ज़बरदस्ती मौजूद रहने की ज़रूरत नहीं रहेगी। एक developer के रूप में मुझे code structure को निखारना, उसे ज़्यादा स्पष्ट बनाना, अच्छी abstractions सोचना, और modules में बाँटना सचमुच पसंद है
    मुझे इसमें आनंद आता है, लेकिन किसी बिंदु पर मैं खुद ही bottleneck बन जाता हूँ, यह भी समझता हूँ। अगर software का मकसद लोगों को फ़ायदा पहुँचाना है, तो क्या मुझे अब भी इस बात की परवाह करनी चाहिए कि code कैसा दिखता है? अभी मुझे जवाब “हाँ” लगता है, लेकिन 3 साल बाद? 10 साल बाद?

    • अगर आप चाहते हैं कि software आगे भी लोगों को फ़ायदा देता रहे, तो जवाब हाँ है
    • अगर आप ऐसी जगह हैं जहाँ tech के अलावा और कुछ अर्थपूर्ण नहीं लगता, तो यह कठिन हो सकता है। लगता है जल्द ही किसी ज़्यादा संतोषजनक काम की तरफ एक existential turn आएगा। हो सकता है यह भोली सोच हो, या बस वही हो जिसकी मुझे अपने लिए ज़रूरत महसूस होती है
    • refactoring तो किसी agent से कभी भी करवाया जा सकता है। वह इतने बड़े refactoring भी कर सकता है कि सिर्फ सोचकर ही थकान होने लगे

  • अगर किसी चीज़ में बहुत ज़्यादा judgment की ज़रूरत हो और वह “वह code जिसकी मुझे गहरी परवाह है” हो, तो यहाँ बताई गई दिशा से सहमत होना मुश्किल है। जिन फ़ैसलों की आपको गहरी परवाह है, उन्हें delegate करने की कोशिश नहीं करनी चाहिए
    agent loop और harness loop के बीच का भेद मुझे पसंद है, लेकिन delegate वही करना चाहिए जिसे पहले से सटीक रूप से specify किया जा सके। मेरे मामले में यह ज़्यादातर repeat होने वाले काम होते हैं, जैसे “देखो X कैसे किया गया था, और Y में भी वैसा ही करो”, और यह मूल रूप से predictable काम है। अगर मेरा judgment हट जाए और अंत में वह ऐसी चीज़ बन जाए जिस पर मैं “नहीं” कहूँ, तो Armin के बताए agent loop के भीतर collaborate करने वाले पक्ष पर लौट आना चाहिए। यह पूरी तरह ठीक है। तेज़ भी है और सुरक्षित भी। AI coding assistants से पहले भी कभी-कभी बेहद productive engineer टीम में आ जाते थे। दूसरे लोग जलकर कहते थे, “तुम लोगों ने यह सब इसलिए कर लिया क्योंकि टीम में X था!” लेकिन उन्होंने अपने पास ऐसे व्यक्ति को रखने का अभिशाप नहीं झेला होता था। अगर पूरी तरह aligned न हो, तो वे अविश्वसनीय रफ़्तार से ग़लत दिशा में भागते हैं

    • जिन फ़ैसलों की आपको गहरी परवाह है, उन्हें delegate नहीं करना चाहिए। या फिर उन फ़ैसलों को शामिल करने का deterministic method ढूँढ़ना चाहिए
    • बिल्कुल सही। अगर आप किसी ऐसे व्यक्ति को भी outsource नहीं करेंगे जिसे आप बहुत highly skilled मानते हैं, तो फिर मशीन को outsource क्यों करेंगे?

  • इसका असल में क्या मतलब है, समझ नहीं आता। यह बस abstract concepts को सजाकर लिखा गया लंबा लेख लगता है, जैसे किसी बड़े picture की ओर इशारा करने के लिए बनाया गया हो, और अंत में बात सिर्फ़ AI से code लिखवाने की है
    क्या अब आगे यही होने वाला है? असल में हम thought leader नहीं, बल्कि AI बेवकूफ़ों की भीड़ को सही जवाब की तरफ हाँकने वाले pseudo-teacher बनते जा रहे हैं, और फिर भी thought leader जैसे दिखने के लिए अपनी भूमिका को रहस्यमय बनाना पड़ेगा? वह भी बिना यह पकड़े जाने के कि यह सब technical posturing है?

    • यह न तो लंबा-खींचा लेख है, न abstract। यहाँ बात कम supervision वाले तरीके से “AI से code लिखवाने” के second-order effects की हो रही है
      लेखक इसे और concise बना सकता था, लेकिन मौजूदा रूप में अगर कोई पाठक बात नहीं समझ पा रहा, तो इसका मतलब यह नहीं कि कोई रहस्य पैदा किया जा रहा है
    • AI hype अपना लो तो ऐसी ही बातें निकलती हैं। Yegge इसका और भी बड़ा उदाहरण है
    • मुझे पूरा यक़ीन है कि software engineering दो हिस्सों में बँट रही है। ये असली चिंताएँ हैं, और उन developers के लिए यह एक consistent logic है जिन्होंने agent loop और मज़बूत AI-assisted workflows का इस्तेमाल किया है
      मैं नौकरी और personal projects दोनों में वही देख रहा हूँ जो मूल लेख कह रहा है, इसलिए यह डरावना है कि कोई इसे “abstract concepts को सजाकर लिखा गया लंबा लेख” मानता है। लगता है ज़्यादातर लोगों को अभी जो हो रहा है उसकी बिल्कुल समझ नहीं है
    • पहले के tech blogs ऐसे पढ़े जाते थे जैसे सीधे लागू किए जा सकने वाले README guides हों। यह लेख पढ़ते हुए बार-बार लगा, “इस जानकारी के साथ मैं करूँ क्या?” इसलिए मैं इसे पूरा नहीं पढ़ पाया
      AI क्षेत्र में latest और best technique की shelf life लगभग 2 हफ़्ते है। मैं Ralph Wiggum loop को पकड़ भी नहीं पाया, और अब लगता है कि कोशिश न करना ही अच्छा था
      https://news.ycombinator.com/item?id=46682325
    • “असल में इसका क्या मतलब है” यानी, और ज़्यादा tokens इस्तेमाल करो