Fable को मात देने वाली ‘Short Leash’ AI coding विधि

 (blog.okturtles.org)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सुरक्षा-महत्वपूर्ण software में AI coding agent का उपयोग करना हो तो उसे स्वायत्त रूप से चलाने देने के बजाय, developer द्वारा बदलावों पर लगातार नियंत्रण रखने वाली Short Leash पद्धति की ज़रूरत होती है
  • कई agents द्वारा parallel में code लिखने और review करने वाला “vibe” शैली का approach, codebase की समझ को कमजोर कर सकता है और समस्या का पता तब चलता है जब AI off the rails हो चुका होता है
  • मुख्य प्रक्रिया planning, चरणों में विभाजन, permission prompt के diff review, बार-बार अस्वीकार और हस्तक्षेप, sub-task के हिसाब से commit, और अंत में final review तक जाती है
  • PR review में AI और इंसानों को साथ इस्तेमाल करना गलतियाँ कम कर सकता है; AI आम errors जल्दी पकड़ता है और इंसान ऊँचे स्तर की समस्याओं व दिशा का निर्णय लेते हैं
  • AI की मदद से बने PR में submitter को हर लाइन खुद review करनी चाहिए, और PR description में इस्तेमाल किए गए model को AI Disclosure के रूप में स्पष्ट करना चाहिए ताकि भरोसा बन सके

AI coding agent का उपयोग करने की पूर्वशर्तें

  • यह तरीका सुरक्षा-महत्वपूर्ण systems में high-quality software बनाने के लिए AI agents के उपयोग के अनुभव पर आधारित है
  • यह उन शुरुआती developers के लिए नहीं है जिन्हें AI को सीखने का दुश्मन समझना चाहिए, बल्कि उन विशेषज्ञ developers के लिए है जो अपने क्षेत्र में “frontier AI models” से बेहतर हैं
  • लक्ष्य यह है कि AI को performance बढ़ाने वाले tool की तरह इस्तेमाल किया जाए, लेकिन software quality से समझौता किए बिना
  • अनुभव के दायरे में AI agent की सीमाओं की पड़ताल, अपना AI review tool बनाना, और AI coding agent Crush के custom fork को maintain करना शामिल है

“vibe” शैली का approach कहाँ डगमगाता है

  • AI agent के साथ काम करने वाले session में अक्सर दो समस्याएँ सामने आ सकती हैं
    • शुरुआती idea खराब होता है और बाद में पता चलता है कि बेहतर approach मौजूद था
    • agent अनचाही दिशा में off the rails हो जाता है
  • जब कई parallel agents और orchestrator एक साथ काम करते हैं और developer coding process से बाहर हो जाता है, तो codebase की समझ सीधे बनाना मुश्किल हो जाता है
  • जहाँ quality की चिंता नहीं होती, वहाँ यह तरीका ठीक हो सकता है, लेकिन जहाँ quality महत्वपूर्ण है, वहाँ अलग approach चाहिए
  • Fable 5 द्वारा लिखा या review किया गया code चल सकता है, लेकिन वह inefficient और बदसूरत हो सकता है
  • ऐसे niche domains में, जहाँ model के भरोसे के लिए training data कम है, यह समस्या और ज़्यादा दिख सकती है
  • कुछ CEOs की marketing के विपरीत, इस दृष्टिकोण में model training data से आगे सोच नहीं सकते

Short Leash पद्धति कैसे काम करती है

  • Short Leash पद्धति हर किसी के लिए नहीं है; यह विशेषज्ञ software developers के लिए बनी है
  • इसकी खासियत यह है कि frontier model का उपयोग किए बिना भी Fable से बेहतर नतीजे दिए जा सकते हैं
  • काम शुरू करने से पहले planning चरण में task की जाँच और योजना बनाई जाती है
    • बड़े कामों को tasks skill जैसे tools से track किया जाता है और चरणों में बाँटा जाता है
    • इस हिस्से में कई “vibe engineering” तरीकों से समानता है
  • इसके बाद असली बात यह है कि AI को लगातार छोटी लगाम पर रखा जाए
    • “YOLO” mode या “dangerously skip permissions” का उपयोग नहीं किया जाता
    • AI को यूज़र के गेम खेलने के दौरान अकेले काम नहीं करने दिया जाता
    • ऐसा coding agent इस्तेमाल किया जाता है जो permission prompt में लागू होने वाले बदलावों का diff दिखाए
    • developer, AI द्वारा सुझाए गए बदलावों का वास्तव में विश्लेषण करता है
    • permission prompt के diff की मदद से codebase की समझ को up to date रखा जाता है और AI पर नियंत्रण बनाए रखा जाता है
    • अगर AI अनचाहा काम करने लगे तो permission अस्वीकार कर दी जाती है
    • ज़रूरत पड़ने पर बार-बार हस्तक्षेप किया जाता है ताकि AI दिशा न खोए
  • हर sub-task के बाद commit बनाया जाता है, ताकि AI पहले के काम को खराब या delete न कर दे
    • ऐसा वास्तव में हो सकता है, और Opus में ऐसे मामले देखे गए हैं
  • आखिरी चरण में review किया जाता है

