Claude Code ने low-level crypto code को debug किया

• ML-DSA नामक NIST-निर्धारित post-quantum signature algorithm के Go implementation के दौरान signature verification fail होने की समस्या आई
• Claude Code v2.0.28 ने सिर्फ test code और source path के आधार पर जटिल low-level bug को तेज़ी से ढूंढ लिया
• समस्या का कारण Verify चरण में w1 के high bits को दोबारा compute करने वाली function merge error निकला
• इसके बाद हुए दूसरे experiment में भी Claude ने Montgomery constant calculation error और signature length mismatch bug को अलग-अलग ढूंढ निकाला
• तीनों कोशिशों में bug की सफल पहचान हुई, जिससे low-level debugging में AI के उपयोग की संभावना सामने आई

---

ML-DSA implementation और शुरुआती समस्या

• लेखक ने NIST द्वारा निर्धारित ML-DSA(Post-Quantum Signature Algorithm) को Go भाषा में नया implement किया
  • 4 दिन की live coding के बाद test में Verify function हर signature को reject कर रहा था
  • test log में invalid signature error बार-बार दिख रहा था
• थकान की वजह से debugging रोककर, Claude Code से समस्या का analysis करने को कहा गया

Claude Code की पहली debugging

• Claude Code v2.0.28 (model Opus 4.1, system prompt नहीं) को ये जानकारी दी गई
  • test run command (bin/go test crypto/internal/fips140/mldsa)
  • code location (src/crypto/internal/fips140/mldsa)
  • “signature हमेशा reject हो रहा है” का विवरण और “w1 अलग है” का hint
• Claude ने कुछ ही मिनटों में पूरा fix suggestion लौटाया
  • कारण यह था कि HighBits और w1Encode को एक में merge करने के बाद, Verify में UseHint के उस result पर, जिसमें high bits पहले से बने हुए थे, फिर से high bits ले लिए गए
  • यानी, w1 के high bits को दो बार compute करने वाली structural error
• Claude ने code load करने के तुरंत बाद कारण समझ लिया और अपनी hypothesis verify करने के लिए खुद test भी लिखा
  • सुझाया गया fix पूरी तरह perfect नहीं था, लेकिन मूल कारण की पहचान कर debugging समय घटा दिया
• इसके बाद लेखक ने w1Encode को refactor करके high bits को input के रूप में लेने वाली structure में बदला, और Montgomery representation conversion process भी छोटा किया

दूसरा experiment: signature generation चरण का bug

• signature generation implementation में भी test fail हुआ
  • पहला bug: Montgomery domain में constant (1, -1) calculation error
    • यह ढूंढना मुश्किल था, इसके लिए बहुत सारे printf और अंदाज़ों की जरूरत पड़ी, और लगभग 1~2 घंटे लगे
  • दूसरा bug: signature में शामिल value की length error (32-bit की जगह 32-byte)
    • signature length के फर्क से यह अपेक्षाकृत आसानी से पकड़ में आ गया
• लेखक ने माना कि ये दोनों bug Claude की performance जांचने के लिए उपयुक्त हैं, और पुराने version के code पर Claude Code को फिर चलाया

Claude Code की दूसरी debugging के नतीजे

• पहले prompt में Claude ने printf debugging और value tracing करके गलत constant को ढूंढा और ठीक किया
  • processing time इंसान से कम था, और test fail के कारण की सटीक पहचान की गई
• दूसरे prompt में उसने signature length mismatch समस्या ढूंढ ली
  • Claude ने कई रास्तों की जांच के बाद सिर्फ allocation length बदलने का suggestion दिया
  • सुझाया गया fix पूरी तरह perfect नहीं था, लेकिन core error location को सटीक रूप से बताया
• तीनों स्वतंत्र कोशिशों में Claude ने सही bug cause अपने दम पर ढूंढ निकाला

AI debugging की दक्षता और संकेत

