Claude के साथ एजेंटिक डेवलपमेंट: पूरी लूप AI कोडिंग

पिछले अक्टूबर में मैंने Claude को एक काफ़ी उबाऊ काम सौंपा: "PHP में WordPress REST API का एक wrapper तैयार करो, उसके लिए PHPUnit टेस्ट लिखो, उन्हें चलाओ और जो भी फ़ेल हो उसे ठीक करो।" मैंने उसे एक स्थानीय Claude tool-use सेटअप के ज़रिए अपने टर्मिनल का एक्सेस दिया और चाय बनाने चला गया। बारह मिनट बाद लौटा तो टेस्ट पास हो चुके थे। मेरे पास 94% कवरेज वाला एक चालू wrapper था, और एक छोटी-सी इनलाइन कमेंट भी, जहाँ Claude ने एक ऐसा एज केस पकड़ा था जिसका मैंने ब्रीफ़ में ज़िक्र तक नहीं किया था। मैं Bermondsey में अपनी रसोई में खड़ा था और सचमुच बेचैन हो गया था।

यह agentic विकास है। autocomplete नहीं, कोई स्मार्टर Stack Overflow नहीं। एक मॉडल जो एक लक्ष्य के बारे में सोचता है, अगली कार्रवाई चुनता है, इसे निष्पादित करता है, परिणाम देखता है, और तब तक लूप करता है जब तक यह किया न जाए। और यह मेरे नौ साल वहां लगभग किसी भी चीज से ज्यादा तेजी से Seahawk Media पर प्रोजेक्ट्स कैसे चलाता हूं इसे बदल दिया।

"एजेंटिक" का असल मतलब क्या है (और क्या नहीं)

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

यह जादू नहीं है। मॉडल अभी भी फंक्शन सिग्नेचर को हैलूसिनेट कर सकता है। यह खुद को एक कोने में लूप कर सकता है सात बार एक ही गलत फिक्स को दोहराते हुए। यह स्टेप एक पर आपके लक्ष्य को गलत समझ सकता है और दस स्टेप्स के लिए आत्मविश्वास से गलत दिशा में बिल्ड कर सकता है। मैंने सभी को देखा है। एक बार, एक React dashboard प्रोजेक्ट पर, Claude ने लगभग बीस मिनट बिताए एक समस्या को हल करने के लिए तेजी से बैरोक null चेक जोड़ते हुए जो वास्तव में एक मिसिंग await था। वह मेरी गलती थी, मैंने इसे एक अस्पष्ट इनिशियल स्पेक दिया।

जो व्यावहारिकों के लिए मायने रखता है उसका अंतर: संकीर्ण एजेंटिक कार्य खुले-अंत वाले कार्यों को मात देते हैं। "एक slug sanitisation फंक्शन लिखें और परीक्षण करें जो अरबी, जापानी और emoji को संभालता है" एक शानदार एजेंटिक कार्य है। "मेरे लिए एक SaaS बनाओ" नहीं है। इसे सीमित रखें, नहीं तो आप गलत मोड़ों की समीक्षा करने में उतना समय लगाएंगे जितना आपने कोड लिखने में लगाते।

असल Stack जो मैं इस्तेमाल कर रहा हूँ

यहाँ टूल्स बहुत महत्वपूर्ण हैं। सही scaffolding के बिना, "agentic Claude" सिर्फ एक चैट विंडो है।

Seahawk पर मेरा सेटअप:

