सॉफ्टवेयर फैक्ट्रियाँ पिछले कुछ हफ़्तों में बहुत चर्चा का विषय बनी हुई हैं। तो मैंने एक बना ली।
यहाँ बताया गया है कि मैंने क्या सीखा, यह कैसे काम करता है, और आप एक दोपहर में कैसे एक बना सकते हैं।
मेरे लक्ष्य
इसे वास्तव में सरल होना था, ऐसा कुछ जो बस काम करे और जिसमें बहुत अधिक निगरानी की आवश्यकता न हो। आदर्श रूप से, यह पूरी तरह से मेरे मौजूदा Claude सब्सक्रिप्शन पर चले।
यह भोला-भाला लगता है, लेकिन असल में जब तक यह मेरे मौजूदा वर्कफ़्लो में आसानी से एकीकृत नहीं होता, यह ऐसी चीज़ नहीं होगी जो टिकी रहे। मैं इसे बनाकर अपनी सभी मौजूदा आदतों को नहीं बदलना चाहता, सिर्फ़ इस नए सिस्टम का उपयोग करने के लिए। मैं अनुभव से जानता हूँ कि अगर ऐसा हुआ, तो यह लंबे समय तक मेरे लिए काम नहीं करेगा और अप्रासंगिक हो जाएगा।
इसलिए इसे एक बड़े प्रयास के रूप में हमला करने के बजाय, मैंने इसे दो अलग-अलग चरणों में विभाजित किया:
- प्री-ट्राइएज - "करने योग्य" चीज़ों का पता लगाना
- कार्यान्वयन - वास्तव में चीज़ों को "करना"
केंद्र में Linear है, जो इस बात का स्रोत है कि क्या काम करने की आवश्यकता है।
हर सॉफ्टवेयर फैक्ट्री के पास किए जाने वाले काम का यह केंद्रीकृत भंडार होना चाहिए, चाहे वह GitHub के मुद्दे हों, Linear, या कुछ और। यह वही होना चाहिए जो आप पहले से उपयोग करते हैं ताकि कोई भी सिस्टम काम जोड़ने के लिए इसे आसानी से विस्तारित कर सके, जिसे बाद में एजेंट या मनुष्य उठाकर पूरा कर सकें।
सिस्टम हेल्थ चेक लूप के माध्यम से ऑटो-जेनरेट किए गए मुद्दे के साथ Linear
पाइपलाइन में जानबूझकर परिभाषित सीमाएँ हैं जो सॉफ्टवेयर फैक्ट्री बनाने की प्रक्रिया को वास्तव में प्रबंधनीय बनाती हैं:
- काम बनाएँ (MCP के साथ लूप)
- काम संग्रहीत करें (linear)
- काम पूरा करें (SDLC एजेंट)
इसे विभाजित करके, आपको एक साथ प्री-ट्राइएज और कार्यान्वयन दोनों पक्षों का निर्माण नहीं करना पड़ता (और मैं वास्तव में ओवर-इंजीनियरिंग से बचने के लिए इसके खिलाफ सलाह देता हूँ)। Linear "क्या करना है" और हम वर्तमान में "क्या कर रहे हैं" के बीच इंटरफ़ेस को अच्छी तरह से परिभाषित और विस्तारित करने में आसान बनाता है।
प्री-ट्राइएज चरण
उपरोक्त आरेख में, काम बाएँ से दाएँ बढ़ता है। बायाँ पक्ष वह है जहाँ काम बनाया जाता है और इसमें किसी भी प्रणाली (या तो मनुष्य, एजेंट, या API) की कोई भी संख्या होती है जो किए जाने वाले कार्यों में जोड़ती है। इस प्री-ट्राइएज चरण में बनाए गए सभी आउटपुट हमारे Linear में डाल दिए जाते हैं।
Claude क्लाउड वातावरण में चलने वाले कुछ लूप
इस चरण में, हमारे पास तीन मुख्य लूप हैं:
- सिस्टम हेल्थ चेक लूप (यानी एक बग फ़ाइंडर) - यह लूप प्रतिदिन सुबह 5 बजे चलता है और कुछ MCP सर्वरों से जुड़ा होता है: Posthog त्रुटि ट्रैकिंग के लिए; Vercel सिस्टम डायग्नोस्टिक्स के लिए; और Linear मुद्दे बनाने के लिए।
- UX सुधार और ग्राहक प्रतिक्रिया लूप - यह लूप सप्ताह में एक बार सोमवार को सुबह 9 बजे चलता है, और प्रतिक्रिया के हर नए टुकड़े, Intercom/Fin से हर ग्राहक सहायता चैट, और सभी Posthog सत्र रीप्ले को स्कैन करता है। सत्र रीप्ले एक सोने की खान हैं। आप देख सकते हैं कि कहाँ रेज क्लिक होते हैं या जहाँ उपयोगकर्ता संघर्ष कर रहे हैं और भ्रमित हैं।
- टर्न विश्लेषण लूप - यह प्रतिदिन सुबह 6 बजे चलता है और उन सभी ग्राहकों की जाँच करता है जिन्होंने पिछले 24 घंटों में रद्द करने पर क्लिक किया। यह Stripe से भुगतान और उपयोगकर्ता डेटा खींचता है (उनके ईमेल/स्थान सहित), और फिर यह देखने के लिए Posthog में इस ग्राहक के सत्र रीप्ले को देखता है कि वे रद्द करने से पहले क्या कर रहे थे। हम यह देखने के लिए Supabase से उनके उपयोग को खींचते हैं कि क्या यह गलत ICP था, कभी उस "वाह" पल का अनुभव नहीं किया, या बग से टकराए। रिपोर्ट Slack पर भेज दी जाती है और एजेंट मुद्दे बनाता है (या उन पर टिप्पणी करता है) यदि वे प्राथमिकता बढ़ाने के लिए ग्राहकों के टर्न से संबंधित हैं।
इन एजेंटों को लगातार चलाने के लिए, मैंने इसे सरल रखा और Claude Code Cloud Routines का उपयोग किया।
कोई ओवर-इंजीनियरिंग नहीं जैसे कि Hetzner VPS, कैफ़िनेटेड मैक मिनी, आदि। अपने मौजूदा Claude Code सब्सक्रिप्शन का लाभ उठाने और ऑलवेज-ऑन एजेंट बनाने का यह अब तक का सबसे आसान तरीका है जो मुझे मिला है, जिन्हें शेड्यूल पर या वेबहुक इवेंट के माध्यम से ट्रिगर किया जा सकता है। और उन सभी लोगों के लिए जो कह रहे हैं "लेकिन वेंडर लॉक इन का क्या!!" - यह सचमुच सिर्फ़ कुछ टेक्स्ट है। बेझिझक प्रॉम्प्ट को जहाँ चाहें कॉपी करें, मैं तो बस सबसे आसान और सस्ती चीज़ चाहता था जो विश्वसनीय रूप से काम करे।
और Claude Code Cloud Routines का उपयोग करने का एक और कारण यह है कि Anthropic के क्लाउड वातावरणों का Claude को स्थानीय रूप से चलाने के साथ घनिष्ठ समानता है।
Cloud Claude Routines
जाहिर है, उनके पास आपके एनवी वेरिएबल नहीं हैं (जिन्हें यदि आवश्यक हो, क्लाउड वातावरण सेटअप में जोड़ा जा सकता है) लेकिन यदि आप डेस्कटॉप ऐप के कनेक्टर के माध्यम से MCP कनेक्शन सेट करते हैं, तो आपका स्थानीय Claude cli और रिमोट Claude दोनों उनका उपयोग कर सकते हैं, Codex के विपरीत। यह मेरे लिए किलर फ़ीचर था और यही इन प्री-ट्राइएज एजेंट लूप को इतना अच्छा बनाता है। यह आपके लैपटॉप की मेमोरी की चिंता किए बिना समानांतर में बहुत सारे सत्र चलाना भी आसान बनाता है।
यदि आप केवल इस प्री-ट्राइएज चरण को लागू करते हैं, तो भी आपको बहुत अधिक लाभ मिलेगा, भले ही आप अगला चरण न बनाएँ जहाँ काम पूरा होता है।
एक ही लूप के साथ छोटा शुरू करें, इसे आज़माएँ, इसे परिष्कृत करें, फिर और जोड़ें। पता लगाएँ कि आज आप ऐसी कौन सी रूटीन बना सकते हैं जो आपके मौजूदा इश्यू ट्रैकर में नया, उच्च-गुणवत्ता वाला काम डालें और फिर कार्यान्वयन के लिए वही करें जो आप आज करते हैं।
कार्यान्वयन चरण
चरण दो का सबसे बुनियादी संस्करण आपके एजेंट को एक इश्यू ID देना और कहना है कि जाओ और इसे पूरा करो। यह वही है जो ज़्यादातर लोग एजेंटों के साथ काम करते समय पहले से ही करते हैं, हालांकि, यदि आप यह पढ़ रहे हैं तो शायद यह वह नहीं है जो आप चाहते हैं, क्योंकि अब आप लूप में अड़चन हैं, सीधे एक सत्र में एजेंट को किक कर रहे हैं।
इसके बजाय मैंने जो किया वह सीधे Linear से रिमोट Claude Code सत्रों को ट्रिगर करने का एक तरीका बनाया।
Linear इश्यू से Claude तक जाना
यह इस तरह काम करता है:
- पहले, पहचानें कि आप एक नया Claude सत्र कैसे ट्रिगर करना चाहते हैं। हमारे लिए, हम एक Linear इश्यू में 'auto' लेबल जोड़ते हैं जो इस नए कार्य को किक करता है।
- फिर, Linear हमारी आंतरिक वेबहुक API सेवा (एक नव-निर्मित आंतरिक Hono ऐप) को एक वेबहुक इवेंट भेजता है जो इवेंट को पार्स करता है और फिर सही जानकारी को Claude Routine को अग्रेषित करता है।
- अंत में, यह हल्की API सेवा Anthropic को एक POST अनुरोध करती है जो एक प्रारंभिक प्रॉम्प्ट के साथ Claude रूटीन को ट्रिगर करती है।
ट्रिगर के रूप में 'auto' लेबल का उपयोग करने से हमें नए Claude सत्रों के स्वचालित निष्पादन को नियंत्रित करने की अनुमति मिलती है।
डिफ़ॉल्ट रूप से, हमारे पास प्री-ट्राइएज चरणों में ये 'auto' लेबल शामिल नहीं होते हैं और एजेंट को काम शुरू करने के लिए ट्रिगर करने वाला लेबल जोड़ने के लिए एक मानव की आवश्यकता होती है (मानव-इन-द-लूप रखते हुए)। इसीलिए हम चरण 1 को प्री-ट्राइएज चरण कहते हैं, क्योंकि कुछ अभी भी यह पता लगा रहा है कि वास्तव में क्या काम करना है, या तो मानवीय भागीदारी के माध्यम से या किसी एजेंट के लूपिंग और नए मुद्दों को जोड़े जाने और नए कार्यान्वयन सत्रों को किक करने के माध्यम से।
हालांकि, क्योंकि लेबल जोड़ना भी एक एजेंट द्वारा आसानी से किया जा सकता है, हम प्री-ट्राइएज लूप डिफ़ॉल्ट रूप से 'auto' लेबल के साथ नए मुद्दे बना सकते हैं, जो एक नया Claude सत्र शुरू करता है। लेबल का उपयोग करना नए कार्यान्वयन कार्य को या तो स्वचालित रूप से किसी एजेंट द्वारा या हम मनुष्यों द्वारा शुरू करने का एक बहुत ही लचीला तरीका बन जाता है।
Claude सत्र शुरू करने के लिए एक हल्की रूटिंग सेवा
क्योंकि Linear वेबहुक का समर्थन करता है, "जब कोई लेबल जोड़ा जाता है तो पुश करें" पूरी चीज़ काम करती है। एकमात्र कमी यह है कि हमारे पास एक सार्वजनिक API होना चाहिए जो रूट इन वेबहुक को स्वीकार करता है और इवेंट और पेलोड डेटा को Claude Code को ट्रिगर करने के लिए फ़ॉर्मेट करता है। यह नई सेवा सही प्रमाणीकरण हेडर भी जोड़ती है, यही कारण है कि आप Linear को सीधे रूटीन को ट्रिगर नहीं कर सकते।
वैकल्पिक रूप से, आपके पास एक शेड्यूल्ड रूटीन हो सकता है जो हर थोड़ी देर में शुरू होता है और ऑटो लेबल के साथ प्रगति पर नहीं होने वाले किसी भी नए मुद्दे को लागू करने का प्रयास करता है।
वास्तविक रूटीन प्रॉम्प्ट के लिए, मैं एक पुन: प्रयोज्य कौशल बनाने की सलाह देता हूँ जो पूरे SDLC से गुज़रता है, जिसे /implement या /do जैसा कुछ नाम दिया गया है, जो केवल "/do ISSUE-NNN" कहना आसान बनाता है, जो दस्तावेज़ करता है कि इश्यू संदर्भ प्राप्त करने, काम को लागू करने, ब्राउज़र में सत्यापित करने, PR बनाने और टिप्पणियों पर नज़र रखने के चरणों से सही ढंग से कैसे गुज़रना है।
फिर Claude रूटीन प्रॉम्प्ट, जो Linear इवेंट द्वारा ट्रिगर होता है, में एक बहुत ही सरल प्रॉम्प्ट हो सकता है। यहाँ मेरा है:
दिए गए इश्यू को प्राप्त करें और अनुरोधित परिवर्तन को लागू करने और एक पुल अनुरोध बनाने के लिए /do कौशल का उपयोग करें। केवल दिए गए सटीक इश्यू को ही प्राप्त करें। यदि यह पहले से ही पूर्ण या प्रगति पर है, तो रुक जाएँ।
इश्यू संदर्भ इस संदेश में दिखाई नहीं देता है — यह एक अलग फ़ॉलो-अप संदेश के रूप में आता है जो एक
<routine-fire-payload>टैग में लिपटा होता है, इसके तुरंत बाद, उसी सत्र में भेजा जाता है। यह तय करने से पहले कि क्या कोई इश्यू प्रदान किया गया था, उस संदेश की प्रतीक्षा करें।<routine-fire-payload>संदेश में इसकी जाँच करने और संदर्भित इश्यू की पुष्टि करने के बाद ही निष्कर्ष निकालें कि इश्यू मौजूद नहीं है, या कोई नहीं दिया गया था, कि यह वास्तव में मौजूद नहीं है।जब आप काम शुरू करते हैं, तो इश्यू पर टिप्पणी करें, इसे "प्रगति पर" पर सेट करें, और जैसे-जैसे आप आगे बढ़ते हैं, इश्यू को किसी भी सार्थक चीज़ से अपडेट करें। Linear इश्यू टिप्पणियों को हमेशा [Claude] से उपसर्गित करें।
तो इस बिंदु पर आपके पास API के माध्यम से ट्रिगर किए गए, मुद्दों को लागू करने, PR खोलने (और उम्मीद है कि Playwright या Agent Browser के माध्यम से अपने काम को सत्यापित करने) वाले समानांतर Claude Remotion सत्र होते हैं।
यह अनिवार्य रूप से एक पूर्ण सॉफ्टवेयर फैक्ट्री है जो पूरी तरह से देखने योग्य है, आपके सोते समय चलती है, और पूरी तरह से आपके Claude Code सब्सक्रिप्शन पर काम करती है।