AI review, human review की जगह नहीं लेता

  • सिर्फ इंसानों द्वारा review किए गए PR या सिर्फ AI द्वारा review किए गए PR की तुलना में, इंसान और AI के साथ review किए गए PR गलतियाँ और कम कर सकते हैं
  • AI को linter की तरह इस्तेमाल किया जा सकता है
    • यह आम गलतियों को जल्दी पकड़ लेता है
    • इंसान ऊँचे स्तर की समस्याओं और दिशा बदलने की ज़रूरत का आकलन करते हैं
  • हर PR को AI review से गुज़रना चाहिए, यह सिफारिश की जाती है
  • AI review के लिए पर्याप्त context ज़रूरी है
    • issue
    • PR description
    • codebase
    • changes
  • review के लिए उपलब्ध सबसे नए models का उपयोग करने की सिफारिश की जाती है

AI Disclosure और submitter की ज़िम्मेदारी

  • अगर PR लिखने में AI का उपयोग हुआ है, तो PR description के AI Disclosure section में इस्तेमाल किए गए सटीक model को बताना चाहिए
  • इस खुलासे के कई उद्देश्य हैं
    • maintainers को AI उपयोग की जानकारी देना
    • अगर कमजोर model इस्तेमाल हुआ हो, तो बेहतर model सुझाने की सुविधा देना
    • यह संकेत देना कि AI को छिपाकर नहीं लाया जा रहा है
  • AI का उपयोग करने वाले PR को PR के “author” द्वारा स्वयं review करना अनिवार्य है
  • AI-सहायित PR वास्तव में इंसानी मदद पाने वाले AI के PR के अधिक करीब होते हैं, इसलिए submitter को अपनी submitted सामग्री समझनी चाहिए
  • submitter को अपने PR को किसी और के PR की तरह देखकर line-by-line खुद review करना चाहिए
  • self-review पूरा होने के बाद, वह अपनी approval की पुष्टि कर maintainer से review का अनुरोध कर सकता है
  • यह प्रक्रिया submitter को codebase समझने और उसे प्रदर्शित करने, दोनों में मदद करती है

okTurtles इसे कैसे लागू करता है

  • okTurtles इस तरीके से AI का उपयोग करता है
  • इसकी आधिकारिक policy AI Usage Policy में दी गई है
  • लेख स्वयं इंसान ने लिखा था, और publish करने से पहले केवल AI-शैली की spell check की गई थी, ऐसा AI Disclosure भी शामिल है

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

