Claude Code के साथ सॉफ्टवेयर फैक्ट्री कैसे बनाएं जो आपके सोते समय भी फीचर्स शिप करे

मैंने सोचा कि मैं AI का उपयोग करके कोडिंग कर रहा हूँ।

असल में मैं सिर्फ तेज़ टाइप कर रहा था।

यह रहा अंतर — और वह 7-एजेंट सिस्टम जिसने सब कुछ बदल दिया।

इसे सेव करें। यह आपके महीनों बचाएगा।

वह समस्या जिसके बारे में कोई बात नहीं करता

वह लूप जो उत्पादक लगता है लेकिन है नहीं:

→ Claude से एक फीचर बनाने को कहें → यह कोड जनरेट करता है → कुछ टूट जाता है → एरर वापस पेस्ट करें → यह उसे ठीक करता है → कुछ और टूट जाता है → फिर से पूछें

दिन 1: यह जादू जैसा लगता है।

दिन 30: आप AI की निगरानी में, पहले कोड लिखने में लगने वाले समय से ज़्यादा समय बिता रहे हैं।

एक ही लॉजिक तीन अलग-अलग जगहों पर दिखाई देती है।

Claude वह कन्वेंशन भूल गया जो आपने दो हफ़्ते पहले सेट किया था।

नए फीचर पुराने को तोड़ देते हैं।

टेस्ट गायब या सतही हैं।

आप जागते हैं और महसूस करते हैं: AI फेल नहीं हो रहा है।

आपका वर्कफ़्लो फेल हो रहा है।

असली समस्या संरचनात्मक है।

जब आप Claude Code में "यह फीचर बनाएँ" टाइप करते हैं, तो आप एक AI सेशन से यह सब करने को कह रहे हैं:

→ उत्पाद विश्लेषक → आर्किटेक्ट → बैकएंड इंजीनियर → फ्रंटएंड इंजीनियर → टेस्ट इंजीनियर → कोड रिव्यूअर

एक ही बार में।

एक ही गंदी बातचीत में।

प्लान में गलत धारणाएँ गलत डेटाबेस मॉडल बन जाती हैं।

गलत डेटाबेस मॉडल गलत API बन जाते हैं।

गलत API गलत UI बन जाते हैं।

जब तक आपको पता चलता है, गलती हर जगह फैल चुकी होती है।

इसे वाइब कोडिंग कहते हैं।

और इसकी एक सख्त सीमा है।

बदलाव: वाइब कोडिंग से सॉफ़्टवेयर फ़ैक्टरी तक

वह चीज़ जो वास्तव में सब कुछ बदल देती है:

असली इंजीनियरिंग टीमें एक बड़ी बातचीत में काम नहीं करतीं।

अलग-अलग लोग अलग-अलग काम करते हैं:

→ कोई उपयोगकर्ता की समस्या स्पष्ट करता है → कोई आर्किटेक्चर के बारे में सोचता है → कोई API बनाता है → कोई UI बनाता है → कोई एज केस के बारे में सोचता है → कोई रिव्यू करता है

जब आप यह सब एक AI सेशन में समेट देते हैं, तो गलतियाँ चुपचाप बढ़ती जाती हैं।

समाधान है काम को विशिष्ट एजेंटों में बाँटना।

हर एजेंट को मिलता है: → एक फ़ोकस्ड काम → अपना साफ़ कॉन्टेक्स्ट विंडो → केवल वे टूल जिनकी उसे वास्तव में ज़रूरत है → सख्त नियम कि वह क्या छू नहीं सकता

परिणाम: एक सॉफ़्टवेयर फ़ैक्टरी।

एक डेवलपर + सात फ़ोकस्ड एजेंट = एक समन्वित टीम।

यह रहे सात एजेंट जो इसे काम करते हैं।

7 एजेंट

एजेंट 1: कोडबेस रिसर्चर

डेवलपर्स AI के साथ सबसे बड़ी गलती क्या करते हैं?

पहली चाल के रूप में कोड माँगना।

AI प्रॉम्प्ट स्वीकार करता है, अंतराल भरने के लिए अनुमान लगाता है, और जनरेट करना शुरू करता है।

तभी बुरे डिज़ाइन घुस जाते हैं।

कोडबेस रिसर्चर इसे ठीक करता है।

