पृष्ठभूमि
इसकी शुरुआत मेरे टीम लीड के साथ हुई कई वन-ऑन-वन मीटिंग्स से हुई। उन्हें इस बात में दिलचस्पी थी कि मैं AI टूल्स का इस्तेमाल कैसे करता हूँ, अपने पर्सनल Harnesses कैसे बनाता हूँ, और अपना AI Coding वर्कफ़्लो कैसे स्ट्रक्चर करता हूँ। इसकी मुख्य वजह यह थी कि मैं रिक्वायरमेंट्स को तेज़ी से और बेहतरीन तरीके से डिलीवर कर रहा था, और पहले से ही कुछ प्रोजेक्ट्स का प्राइमरी ओनर बन चुका था। इसलिए, मैंने इस मौके का फायदा उठाकर अपने रोज़मर्रा के AI वर्कफ़्लो को व्यवस्थित किया। फिलहाल, मैं अपनी टीम में मौजूदा बैकएंड बिज़नेस लॉजिक को मेंटेन करते हुए मुख्य रूप से Agent डेवलपमेंट का काम करता हूँ।
इससे पहले, मैंने Xiaohongshu पर इससे जुड़े वर्कफ़्लो शेयर किए थे। उस समय का संदर्भ यह था कि GPT-5.4 और Opus 4.6 सटीक context और उचित constraints दिए जाने पर पहले से ही टास्क को अच्छी तरह पूरा कर सकते थे। Harness Engineering के उदय ने सभी को यह एहसास दिलाया: आप constraints जोड़कर शक्तिशाली मॉडल्स पर बेहतर नियंत्रण रख सकते हैं।
उदाहरण के लिए, Skills like Superpowers एक अपेक्षाकृत भारी (heavy) इम्प्लीमेंटेशन प्रदान करता है, जो मुख्य रूप से Spec और TDD के इर्द-गिर्द घूमता है, जिससे लोगों को टास्क को आसानी से व्यवस्थित करने और आगे बढ़ाने में मदद मिलती है।
लेकिन ऐसा करने के कुछ नुकसान भी हैं। सबसे स्पष्ट अनुभव यह होता है: Token की खपत बहुत तेज़ी से होती है। Skills like Superpowers में कई Workflows होते हैं जिनका उपयोग मॉडल के अगले कदम को नियंत्रित करने के लिए किया जाता है। भले ही समग्र दृष्टिकोण से कोई विशेष स्टेप अब ज़रूरी न हो—उदाहरण के लिए, context पर्याप्त है और सीधे इम्प्लीमेंटेशन शुरू किया जा सकता है—फिर भी मॉडल पहले से तय प्रक्रिया के अनुसार काम करता रह सकता है।
नए मॉडल्स के रिलीज़ होने के बाद, मैंने कई डेवलपर्स को यह शेयर करते देखा है कि वे अब इन भारी-भरकम Skills का इस्तेमाल लगभग नहीं करते। इसका एक मुख्य कारण यह है कि मॉडल की क्षमताओं में सुधार के बाद, कुछ constraints और प्रक्रियाएँ जिन्हें हम पहले उपयोगी मानते थे, अब मॉडल के लिए शोर (noise) बन गई हैं। उदाहरण के लिए, जब OpenAI ने Astra रिलीज़ किया, तो उन्होंने खास तौर पर एक ब्लॉग पोस्ट लिखी जिसमें बताया गया कि मॉडल के उपयोग के अनुभव को बेहतर बनाने के लिए अनावश्यक Skills और system prompts को कैसे साफ़ करें।
इसलिए, इस लेख में मैं पिछले कुछ महीनों में अपने द्वारा अपनाए गए तरीकों को साझा करूँगा, जो वर्तमान में मेरे लिए कारगर हैं, और चर्चा करूँगा कि रोज़मर्रा के डेवलपमेंट की कार्यक्षमता (efficiency) को बढ़ाने के लिए विभिन्न Agents का बेहतर उपयोग कैसे किया जाए।
1. मेरे सामान्य रूप से इस्तेमाल किए जाने वाले Skills और Prompts
मेरे वर्तमान टूल डिवीज़न इस प्रकार हैं:
फिलहाल, मैं कोडिंग इम्प्लीमेंटेशन के लिए मुख्य रूप से Codex + GPT-5.6 Sol का उपयोग करता हूँ, और प्लानिंग के लिए Astra का। Astra के रिलीज़ होने से पहले, प्लानिंग का काम मुख्य रूप से GPT-5.6 Sol Max को सौंपा जाता था।
सरल रिक्वायरमेंट्स के लिए, मैं इम्प्लीमेंटेशन हेतु pi + DeepSeek V4 Flash का उपयोग करता हूँ; समाधानों की adversarial review और Code Review मुख्य रूप से Claude 5 Fable द्वारा संभाली जाती है। पर्सनल प्रोजेक्ट्स में, मैं मुख्य समाधान डिज़ाइन के लिए वेब-आधारित GPT-6 Pro का भी उपयोग करता हूँ।
मेरे सामान्य रूप से इस्तेमाल किए जाने वाले Skills
- think: tw93 का Skill, जिसका उपयोग मुख्य रूप से समाधान को अलाइन करने और ब्रेनस्टॉर्मिंग के लिए किया जाता है।
- grill me / grill with docs: मुख्य रूप से रिक्वायरमेंट को स्पष्ट करने के लिए उपयोग किया जाता है। लगातार सवाल पूछकर, यह लक्ष्यों, constraints और trade-offs को स्पष्ट करता है, और फिर डेवलपमेंट प्रक्रिया की आवश्यकताओं के अनुसार उन्हें ADR या CONTEXT.md में दर्ज करता है। यह मुझे उन समस्याओं को खोजने में मदद करता है जिन पर शुरुआती अलाइनमेंट के दौरान विचार नहीं किया गया था।
- implement: grill के साथ मिलकर उपयोग किया जाता है, Matt Pocock के Skills suite का हिस्सा है, जिसका उपयोग स्पष्ट रूप से परिभाषित योजनाओं या Issues को लागू करने के लिए किया जाता है।
- ponytail: AI द्वारा की गई ओवर-डिज़ाइनिंग को साफ़ करने और Review को आसान बनाने के लिए उपयोग किया जाता है। मैं इसे अक्सर इस्तेमाल करता हूँ क्योंकि GPT-5.6 Sol बार-बार ओवर-डिज़ाइन करता है।
- handoff: वर्तमान context को फ़ाइलों में व्यवस्थित करता है, जिससे नए sessions में काम को आगे बढ़ाना आसान हो जाता है। मैं आम तौर पर इसका उपयोग Codex से Claude Code या pi agent को काम सौंपने के लिए करता हूँ।
- check: code review के लिए उपयोग किया जाता है, आमतौर पर MRs सबमिट करते समय इसका इस्तेमाल होता है।
- काम और पर्सनल डेवलपमेंट से निकाले गए Skills: मुख्य रूप से पुन: उपयोग योग्य प्रक्रिया SOPs, जैसे end-to-end testing। मेरा सुझाव है कि रोज़मर्रा के काम में, यदि कोई प्रक्रिया तीन बार से अधिक दोहराई जाती है, तो Codex से उसे एक Skill में व्यवस्थित करवाने पर विचार करें ताकि बाद में इसका सीधा पुन: उपयोग किया जा सके।
मेरे सामान्य रूप से इस्तेमाल किए जाने वाले Prompts
अब मैं खुद से बड़े-बड़े Prompt शायद ही लिखता हूँ। जब ज़रूरत पड़ती है, तो मैं आमतौर पर Codex से उन्हें व्यवस्थित करवाता हूँ। उदाहरण के लिए, कई दौर की चर्चा के बाद, अगर मैं वर्तमान context को समाधान डिज़ाइन के लिए GPT Pro को सौंपना चाहता हूँ, तो मैं पहले Codex से एक पूरा handoff Prompt जनरेट करवाता हूँ।
इसके अलावा, मैं अक्सर निम्नलिखित प्रकार के बहुत छोटे Prompts का उपयोग करता हूँ।
ये कभी-कभी "एक वाक्य, हज़ार शब्दों के बराबर" वाला असर दिखाते हैं। मैं इन्हें मॉडल के "थिंकिंग शॉर्टकट्स" के रूप में समझता हूँ।
ये कोई जादुई मंत्र नहीं हैं, बल्कि मानवीय ज्ञान में अत्यधिक मानकीकृत (standardized) कार्यप्रणालियाँ हैं। ट्रेनिंग के दौरान, मॉडल ने इससे जुड़ी बड़ी मात्रा में रिसर्च पेपर्स, कोड, डिज़ाइन डॉक्यूमेंट्स और चर्चाएँ देखी हैं, इसलिए अक्सर सैकड़ों लाइनों का Workflow हाथ से लिखने की ज़रूरत नहीं होती, बस उसे बता दें कि किस सोचने के तरीके को अपनाना है। यहाँ कुछ ऐसे prompts हैं जो अभ्यास के दौरान मुझे बहुत प्रभावी लगे:
- First Principles: मौजूदा समाधानों के आधार पर सुधार करना जारी न रखें, बल्कि दोबारा पूछें कि इस समस्या को वास्तव में कैसे हल किया जाना चाहिए। उदाहरण के लिए, अगर कोई इंटरफ़ेस धीमा है, तो आप कह सकते हैं:
"Redis cache जोड़ने" के तय समाधान के आधार पर डिज़ाइन करना जारी न रखें। First principles से विश्लेषण करें कि यह इंटरफ़ेस धीमा क्यों है, और इसके लिए न्यूनतम आवश्यक समाधान क्या है।
मॉडल का फोकस "Redis को कैसे डिज़ाइन किया जाए" से हटकर इस पर चला जाता है:
क्या बाधा SQL, नेटवर्क, serialization, lock contention, या बार-बार होने वाली गणना में है? अगर SQL में index जोड़ने से यह हल हो जाता है, तो Redis को क्यों शामिल करें?
इस प्रकार का Prompt तब उपयुक्त होता है जब आपको शक हो कि "सवाल ही गलत हो सकता है।"
- Adversarial Review: मेरे समाधान के पक्ष में कारण मत ढूँढो, बल्कि यह साबित करने की कोशिश करो कि यह गलत है।
आम तौर पर पूछने का तरीका यह होता है:
देखो कि क्या इस तकनीकी समाधान में कोई समस्या है।
इसे बदलकर यह किया जा सकता है:
इस समाधान की adversarial review करो, और उन counter-examples को खोजने को प्राथमिकता दो जो मुख्य मान्यताओं को पलट सकें।
मान लीजिए आपका समाधान "डुप्लिकेट रिक्वेस्ट्स को हल करने के लिए distributed locks लागू करना" है, तो मॉडल अब सिर्फ यह नहीं बताएगा कि lock timeout कैसे सेट करें, बल्कि सवाल पूछना शुरू कर देगा:
क्या डुप्लिकेट रिक्वेस्ट्स को वास्तव में mutual exclusion की ज़रूरत है? क्या interface idempotency इसे हल कर सकती है? अगर lock service क्रैश हो जाए तो क्या होगा? अगर lock expire हो जाए लेकिन बिज़नेस प्रक्रिया पूरी न हुई हो तो? क्या हमने एक लोकल समस्या को हल करने के लिए एक नया distributed failure point तो नहीं जोड़ दिया?
इस प्रकार का Prompt विशेष रूप से समाधान की समीक्षाओं (solution reviews) और Code Reviews के लिए उपयुक्त है।
- Ablation Experiments: सिस्टम का बेहतर होना इसका मतलब नहीं है कि आपके द्वारा जोड़ा गया हर चीज़ उपयोगी है।
उदाहरण के लिए, आपने एक साथ तीन ऑप्टिमाइज़ेशन किए:
indexes, Redis cache और batch queries जोड़ने के बाद, इंटरफ़ेस latency 800ms से घटकर 100ms हो गई।
इस समय, आप सीधे पूछ सकते हैं:
यह पता लगाने के लिए इन तीनों ऑप्टिमाइज़ेशन के लिए ablation experiments डिज़ाइन करें कि असली फायदा कहाँ से मिल रहा है।
मॉडल Baseline से शुरू करते हुए विभिन्न संयोजनों के इर्द-गिर्द controls डिज़ाइन करेगा, जैसे केवल indexes जोड़ना, indexes + cache, indexes + cache + batch queries आदि की तुलना करना।
अंत में, यह पा सकता है:
केवल indexes जोड़ने से ही latency 800ms से घटकर 120ms हो गई, बाकी दोनों जटिल समाधानों ने केवल 20ms का योगदान दिया।
इस तरह, आपको अधिक स्पष्ट रूप से पता चल जाता है कि कौन सा कोड रखने लायक है और कौन सी जटिलता अनावश्यक हो सकती है।
- Occam's Razor: जब परिणाम समान हों, तो कम मान्यताओं और कम जटिलता वाले समाधानों को प्राथमिकता दें।
उदाहरण के लिए, Agent इस तरह का समाधान डिज़ाइन करता है:
Kafka + Redis + Distributed Lock + State Machine + Timed Compensation.
आप एक वाक्य जोड़ सकते हैं:
Occam's Razor का उपयोग करके इस डिज़ाइन की दोबारा समीक्षा करें, और रिक्वायरमेंट्स को पूरा करने की शर्त पर सभी गैर-आवश्यक तंत्रों को हटा दें।
अक्सर, यह अंत में पाता है:
वर्तमान स्थिति में केवल single-database writes शामिल हैं, एक transaction और एक unique index ही काफी है।
यह एक वाक्य वर्तमान Coding Agents के लिए विशेष रूप से उपयोगी है, क्योंकि मॉडल "पूर्णता" के चक्कर में आसानी से ओवर-डिज़ाइन कर बैठते हैं।
- High Cohesion, Low Coupling: कोड की ज़िम्मेदारियों और सीमाओं की दोबारा जाँच करें।
उदाहरण के लिए, अगर आप पाते हैं कि OrderService पहले से ही 2000 लाइनों का हो गया है, तो आप पूछ सकते हैं:
High cohesion और low coupling के सिद्धांतों के अनुसार OrderService की ज़िम्मेदारी की सीमाओं की समीक्षा करें, केवल बांटने के लिए न बांटें।
मॉडल आमतौर पर जाँचना शुरू कर देता है:
ऑर्डर सर्विस एक साथ inventory, coupons, SMS, payment और reports को क्यों संभाल रही है? कौन सी लॉजिक खुद ऑर्डर डोमेन की है, और किसे स्थिर interfaces के माध्यम से अन्य मॉड्यूल्स को सौंपा जाना चाहिए?
यह केवल साधारण "फ़ाइल को बांटने" को सक्रिय नहीं करता, बल्कि modularization, information hiding, dependency direction और responsibility division के बारे में निर्णयों के एक पूरे सेट को सक्रिय करता है।
इसलिए, मैं अब शायद ही कभी लिखता हूँ:
Step 1 रिक्वायरमेंट्स का विश्लेषण करें, Step 2 मान्यताओं की जाँच करें, Step 3 विकल्प खोजें, Step 4...
कई परिपक्व कार्यप्रणालियाँ मॉडल पहले ही सीख चुका है। मैं सीधे बताना पसंद करता हूँ:
First principles से दोबारा विश्लेषण करें, वर्तमान समाधान पर adversarial review करें; मुख्य तंत्रों को ablation experiments के माध्यम से सत्यापित किया जाना चाहिए; समाधान Occam's Razor का पालन करे, कोड high cohesion और low coupling बनाए रखे।
इन कुछ दर्जन शब्दों के पीछे, वास्तव में पाँच अलग-अलग संज्ञानात्मक (cognitive) कार्यों को निर्दिष्ट किया गया है:
समस्या को फिर से परिभाषित करें → मान्यताओं पर हमला करें → योगदान को सत्यापित करें → जटिलता को हटाएं → सिस्टम की सीमाओं को व्यवस्थित करें।
जैसा कि मैं समझता हूँ, नए मॉडल युग में Prompt Engineering में यही बदलाव है: मॉडल के लिए एक पूरी तय थिंकिंग प्रक्रिया लिखने के बजाय, सटीक कार्यप्रणालियों का उपयोग करके उसे यह बताना बेहतर है कि "किस तरह से सोचना है," और फिर वर्तमान टास्क के लिए वास्तव में ज़रूरी constraints को जोड़ना है।
2. मेरा रोज़मर्रा का डेवलपमेंट वर्कफ़्लो
कोई रिक्वायरमेंट मिलने के बाद, मैं आमतौर पर पहले संबंधित context को Agent को सौंपता हूँ, जैसे PRD, मीटिंग के नोट्स, चैट रिकॉर्ड्स और यूज़र फीडबैक, फिर उसके साथ रिक्वायरमेंट्स को अलाइन करने के लिए grill का उपयोग करता हूँ।
ये सामग्रियाँ अक्सर एक पूर्ण, सुसंगत रिक्वायरमेंट नहीं होती हैं। हो सकता है PRD अपडेट न हुआ हो, मीटिंग्स में कुछ प्रतिबंध जोड़े गए हों, या चैट में प्राथमिकताएँ बदल दी गई हों। रिक्वायरमेंट्स को लेकर मेरी अपनी समझ में भी कुछ अनकही मान्यताएँ शामिल हो सकती हैं।
मैं Agent को टीम Wiki और मौजूदा कोड के साथ इन सामग्रियों को समझने देता हूँ, फिर लगातार सवाल पूछकर उन लक्ष्यों, सीमाओं और trade-offs को स्पष्ट करता हूँ जो इम्प्लीमेंटेशन को प्रभावित करते हैं। कुछ सवालों के जवाब मैं तुरंत दे सकता हूँ, जबकि अन्य के लिए प्रोडक्ट या संबंधित सहकर्मियों से दोबारा पुष्टि करने की ज़रूरत पड़ती है।
यहाँ, मैं एक पैमाना नियंत्रित करता हूँ: जब बचे हुए सवाल इम्प्लीमेंटेशन की दिशा और स्वीकृति (acceptance) के परिणामों को महत्वपूर्ण रूप से नहीं बदलेंगे, तब डेवलपमेंट शुरू किया जा सकता है।
मैं यह ज़रूरी नहीं मानता कि वह पहले से सभी इम्प्लीमेंटेशन विवरणों की योजना बनाए, अन्यथा रिक्वायरमेंट अलाइनमेंट खुद एक बहुत भारी प्रक्रिया बन जाएगा।
अलाइनमेंट के बाद के निष्कर्षों को Spec या CONTEXT.md में दर्ज किया जाता है, जिसमें मुख्य रूप से इस बार हल की जाने वाली समस्या, scope, मुख्य निर्णय और acceptance criteria रिकॉर्ड किए जाते हैं। इससे इम्प्लीमेंटेशन और review की ज़िम्मेदारी संभालने वाले बाद के Agents के लिए भी उसी context को साझा करना आसान हो जाता है, बिना पिछली सभी बातचीत को दोबारा पढ़े।
समाधान तय होने के बाद, मैं मुख्य Agent को टास्क की जटिलता के आधार पर यह तय करने देता हूँ कि इसे कैसे लागू करना है। सरल रिक्वायरमेंट्स को सीधे लागू किया जाता है; जटिल रिक्वायरमेंट्स को स्पष्ट सीमाओं वाले Issues में विभाजित किया जाता है जिन्हें स्वतंत्र रूप से स्वीकार किया जा सकता है। केवल उन हिस्सों को subagents को सौंपा जाता है जो स्वतंत्र रूप से आगे बढ़ सकते हैं, ताकि वे अलग-अलग worktrees में समानांतर डेवलपमेंट कर सकें, और अंत में मुख्य Agent द्वारा उन्हें एकीकृत किया जाता है।
coding Agent पहले टेस्ट्स पूरा करता है। जब उसे लगता है कि वह डिलीवर करने के लिए तैयार है, तो मैं टास्क की जटिलता के आधार पर cross-adversarial review के लिए अन्य Agents को शामिल करता हूँ। पाई गई समस्याओं को एक साथ मुख्य coding Agent, यानी Codex को फीडबैक दी जाती है, जो उन्हें ठीक करता है और दोबारा सत्यापित करता है।
अपनी Review से पहले, मैं end-to-end testing भी करता हूँ।
मैं अभी जनरेट किए गए सभी कोड को लाइन-बाय-लाइन नहीं पढ़ता, मुख्य रूप से टेस्ट परिणामों और कोर बिज़नेस लॉजिक पर ध्यान देता हूँ। यहाँ एक महत्वपूर्ण शर्त है: हर MR का scope पर्याप्त रूप से छोटा होना चाहिए, और डेवलपमेंट के साथ-साथ पूर्ण बिज़नेस पाथ को धीरे-धीरे सत्यापित किया जाना चाहिए।
छोटे MRs हर बार समझने और निर्णय लेने के लिए ज़रूरी बदलावों को नियंत्रणीय सीमा में रखते हैं; end-to-end tests यह जाँचने में मदद करते हैं कि क्या ये बदलाव वास्तविक बिज़नेस प्रक्रियाओं में लागू होने पर खरे उतरते हैं। मैन्युअल Review के दौरान, मैं बिज़नेस लॉजिक की पुष्टि करने और यह देखने पर ध्यान केंद्रित करता हूँ कि क्या मौजूदा टेस्ट परिणाम इस डिलीवरी का समर्थन करने के लिए पर्याप्त हैं।
3. Agent-Friendly End-to-End Testing कैसे बनाएं
AI टेस्ट केस लिखने में पहले से ही बहुत अच्छा है, और अक्सर एक Bugfix के लिए सैकड़ों लाइनों के टेस्ट लिख देता है (विशेषकर 5.6 sol)। अक्सर, अधिक टेस्ट लिखना अपने आप में कोई समस्या नहीं है, लेकिन डिप्लॉयमेंट और लॉन्च के बाद भी हमें अप्रत्याशित त्रुटियों का सामना करना पड़ता है।
मेरे अनुभव में, एक मुख्य समस्या यह है: Agent को end-to-end testing environment नहीं दिया गया, ताकि उसे कोडिंग और self-testing चरणों के दौरान इन समस्याओं को खोजने का मौका मिल सके।
अगर ऐसा environment बनाया जा सके, जिससे Agent टेस्ट environment के वास्तविक entry point से आसानी से टास्क निष्पादित कर सके, और यूज़र्स को चाहिए परिणामों तक लगातार जाँच कर सके, तो हम पूरे आत्मविश्वास के साथ AI द्वारा लिखे गए कोड को वास्तविक सिस्टम में चला सकते हैं।
वास्तविक डेवलपमेंट में, मैंने हमारे बिज़नेस के लिए end-to-end development testing environments का एक सेट बनाया है। Agent आसानी से डेटाबेस टेबल्स, लॉग्स को query कर सकता है, और समस्याओं का समाधान खोजने के लिए मशीनों से कनेक्ट हो सकता है।
पूरी निर्माण प्रक्रिया मूल रूप से Agent को मेरे रोज़मर्रा के डेवलपमेंट self-test प्रोसेस को निकालने देने, और बिखरे हुए टूल्स और क्षमताओं को एकीकृत करने देने जैसी है: जिन क्षमताओं को toolized किया जा सकता है उन्हें MCP या CLI में बनाया जाता है; पुन: उपयोग योग्य प्रक्रियाओं को Skills में लिखा जाता है।
इसमें वास्तव में शुरुआत में कुछ मेहनत लगती है, लेकिन झंझट से न डरें। एक बार बन जाने के बाद, यह डेवलपमेंट को काफी तेज़ कर देता है, rework और ऑनलाइन समस्याओं की संभावनाओं को कम करता है, और आपको पूरे दिन यह चिंता नहीं करनी पड़ती कि AI द्वारा लिखा गया कोड कोई दुर्घटना तो नहीं कर देगा।
Agent-friendly end-to-end testing के इर्द-गिर्द, मैंने मुख्य रूप से चार काम किए:
- Agent को environment से परिचित कराना: जैसे टेस्ट environments को एक-क्लिक में शुरू करने का समर्थन, टेस्ट डेटा बनाना, वर्तमान versions, टेस्ट accounts और permissions को स्पष्ट करना, और cleanup तथा reset क्षमताएँ प्रदान करना।
- Agent को बिज़नेस सिस्टम संचालित करने देना: browsers, APIs, या CLIs के माध्यम से वास्तविक बिज़नेस प्रक्रियाओं को निष्पादित करना।
- Agent को आसानी से डेटाबेस टेबल्स और लॉग्स query करने देना: read-only database MCP के माध्यम से storage परिणामों की पुष्टि करना, log system Skills और Trace queries के माध्यम से समस्याओं का पता लगाना।
- नीरस लेकिन स्थिर प्रक्रियाओं का पुन: उपयोग करना: स्थिर संचालनों को scripts में लिखना, entry points और troubleshooting तरीकों को Skills में व्यवस्थित करना, जिससे बार-बार मैन्युअल हस्तक्षेप और बातचीत कम हो।
इन कार्यों के आधार पर, यहाँ कुछ तरीके हैं जो मुझे वर्तमान में प्रभावी लगते हैं:
- Browser Automation: जब बिज़नेस सिस्टम को browser संचालन की आवश्यकता होती है, तो मैं open-source browser ego lite की सलाह देता हूँ। यह उपयोग करने में आसान और तेज़ है। pi agent + DeepSeek V4 Flash के साथ मिलकर, टेस्ट अपेक्षाकृत जल्दी पूरे किए जा सकते हैं, जिससे टेस्ट का समय कम होता है।
- संचालनों को CLI में एकीकृत करना: पुन: उपयोग योग्य Skills, कॉन्फ़िगर किए गए MCPs, और लिखी गई scripts को एक unified test CLI में एकीकृत करें, जो environment checks, data preparation, scenario execution, result queries और cleanup की क्षमताएँ प्रदान करे। यह एक internal efficiency tool भी बन सकता है। फिलहाल, मैंने इस सेट को एक CLI में बनाया है, और समस्याएँ आने पर troubleshooting के लिए भी यह सुविधाजनक है।
- Tools को सीधे Acceptance की सेवा करने दें: DB queries का उपयोग status की पुष्टि के लिए किया जाता है, logs और Traces का उपयोग failures को समझाने के लिए किया जाता है, लेकिन अपेक्षित परिणाम अभी भी business contracts से ही आने चाहिए। Agent को यह न मानने दें कि सिस्टम ने जो लौटाया है वह सही है, इसलिए वही सही है। जटिल बिज़नेस लॉजिक के तहत, सिस्टम पूरी तरह से ऐसा परिणाम लौटा सकता है जो उचित लगता है लेकिन वास्तव में अनुपालन नहीं करता। Tools हमें सबूत प्राप्त करने में मदद करते हैं, हमारे लिए सही उत्तर परिभाषित नहीं करते।
- अगर Product खुद एक Agent है, तो Answer Quality की भी जाँच करें: अगर जिस product का टेस्ट किया जा रहा है वह खुद एक Agent है, तो बिज़नेस प्रक्रियाओं के सही से चलने के अलावा, answer quality पर भी विचार करने की ज़रूरत है। इसे हम अक्सर Agent Eval कहते हैं, जिस पर यहाँ विस्तार से चर्चा नहीं की जाएगी।
4. AI द्वारा लिखे गए Code की Review कैसे करें
पिछले भागों में साझा किया गया कि AI से उच्च गुणवत्ता वाला कोड कैसे लिखवाएं, लेकिन अंततः, डेवलपर ही बिज़नेस रिक्वायरमेंट्स के लिए मुख्य ज़िम्मेदार व्यक्ति बना रहता है।
Review के बिना, बड़े सिस्टम में आसानी से समस्याएँ आ सकती हैं।
और आप यह भी नहीं चाहेंगे कि आधी रात को On-call के लिए आपको बुलाया जाए, और पता चले कि समस्या AI द्वारा लिखे गए कोड की वजह से थी।
Review के संबंध में, वर्तमान में मेरे मुख्य तरीके ये हैं:
- पहले acceptance criteria देखें, फिर टेस्ट परिणाम: पहले Agent द्वारा दिए गए acceptance criteria की जाँच करें, फिर पिछले end-to-end टेस्ट परिणामों से तुलना करें ताकि यह पुष्टि हो सके कि क्या अपेक्षाएँ पूरी हुई हैं और कुछ छूटा तो नहीं है। केवल यह न देखें कि कितने टेस्ट पास हुए, बल्कि यह भी देखें कि क्या इन टेस्ट्स ने वास्तव में उस चीज़ को सत्यापित किया जो इस रिक्वायरमेंट के लिए मायने रखती है।
- बिज़नेस पाथ का अनुसरण करके इम्प्लीमेंटेशन देखें, ऊर्जा को high-risk हिस्सों पर केंद्रित करें: मैं मुख्य रूप से permissions, state changes, concurrency, retries, data consistency, और migration और rollback जैसे high-risk हिस्सों की जाँच करता हूँ। stable pattern CRUD पर कम समय लगाया जा सकता है—इसका कुछ हिस्सा तो मैं अब देखता भी नहीं हूँ।
- विशेष रूप से नए जोड़े गए abstractions और mechanisms की जाँच करें: नए जोड़े गए abstractions और mechanisms के लिए, मैं Occam's Razor जैसी सोच का उपयोग करके AI से दोबारा review करवाता हूँ: क्या वे वास्तव में ज़रूरी हैं, क्या कोई सरल इम्प्लीमेंटेशन है, क्या उन्होंने लोकल समस्याओं के लिए बहुत अधिक जटिलता तो नहीं जोड़ दी?
- जब MRs अधिक हों तो Dedicated Review Bots बनाने पर विचार करें: अगर टीम में बहुत सारे MRs हैं, तो cross-review को संभालने के लिए एक dedicated Review Bot डिज़ाइन किया जा सकता है। पहले बताए गए adversarial review के लिए सीधे pi agent / Claude Code को कॉल करने से अलग, यह Git change information को पहले से डिज़ाइन की गई review प्रक्रियाओं के साथ जोड़ने पर ज़ोर देता है, जिससे एक repeatable review क्षमता बनती है जो विशेष रूप से MRs की सेवा करती है।
5. कुछ सारांश और विचार
वर्तमान डेवलपमेंट में मेरी सबसे स्पष्ट बाधा (bottleneck) Review की गति है।
Agents एक साथ कई टास्क को आगे बढ़ा सकते हैं, लेकिन बिज़नेस को समझने, समाधानों का निर्णय लेने और डिलीवरी की पुष्टि करने की मेरी गति उस अनुपात में नहीं बढ़ती। अगर आप बस इसे और अधिक लिखने देंगे, तो संभावना है कि आप केवल review का इंतज़ार कर रहे कोड का ढेर लगा लेंगे।
इसलिए, मैं आगे जिस चीज़ में सुधार करना चाहता हूँ वह यह है कि दोहराई जाने वाली समस्याओं को मेरे पास पहुँचने से पहले ही खोज लिया जाए और ठीक कर दिया जाए।
जो समस्याएँ type checking, tests और business assertions के माध्यम से पाई जा सकती हैं, उन्हें डेवलपमेंट के दौरान Agent को खुद ही संभालना चाहिए; जिनके लिए मेरे निर्णय की आवश्यकता होती है, वे इस पर केंद्रित होते हैं कि क्या रिक्वायरमेंट्स को सही ढंग से समझा गया है, क्या मुख्य बिज़नेस लॉजिक सही है, और इस बदलाव में कौन से असत्यापित जोखिम बचे हैं।
Dedicated Review Bots ये काम करने में मदद कर सकते हैं, लेकिन उनका मूल्य इस पर निर्भर करता है कि क्या वे प्रभावी समस्याओं के छूटने और मैन्युअल बोझ को कम करते हैं, न कि केवल इस पर कि वे कितनी टिप्पणियाँ करते हैं।
इससे Harness के बारे में मेरी समझ भी धीरे-धीरे ठोस होती गई: Agents को सही context देने के अलावा, उन्हें टास्क निष्पादित करने में सक्षम environments और परिणामों का निर्णय लेने के आधार की भी आवश्यकता होती है।
मैंने रोज़मर्रा के self-tests में बार-बार किए जाने वाले संचालनों को CLIs, scripts और Skills में व्यवस्थित किया, ताकि यह खुद सिस्टम चला सके, परिणामों की जाँच कर सके और failure के सबूत खोज सके। भविष्य में इसी तरह के टास्क में, इन क्षमताओं का उपयोग जारी रखा जा सकता है, और धीरे-धीरे पुन: उपयोग के लिए अन्य सहकर्मियों को सौंपा जा सकता है।
इसके साथ ही, इस वर्कफ़्लो में नियमित रूप से कटौती (subtraction) करने की भी आवश्यकता है।
कुछ स्टेप्स किसी विशेष पीढ़ी के मॉडल्स की कमियों की भरपाई कर रहे होते हैं। जब मॉडल बदलते हैं, तो इन स्टेप्स के लाभों का पुनर्मूल्यांकन किया जाना चाहिए। सरल टास्क सीधे किए जाते हैं, जटिल टास्क में planning, splitting और cross-review जोड़े जाते हैं। उदाहरण के लिए, Astra अपडेट के बाद, मैंने AGENTS.md में कुछ अत्यधिक सख्त constraints को हटा दिया। मॉडल iterate होते हैं, और हमारे वर्कफ़्लो को भी तदनुसार iterate होने की आवश्यकता है।
बेशक, testing और Review अनिश्चितता को कम कर सकते हैं, लेकिन इंसानों को अभी भी सही acceptance criteria देने की ज़रूरत है। भले ही कोड और टेस्ट एक-दूसरे से मेल खाते हों, हो सकता है कि दोनों ने मिलकर रिक्वायरमेंट्स को गलत समझा हो। End-to-end tests केवल चुने हुए environments और scenarios में व्यवहार को कवर करते हैं; production environments में traffic, concurrency और data distribution अभी भी नई समस्याएँ ला सकते हैं।
मेरी तरह एक ऐसे डेवलपर के लिए जिसने अभी-अभी काम करना शुरू किया है, मैं अभी भी काम के माध्यम से इस क्षेत्र में अधिक पेशेवर ज्ञान सीखने की उम्मीद करता हूँ। हालाँकि, AI ने वास्तव में खुद गड्ढों में गिरकर सीखने के कुछ अवसरों को कम कर दिया है। कुछ मूल्यवान अनुभव जो पहले समस्याओं का सामना करने और उनके कारणों की जाँच करने से मिलते थे, अब शायद AI के यह कहने में बदल गए हैं:
"मैं गलत था, अभी ठीक कर रहा हूँ।"
इसलिए,
मैं अब रोज़मर्रा के डेवलपमेंट समय का एक हिस्सा सीखने और आत्म-चिंतन के लिए सुरक्षित रखता हूँ, और साथ ही यह सोचता हूँ: AI युग में R&D सहकर्मियों को वास्तव में किन क्षमताओं की आवश्यकता है।
यह लेख उन तरीकों का एक सेट रिकॉर्ड करता है जिन्हें मैंने अपने पहले कुछ महीनों में अपने बिज़नेस में धीरे-धीरे खोजा है। इसके लागू होने के दायरे और कमियों को, मैं अभी भी तलाश रहा हूँ।
हर कोई पहले कोई एक self-test path चुन सकता है जो आमतौर पर किया जाता है, Agent को इसे स्वतंत्र रूप से चलाने देने की कोशिश करें, सबूत संरक्षित करें, और फिर प्रभावी स्टेप्स को दर्ज करें।
कंपनी की गोपनीयता आवश्यकताओं के कारण, कई विवरण लेख में शामिल नहीं किए जा सकते। उम्मीद है कि यह लेख ईंट फेंककर हीरा पाने (विचारों को आकर्षित करने) का काम करेगा, और मुझे वास्तविक डेवलपमेंट में सभी के अच्छे तरीकों के बारे में सुनना बहुत अच्छा लगेगा~