1 टिप्पणियां

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

  • यह "छोटी पट्टा" तरीका किसी सहायक टूल से ज़्यादा बैसाखी जैसा लगता है, और ऐसा संकेत देता है कि या तो शुरुआत में AI को समस्या ठीक से समझाई नहीं गई, या आउटपुट को review/iterate नहीं किया गया
    Fable जैसे मजबूत model का implementation चरण में हाथ पकड़कर ले जाना समय की बर्बादी है, और Fable की भी बर्बादी है। जितना मजबूत model होगा, उतनी ही सूक्ष्म design discussion संभव होती है, और वह पहले से कहीं बेहतर code लिखता है। Design और implementation पर चर्चा करना, अजीब दिखने वाली चीज़ों पर सवाल करना, और AI के जवाबों को सच में पढ़ना—यह पूरी प्रक्रिया बेहतर समाधान खोजने में मदद करती है
    पहले जब मैं greedy algorithm solution बनाने की कोशिश कर रहा था, तो Opus के साथ चर्चा के दौरान उसने सुझाव दिया कि मौजूदा MILP library से इस समस्या को ठीक-ठीक हल किया जा सकता है। मैंने MILP का नाम भी नहीं सुना था, लेकिन final implementation, अकेले करने पर जो बनता उससे बेहतर और सरल निकला

    • कहते हैं कि मजबूत model के साथ ज़्यादा सूक्ष्म चर्चा हो सकती है, लेकिन जब मैंने Claude से पूछा कि उसने एक छोटा-सा बदलाव क्यों किया जिसे मैं समझ नहीं पाया, तो उसने code path के आधार पर कहा कि उसने "first principles से reasoning की"
      लेकिन वह काम नहीं कर रहा था, और जब मैंने उससे वह first-principles reasoning step समझाने को कहा, तो उसने जवाब दिया कि उसने बस बात बना दी थी। इसलिए model के साथ सूक्ष्म चर्चा वाली बात पर भरोसा करना मुश्किल है
    • कुल मिलाकर सहमत हूँ
      अगर planning चरण में पर्याप्त निवेश किया गया हो, और project की मौजूदा architecture तथा conventions मजबूत हों, तो implementation चरण में यहाँ बताए गए जितनी निगरानी की ज़रूरत शायद न पड़े
      "शुरुआती idea बेवकूफ़ी भरा था और इससे बेहतर तरीका मिल सकता है"—यह बात आम तौर पर planning और architecture चरण में high level पर सामने आती है
      Agent के अनचाही दिशा में "पटरी से उतरने" की समस्या भी अब पहले जितनी बुरी नहीं रही, और असर डालने वाले बदलावों के लिए कम-से-कम कुछ test coverage होना चाहिए। वह test सिर्फ implemented behavior को "freeze" करने भर का हो, तब भी चलेगा। आख़िरी review discussion, review या adversarial review agent द्वारा मिली चीज़ों से आगे की पुष्टि करने का अच्छा मौका होता है
    • यह थोड़ा उलझन भरा है कि आप ठीक किस हिस्से से असहमत हैं। AI के जवाब पढ़ना और code review करना आखिरकार मुझे तो एक ही तरह की बात लगती है
      MILP वाला उदाहरण ऐसा नहीं है जिसे यह approach रोकती, और वह planning चरण में ही सामने आ जाता
      आखिरकार details मायने रखती हैं, और काम शुरू करते समय prompt कैसे दिया जाता है, उसका असर पड़ता है। फिर भी output verify करना, model जो कर रहा है उसमें शामिल रहना, और वह ऐसा क्यों बना रहा है इस पर सवाल करते रहना—यह सब ज़रूरी है
    • यह लेख AI को micromanage करने जैसा लगता है। अगर इसे किसी junior employee की तरह सोचें, तो micromanaging से आप उससे वही काम, उसी तरीके से करवा सकते हैं जैसा आप चाहते हैं
      लेकिन तब उस कर्मचारी के अपने ideas सामने नहीं आते, और लंबे समय में पूरी team के लिए फ़ायदेमंद हो सकने वाला योगदान भी गायब हो जाता है
    • मैं इसी तरीके से काम करता हूँ
      इससे जो कुछ भी generate हो रहा है उसे समझना आसान रहता है, और codebase के बारे में working knowledge लगातार बनी रहती है। दिशा बदलवाना भी आसान होता है

  • मैंने side project में 2 हफ्ते तक ऐसा किया, लेकिन आखिर में codebase का कोई mental model ही नहीं बचा
    इससे मेरा यह भरोसा और मज़बूत हुआ कि खुद बनाए बिना वह model बनाया ही नहीं जा सकता

    • अफ़सोस की बात है कि AI से पहले भी मुझे यही समस्या थी
      forgetting curve की वजह से मेरा mental model, उसे शुरू में बनाते समय जितना मज़बूत था, उतना लंबे समय तक टिकता नहीं। उसे फिर से कैसे बनाया जाए, यह अभी तक समझ नहीं पाया हूँ
    • अगर आप किसी बड़े project के manager हों, तो फिर यह model कैसे बनाते हैं? मतलब, जब role के हिसाब से पूरे project को समझना ज़रूरी हो, लेकिन खुद बहुत code लिखने या review करने की ज़रूरत न हो
    • बस model से code समझाने के लिए कह दीजिए
    • पक्का नहीं। मुझे लगता है कि यह संभव है, लेकिन जिन हिस्सों को आप नहीं समझते उन्हें जानबूझकर खंगालना पड़ता है, और वही guideline होनी चाहिए
      हाँ, मैं इस बात से सहमत हूँ कि इससे वैसी "मैं इसे खुद बना सकता हूँ" वाली क्षमता नहीं बनती जैसी सीधे लिखने से बनती है
      उदाहरण के लिए, मुझे पता होता है कि किसी effect के लिए कौन-सा बदलाव करना होगा, और जब सच में वह बदलाव करता हूँ तो अपेक्षित result मिल जाता है, इसलिए पता चलता है कि मेरा mental model काम कर रहा है। लेकिन अगर वही जैसी चीज़ शुरू से खुद बनाने को कहें, तो शायद न बना पाऊँ। ऐसा लगता है कि यह approach मेरी प्रत्यक्ष पहुँच से थोड़ा बाहर है, लेकिन इसे समझाना मुश्किल है
    • code review मेरे लिए अच्छा काम करता है

  • मुझे लगा था कि जो लोग सच में coding जानते हैं, वे किसी अहम काम में AI को इस्तेमाल करते समय सब ऐसे ही करते हैं
    क्या मैं ग़लत था? क्या आजकल सब बस YOLO mode में चला रहे हैं?

    • हाँ। मैंने एक अलग बेफ़िक्र laptop रखा है और Claude को WSL के अंदर जो चाहे करने देता हूँ
      यही funemployment का मज़ा है। दोबारा काम शुरू करूँगा तो काफ़ी दिलचस्प बदलाव लगेगा
      अभी तो बस इसे चलने देता हूँ, फिर beer पीते हुए कोई एक घंटा बड़े दिशा-संबंधी critique और self-check/closed-loop feedback को फिर से सेट करता हूँ, और उसके बाद इसे फिर खुला छोड़ देता हूँ, तो सब काफ़ी simple रहता है
    • "YOLO mode", यानी "खतरनाक permission bypass", क्या इस बात का मतलब यही है कि इसका इस्तेमाल नहीं करना चाहिए?
      मैं जानना चाहता हूँ कि लोग Claude को bypass-permissions के अलावा किस तरीके से इस्तेमाल करते हैं। मैंने Claude के लिए उपलब्ध tools की list को लंबे समय तक manage किया, लेकिन आखिर में लौटकर देखने पर बार-बार यही मिलता था कि वह एक tool के output को दूसरे tool में pipe करना चाहता था और explicit permission न होने के कारण रुक गया था। कई बार यह बस grep जैसा साधारण काम था, फिर भी रुक जाता था, जो बहुत चिढ़ाने वाला था
      bypass-permissions में तो "बस काम हो जाता है"। बेशक, मैं इसका इस्तेमाल सिर्फ मौजूदा code के analysis और change suggestions के लिए करता हूँ, और अगर कुछ टूट भी जाए तो version control इसी लिए है

  • कुल मिलाकर मैं लेखक से सहमत हूँ। सबसे बढ़कर मैं यह जोड़ना चाहूँगा कि LLM जो भी करे या कहे, उस पर भरोसा मत करो
    आज मैंने Claude से 3 components के behavior को एक जैसा करने को कहा, और यह काम उससे 5 बार करवाया। हर बार अंत तक पहुँचने पर कुछ न कुछ अब भी मेल नहीं खा रहा था, और Claude उसके लिए कोई-न-कोई तर्क गढ़ लेता था
    पूछने पर वह कहता था, "यह मेरी ज़िम्मेदारी है" या "मुझे लगा यह जानबूझकर किया गया चुनाव था", लेकिन उसने पहले कभी यह नहीं पूछा कि क्या करना है या समस्या क्या है। इसलिए छोटी पट्टा पकड़े रखनी पड़ती है, उसकी सोचने की प्रक्रिया देखनी पड़ती है, और उसकी बेकार हरकतों को तुरंत ठीक करना पड़ता है। आज Sonnet 5 के साथ मेरी यही स्थिति है; कल यह बेहतर भी हो सकता है, बदतर भी। आज Claude से जो लहजा काम कर रहा है, कल वही अलग नतीजा दे सकता है

  • “AI से X करने के तरीके” जैसी पोस्टों की समस्या यह है कि हर स्थिति पूरी तरह अलग होती है। उदाहरण के लिए Symfony प्रोजेक्ट को 3.1 से 8.1 तक अपग्रेड करने का काम एक स्पष्ट रास्ता रखता है
    हर major version के लिए लिखी गई migration guide का पालन करना होता है, और सभी routes व auth flow आदि को test करना होता है। इन tests को आप खुद चुन सकते हैं, और कुछ 200 तो कुछ 302 return कर सकते हैं
    चाहें तो पहले safety net लिखकर manual testing कम की जा सकती है, और उदाहरण के लिए PHPStan baseline जैसी चीज़ भी रखी जा सकती है
    अगर routes end-to-end functional रूप से इरादे के मुताबिक काम कर रहे हों तो काम पूरा है। इसमें snapshot tests भी इस्तेमाल किए जा सकते हैं
    ऐसे मामलों में AI पर नज़र रखने की ज़रूरत नहीं होती। आखिर में code review किया जा सकता है, लेकिन बीच-बीच में manual approval की ज़रूरत नहीं होती, इसलिए safety features बंद रखता हूँ

    • यह “AI से X करने के तरीके” की समस्या कम और इंटरनेट कंटेंट को ग्रहण करने के तरीके की समस्या ज़्यादा है
      ज़्यादातर लोग एक ही दृष्टिकोण से लिखते हैं, लेकिन वास्तविक दृष्टिकोण कहीं अधिक व्यापक होता है, और जो एक स्थिति में काम करता है वह दूसरी में नहीं भी कर सकता। पूरा software engineering अंततः इस बात को समझने के अधिक करीब है कि क्या, कहाँ और कब लागू करना है, और बाकी को नज़रअंदाज़ करना है
      बहुत-सी company blog posts यह भरोसा दिलाती हैं मानो हर स्थिति पर लागू होने वाली कोई silver bullet हो, लेकिन आम तौर पर ऐसा नहीं होता
      अंत में बात वही है जो software engineering में हमेशा से रही है: “कुछ चीज़ें कुछ परिस्थितियों में काम करती हैं”; यह सही-गलत का प्रश्न कम है, और अलग-अलग स्थितियों में वास्तविक लागू करने का तरीका अलग होना सामान्य है
    • rector इस्तेमाल किया है क्या?

  • AI जूनियर से मिड-लेवल इंजीनियर जैसा है। अगर उसके साथ वैसा ही व्यवहार करो, तो इस सारी paranoia के बिना vibe coding और सख्त engineering—दोनों के फायदे मिल सकते हैं
    मैंने शुरू से ही isolate किए गए VM में Claude को YOLO mode में चलाया। यह किसी इंजीनियर को अपना laptop दे देने जैसा है। Claude feature को PR करने लायक स्थिति तक बना देता है, फिर मैं किसी दूसरे engineer की तरह diff review करता हूँ, उसे ठीक आकार में ढालता हूँ और आगे बढ़ जाता हूँ
    अनुभवहीन इंजीनियर भी यही गलतियाँ करते हैं। rm -rf करते हुए भी देखा है, हालाँकि root पर नहीं। अगर मैं किसी को सारे permissions ठुकराकर micro-manage करता रहता, तो शायद पागल हो जाता

    • मैं इस दृष्टिकोण से बहुत सहमत हूँ, इसलिए यह पोस्ट और भी कम समझ आती है। क्या PR ही पहले से gate नहीं है? workspace के अंदर agent क्या करता है, इससे मुझे फ़र्क नहीं पड़ता, जब तक contribution git repository से gate हो रहा है और development के लिए कोई अजीब production access नहीं चाहिए
      जूनियर/मिड-लेवल इंजीनियर वाली उपमा से भी सहमत हूँ, लेकिन एक बड़ा caveat है। AI ऐसा जूनियर इंजीनियर है जो सीखना नहीं जानता
      यह Memento के नायक के साथ काम करने जैसा है। हर दिन जब LLM काम पर लौटता है, तो वह अब तक किए गए काम से कुछ नहीं सीखता; हर दिन उसका पहला दिन होता है
      हाँ, Memento के नायक की तरह आप workspace में हर तरफ post-it notes और reminders बिखेरकर उसकी मदद कर सकते हैं। मेहनत करें तो आप किसी हद तक “learning” जैसी चीज़ के करीब पहुँच सकते हैं, और यह टीम के हर software developer की सचमुच सबसे अहम विशेषता होती है
      लेकिन यह आसान नहीं है, और tools भी अभी कमज़ोर हैं। मैंने जो सबसे अच्छा किया, वह Obsidian जैसे tools के साथ लिखे जाने वाले “second brain” के सबसे करीब था। अफ़सोस की बात यह है कि second brain first brain का विकल्प नहीं है। सच कहूँ तो अगर कोई engineer AI agent की तरह सीख और विकसित न हो पाता, तो जिन कंपनियों में मैंने काम किया है उनमें कहीं भी वह पहले महीने के बाद निकाल दिया जाता
      फिर भी मैं काफ़ी आशावादी हूँ कि बड़े AI providers या कोई और आगे चलकर इस हिस्से को बेहतर करेंगे। अच्छी memory, context के हिसाब से बेहतर memory injection करने वाला सुडिज़ाइन किया गया reasoning system, और बिना supervision के वास्तविक learning को पकड़ लेने की क्षमता—इनके साथ यह कोई असंभव समस्या नहीं लगती
      मैं ऐसे लेख इस उम्मीद में पढ़ता हूँ कि शायद कोई यह समस्या पहले ही हल कर चुका हो और मुझे बस देर से पता चल रहा हो, लेकिन फिलहाल मेरी agent design करने की क्षमता बस शुरुआत की तुलना में थोड़ी बेहतर हुई है
    • मेरा अनुभव भी यही है। मुझे यह एक बहुत होशियार और तेज़ intern के ज़्यादा करीब लगता है। उसमें बहुत आगे जाने की क्षमता दिखती है और कई मामलों में वह पहले से मुझसे काफ़ी बेहतर है, लेकिन फिर भी उसे किसी अनुभवी व्यक्ति के हाथों दिशा चाहिए
      मेरा नियम यह है कि AI के लिए बनाया गया कोई खास process इंसानों के लिए भी उचित होना चाहिए; अगर नहीं, तो उसकी कोई खास कीमत नहीं। अच्छे command-line tools, लंबे command output का automatic summary, Markdown docs और workflows इंसानों के लिए भी उपयोगी हैं
      गलतियों और दुरुपयोग को रोकने के लिए micro-managing नहीं, बल्कि sandbox और scope-limited permissions का इस्तेमाल करना चाहिए
      मैं जिस चीज़ का पता लगाना चाहता हूँ, वह AI agent के साथ अच्छा pair programming workflow है। आप high-performance model को बड़ा काम दे सकते हैं, और वह ठीक काम करता है। low-level model को IDE assistant की तरह भी इस्तेमाल कर सकते हैं, और वह भी ठीक काम करता है। लेकिन दोनों अलग workflows हैं
      सच में उपयोगी तरीका यह है कि high-performance model के साथ कीबोर्ड एक-दूसरे को देते हुए मिलकर बनाया जाए। बस यह मेरे machine पर पूरी तरह YOLO mode में नहीं चलना चाहिए। यही इंसान और LLM का फ़र्क है। वह इतना तेज़ है कि जब वह पटरी से उतरता है, तब कीबोर्ड वापस छीन लेना मुश्किल हो जाता है
    • अगर Claude को सचमुच laptop दे दो, तो वह Linux Bluetooth audio problems भी ठीक कर सकता है ;)
    • कौन-सा VM/provisioning इस्तेमाल कर रहे हो?
    • “AI जूनियर से मिड-लेवल इंजीनियर है” यह बात अब सच नहीं रही, और ऐसा मान लेने से कोई मदद नहीं मिलती
      AI क्या है यह ठीक-ठीक किसी को नहीं पता, लेकिन वह जूनियर या मिड-लेवल इंजीनियर नहीं है। वह ज़्यादा करीब है domain context के बिना, हर 5 घंटे में बिना memory के जागने वाले, झुग्गी में रहने वाले nuclear staff engineer के

  • LLM अब भी अगले token का predictor है। इसे ज़्यादा अस्पष्ट निर्देश देने पर भी अगर यह सही steps ढूंढ लेता है, तो इसका मतलब यह नहीं कि इसमें intelligence है। इसका मतलब बस इतना है कि तुम वही भाषा बोल रहे हो जो model training में इस्तेमाल हुई harness की भाषा है
    और इसकी सीमाएँ हैं। अगर तुम proof-of-concept स्तर या simple app तक ही रुके हो, तो शायद तुम्हें पता न चले कि मौजूदा models अब भी कितने सीमित हैं। ऐसे मामलों में काम को छोटे हिस्सों में तोड़ना चाहिए, किसी ऐसे token predictor पर भरोसा नहीं करना चाहिए जो बस plausible steps गिना दे
    कहीं न कहीं human loop ज़रूर होना चाहिए। जैसे ही तुम permissions bypass करना शुरू करते हो, best case तो jackpot है, लेकिन ज़्यादा संभव यह है कि second-best solution मिले और tokens बर्बाद हों। सच में डराने वाली बात तब होती है जब model निर्देशों को नज़रअंदाज़ करके कोई बेवकूफ़ी कर दे और तुम्हारा पूरा दिन खराब कर दे
    यह CNC machine की तरह धारदार है। बेकार नहीं है, लेकिन ख़तरनाक हो सकती है। अगर तुम parallel parking नहीं कर सकते, तो किसी monster machine से लकड़ी तराशने या तंग मोहल्ले में Ferrari पार्क करने की कोशिश न करना ही बेहतर है

    • अगला token prediction algorithm नहीं, interface है। “अगले token का prediction” करने की प्रक्रिया मनमानी हद तक complex या simple हो सकती है, और दिए गए task को करने की क्षमता भी कम या ज़्यादा कुछ भी हो सकती है
      यह कहना कि LLM “token predictor” है इसलिए वह कुछ कर सकता है या नहीं कर सकता, category error है। interface कोई कठोर सीमा नहीं है
    • “यह intelligence नहीं है” में intelligence को कैसे define किया जा रहा है, यह समझ नहीं आता
      मैं जानना चाहता हूँ कि ऐसी definition कैसे संभव है जो language model को बाहर कर दे लेकिन इंसानों को शामिल रखे, बिना पहले से यह axiom मान लिए कि LLM में intelligence नहीं होती
    • तो फिर तुम भी बस अगला शब्द बोलने वाले इंसान हो
    • LLM को “अगला token predictor” कहना पूरी तरह reductionist और बेईमानी है। तकनीकी रूप से सही है, लेकिन यही बात तुम पर भी लागू होती है
      आम तौर पर इसका मतलब यह लिया जाता है कि “यह बस training data, यानी internet, का अगला token predict करता है”, और raw model के लिए यह सच हो सकता है। लेकिन model post-training से गुजरते हैं, इसलिए यह व्याख्या भी अब पूरी तरह सही नहीं रहती
      “यह intelligence नहीं है” कहना न उपयोगी है, और मेरी राय में गलत भी है। किसे परवाह है कि यह तुम्हारी intelligence की definition में फिट बैठता है या नहीं। यह अब भी प्रभावशाली काम कर रहा है, और उससे भी कहीं ज़्यादा बड़ी चीज़ें कर रहा है जितना तुम संकेत दे रहे हो
    • किस threshold के बाद तुम इसे intelligent कहोगे?

  • मूल पोस्ट अब भी 2025 में अटकी हुई लगती है
    उसमें कहा गया है, “AI कई बार पटरी से उतर जाएगा और यह बात तुम्हें तभी पता चलेगी जब तुम सच में software इस्तेमाल करोगे,” लेकिन अब AI खुद software इस्तेमाल करके bugs ढूंढ, उन्हें fix, और नए features आगे बढ़ा सकता है
    ऐसा होता है कि agent कोई अनचाही चीज़ शुरू कर दे, लेकिन पहले की तुलना में यह बहुत कम हुआ है, और fully autonomous agents के पक्ष में तर्क कमज़ोर नहीं बल्कि मज़बूत हो रहे हैं
    “किसी इंसान के लिए codebase को समझना मानवीय रूप से असंभव है” यह बात भी पुरानी लगती है। अब दिशा शायद ऐसी हो रही है जहाँ इंसान को codebase समझने की ज़रूरत ही नहीं पड़ेगी और AI नेतृत्व करेगा

    • AI कंपनियों के पास ऐसी लापरवाह slopmaxxing को आगे बढ़ाने की प्रेरणा है। अंतिम नतीजा यह होगा कि तुम्हारा business पूरी तरह उन पर निर्भर हो जाएगा, और तुम्हारे product की सारी value भी उन्हीं से आएगी
      बहुत से लोग इस लहर पर सवार हैं, लेकिन मुझे यह एक मूर्खतापूर्ण trend लगता है
    • सही है, किसी चीज़ को समझना तो बहुत 2025 वाली बात हो गई
    • यह बात entertainment या media जैसे non-core software के लिए सही हो सकती है
      लेकिन जिन systems में security risk बड़ा है, वहाँ यह बिल्कुल सही नहीं है। banking, aviation, defense जैसे क्षेत्रों में AI निश्चित रूप से योगदान देगा, लेकिन human engineering understanding से स्वतंत्र होकर काम नहीं कर सकेगा
    • जो लोग effective programming और architecture की समझ सच में अच्छी रखते हैं, वे इस बात से सहमत नहीं होंगे कि AI खुद software इस्तेमाल करके bugs ढूंढ सकता है और features बना सकता है
      short leash approach training data के बाहर के काम में अच्छे नतीजे सुनिश्चित करने का तरीका है। मेरे हिसाब से average से थोड़ा बेहतर programmer के लिए भी LLM के साथ तेज़ और high-quality development सुनिश्चित करने का यही एकमात्र तरीका है
      यह कहना कि इंसान को अब codebase समझने की ज़रूरत नहीं, शायद इस बात से आता है कि AI अभी programming की दुनिया में कितना बुरी तरह अनाड़ी है, इसका अंदाज़ा नहीं है। मैंने बार-बार देखा है कि manual memory management वाली languages में यह memory handling बिगाड़ देता है। यह इतना simple नहीं कि बस इसे Valgrind loop में डाल दो और काम हो जाए
    • मुझे नहीं लगता कि fully autonomous agents के पक्ष में तर्क मज़बूत हुए हैं। कुछ हफ़्ते पहले Claude Code + Opus 4.8 के साथ मेरा अनुभव यही था। काम बहुत complex नहीं था: 4 नए API endpoints और client पर websocket के जरिए stream होने वाले events
      मैंने API definitions, request/response models, database schema, और पूरे flow को कई बार दोहराकर refine किया, contradictions हटाए और documentation में बहुत कुछ खुद ठीक किया। Opus बार-बार पटरी से उतरता रहा और अंतिम document 500 lines से ऊपर चला गया
      API integration tests में भी आगे-पीछे जाना पड़ा। AI documentation से सीधे tests नहीं बना सका, इसलिए पहले Given-When-Then comments वाले placeholders बनाए, उन्हें हाथ से review और fix किया, फिर दूसरे iteration में tests implement किए। review के बाद सुधारी गई गलतियाँ बहुत थीं
      implementation phase में मैंने API docs, working tests, fix-blocking hooks, 6 से ज़्यादा “best practice” skills, “rubber duck” और “code simplification” agents, और test·linter·compile errors check करने वाले scripts दिए। planning, execution, review और कई rounds of fixes के बाद feature implement हुआ और सारे tests pass भी हुए
      code review में औसतन हर 20 lines code पर एक issue मिला। code style छोड़ भी दें, तो Kubernetes service में in-memory semaphore का उपयोग, एक ही request के दौरान उसी record को update करने के लिए DB को 8 बार call करना, एक बार में एक column update करना, transaction के बिना read-modify-save, और business logic·recovery·authorization की गलतियाँ थीं
      नतीजा था लगभग एक हफ़्ते का काम का समय, 100 डॉलर से ज़्यादा token cost, और बस यही सवाल: “क्या यह मेहनत वाकई क़ीमती थी?” मेरी team में 2 developers हैं, और अभी-अभी उनमें से एक का PR review किया तो 80% slop निकला

  • मैंने ऐसा ही approach आज़माया, लेकिन यह मेरे लिए अच्छी तरह काम नहीं किया। speed-up बहुत कम था या बिल्कुल नहीं था। productivity पाने के लिए मुझे लगता है कि sandbox के अंदर कुछ हद तक YOLO mode चाहिए
    लक्ष्य यह होना चाहिए कि model को जितना संभव हो उतना काम outsource किया जाए, और उसके output को समझने और review करने के लिए ज़रूरी effort को कम से कम रखा जाए
    उदाहरण के लिए model से bug का कारण ढूंढवाना, X का proof of concept बनवाना, किसी चीज़ को धीरे-धीरे optimize करवाना, guided और well-defined refactoring करवाना
    लोग जब कहते हैं कि वे loop बनाते हैं, तो वह भी बहुत हद तक यही है। model जो कर रहा है उसे maximum करना, और उसे control में रखने के लिए मुझे जो करना पड़े उसे minimum करना

  • लेख में खास कुछ नहीं था

    • बस अभी चलन में चल रहे जुमलों को दोहरा रहा है
      पिछले साल यह था: “AI बस एक probabilistic parrot है”
      इस साल यह है: “AI कोड लिख सकता है, लेकिन इंसानों को अब भी उसका review करना होगा!” और बेशक, उस review में भी AI का इस्तेमाल होता है
      एक साल और बीतते ही कथा यह बन जाएगी: “code review सिर्फ AI ही कर सकता है, और AI के review का review भी सिर्फ AI ही कर सकता है। इंसानों को अर्थपूर्ण निगरानी बनाए रखने के लिए बस AI की अंतिम राय पढ़नी होगी”
      goalpost लगातार खिसकता रहता है, लेकिन यक़ीन कभी नहीं खिसकता