इसका एकमात्र काम: कोडबेस का निरीक्षण करना और समझाना कि चीज़ें कैसे काम करती हैं — एक भी लाइन लिखने से पहले।

यह क्या करता है: → प्रासंगिक फ़ाइलों और उनकी भूमिकाओं का मैप बनाता है → पालन करने के लिए मौजूदा पैटर्न दस्तावेज़ित करता है → पहले से बने समान फीचर ढूँढता है → जोखिमों को फ़्लैग करता है (टाइमज़ोन, मल्टी-टेनेंट, रिट्री लॉजिक) → सूची बनाता है कि किन टेस्ट को अपडेट की ज़रूरत होगी

यह क्या नहीं कर सकता: → फ़ाइलों को एडिट करना (केवल रीड-ओनली एक्सेस) → कोई भी कमांड चलाना जो स्टेट को बदलता है → अनुमान लगाना — इसके बजाय पूछता है

टूल: केवल Read, Grep, Glob।

नियम: बनाने से पहले एक्सप्लोर करें, हर बार।

रिसर्चर पहले चलता है। हमेशा।

एजेंट 2: स्टोरी राइटर

ज़्यादातर फीचर इसलिए फेल नहीं होते क्योंकि कोड गलत था।

बल्कि इसलिए क्योंकि समस्या कभी स्पष्ट रूप से परिभाषित नहीं की गई थी।

स्टोरी राइटर किसी भी तकनीकी निर्णय से पहले एक मोटे फीचर आइडिया को एक वास्तविक उपयोगकर्ता कहानी में बदल देता है।

इनपुट जो इसे मिलता है: → आपका मोटा फीचर विवरण → रिसर्चर के निष्कर्ष

यह क्या उत्पन्न करता है:

एक उपयोगकर्ता कहानी:"एक [भूमिका] के रूप में, मैं [व्यवहार] चाहता/चाहती हूँ, ताकि [परिणाम] मिल सके।"

स्वीकृति मानदंड:ऐसे कथन जिन्हें एक टेस्ट सीधे सत्यापित कर सके। खुशी का रास्ता। असफलता के रास्ते। व्यावसायिक नियम।

एज केस:सीमाएँ, रिट्री, मल्टी-टेनेंट चिंताएँ।

दायरे से बाहर:स्पष्ट रूप से क्या नहीं बनाया जा रहा है।

खुले प्रश्न:ऐसी चीज़ें जो इसे वास्तव में नहीं पता — कभी अनुमान नहीं लगाता।

यह क्या नहीं कर सकता: → व्यावसायिक नियमों का आविष्कार करना → कोई कोड या तकनीकी डिज़ाइन लिखना → आगे बढ़ना अगर कुछ वास्तव में अस्पष्ट है

टूल: केवल Read।

नियम: आप इस कहानी को पढ़ते हैं और कुछ और होने से पहले इसे मंज़ूरी देते हैं।

यह मानव चेकपॉइंट है जो बाकी सब कुछ बचाता है।

एजेंट 3: स्पेक राइटर

एक बार कहानी मंज़ूर हो जाने के बाद, स्पेक राइटर इसे एक तकनीकी ब्रीफ में बदल देता है।

यह वह ब्लूप्रिंट है जिसका हर बिल्ड एजेंट पालन करता है।

इनपुट जो इसे मिलता है: → आपकी मंज़ूरशुदा उपयोगकर्ता कहानी → रिसर्चर के निष्कर्ष → आपके प्रोजेक्ट के CLAUDE.md नियम

यह क्या उत्पन्न करता है:

→ डेटा मॉडल बदलाव (फ़ील्ड, टाइप, माइग्रेशन) → बैकग्राउंड फ़्लो / प्रोसेस फ़्लो → API बदलाव (एंडपॉइंट, रिक्वेस्ट/रिस्पॉन्स शेप) → फ्रंटएंड बदलाव (कम्पोनेंट, पेज, हुक) → आवश्यक टेस्ट (सफलता, असफलता, एज केस) → जोखिम और खुले प्रश्न → हर फ़ाइल जो बदलेगी

