AI का इस्तेमाल करके बेहतर कोड और भी धीरे लिखना

 (nolanlawson.com)
5 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI coding का इस्तेमाल सिर्फ कम-गुणवत्ता वाला कोड तेज़ी से बड़े पैमाने पर बनाने के लिए ही नहीं, बल्कि PR की गहराई से समीक्षा करके उच्च-गुणवत्ता वाला कोड धीरे-धीरे बनाने के लिए भी किया जा सकता है
  • LLM agents codebase में bug detection में मजबूत होते हैं, लेकिन असली कठिनाई मिली हुई चीज़ों की प्राथमिकता तय करने और उनकी पुष्टि करने में होती है
  • कई models को साथ इस्तेमाल करने वाली Claude skill, Claude sub-agent, Codex, और Cursor Bugbot से PR की समीक्षा कराती है और false positives कम करके अंतिम रिपोर्ट बनाती है
  • प्रक्रिया का flow critical/high समस्याओं को बार-बार ठीक करने, लागत के मुकाबले लाभ कम होने वाले items को छोड़ने, और बहुत ज़्यादा गंभीर समस्याएँ होने पर PR को छोड़ देने पर आधारित है
  • यह तरीका गति से ज़्यादा codebase health को महत्व देता है और failure modes तथा मौजूदा bugs को समझने वाली सावधान programming को मजबूत करता है

AI coding को धीमे तरीके से इस्तेमाल करना

  • AI coding को सिर्फ कम-गुणवत्ता वाला कोड तेज़ी से बड़े पैमाने पर बनाने के उपयोग तक सीमित करके देखना, LLM की लचीलापन क्षमता को कम आँकना है
  • LLM का उपयोग सिर्फ तेज़ code generation के लिए नहीं, बल्कि उच्च-गुणवत्ता वाला कोड और भी धीरे लिखने के लिए भी प्रभावी ढंग से किया जा सकता है
  • slop cannons की तरह बिना सत्यापन वाले बड़े PR उगलने के तरीके के उलट, PR की और गहराई से समीक्षा करने और संभावित विफलताओं को लगातार परखने वाला तरीका भी संभव है

Bug detection से ज़्यादा महत्वपूर्ण है verification और prioritization

  • Mythos दिखाता है कि LLM agents codebase में bugs बहुत अच्छी तरह ढूँढ सकते हैं
  • दूसरे उदाहरणों में भी, Mythos के अलावा अन्य models बिना समीक्षा वाले codebase में बहुत से bugs ढूँढ सकते हैं
  • नवीनतम सार्वजनिक Anthropic और OpenAI models में सूक्ष्म bug detection और false positives से बचने की क्षमता में अंतर है, लेकिन वे पर्याप्त संख्या में bugs ढूँढ सकते हैं
  • वास्तविक कठिनाई bug ढूँढने से अधिक prioritization और verification में है

कई models के साथ PR की समीक्षा करने वाली Claude skill

  • कई models को तुलना और बहस में शामिल करने वाला AI code review approach इस बात पर केंद्रित है कि अलग-अलग models को ज़्यादा शामिल करने से hallucination या गलत bug reports की संभावना घटती है
  • उपयोग में लाई जा रही Claude skill, PR review के लिए Claude sub-agent, Codex, और Cursor Bugbot चलाती है
  • हर tool PR के bugs को critical/high/medium/low के रूप में grade करता है, और फिर परिणामों को मिलाकर false positives हटाई गई अंतिम रिपोर्ट बनाता है
  • “bug” की परिभाषा को project standards के अनुसार व्यापक किया जा सकता है
    • KISS और DRY सिद्धांतों का उल्लंघन
    • accessible HTML/JSX लिखा गया है या नहीं
    • SQL queries में उचित indexes का इस्तेमाल हुआ है या नहीं
    • इसके अलावा project-विशिष्ट quality standards

वास्तविक workflow और निर्णय मानदंड

  • यह तरीका PR में बहुत से bugs ढूँढ सकता है, और false positive दर को भी लगभग 0 के करीब ला सकता है
  • मिलने वाली समस्याएँ security और correctness से जुड़े critical bugs से लेकर performance issues तक, और “comments भ्रामक हैं” जैसे कम गंभीरता वाले मुद्दों तक फैली हो सकती हैं

  • सामान्य प्रक्रिया flow

    • critical और high grade वाली समस्याएँ agent से ठीक कराई जाती हैं, लेकिन उचित समाधान के लिए इंसान मार्गदर्शन देता है
    • critical/high समाप्त होने तक यह प्रक्रिया दोहराई जाती है
    • जिन high/medium समस्याओं को ठीक करने की लागत के मुकाबले लाभ कम हो, उन्हें छोड़ दिया जाता है
    • इसका एक प्रतिनिधि उदाहरण है, किसी संकीर्ण edge case को ठीक करने के लिए 100 lines of code की ज़रूरत पड़ना
    • अगर critical समस्याएँ इतनी ज़्यादा हों कि पूरा approach ही गलत लगे, तो PR छोड़ दिया जाता है