[Claude API](https://www.anthropic.com/api) tool-use के साथ, विशेष रूप से computer_use बीटा और कस्टम bash/filesystem टूल्स
Cursor IDE लेयर के रूप में, Claude 3.5 Sonnet को backend मॉडल के रूप में सेट किया गया है
pytest / PHPUnit / Jest प्रोजेक्ट के आधार पर, क्योंकि Claude को लूप करने के लिए एक निर्धारित सिग्नल चाहिए। टेस्ट आउटपुट के बिना, वह अंधा उड़ रहा है।
एक छोटा system prompt जो Claude को बताता है कि प्रोजेक्ट स्ट्रक्चर क्या है, कोडिंग स्टैंडर्ड्स क्या हैं, और महत्वपूर्ण बात, यदि वह निर्दिष्ट डायरेक्टरी के बाहर एक नई फाइल बनाने वाला है तो रुकना और पूछना है।

वह अंतिम बाधा मामूली लगती है। यह नहीं है। एजेंटिक मॉडल्स खुशी-खुशी पूरे नए मॉड्यूल्स को scaffold करेंगे अगर उन्हें लगता है कि यह लक्ष्य को पूरा करता है। फाइल सिस्टम पर guardrails ने मुझे कई "यह कहाँ से आया?" के पलों से बचाया है।

एक चीज जो मैं इस्तेमाल नहीं करता: ज्यादातर काम के लिए multi-agent orchestration frameworks। LangChain, AutoGen, CrewAI, ये सच में दिलचस्प हैं, लेकिन solo developer या छोटी-agency के उपयोग के लिए, agents-talk-to-agents को कॉन्फ़िगर करने का ओवरहेड आमतौर पर लायक नहीं होता। एक अच्छी तरह से परिभाषित Claude लूप तीन खराब तरीके से परिभाषित agents को एक-दूसरे पर चिल्लाते हुए हराता है।

मैं एक लूप-योग्य कार्य को कैसे संरचित करता हूँ

यह वह है जो मैंने इस साल शायद 200+ एजेंटिक सेशन के बाद तय किया है। मॉडल को एक कार्य विवरण दें जिसमें चार चीजें हों:

लक्ष्य, विशिष्ट, परीक्षणीय, 30 चरणों में पूरा करने के लिए काफी छोटा
प्रारंभिक स्थिति, कौन सी फाइलें मौजूद हैं, कौन सी परीक्षाएं पहले से पास हो रही हैं
सफलता की शर्त, आमतौर पर "सभी परीक्षाएं हरी" या एक विशिष्ट फंक्शन सिग्नेचर जो इसे बनाना चाहिए
रुकने की शर्त, "अगर आपने एक ही समाधान तीन से अधिक बार आजमाया है, तो रुकें और समझाएँ कि आप कहाँ फँसे हुए हैं"

वह चौथा एक underrated है। इसके बिना, Claude कभी-कभी forever loop करेगा। Forever-forever नहीं, लेकिन मैंने इसे एक gnarly regex problem पर 18 attempts करते देखा है, हर एक slightly अलग, कोई भी सही नहीं, कभी नहीं रुका यह कहने के लिए "मुझे sure नहीं हूँ।" इसे explicitly confusion को surface करने के लिए कहना actually कुछ ऐसा है जिसकी Anthropic model spec uncertainty के प्रति model के approach के संदर्भ में discusses करती है, लेकिन व्यावहार में, आपको अभी भी इसे prompt करने की जरूरत है।

2022 में एक क्लाइंट ने हमें 14,000 product listings को legacy Magento install से WooCommerce में migrate करने का काम दिया। उस बिंदु पर Claude agentic loops नहीं कर रहा था, तो हमने migration scripts को hand से दो हफ्ते में लिखा। आज वही काम? मैं एक tight spec लिखूँगा, इसे Claude को Magento DB schema के read access के साथ और staging WooCommerce instance के write access के साथ दूँगा, और इसे run करने दूँगा। मुझे genuinely लगता है कि हम दो दिनों में हो जाते। वही delta है।

जहाँ Claude आश्चर्यजनक रूप से अच्छा है

मौजूदा कोड को पुनर्गठित करना

यह वह जगह है जहाँ मुझे सबसे ज़्यादा प्रभावित हुआ हूँ। इसे एक गंदी 400-लाइन की क्लास दो, इसे single responsibility की ओर refactor करने के लिए कहो, और इसे अपने unit tests को checkpoints के रूप में चलाने दो। यह पूरी फ़ाइल में context को मेरी अपेक्षा से बेहतर रखता है और passing tests को तोड़ने के बारे में genuinely सावधान है। output हमेशा वह architecture नहीं होता जो मैं चुनूँ, लेकिन यह आमतौर पर defensible होता है।

ऐसे कोड के लिए Tests लिखना जो तुमने नहीं लिखा

Seahawk ने बहुत साइट ऑडिट और बचाव काम किए। हम हमेशा codebases को inherit करते थे, अक्सर जीरो टेस्ट्स के साथ और कोई original developer नहीं। मैंने agentic Claude का विशेष रूप से इस्तेमाल शुरु किया inherited कोड के लिए test suite लिखने के लिए इससे पहले कि हम कुछ करें। यह source को पढ़ता है, function नामों और कमेंट्स से intent को infer करता है, test लिखता है, उन्हें चलाता है, और जब कुछ अप्रत्याशित रूप से फेल होता है तो समायोजन करता है। एक बार इसने एक custom WooCommerce order हैंडलर में एक silent डेटा corruption bug को पकड़ा जो शायद दो साल से वहां था। किसी को पता नहीं था।

Boilerplate को Grind करना

REST endpoint scaffolding, CRUD migrations, admin panel forms। वह boring stuff जो एक competent developer को एक दोपहर लगता है और किसी को पसंद नहीं। Claude यहाँ fast और consistent है, और consistency वास्तव में वह है जो तुम boilerplate में चाहते हो, यह creative नहीं बनता, यह tired नहीं होता, यह सिर्फ तुम्हारे existing code को pattern-match करता है और उसे extend करता है।

यह कहाँ गलत होता है

ईमानदारी से, failures instructive हैं। यहाँ वे हैं जो मुझे सबसे अधिक hit करते हैं:

बड़े codebases पर context window overflow। Claude 3.5 Sonnet के पास 200k token का context window है, जो तब तक असंभव बड़ा लगता है जब तक तुम इसे एक full WP plugin के साथ 40 files के साथ नहीं खिला रहे हो। यह उन चीजों को भूलना शुरू करता है जो इसने session के शुरुआत में देखी थीं। Solution: job को smaller loops में break करो explicit checkpoints के साथ।
उन चीजों पर confidence जिनके बारे में यह confident नहीं होना चाहिए। Claude एक database query को fix करेगा, test को चलाएगा, यह pass हो जाता है, और success report करता है, लेकिन query अब subtly कम efficient है क्योंकि इसने एक index-friendly WHERE clause को एक subquery से swap किया। इसने stated problem को solve किया और एक unstated problem create किया। Code review अभी भी matter करता है।
Tool permission creep। अगर तुम इसे bash access देते हो और इसे constrain नहीं करते, तो यह उन packages के लिए npm install चलाएगा जिन्हें तुमने ask नहीं किया, या worse, एक network request करेगा जिसे तुमने sanction नहीं किया। यह malicious नहीं है, यह model है जो helpful लगता है ऐसा कर रहा है। अपनी tool permissions को set करो शुरुआत से पहले, कुछ weird होने के बाद नहीं।

Security पर एक नोट: अगर आप agentic loops को कुछ चलाना चाहते हैं जो production data से connected है, तो कृपया Anthropic के अपने tool-use safety पर guidance को पढ़ें। यह लंबा नहीं है, और यह आपको एक बुरे दिन से बचाएगा।

एजेंटिक बिहेविअर बनाम चैट बिहेविअर के लिए प्रॉम्पटिंग

प्रॉम्पटिंग मॉडल अलग है और यह लोगों को भ्रमित करता है। चैट संदर्भ में आप बातचीत करते हैं, पुनरावृत्तिमूलक होते हैं, आगे-पीछे करते हैं। एक एजेंटिक संदर्भ में, प्रारंभिक प्रॉम्प्ट एक विशिष्टता दस्तावेज़ है। आप कार्य के बीच में स्पष्टीकरण देने के लिए वहां नहीं होंगे।

चीज़ें जो एजेंटिक प्रॉम्प्ट्स को काम करने देती हैं:

सीमाएं पहले बताएं, आखिरी में नहीं। अधिकांश लोग उन्हें दबाते हैं।
इसे बताएं कि क्या न करें। "/src/utils के बाहर किसी भी फ़ाइल को संशोधित न करें" दस पंक्तियों के सकारात्मक निर्देशों से अधिक उपयोगी है।
इसे एक एस्केप हैच दें। "अगर आप एक निर्णय बिंदु पर पहुंचते हैं जहां आगे बढ़ने के लिए डेटाबेस स्कीमा बदलने की आवश्यकता होगी, तो रुकें और समझाएं कि क्यों।"
टेस्ट रनर कमांड को स्पष्ट रूप से संदर्भित करें। "हर परिवर्तन के बाद ./vendor/bin/phpunit tests/ चलाएं और अपने अगले चरण के लिए आउटपुट का उपयोग करें।"

फ्रेमिंग शिफ्ट यह है: आप एक बहुत सक्षम लेकिन सवाल नहीं पूछ सकने वाले ठेकेदार के लिए एक ब्रीफ लिख रहे हैं। तो एक की तरह लिखें।

ऑटोनॉमी डायल: इसे कितना चलने दें

यह सवाल मुझे दूसरे एजेंसी मालिकों से सबसे ज्यादा मिलता है। क्या तुम इसकी निगरानी करोगे या इसे अपने आप चलने दोगे?

एक साल की कोशिश के बाद मेरा जवाब: यह पूरी तरह इस बात पर निर्भर करता है कि क्रियाएं कितनी प्रतिवर्ती हैं। सिर्फ़ पढ़ने वाली शोध, टेस्ट लिखना, नई डायरेक्टरी में स्कैफ़ोल्डिंग, इसे चलने दो। लेकिन जो कुछ भी लाइव डेटाबेस को छूता है, पैकेज मैनिफेस्ट में बदलाव करता है, या बाहरी APIs के साथ इंटरैक्ट करता है, हर कुछ कदमों पर जांच करो, या कम से कम एक्सीकूशन से पहले प्लान पढ़ लो।

ReAct prompting pattern (Reason + Act, 2022 के Yao et al. paper से) यहाँ समझने लायक है। यह essentially वही है जो Claude internally करता है जब आप इसे tools देते हैं: यह सोचता है loud के बारे में क्या करना है, करता है, परिणाम पढ़ता है, फिर सोचता है। उस reasoning को visible बनाना, Claude से अपनी plan को हर action से पहले print करने को कहना, आपको एक natural review point देता है बिना loop को break किए।

मैंने Claude के स्टेप-बाय-स्टेप तर्क आउटपुट को उसी तरह देखना शुरू किया है जैसे मैं एक जूनियर डेवलपर के PR को देखता हूं। मैं इसे जल्दी से पढ़ता हूं। अगर कुछ गड़बड़ लगे, तो मैं हस्तक्षेप करता हूं। अगर यह उचित लगे, तो मैं इसे आगे बढ़ने देता हूं। यह मानसिक मॉडल मेरे लिए अच्छी तरह काम करती है।

FAQ

क्या agentic Claude वाकई क्लाइंट काम के लिए प्रोडक्शन-रेडी है?

गैर-प्रोडक्शन वातावरण में विशिष्ट, सीमित कार्यों के लिए: हाँ, बिल्कुल। मैं इसे नियमित रूप से प्रोजेक्ट्स के स्कैफ़ोल्डिंग, रिफैक्टरिंग और टेस्ट-लिखने के चरणों के लिए उपयोग करता हूं। लाइव क्लाइंट डेटाबेस या बाहरी पेमेंट API को छूने वाली किसी भी चीज़ के लिए, मैं हर एक्सीकूशन स्टेप पर एक इंसान को शामिल रखता हूं। मॉडल सक्षम है; जोखिम मॉडल में नहीं, बल्कि एक गलती के विस्फोट की त्रिज्या में है।

agentic Claude और बस Cursor या GitHub Copilot का उपयोग करने में क्या फर्क है?

Cursor और Copilot इनलाइन कोड सुझाव और चैट इंटरफेस हैं। वे तुम्हारे द्वारा टाइप किए गए चीज़ों पर प्रतिक्रिया करते हैं। Agentic Claude एक लक्ष्य लेता है और स्वयं एक बहु-चरणीय योजना को एक्सीकूट करता है, टर्मिनल, फाइल सिस्टम या वेब ब्राउज़र जैसे टूल्स का उपयोग करके। यह एक ऑटोकंप्लीट इंजन और एक ऐसी प्रक्रिया के बीच का अंतर है जो दस मिनट के लिए बिना निरीक्षण के चल सकती है और एक पूर्ण कार्य के साथ वापस आ सकती है।

क्या मुझे इसे उपयोग करने के लिए कोड करना सीखना होगा?

आपको एक सुसंगत विनिर्देश लिखने के लिए पर्याप्त संदर्भ की जरूरत है और आउटपुट की आलोचनात्मक समीक्षा करने के लिए भी। अगर आप एक diff को पढ़ नहीं सकते और बता नहीं सकते कि बदलाव समझ में आता है या नहीं, तो आपका समय बेकार जाएगा। एजेंटिक AI दक्षता को बढ़ाता है। यह आधारभूत स्तर की जगह नहीं लेता।

एजेंटिक लूप्स के लिए मुझे कौन सा Claude मॉडल इस्तेमाल करना चाहिए?

Claude 3.5 Sonnet मेरा वर्तमान डिफ़ॉल्ट है। यह तर्क की गुणवत्ता और गति के बीच अच्छा संतुलन बनाता है, जो तब महत्वपूर्ण है जब आप 30-स्टेप लूप में प्रति टोकन पैसे खर्च कर रहे हों। Claude 3 Opus बहुत जटिल तर्क कार्यों में बेहतर है लेकिन धीमा और अधिक महंगा है, मैं इसे बड़ी नौकरियों के लिए शुरुआती योजना चरण में इस्तेमाल करता हूँ, फिर निष्पादन के लिए Sonnet को सौंप देता हूँ।

---

जो बात मुझे बार-बार लगती है वह यह है कि एजेंटिक विकास वास्तव में AI के डेवलपर्स की जगह लेने के बारे में नहीं है। यह इस बारे में है कि एक डेवलपर का समय कितना मूल्यवान है इसे बदलना। उन बारह मिनटों में जो मैंने पिछले अक्टूबर में वह PHP wrapper लिखने में नहीं बिताए, मैंने आर्किटेक्चर के बारे में सोचा। यह एक ऐसा सौदा है जो मैं हर बार लूँगा।