यह क्या नहीं कर सकता: → कोई फ़ाइल एडिट करना → नए इन्फ्रास्ट्रक्चर का आविष्कार करना — इसके बजाय इसे स्पष्ट रूप से बताता है → टेनेंट आइसोलेशन या टाइमज़ोन चिंताओं को छोड़ना → प्रश्नों को अनुत्तरित छोड़ना

टूल: केवल Read, Grep, Glob।

नियम: यह ब्रीफ दूसरा मानव चेकपॉइंट है।

आप इसे पढ़ते हैं और एक भी फ़ाइल को छूने से पहले मंज़ूरी देते हैं।

अगर आप "मेमोरी में स्टोर IDs" देखते हैं — तो यह आपका रेड फ़्लैग है।

इसे अभी पकड़ें। 10 फ़ाइलें बदल जाने के बाद नहीं।

एजेंट 4: बैकएंड बिल्डर

अब बिल्डिंग शुरू होती है।

बैकएंड बिल्डर फीचर के बैकएंड हिस्से को लागू करता है — और केवल बैकएंड हिस्से को।

इनपुट जो इसे मिलता है: → मंज़ूरशुदा तकनीकी ब्रीफ → रिसर्चर के निष्कर्ष → आपके प्रोजेक्ट का CLAUDE.md

यह क्या बनाता है: → API रूट्स → सर्विसेज और बिज़नेस लॉजिक → डेटाबेस एक्सेस और माइग्रेशन → बैकग्राउंड जॉब्स → जो कुछ भी लिखता है उसके लिए यूनिट टेस्ट

यह क्या नहीं कर सकता: → React कम्पोनेंट, पेज या क्लाइंट-साइड हुक को छूना (वह एजेंट 5 का काम है) → बिना निर्देश के नई डिपेंडेंसी का आविष्कार करना → सहमत दायरे से बाहर की फ़ाइलों को संशोधित करना → टाइपचेक, लिंट और टेस्ट सूट चलाए बिना रुकना

समाप्त करने के बाद, यह एक सारांश लौटाता है: → हर फ़ाइल जोड़ी या संपादित की गई → हर मौजूदा हेल्पर या पैटर्न जिसका पुन: उपयोग किया गया → कोई भी CLAUDE.md नियम जो मददगार होता

टूल: Read, Edit, Write, Bash — केवल बैकएंड फ़ोल्डरों तक सीमित।

अलगाव ही मुद्दा है।

बैकएंड बिल्डर गलती से फ्रंटएंड को नहीं तोड़ सकता। कभी नहीं।

एजेंट 5: फ्रंटएंड बिल्डर

फ्रंटएंड बिल्डर UI हिस्से को लागू करता है — और केवल UI हिस्से को।

यह पहले बैकएंड बिल्डर का सारांश पढ़ता है।

यह मायने रखता है।

यह API का उपयोग बिल्कुल वैसे ही करता है जैसे बैकएंड ने इसे तैयार किया है।

यह नए एंडपॉइंट का आविष्कार नहीं करता।

अगर UI के लिए API का आकार गलत है, तो यह बेमेल को पैच के रूप में नहीं, बल्कि फीडबैक के रूप में सामने लाता है।

इनपुट जो इसे मिलता है: → मंज़ूरशुदा तकनीकी ब्रीफ → रिसर्चर के निष्कर्ष → बैकएंड बिल्डर का सारांश (API अनुबंध)

यह क्या बनाता है: → React कम्पोनेंट और पेज → क्लाइंट-साइड हुक और स्टेट → लोडिंग और एरर स्टेट्स → जो कुछ भी लिखता है उसके लिए कम्पोनेंट और यूनिट टेस्ट

यह क्या नहीं कर सकता: → सर्विसेज, API रूट्स, वर्कर्स या माइग्रेशन को छूना (वह एजेंट 4 का काम है) → एंडपॉइंट या रिस्पॉन्स शेप का आविष्कार करना → बिना निर्देश के डिपेंडेंसी जोड़ना → टाइपचेक, लिंट और टेस्ट सूट चलाए बिना रुकना

टूल: Read, Edit, Write, Bash — केवल फ्रंटएंड फ़ोल्डरों तक सीमित।

दो बिल्डर।

दो साफ़ कॉन्टेक्स्ट विंडो।

शून्य मौका कि एक दूसरे का काम तोड़ दे।

एजेंट 6: टेस्ट वेरिफ़ायर