उत्पादकता से अधिक codebase health पर फोकस

  • यह तकनीक ज़रूरी नहीं कि development speed बढ़ाए
  • review प्रक्रिया में PR से पहले से मौजूद existing bugs भी मिल सकते हैं, जो unit tests लिखने और सूक्ष्म defects ठीक करने तक ले जा सकते हैं
  • यह अक्सर “vibe coding” से जुड़ी “10x productivity” वाली development शैली के लगभग उलट है
  • जटिल architecture में सामान्य paths की तुलना में failure modes ज़्यादा दिलचस्प हो सकते हैं, और उन failure points को समझना व ठीक करना codebase को सीखने का एक तरीका बन सकता है
  • पूरे codebase की health सुधारते हुए उसके कम-ज्ञात हिस्सों को सीखने में यह उपयोगी है

slow vibe coding के लिए व्यावहारिक तरीके

  • अगर आप agents की मदद से ऐसे सैकड़ों lines वाले PR बना रहे हैं जिन्हें आप खुद भी पूरी तरह नहीं समझते, तो आप धीमा तरीका आज़मा सकते हैं
  • आप agent से पूछ सकते हैं कि PR कैसे काम करता है और कहाँ विफल हो सकता है
  • ज़रूरत पड़ने पर उससे Mermaid charts वाले Markdown दस्तावेज़ भी लिखवाए जा सकते हैं
  • PR को शुरू से अंत तक समझने तक आप Matt Pocock के /grill-me skill का इस्तेमाल कर सकते हैं
  • lines of code के हिसाब से “productivity” शायद न बढ़े, और बहुत सारे tokens खर्च करने के बाद यह निष्कर्ष भी निकल सकता है कि शुरुआती योजना ही गलत थी
  • यह तरीका LLM से पहले से जिस सावधान, व्यवस्थित, और quality के प्रति जुनूनी programming की दिशा थी, उसी को और अधिक शक्तिशाली बनाता है

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय

  • मेरे कार्यस्थल पर हमने AI से और तेज़ चलने का सपना छोड़ दिया है। हमारे मामले में coding bottleneck नहीं है
    फिर भी coding agent की अच्छी बात यह है कि वह हमें हमेशा जैसा engineer बनना चाहते थे वैसा काम करने देता है
    उदाहरण के लिए, ऐसा ठीक-ठाक test harness बनाना जिससे code को थोड़ा और आगे तक push किया जा सके, generated code मूल से मेल खाता है या नहीं इसकी जाँच के लिए CI चरण जोड़ना, और change deployment की सही तरह से monitoring करना
    पहले ऐसे काम schedule के हिसाब से संभव नहीं थे, क्योंकि GitLab CI manual पढ़ना पड़ता, conditions कैसे मिलानी हैं यह समझना पड़ता, और हमारी कंपनी के उलझे हुए तरीकों को भी पकड़ना पड़ता था; अब यह संभव हो गया है, और मुझे लगता है कि यही भविष्य है

  • LLM को API जानने वाले spike partner या mechanical refactoring device की तरह इस्तेमाल करने पर काफ़ी सफलता मिली, खासकर strongly typed languages में। यह test लिखने में भी अच्छा है, लेकिन यह पक्का करने के लिए कि वे tests सच में बाध्यकारी हैं, कई परतों वाली प्रक्रिया होनी चाहिए
    mutation testing काफ़ी मददगार रही, और जैसा मूल लेख ने सुझाया, कई बार review करना भी ज़रूरी है
    पहले मैं LLM के प्रति कहीं ज़्यादा नकारात्मक था, और पीछे मुड़कर देखता हूँ तो लगभग अतार्किक रूप से, लेकिन उसका बड़ा कारण यह था कि LLM बहुत निम्न-गुणवत्ता वाला software उगलते थे
    खुद गहराई से देखने पर समझ आया कि इसे cardboard prototyping tool और बहुत तेज़ typist की तरह लेना सही है। जैसे अगर मैं कहूँ, “इस Lean project की सभी theorems में यह pattern ढूँढो, उसे उस pattern से बदलो, और जहाँ तुरंत न हो सके उन्हें चिह्नित करके बाकी की सूची दो,” तो यह 100 से ज़्यादा theorems को chunk के हिसाब से ठीक कर देता है, उतने समय में जितने में मैं vim, sed, awk और अस्थायी जुगाड़ मिलाकर पहली एक-दो कोशिशें करता
    Lean में language की प्रकृति और मेरे काम की वजह से “compiled” और “working” के बीच की दूरी कम है, इसलिए यह खास तौर पर अच्छा है; Rust में भी अच्छा test suite और mutation testing जोड़ दूँ तो वैसा ही एहसास होता है
    मुझे लगता है कि इन tools की long tail “button दबाओ और product निकल आए” वाली नहीं है, बल्कि यह है कि अच्छे engineers इन्हें अपनाएँ, अपनी ऊर्जा महत्वपूर्ण कामों पर केंद्रित करें, और पहले के काफ़ी सारे छोटे-मोटे काम machine को सौंप दें

    • मैं भी शुरुआत में LLM को बहुत नकारात्मक नज़र से देखता था, लेकिन अब मुझे लगता है कि यह रुकावट से ज़्यादा मददगार होने के स्तर तक बेहतर हो चुका है
      उदाहरण दिलचस्प है; पहले जब मैं JavaScript framework टीम में काम करता था, तो upgrade या migration जैसे कामों के लिए खुद codemod लिखता था। AST बदलना बड़ा मेहनत वाला काम था
      आजकल होता तो लगता है LLM को देकर लगभग 90% तक पहुँचा जा सकता था

  • यह नज़रिया अच्छा लगा। यह तो स्वाभाविक लगता है कि tools लचीले होते हैं और ज़रूरी नहीं कि वे सिर्फ़ low-quality output ही बनाएँ, लेकिन समर्थन करने वाले और पूरी तरह ठुकराने वाले, दोनों पक्ष अक्सर इस नज़रिए को नज़रअंदाज़ करते हैं
    अभी तक मैंने LLM से code review नहीं करवाया है, लेकिन इसे अपनी to-do list में डालना चाहिए। अब तक मैं इसे idea generation, SQL या VimScript में मदद जैसी चीज़ों के लिए इस्तेमाल करता हूँ और code खुद लिखता हूँ
    एक ख़तरा यह है कि code review भी एक skill है, इसलिए अगर model पर ज़्यादा निर्भर हो जाएँ तो वह क्षमता कमज़ोर पड़ सकती है। हालाँकि commercial environment में सबसे अच्छा code review भी आम तौर पर “उचित समय” और “क्या इस व्यक्ति पर भरोसा है” का मिश्रण होता है, गणितीय शुद्धता के क़रीब नहीं

    • यह बात सही है, लेकिन मुझे लगा कि यह workflow उलटे मेरी code review skill बढ़ाता है। क्योंकि मुझे जाँचना पड़ता है कि “bug” सच में संभव है या सिर्फ़ सैद्धांतिक, इसे ठीक करना उचित है या नहीं, और क्या इसे अगले PR तक टालना चाहिए
      जटिल bugs के मामले में मैं अब भी खुद अंत तक सोचता हूँ, क्योंकि 1) hallucination अभी भी बीच में घुस आती है, और 2) वैसे भी system को end-to-end समझने का मूल्य है

  • यह meta बात है, लेकिन इस पोस्ट पर लगे flags समझ नहीं आते। off-topic 1 और spam 3 होना अजीब है
    पहले पेज के सबसे ऊपर की पोस्ट भी LLM के इस्तेमाल पर है, और वह सामान्य writing पर है, इसलिए coding पर केंद्रित इस पोस्ट की तुलना में शायद कम topical लगती है, फिर भी उस पर flags नहीं दिखते

    • शायद इसे self-promotion मानकर spam flag लगाया गया होगा

  • Lobsters पर ऐसा नज़रिया देखना ताज़गी भरा है। एकरूप anti-AI sentiment अब धीरे-धीरे थकाने लगा है। इस बात पर तो सब सहमत हो सकते हैं कि किसी को low-quality output पसंद नहीं है
    लेकिन जिन्होंने AI का पूरी तरह बहिष्कार कर दिया है और कट्टर रुख अपना लिया है, उनके लिए भविष्य को स्वीकार करना उन लोगों की तुलना में कठिन होगा जिन्होंने ज़्यादा व्यावहारिक रुख चुना है
    मैं शुरू से कहता आया हूँ कि AI कुछ-कुछ power tools के आविष्कार जैसा है। अगर आप हाथ वाले wrench से tire बदलना चाहते हैं तो ठीक है, लेकिन impact drill आने पर mechanics ने उसका बहिष्कार नहीं किया था। इस लेख के संदर्भ में यह सबसे बेहतरीन उपमा नहीं है, फिर भी मुझे यह बात सही लगती है
    दस्तावेज़ पढ़ने की तुलना में AI इस्तेमाल करते हुए मैंने ज़्यादा सीखा है। क्योंकि docs से आप अतिरिक्त context, explanation, या examples चाहिए हों तो सवाल नहीं पूछ सकते। आप उससे “कुछ बनाओ, गलती मत करना” भी कह सकते हैं, लेकिन सच में सीखने के लिए मैं धीमा तरीका पसंद करता हूँ

    • मुझे यहाँ कोई एकरूप anti-AI sentiment नहीं दिखा। क्या आप कुछ उदाहरण लिंक कर सकते हैं?
      मैंने जो देखा, वह LLM से एक ही बार में लाखों lines के code में बदलाव करके, बिना human review के deploy करने जैसी प्रवृत्ति की आलोचना थी। खास तौर पर Bun की Zig से Rust porting thread जैसे मामले
      यह लेख भी उसी की आलोचना कर रहा है