• Claude का approach test failure के कारण खोजने में विशेषज्ञ automated helper की तरह असरदार रहा
  • उपयोगकर्ता ने Claude के fix को सीधे apply नहीं किया, बल्कि bug location की पुष्टि करने के बाद खुद fix किया
• लेखक ने “ऐसे tool” की जरूरत बताई जो test fail होते ही अपने-आप LLM से कारण analyze कराए और बताए
  • साधारण chat या automatic PR generation की तुलना में test-based debugging agent का रूप अधिक आदर्श बताया गया

समर्थन और अन्य जानकारी

• लेखक का open source maintenance Geomys के जरिए supported है,
  और Smallstep, Ava Labs, Teleport, Tailscale, Sentry आदि sponsor हैं
• Ava Labs ने crypto protocol के sustainable open source development के महत्व पर जोर दिया
• Teleport ने user account takeover रोकने और access control मजबूत करने के लिए Teleport Identity platform का परिचय दिया

परिशिष्ट: image और व्यक्तिगत उल्लेख

• लेख में Microsoft Office के Clippy को एक speech bubble के साथ दिखाया गया है, जिसमें लिखा है कि “w1 के high bits दो बार लिए गए”
• अंत में बिल्ली की फोटो भी शामिल है, जिसे AI पर भावनात्मक बहस को हल्का करने वाले humor के रूप में पेश किया गया है

[ajh508]

मैं हाल ही में triton या cuda का इस्तेमाल करके GPU kernel डेवलपमेंट थोड़ा कर रहा हूँ, और 3.5 तक तो मैंने इसे ठीक से चलते हुए नहीं देखा था, लेकिन 4.5 में यह कुछ हद तक सही code या optimization कर देता है, ऐसा दिख रहा है।

[GN⁺]

Hacker News राय

• कोडिंग एजेंट का इस्तेमाल करके बग के मूल कारण को ट्रेस करने का तरीका काफ़ी अच्छा काम करता है
  तीनों one-shot debugging सफल रहीं। यहाँ मुख्य बात यह है कि LLM सीधे कोड ठीक नहीं करता, बल्कि सिर्फ़ बग की जगह बताने वाले सहायक की तरह काम करता है ताकि मैं खुद समझकर उसे ठीक कर सकूँ
  यह तरीका LLM को लेकर संदेह रखने वालों के लिए भी एक अच्छा शुरुआती बिंदु हो सकता है। इसे कोड लिखने के बजाय सिर्फ़ परेशान करने वाले बग ढूँढने का काम दें

  • ऐसे एजेंट अक्सर बहुत आक्रामक तरीके से समाधान ढूँढने की कोशिश में असल बात चूक जाते हैं
    “इसे ठीक करना चाहिए” जैसी सलाह पूरी तरह ग़लत नहीं होती, लेकिन अक्सर मुद्दे के केंद्र से उसका लेना-देना नहीं होता। नतीजा यह होता है कि बेकार के fix सुझाव जमा होते जाते हैं, और अगर कोई जूनियर डेवलपर उन्हें वैसे ही लागू कर दे तो अनावश्यक काम ही बढ़ता है
    मैं भी ऐसे टूल इस्तेमाल करता हूँ, लेकिन कई बार लगता है कि “जूनियर को समझाने में ही ज़्यादा समय चला जाता है”
  • LLM algorithmic bugs में काफ़ी अच्छे हैं, लेकिन concurrency bugs में कमज़ोर
    test generation भी algorithmic मामलों में अच्छा है, लेकिन concurrency scenarios में इसकी सीमाएँ हैं। फिर भी “test generation” या “debugging” के उपयोग में इसकी काफ़ी वैल्यू है
    code refactoring या long-term maintenance के नज़रिये से यह अभी भी कमज़ोर है
  • मेरे अनुभव में LLM hobby projects में शानदार रहे, लेकिन बड़े codebase में कम उपयोगी
    लेकिन ब्लॉग में सुझाए गए तरीके से bug hunter की तरह इस्तेमाल किया तो हैरान करने वाला असर दिखा। कुछ ही हफ्तों में कई production bugs पकड़ लिए
  • मुझे सबसे पसंदीदा उपयोग LLM से documentation लिखवाना लगता है
    कोड में गहराई से उतरने से पहले उससे लंबे संबंधित दस्तावेज़ लिखवा दो; अगर उसमें गलती भी हो तो नुकसान कम है, और संदेह रखने वालों के लिए भी यह अच्छी शुरुआत है
  • बग ढूँढना और ठीक करना डेवलपर के तौर पर सबसे ज़्यादा बौद्धिक संतुष्टि देने वाले कामों में से एक है
    यह प्रक्रिया मशीन को सौंप देना थोड़ा अफ़सोसजनक लगेगा। bug hunting सिस्टम की संरचना को गहराई से समझने में मदद करती है और लंबे समय में बेहतर प्रोग्रामर बनाती है
    अगर यह अनुभव न हो, तो अंततः अपने ही कोड पर निर्णय लेने में भी LLM पर निर्भर हो जाने का ख़तरा है