दोनों बिल्डरों ने अपने कोड के लिए यूनिट टेस्ट लिखे।

यह पर्याप्त नहीं है।

टेस्ट वेरिफ़ायर केवल एक काम करता है: यह साबित करना कि फीचर वास्तव में वही करता है जो उपयोगकर्ता कहानी ने कहा था कि उसे करना चाहिए।

यह स्वीकृति परीक्षण लिखता है।

यूनिट टेस्ट नहीं।

स्वीकृति परीक्षण।

ये फीचर का बाहर से परीक्षण करते हैं — जिस तरह एक वास्तविक उपयोगकर्ता इसे अनुभव करेगा।

इनपुट जो इसे मिलता है: → मंज़ूरशुदा उपयोगकर्ता कहानी (सभी स्वीकृति मानदंडों के साथ) → मंज़ूरशुदा तकनीकी ब्रीफ → दोनों बिल्डरों के सारांश

यह क्या उत्पन्न करता है: → एक स्वीकृति परीक्षण फ़ाइल जो हर स्वीकृति मानदंड को कवर करती है → एक रिपोर्ट: कौन से मानदंड पास हुए, कौन से फेल हुए, कौन से साफ़ तौर पर कवर नहीं किए जा सकते

यह क्या नहीं कर सकता: → किसी भी बैकएंड या फ्रंटएंड कोड को संशोधित करना → अप्राप्य मानदंडों के लिए वर्कअराउंड का आविष्कार करना → किसी मानदंड को कवर के रूप में चिह्नित करना अगर वह वास्तव में कवर नहीं है

अगर कोई टेस्ट फेल होता है: फीचर कहानी को संतुष्ट नहीं करता।

यह रिपोर्ट करता है कि वास्तव में कौन सा मानदंड फेल हुआ।

यह कोड को पैच नहीं करता।

वह सही बिल्डर के पास वापस जाता है।

टूल: Read, Edit, Write (केवल टेस्ट फ़ाइलें), Bash।

नियम: आपके पास तब तक फीचर नहीं है जब तक स्वीकृति परीक्षण पास नहीं हो जाते।

एजेंट 7: इम्प्लीमेंटेशन वैलिडेटर

यह वह एजेंट है जो वह सब कुछ पकड़ता है जो बाकी सभी से छूट गया।

वैलिडेटर वर्तमान इम्प्लीमेंटेशन की तुलना मंज़ूरशुदा कहानी और ब्रीफ से करता है — और अंतराल रिपोर्ट करता है।

यह कभी कुछ ठीक नहीं करता।

यह केवल सच बताता है।

हर चेक जो यह चलाता है, हर बार:

→ कहानी से स्वीकृति मानदंड जो अभी तक लागू नहीं हुए हैं → असफलता के रास्ते जिनका कोई टेस्ट कवरेज नहीं है → सुरक्षा मुद्दे: गायब ऑथ चेक, टेनेंट आइसोलेशन अंतराल, लॉग में रा एरर → सहमत दायरे से बाहर बदली गई फ़ाइलें → पैटर्न जो CLAUDE.md या मौजूदा कोड के अनुरूप नहीं हैं → डुप्लिकेट लॉजिक जो मौजूदा हेल्पर का पुन: उपयोग कर सकता है → ब्रीफ से टाइमज़ोन या मल्टी-टेनेंट चिंताएँ जिन्हें चुपचाप छोड़ दिया गया

आउटपुट हमेशा गंभीरता के अनुसार समूहित होता है:

क्रिटिकल — मर्ज से पहले ठीक करना ही होगा महत्वपूर्ण — मर्ज से पहले ठीक करना चाहिए मामूली — राय-आधारित, समीक्षक का निर्णय

हर निष्कर्ष में फ़ाइल पथ और लाइन नंबर शामिल है।

अगर कुछ भी गलत नहीं है, तो यह स्पष्ट रूप से कहता है।

यह पूरी तरह से दिखने के लिए मुद्दों का आविष्कार नहीं करता।

टूल: केवल Read, Grep, Glob।

यह एजेंट ही कारण है कि फ़ैक्टरी भरोसेमंद है।

एक स्व-ग्रेडेड पेपर बेकार है।

