पिछले अक्टूबर मैंने Claude को एक काफी बोरिंग टास्क दिया: "WordPress REST API wrapper को PHP में स्कैफोल्ड करो, इसके लिए PHPUnit टेस्ट लिखो, इन्हें चलाओ, जो कुछ भी फेल हो उसे फिक्स करो।" मैंने इसे एक लोकल Claude tool-use सेटअप के माध्यम से मेरे टर्मिनल तक एक्सेस दिया और चाय बनाने चला गया। बारह मिनट बाद वापस आया। सभी टेस्ट ग्रीन थे। मेरे पास एक काम करने वाला wrapper था 94% कवरेज के साथ और एक छोटी इनलाइन कमेंट जहाँ Claude ने एक एज केस को पकड़ा था जिसका मैंने ब्रीफ में जिक्र नहीं किया था। मैं Bermondsey में अपनी किचन में खड़ा होकर सच में असहज महसूस कर रहा था।
यही एजेंटिक डेवलपमेंट है। ऑटोकंप्लीट नहीं, एक स्मार्टर 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 चरणों में पूरा करने के लिए काफी छोटा
- प्रारंभिक स्थिति, कौन सी फाइलें मौजूद हैं, कौन सी परीक्षाएं पहले से पास हो रही हैं
- सफलता की शर्त, आमतौर पर "सभी परीक्षाएं हरी" या एक विशिष्ट फंक्शन सिग्नेचर जो इसे बनाना चाहिए
- रुकने की शर्त, "अगर आपने एक ही समाधान तीन से अधिक बार आजमाया है, तो रुकें और समझाएँ कि आप कहाँ फँसे हुए हैं"
वह चौथी चीज कम आंकी गई है। इसके बिना, Claude कभी-कभी हमेशा के लिए लूप करेगा। सीमा-सदा के लिए नहीं, लेकिन मैंने इसे एक जटिल regex समस्या पर 18 प्रयास करते देखा है, प्रत्येक थोड़ा अलग, कोई भी सही नहीं, कभी रुकने के लिए नहीं कि "मुझे निश्चित नहीं हूँ।" इसे स्पष्ट रूप से भ्रम को सामने लाने के लिए कहना वास्तव में कुछ है जिस पर Anthropic मॉडल spec अनिश्चितता के लिए मॉडल के दृष्टिकोण के संदर्भ में चर्चा करता है, लेकिन व्यवहार में, आपको अभी भी इसके लिए प्रॉम्प्ट की आवश्यकता है।
2022 में एक क्लाइंट ने हमें एक लीगेसी Magento इंस्टॉल से WooCommerce में 14,000 उत्पाद सूचियों को माइग्रेट करने का काम दिया। उस समय Claude एजेंटिक लूप नहीं कर रहा था, इसलिए हमने माइग्रेशन स्क्रिप्ट को हाथ से दो हफ्तों में लिखा। आज वही काम? मैं एक कड़ी विशिष्टता लिखूँगा, इसे Claude को Magento DB स्कीमा के लिए पढ़ने की पहुँच और एक स्टेजिंग WooCommerce इंस्टेंस के लिए लिखने की पहुँच के साथ सौंपूँगा, और इसे चलने दूँगा। मुझे वास्तव में लगता है कि हम दो दिन में पूरा हो जाते। यह अंतर है।
जहाँ Claude आश्चर्यजनक रूप से अच्छा है
मौजूदा कोड को पुनर्गठित करना
यह वह जगह है जहाँ मुझे सबसे ज़्यादा प्रभावित हुआ हूँ। इसे एक गंदी 400-लाइन की क्लास दो, इसे single responsibility की ओर refactor करने के लिए कहो, और इसे अपने unit tests को checkpoints के रूप में चलाने दो। यह पूरी फ़ाइल में context को मेरी अपेक्षा से बेहतर रखता है और passing tests को तोड़ने के बारे में genuinely सावधान है। output हमेशा वह architecture नहीं होता जो मैं चुनूँ, लेकिन यह आमतौर पर defensible होता है।
ऐसे कोड के लिए Tests लिखना जो तुमने नहीं लिखा
Seahawk बहुत सारे site audits और rescues करता है। हम हर समय codebases को inherit करते हैं, अक्सर zero tests के साथ और original developer कहीं नज़र नहीं आता। मैंने agentic Claude का उपयोग करना शुरू किया है inherited code के लिए एक test suite लिखने के लिए, फिर हम कुछ भी करने से पहले। यह source को पढ़ता है, function names और comments से intent को infer करता है, tests लिखता है, उन्हें चलाता है, और जब कुछ unexpectedly fail हो तो adjust करता है। पिछले महीने इसने एक silent data corruption bug को पकड़ा एक custom WooCommerce order handler में जो शायद दो साल से वहाँ था। किसी को पता नहीं था।
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 होने के बाद नहीं।
सुरक्षा के बारे में एक नोट: अगर आप प्रोडक्शन डेटा से जुड़ी किसी भी चीज़ के विरुद्ध एजेंटिक लूप्स चला रहे हैं, तो कृपया Anthropic के स्वयं के टूल-यूज़ सेफ्टी गाइडेंस को पढ़ें। यह लंबा नहीं है, और यह आपको एक बुरे दिन से बचा लेगा।
एजेंटिक बिहेविअर बनाम चैट बिहेविअर के लिए प्रॉम्पटिंग
प्रॉम्पटिंग मॉडल अलग है और यह लोगों को भ्रमित करता है। चैट संदर्भ में आप बातचीत करते हैं, पुनरावृत्तिमूलक होते हैं, आगे-पीछे करते हैं। एक एजेंटिक संदर्भ में, प्रारंभिक प्रॉम्प्ट एक विशिष्टता दस्तावेज़ है। आप कार्य के बीच में स्पष्टीकरण देने के लिए वहां नहीं होंगे।
चीज़ें जो एजेंटिक प्रॉम्प्ट्स को काम करने देती हैं:
- सीमाएं पहले बताएं, आखिरी में नहीं। अधिकांश लोग उन्हें दबाते हैं।
- इसे बताएं कि क्या न करें। "/src/utils के बाहर किसी भी फ़ाइल को संशोधित न करें" दस पंक्तियों के सकारात्मक निर्देशों से अधिक उपयोगी है।
- इसे एक एस्केप हैच दें। "अगर आप एक निर्णय बिंदु पर पहुंचते हैं जहां आगे बढ़ने के लिए डेटाबेस स्कीमा बदलने की आवश्यकता होगी, तो रुकें और समझाएं कि क्यों।"
- टेस्ट रनर कमांड को स्पष्ट रूप से संदर्भित करें। "हर परिवर्तन के बाद ./vendor/bin/phpunit tests/ चलाएं और अपने अगले चरण के लिए आउटपुट का उपयोग करें।"
फ्रेमिंग शिफ्ट यह है: आप एक बहुत सक्षम लेकिन सवाल नहीं पूछ सकने वाले ठेकेदार के लिए एक ब्रीफ लिख रहे हैं। तो एक की तरह लिखें।
ऑटोनॉमी डायल: इसे कितना चलने दें
यह सवाल मुझे दूसरे एजेंसी मालिकों से सबसे ज्यादा मिलता है। क्या तुम इसकी निगरानी करोगे या इसे अपने आप चलने दोगे?
एक साल की कोशिश के बाद मेरा जवाब: यह पूरी तरह इस बात पर निर्भर करता है कि क्रियाएं कितनी प्रतिवर्ती हैं। सिर्फ़ पढ़ने वाली शोध, टेस्ट लिखना, नई डायरेक्टरी में स्कैफ़ोल्डिंग—इसे चलने दो। लेकिन जो कुछ भी लाइव डेटाबेस को छूता है, पैकेज मैनिफेस्ट में बदलाव करता है, या बाहरी APIs के साथ इंटरैक्ट करता है—हर कुछ कदमों पर जांच करो, या कम से कम एक्सीकूशन से पहले प्लान पढ़ लो।
ReAct प्रॉम्पटिंग पैटर्न (Reason + Act, 2022 के Yao et al. पेपर से) यहां समझने लायक है। यह असल में वही है जो Claude आंतरिक रूप से करता है जब तुम उसे टूल्स देते हो: वह अपने बारे में सोचता है कि क्या करना है, करता है, नतीजा पढ़ता है, फिर से सोचता है। उस तर्क को स्पष्ट करना, Claude से कहना कि हर कार्रवाई से पहले अपनी योजना प्रिंट करे, तुम्हें एक प्राकृतिक समीक्षा बिंदु देता है बिना लूप को तोड़े।
मैंने 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 लिखने में नहीं बिताए, मैंने आर्किटेक्चर के बारे में सोचा। यह एक ऐसा सौदा है जो मैं हर बार लूँगा।