• मेरी सिर्फ़ एक सलाह है: AI First
  पहले AI को समस्या देकर देखो; इससे एक तरफ़ मॉडल की सीमाएँ समझ में आती हैं, और दूसरी तरफ़ prompt को structure करने की क्षमता भी विकसित होती है
  नए मॉडल ज़्यादातर समस्याओं में इतने शक्तिशाली हैं कि उन्हें लगभग सहकर्मी की तरह इस्तेमाल किया जा सकता है। लेकिन उनके failure patterns को समझना और intuition बनाना ज़रूरी है
  हर नई model generation आने पर पुरानी process छोड़कर GPT-5-Codex या Sonnet 4.5 जैसे नए मॉडल के साथ प्रयोग करने की सलाह दूँगा

  • लेकिन “पहले AI को दे दो” वाला तरीका हर बार काम नहीं करता
    अगर आप domain expert हैं तो LLM की hallucinations और errors पहचान सकते हैं, वरना यह उल्टा समय बर्बाद करता है
    आख़िरकार ये टूल विशेषज्ञों के लिए सबसे उपयोगी हैं, और शुरुआती लोगों के लिए इनकी quality काफ़ी अस्थिर है
    मैंने भी Sonnet 4.5 इस्तेमाल किया, लेकिन यह बस पुराने वर्ज़न से थोड़ा बेहतर लगा। अब भी समय की बर्बादी अक्सर होती है

• Anthropic ने मुझे कुछ महीनों के लिए Claude Max मुफ़्त दिया
  हाल में Instagram विज्ञापनों में भी Claude से जुड़ा कंटेंट बहुत दिख रहा है। “Claude Code install” जैसे विज्ञापन बार-बार दिख रहे हैं, तो लगता है कि उनकी marketing team काफ़ी मेहनत कर रही है

  • शायद उन्हें product-market fit मिल गया है
    डेवलपर Claude Code को बहुत उपयोगी मान रहे हैं, और $200/month subscription भी काफ़ी हैं। अगर इसमें profit है, तो marketing पर पैसा खर्च करना स्वाभाविक है

• LLM बग ढूँढने में मदद करते हैं, लेकिन कभी-कभी बेतुकी व्याख्याएँ देकर समय भी बर्बाद कराते हैं
  आख़िर में सबसे ज़रूरी चीज़ critical thinking बनाए रखना है

  • OP का मतलब यह था कि “LLM नहीं, फ़ैसला मैं खुद करता हूँ”
    LLM बेहतरीन टूल है, लेकिन जल्दबाज़ी में निष्कर्ष निकालने की इसकी आदत है। जैसे ही इंसान सोचना बंद करता है, मॉडल ग़लत दिशा में भागने लगता है