एक वैलिडेटर जो केवल वही देखता है जो डिस्क पर है — न कि यह कैसे लिखा गया — ईमानदार है।

चेन कैसे चलती है

पूरा प्रवाह — एक प्रॉम्प्ट इसे शुरू करता है:

आप Claude Code खोलते हैं और टाइप करते हैं:

"7 दिनों से अधिक समय से अवैतनिक चालानों के लिए चालान रिमाइंडर बनाएँ।"

यहाँ बताया गया है कि आपके कुछ और टाइप किए बिना क्या होता है:

चरण 1 → रिसर्चर आपके इनवॉइस, पेमेंट और ईमेल कोड का मैप बनाता है। प्रासंगिक फ़ाइलें, मौजूदा पैटर्न, जोखिम लौटाता है।

चरण 2 → स्टोरी राइटर उपयोगकर्ता कहानी और स्वीकृति मानदंड तैयार करता है।

⏸ ठहराव: आप कहानी पढ़ते और मंज़ूरी देते हैं।

चरण 3 → स्पेक राइटर मंज़ूरशुदा कहानी को एक तकनीकी ब्रीफ में बदल देता है।

⏸ ठहराव: आप ब्रीफ पढ़ते और मंज़ूरी देते हैं।(उस "मेमोरी में स्टोर IDs" गलती को यहीं पकड़ें।)

चरण 4 → बैकएंड बिल्डर सर्विस, API रूट, BullMQ जॉब और यूनिट टेस्ट लागू करता है। लौटाता है: बदली गई फ़ाइलें, पुन: उपयोग किए गए पैटर्न, सभी टेस्ट ग्रीन।

चरण 5 → फ्रंटएंड बिल्डर बैकएंड बिल्डर के API सारांश को पढ़ता है, एडमिन UI टाइल और रिमाइंडर बटन बनाता है, कम्पोनेंट टेस्ट लिखता है। सभी टेस्ट ग्रीन।

चरण 6 → टेस्ट वेरिफ़ायर सभी छह स्वीकृति मानदंडों के लिए स्वीकृति परीक्षण लिखता है। रिपोर्ट: 7 पास, 1 फेल — मैनुअल ट्रिगर टेनेंट स्वामित्व की जाँच नहीं करता।

चरण 7 → वैलिडेटर इसे ढूँढता है। फ़ाइल पथ और लाइन नंबर के साथ क्रिटिकल के रूप में रिपोर्ट करता है।

→ बैकएंड बिल्डर पर वापस लूप करें। फिक्स लागू किया गया। सभी 8 स्वीकृति परीक्षण पास। वैलिडेटर फिर से चलता है। साफ़।

⏸ ठहराव: आप समीक्षा करते हैं और PR खोलते हैं।

तीन मानव चेकपॉइंट।

बाकी सब अपने आप चलता है।

नींव: एजेंट के काम करने से पहले, आपको यह चाहिए

CLAUDE.md — वह मेमोरी जो हर सेशन में बची रहती है:

हर बार जब आप Claude Code खोलते हैं, यह शून्य मेमोरी से शुरू होता है।

CLAUDE.md इसे ठीक करता है।

यह आपके रिपो रूट पर एक Markdown फ़ाइल है जो हर सेशन में स्वचालित रूप से लोड होती है।

यह वह जगह है जहाँ स्थायी प्रोजेक्ट तथ्य रहते हैं:

→ आपका स्टैक (Next.js App Router, Node.js, Prisma, BullMQ, Resend) → आपके कमांड (npm run dev, npm test, npx prisma migrate dev) → आर्किटेक्चर नियम ("बिज़नेस लॉजिक सर्विसेज में रहता है। API रूट पतले रहते हैं।") → क्या नहीं करना है ("क्रॉन न जोड़ें — BullMQ का उपयोग करें। रा पेमेंट पेलोड लॉग न करें।") → गहरे डॉक्स के लिए संकेत (docs/billing.md, docs/architecture.md)

इसे 100-300 लाइनों में रखें।

हर बार जब AI कोई गलती करता है जो आपको आश्चर्यचकित करती है, तो पूछें: क्या CLAUDE.md में कोई नियम इसे रोक सकता था?

नियम जोड़ें।

