अपने AI कोडिंग एजेंट को एक फीडबैक लूप कैसे दें जो उसकी अपनी बग्स पकड़े

जब कोई AI कोडिंग एजेंट ऐसा कोड लिखता है जो सही दिखता है लेकिन चुपचाप कुछ तोड़ देता है, तो समस्या आमतौर पर मॉडल नहीं होती — समस्या यह होती है कि एजेंट ने वह विफलता कभी देखी ही नहीं। उसने बदलाव लिखा, जीत का ऐलान किया, और आगे बढ़ गया, क्योंकि किसी ने उसे नहीं बताया कि टेस्ट सूट अब रेड हो चुका है। समाधान है लूप को बंद करना: एजेंट के अपने टूल्स को स्वचालित रूप से उसे वापस रिपोर्ट करने दें।

यह गाइड दिखाती है कि वह फीडबैक लूप कैसे बनाया जाए ताकि आपका एजेंट अपनी गलतियाँ आपसे पहले पकड़ ले।

मूल विचार: एरर्स को संदर्भ (context) में वापस बहना चाहिए

एक भरोसेमंद एजेंट वर्कफ़्लो में चार चरण होते हैं — explore, plan, build, verify। ज़्यादातर लोग "build" पर रुक जाते हैं। verify चरण ही वह चीज़ है जो काम करने वाला कोड बनाने वाले एजेंट को सही-दिखने वाला कोड बनाने वाले एजेंट से अलग करती है।

वेरिफिकेशन का मतलब है हर बदलाव के बाद असली जाँचें चलाना — आपका test runner, linter, और type-checker — और आउटपुट को एजेंट को वापस फीड करना। जब कोई जाँच विफल होती है, तो एरर मैसेज एजेंट के संदर्भ में आ जाता है, और मॉडल इसे किसी अन्य निर्देश की तरह ही मानता है: वह विफलता को पढ़ता है और उसे ठीक करता है। उबाऊ राउंड-ट्रिप के लिए लूप में कोई इंसान नहीं।

आप यह दो तरीकों से कर सकते हैं: इसे अपने project instructions में माँगें, या इसे स्वचालित करें ताकि इसे छोड़ा न जा सके।

विकल्प 1: बस माँगें, अपने project config में

सबसे कम मेहनत वाला संस्करण आपके CLAUDE.md या AGENTS.md (वह plain-text निर्देश फाइल जिसे अधिकांश एजेंट स्टार्टअप पर पढ़ते हैं) में एक पंक्ति है:

## Verification
After any code change, run `npm run typecheck && npm test`.
If either fails, fix the cause and re-run before reporting done.

यह आश्चर्यजनक रूप से अच्छा काम करता है — लेकिन यह सलाहकारी (advisory) है। एक व्यस्त एजेंट भूल सकता है, या तय कर सकता है कि कोई बदलाव वेरिफाई करने के लिए "बहुत छोटा" है। जिस भी चीज़ की आपको परवाह है, उसके लिए वेरिफिकेशन को निश्चित (deterministic) बनाएँ।

विकल्प 2: इसे एक hook से स्वचालित करें

Claude Code hooks आपको lifecycle events के जवाब में एक shell command चलाने देते हैं, चाहे मॉडल को याद रहे या न रहे। यहाँ प्रासंगिक hook है PostToolUse, जो एजेंट द्वारा किसी फाइल को एडिट करने के बाद चलता है। जैसा कि एक व्यावहारिक hooks गाइड कहती है, PostToolUse प्रतिक्रियाओं के लिए बनाया गया है — फ़ॉर्मेटिंग, लॉगिंग, टेस्ट चलाना — और इसका आउटपुट एजेंट के संदर्भ में वापस इंजेक्ट किया जाता है ताकि उसके अगले कदम को प्रभावित किया जा सके।

यहाँ एक न्यूनतम hook है जो किसी भी फाइल एडिट के बाद आपका type-checker चलाता है और विफलताओं को एजेंट को वापस सौंपता है। .claude/settings.json में:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run typecheck"
          }
        ]
      }
    ]
  }
}

अब चक्र स्वचालित है: एजेंट कोड लिखता है → hook tsc चलाता है → यदि कोई type error है, तो मैसेज संदर्भ के रूप में वापस बहता है → एजेंट उसे ठीक करता है → hook फिर से चलता है। hooks reference यह दस्तावेज़ित करता है कि non-zero exit code और आउटपुट मॉडल के सामने कैसे प्रस्तुत होते हैं। यह लूप हर write पर चलता है, बिना किसी प्रॉम्प्टिंग के।

लूप को तेज़ और दायरे में रखें

एक फीडबैक लूप तभी मदद करता है जब वह तेज़ हो। कुछ अंगूठे के नियम:

• सस्ती जाँचें हर एडिट पर चलाएँ, महँगी जाँचें कम बार। बदली हुई फाइल पर type-check या linter तेज़ है। एक पूरा integration suite नहीं — उसे एक Stop hook (जब एजेंट एक टर्न पूरा करता है) या एक मैनुअल कमांड के पीछे गेट करें, न कि हर कीस्ट्रोक पर।
• जो बदला उसी तक दायरा सीमित रखें। एक लाइन के CSS बदलाव के बाद अपना पूरा test suite चलाना समय बर्बाद करता है और संदर्भ को भर देता है। जहाँ आपका टूलिंग अनुमति दे, प्रभावित फाइलों को लक्षित करें।
• विफलताओं को पठनीय बनाएँ। एजेंट केवल वही ठीक करता है जो वह पढ़ सकता है। स्पष्ट, स्थान-निर्दिष्ट एरर मैसेज (file:line: message) वाले linters और type-checkers मॉडल को बिल्कुल वही देते हैं जिसकी उसे ज़रूरत है; एक सामान्य "build failed" नहीं देता।

एक ठोस पहले-और-बाद का उदाहरण

लूप के बिना: आप एजेंट से किसी फ़ंक्शन का नाम बदलने को कहते हैं। वह तीन call sites अपडेट करता है, एक चौथी ऐसी फाइल में चूक जाता है जिसे उसने खोला ही नहीं, और काम पूरा होने की रिपोर्ट देता है। आपको टूटा हुआ import एक घंटे बाद runtime पर पता चलता है।

लूप के साथ: वही rename सेव पर typecheck ट्रिगर करता है। tsc चूकी हुई call site पर Cannot find name 'oldFn' रिपोर्ट करता है। वह एरर संदर्भ में आ जाता है, एजेंट चौथी फाइल खोलता है, संदर्भ ठीक करता है, और अगली जाँच पास हो जाती है — यह सब इससे पहले कि वह आपको बताए कि उसका काम हो गया है।

निष्कर्ष

AI एजेंट कोड बनाने में अच्छे हैं और यह नोटिस करने में बुरे कि वह कब गलत है। आप उस खाई को उन्हें वही संकेत देकर पाटते हैं जिस पर आप भरोसा करते हैं: एक रेड टेस्ट, एक type error, एक विफल lint rule — स्वचालित रूप से दिया गया, बदलाव के ठीक बाद। अपने project instructions में एक पंक्ति से शुरू करें, फिर अपनी सबसे महत्वपूर्ण जाँच को एक hook में बढ़ावा दें ताकि वह चले चाहे मॉडल को याद रहे या न रहे। जो एजेंट "स्मार्ट" महसूस होते हैं, वे आमतौर पर बस वही होते हैं जो एक सघन फीडबैक लूप से जुड़े होते हैं।