• “LLM को सिर्फ़ chat या autocomplete के रूप में इस्तेमाल करना खास उपयोगी नहीं” — इस राय से सहमत हूँ
  मुझे भी Claude Code/Codex इस्तेमाल करने के बाद ही इसकी असली संभावना महसूस हुई। अगर कोई continuously running mode हो, तो और भी दिलचस्प हो सकता है

  • chat UI धीमा और अक्षम है, लेकिन LLM को सिस्टम access देना security और privacy के लिहाज़ से जोखिम भरा है
    वह गलती से फ़ाइलें मिटा सकता है या Git repository खराब कर सकता है। इसलिए मैं सिर्फ़ sandbox environment में ही प्रयोग करता हूँ
  • मैं भी यही सोचता हूँ। असल में चाहिए साथ बैठकर कोड करने वाला copilot
    ऐसा collaborative tool चाहिए जिसमें मॉडल मुझसे सवाल पूछे, मैं सीधे हस्तक्षेप करूँ, और सीखूँ — यानी Socratic शैली की साझेदारी
    आज का “automation-first” दृष्टिकोण डेवलपर को code-illiterate बना देने का जोखिम रखता है। उल्टा, अगर सही डिज़ाइन किया जाए तो यह समझ और intuition को बढ़ाने वाला टूल बन सकता है

• CLI terminal अब भी एक शक्तिशाली interface है
  Gemini CLI और Qwen Code मुफ़्त हैं, और OpenAI-compatible API भी आसानी से जोड़ी जा सकती है।
  आसान काम automate करो, और मुश्किल हिस्सों को Grok से one-shot में निपटाओ तो अच्छा workflow बन सकता है। सिर्फ़ CLI + MCP server + MD files से भी काफ़ी स्मार्ट प्रोग्राम बनाया जा सकता है

  • जानना चाहूँगा कि Gemini CLI, Claude Code या OpenAI Codex के मुकाबले कैसी है
  • फिर भी Claude Code का UX सच में शानदार है

• हर बार test fail होने पर LLM अपने-आप वजह analyze करे — यह idea काफ़ी दिलचस्प है
  Git hook का इस्तेमाल करके Claude CLI चलाने पर यह संभव है।
  उदाहरण और cheat sheet इस गाइड में देखे जा सकते हैं

  • अगर इसे manually चलाना हो, तो एक साधारण Bash script से भी किया जा सकता है। मैं भी मज़े के लिए ऐसा कुछ बनाने का सोच रहा हूँ

• लगता है जल्द ही LLM training data पर adversarial attacks के ज़रिए cryptographic errors उकसाने वाले उदाहरण सामने आएँगे

• “फ़िक्स में पूरी तरह नया function जोड़ना शामिल है” — यह बात cryptographic implementation में जोखिमभरी लगती है
  ऐसा लगता है कि लेख ग़लत सलाह दे रहा है

  • लेकिन लेख का मुख्य बिंदु यह था कि LLM का उपयोग सिर्फ़ बग खोजने के लिए किया गया
    fix code फेंक दिया गया, और इंसान ने खुद लिखा। उल्टा, यह संयमित और ज़िम्मेदार उपयोग का उदाहरण लगता है
  • जैसा लेख में साफ़ कहा गया, असली बात solution नहीं बल्कि detection process है
    LLM को “मिस्त्री” नहीं बल्कि gas leak detector की तरह इस्तेमाल करना चाहिए, जो सिर्फ़ समस्या की जगह बता दे

• LLM ने कोड के अस्पष्ट पैटर्न पहचानकर बहुत-सी उबाऊ समस्याएँ कम कर दी हैं
  लेकिन इसका side effect भी है। मेरा codebase ऊपर से Node.js जैसा दिखता है, जबकि असल में वह नहीं है, इसलिए मॉडल बार-बार उसे Node project समझ लेता है