कुछ हफ़्तों में, आपका CLAUDE.md AI द्वारा की गई हर गलत धारणा का रिकॉर्ड बन जाता है — और आपके सेशन काफ़ी बेहतर हो जाते हैं।

कॉन्टेक्स्ट ड्रिफ्ट — वह साइलेंट किलर:

ज़्यादातर Claude Code सेशन नाटकीय रूप से फेल नहीं होते।

वे ड्रिफ्ट करते हैं।

एक गलत धारणा कॉन्टेक्स्ट में प्रवेश करती है।

मॉडल उसके ऊपर बनाता रहता है।

आप Claude को सब्सक्रिप्शन मैनेजमेंट बनाने के लिए कहते हैं।

यह डिज़ाइन करता है: User → Subscription।

आपको याद आता है: सब्सक्रिप्शन कंपनी से संबंधित हैं, उपयोगकर्ता से नहीं।

अगर आप बस कहते हैं "नहीं, सब्सक्रिप्शन कंपनियों से संबंधित हैं" — Claude पैच करता है।

अब आपके पास user.subscriptionId और company.subscriptionId दोनों इधर-उधर तैर रहे हैं।

नियम:

→ छोटी टाइपो? इसे इनलाइन ठीक करें। → गलत आर्किटेक्चरल धारणा? बातचीत को फेंक दें और सही धारणा के साथ पहले प्रॉम्प्ट में ही नए सिरे से शुरू करें।

सही मेंटल मॉडल वाला एक साफ़ सेशन, पैच किए गए सेशन से हर बार बेहतर होता है।

परिणाम: वास्तव में क्या बदलता है

फ़ैक्टरी से पहले:

→ वाइब कोडिंग लूप: प्रॉम्प्ट → जनरेट → एरर → पैच → दोहराएँ → सेशन कॉन्टेक्स्ट शोर से भर जाता है → गलत धारणाएँ टूटे हुए फीचर में बदल जाती हैं → एक इंजीनियर एक बार में केवल एक ही काम कर सकता है → हर फीचर सही व्यक्ति के उपलब्ध होने की प्रतीक्षा करता है

फ़ैक्टरी के बाद:

→ संरचित श्रृंखला: शोध → कहानी → ब्रीफ → बिल्ड → सत्यापित → मान्य करें → प्रत्येक एजेंट को केवल वही मिलता है जिसकी उसे ज़रूरत है, एक साफ़ कॉन्टेक्स्ट विंडो में → गलत धारणाएँ ब्रीफ मंज़ूरी पर पकड़ी जाती हैं — 10 फ़ाइलों के बाद नहीं → एक इंजीनियर एक पूर्ण वर्टिकल स्लाइस शिप करता है: बैकएंड, फ्रंटएंड, टेस्ट, वैलिडेशन → टीम का सबसे अच्छा ज्ञान एजेंटों में रहता है — लोगों में फँसा नहीं

असली बदलाव:

पेमेंट्स स्पेशलिस्ट एक पेमेंट्स-इंटीग्रेशन एजेंट बनाता है।

अब टीम का हर इंजीनियर एक ऐसा फीचर शिप कर सकता है जो बिलिंग को छूता है।

बिना प्रतीक्षा किए।

बिना हैंडऑफ़ के।

फ्रंटएंड लीड के कम्पोनेंट पैटर्न फ्रंटएंड-बिल्डर एजेंट में रहते हैं।

DevOps इंजीनियर के CI चेक एक हुक में रहते हैं।

QA लीड के एज केस टेस्ट-वेरिफ़ायर नियमों में रहते हैं।

विशेषज्ञ ज्ञान, एजेंट के रूप में साझा किया गया।

उपलब्धता में फँसा नहीं।

इस सप्ताहांत अपना खुद का कैसे बनाएँ

8-चरणीय सेटअप चेकलिस्ट:

1. Claude Code इंस्टॉल करें → code.claude.com

2. फ़ोल्डर संरचना बनाएँ: → .claude/agents/ → .claude/skills/feature-factory/ → .claude/skills/build-with-tests/ → .claude/hooks/

3. अपना CLAUDE.md लिखें (100–300 लाइनें: स्टैक, कमांड, आर्किटेक्चर नियम, क्या न करें सूची)

4. Claude Code में /agents कमांड का उपयोग करके 7 एजेंट बनाएँ। प्रत्येक एजेंट की भूमिका का वर्णन करें। Claude फ़ाइल लिखता है। आप समीक्षा करते हैं और कमिट करते हैं।

5. फीचर-फ़ैक्टरी ऑर्केस्ट्रेटर स्किल बनाएँ। Claude से इसे लिखने को कहें — यह आपकी 7 एजेंट फ़ाइलों को पढ़ता है और चेन को वायर करता है।

6. बिल्ड-विथ-टेस्ट स्किल बनाएँ। बताता है कि आपकी टीम कैसे बिल्ड करती है: मौजूदा पैटर्न से मिलान करें, कोड के साथ टेस्ट लिखें, अंत में टाइपचेक चलाएँ।

7. एक प्री-कमिट हुक जोड़ें। .env, .key, .pem या secrets.json फ़ाइलों वाले कमिट को ब्लॉक करता है। 5 मिनट लगते हैं। आपदाओं को रोकता है।

8. एक वास्तविक फीचर को पूरी श्रृंखला से चलाएँ। कुछ छोटा चुनें। देखें कि यह कहाँ लड़खड़ाता है। नियम जोड़ें। फ़ैक्टरी खुद को ट्यून करती है।

कुल समय: 2–3 घंटे।

फिर कुछ फीचर चलाएँ।

3-4 के बाद, फ़ैक्टरी आपका कोडबेस जान लेती है।

आप निगरानी में कम समय बिताएँगे।

अगला क्या बनाना है, यह तय करने में अधिक समय।

7 एजेंट — त्वरित संदर्भ

→ रिसर्चर — कुछ भी बनाने से पहले कोड का मैप बनाता है (केवल Read) → स्टोरी राइटर — आइडिया को स्वीकृति मानदंडों के साथ उपयोगकर्ता कहानी में बदलता है (केवल Read) → स्पेक राइटर — कहानी को तकनीकी ब्रीफ में बदलता है (केवल Read) → बैकएंड बिल्डर — API, सर्विसेज, जॉब्स, यूनिट टेस्ट बनाता है (केवल बैकएंड फ़ोल्डर) → फ्रंटएंड बिल्डर — कम्पोनेंट, पेज, हुक, UI टेस्ट बनाता है (केवल फ्रंटएंड फ़ोल्डर) → टेस्ट वेरिफ़ायर — उपयोगकर्ता कहानी के विरुद्ध स्वीकृति परीक्षण लिखता है (केवल टेस्ट फ़ाइलें) → वैलिडेटर — इम्प्लीमेंटेशन की तुलना कहानी और ब्रीफ से करता है, अंतराल रिपोर्ट करता है (केवल Read)

3 मानव चेकपॉइंट:→ कहानी मंज़ूर करें → ब्रीफ मंज़ूर करें → PR मंज़ूर करें

बाकी सब अपने आप चलता है।

Claude Code का उपयोग करने वाले अधिकांश डेवलपर अभी भी वाइब कोडिंग कर रहे हैं।

प्रॉम्प्ट करना → जनरेट करना → पैच करना → उम्मीद करना।

यह गलत नहीं है।

यह बस एक सीमा है।

फ़ैक्टरी आपको प्रक्रिया से नहीं हटाती।

यह आपको उन हिस्सों से हटाती है जिनमें आपकी ज़रूरत नहीं है।

आप उस लूप में रहते हैं जहाँ आपका निर्णय मायने रखता है:

क्या यह सही समस्या है? क्या यह सही डिज़ाइन है? क्या यह शिप करने के लिए सुरक्षित है?

एजेंट बीच में बाकी सब संभालते हैं।

यही अंतर है AI को तेज़ कीबोर्ड के रूप में उपयोग करने —

और AI को एक समन्वित टीम के रूप में उपयोग करने के बीच।

अगर यह उपयोगी था:

→ इसे अपने नेटवर्क के साथ साझा करने के लिए रिपोस्ट करें → और अधिक ऐसे ब्रेकडाउन के लिए @sairahul1 को फॉलो करें → इसे बुकमार्क करें — आप 7 एजेंटों को संदर्भित करना चाहेंगे

मैं AI, उत्पाद बनाने और ऐसे सिस्टम के बारे में लिखता हूँ जो आपके सोते समय काम करते हैं।