क्या आपको सॉफ्टवेयर फैक्ट्री की आवश्यकता है?

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

यदि हाँ:

• उत्पाद के इरादे, सिस्टम डिज़ाइन (यदि आपको परवाह है) और अपनी गुणवत्ता की सीमा तय करने के लिए शुरुआत में आपको संभवतः मनुष्यों को लूप में रखना होगा।
• कोड की समीक्षा करें (लाइट्स-ऑन फैक्ट्री) लेकिन जहाँ इसकी सबसे अधिक आवश्यकता है, वहाँ जानबूझकर रहें। मैंने पाया है कि आप यह देखना चाहते हैं कि स्वचालित बैक-प्रेशर कहाँ टूटता है। या जहाँ रखरखाव के व्यापार-नापसंद करने की आवश्यकता है।
• गुणवत्ता जांच का लक्ष्य जितनी जल्दी हो सके और लगातार होना चाहिए। उन सभी को ऐसा करने की आवश्यकता नहीं है, लेकिन इसमें टाइप सिस्टम, स्वचालित परीक्षण, म्यूटेशन टेस्टिंग, सुरक्षा स्कैनर और आर्किटेक्चर नियमों के लिए लिंटिंग शामिल है।
• जांच की संख्या != गुणवत्ता। आपको संभवतः प्रयोग करने की आवश्यकता होगी कि कौन सी जाँच आपको सबसे अच्छा सिग्नल-टू-नॉइज़ अनुपात देती हैं। जानबूझकर अपनी बाधाओं को कसने या ढीला करने के लिए तैयार रहें।

आप अपनी फैक्ट्री इस तरह बनाना चाहते हैं कि मानवीय स्वाद के कुछ पहलू वातावरण में एन्कोड हो जाएँ, एजेंट आपको अपने काम के सही होने का सबूत दे और एक मानव अभी भी उस चीज़ का "मालिक" हो जो प्रोडक्शन में जाती है।

क्या आपको वास्तव में सॉफ्टवेयर फैक्ट्री की आवश्यकता है?

मेरे अनुभव में, आप अपने स्टॉक कोडिंग हार्नेस के साथ आश्चर्यजनक रूप से आगे बढ़ सकते हैं! जैसे कि Claude Code या Codex, कई सत्र, एम्बेडेड सत्यापन और बाधाओं के साथ अच्छे स्पेक। आप उन पर कार्यान्वयन और मानव-भागीदारी मानदंडों के साथ GitHub मुद्दों का एक बैच भी फेंक सकते हैं। Claude Code रूटीन और Copilot/Codex क्लाउड एजेंट पहले से ही आपको कस्टम इंफ्रा के बिना एक शेड्यूल या इवेंट-संचालित लूप देते हैं।

एक फैक्ट्री तब सार्थक होती है जब आपको दोहराए जाने योग्य सुसंगत रन, एजेंटों के बीच काम सौंपना, दो सत्रों को एक ही मुद्दे पर काम करने से रोकना, सबूत रखना और समीक्षा पीछे रहने पर उत्पादन को रोकना की आवश्यकता होती है।

इसलिए मैंने यह कहकर शुरुआत की कि एक सॉफ्टवेयर फैक्ट्री सॉफ्टवेयर कार्य के चारों ओर एक दोहराए जाने वाला लूप है। हम वास्तव में एक प्रॉम्प्ट देख सकते हैं जो यहाँ एक बहुत छोटे फैक्ट्री लूप को प्रदर्शित करता है:

कोड बदलने से पहले GitHub इश्यू #123 और रिपॉजिटरी निर्देशों को पढ़ें।

केवल बताए गए स्वीकृति मानदंडों को लागू करें। प्रमाणीकरण, बिलिंग, माइग्रेशन या मौजूदा परीक्षण अभिकथनों को संशोधित न करें। एक ब्रांच में काम करें और डिफ को समीक्षा योग्य रखें।

npm run lint, npm test, और npm run build चलाएँ। यदि कोई आवश्यक जाँच नहीं चल सकती है, तो रुकें और समझाएँ कि क्यों। आपके द्वारा चलाई गई जाँचों, शेष जोखिमों और किसी भी निर्णय के साथ एक ड्राफ्ट पुल रिक्वेस्ट खोलें जो एक मानव को अभी भी लेने की आवश्यकता है। मर्ज न करें।

एक लक्ष्य इसे तब तक चलता रख सकता है जब तक जाँचें पास न हो जाएँ और हम किसी विशिष्ट लेबल के लिए GitHub मुद्दों को पोल कर सकते हैं या हर सुबह खुली पुल रिक्वेस्ट की समीक्षा कर सकते हैं। ब्रांच प्रोटेक्शन एक मर्ज सीमा लागू कर सकता है और मानव यह चुनकर लूप में रह सकता है कि क्या तैयार हो जाता है, समीक्षा करके और अंतिम मर्ज कॉल करके आदि।

एक सॉफ्टवेयर फैक्ट्री तब जोड़ें जब आपको कुछ स्पष्ट मानवीय निगरानी के साथ ट्राइएज, कार्यान्वयन और परीक्षण को संभालने के लिए एक अलग क्लाउड वातावरण में चलने के लिए कार्य की एक इवेंट-संचालित कतार (जैसे Slack ट्रिगर, GitHub मुद्दे, Linear, एक बैकलॉग) की आवश्यकता हो। कुछ अपने लूप को एक मॉनिटर एजेंट के साथ समाप्त करते हैं जो प्रोडक्शन देखता है और मुद्दे दर्ज करता है जो फिर से ट्राइएज करते हैं।

मेरे अनुभव में, फैक्ट्री तब उपयोगी हो जाती है जब कठिन हिस्सा आपके विभिन्न रनों को लगातार व्यवहार करना, एजेंटों के बीच काम सौंपना और विभिन्न सत्रों को एक ही मुद्दे पर दावा करने से बचना, सबूत संरक्षित करना और मानव समीक्षा पीछे रहने पर उत्पादन को रोकना हो।

इसे हल करने वाली चीज़ थोड़ी उबाऊ लग सकती है। उदाहरण के लिए, Warp प्रत्येक आने वाले मुद्दे को चार राज्यों में से एक में ट्राइएज करने का उल्लेख करता है - ready-to-implement, ready-to-spec, needs-info, wait-to-implement - और लेबल वह है जो अगले एजेंट को फायर करता है।

यह लेबल एक साथ कई काम करता है: यह कतार है, ताला है और चूंकि एक सत्र केवल वही उठाता है जो तैयार के रूप में चिह्नित है, यह वह जगह है जहाँ एक मानव स्थायी रूप से मना किए बिना चीज़ों को पार्क कर सकता है।

वर्कफ़्लो के संदर्भ में, केवल Claude/Codex का उपयोग करने के लिए कुछ समानताएँ और अंतर हैं:

• स्टीयरिंग: एजेंट को पाठ्यक्रम-सुधार की आवश्यकता है, आप इनपुट दे सकते हैं और इसे पुनर्निर्देशित कर सकते हैं
• सूचनाएँ: फैक्ट्री कैसे कहती है कि यह अवरुद्ध है। यह इसलिए हो सकता है क्योंकि कोई आवश्यकता अस्पष्ट थी, इसने कुछ जोखिम भरा शुरू किया या इसे मानव इनपुट (स्टीयरिंग) की आवश्यकता है
• हैंडऑफ़: कार्य, उसकी स्थिति और संदर्भ को क्लाउड फैक्ट्री/किसी अन्य एजेंट/मानव समीक्षक के बीच ले जाएँ। अच्छे हैंडऑफ़ इस बात का ट्रैक रखेंगे कि क्या हुआ, क्या करना बाकी है और हैंडऑफ़ की आवश्यकता क्यों है।

एक अच्छी फैक्ट्री में, मानव केवल अंत में अंतिम डिफ की समीक्षा और अनुमोदन करने तक सीमित नहीं है। वे शुरुआत में काम को आकार दे सकते हैं, कार्यान्वयन के दौरान इसे चला सकते हैं, इसे हैंडऑफ़ के माध्यम से प्राप्त कर सकते हैं या इसे प्रोडक्शन में शिप होने से रोक सकते हैं।

सत्यापन वह जगह है जहाँ एक जिम्मेदार फैक्ट्री अपना बहुत सारा समय बिताती है। हम इसके बारे में बाद में और कवर करेंगे।

यदि आप तय करते हैं कि आपको एक सॉफ्टवेयर फैक्ट्री की आवश्यकता है, तो इसे बनाना ही एकमात्र विकल्प नहीं है। एक फैक्ट्री को स्केल करने के लिए इंफ्रा खड़ा करना बहुत काम हो सकता है और आप खरीदने बनाम बनाने पर विचार करना चाह सकते हैं। Factory.ai, Devin, Warp और HumanLayer सभी इस लूप का कुछ हिस्सा बेचते हैं।

मैं वास्तव में अपना ध्यान कहाँ लगाता हूँ

पिछले एक साल में सॉफ्टवेयर डेवलपमेंट का मेरा दैनिक अनुभव बहुत बदल गया है। मैं एजेंटों के साथ बहुत सारे समानांतर काम करने, लाइट्स-ऑन सॉफ्टवेयर फैक्ट्री की ओर बढ़ने के बारे में तेजी से बात कर रहा हूँ। और बहुत से लोग मुझसे पूछ रहे हैं कि, इन चीज़ों का वास्तव में क्या मतलब है? आप क्या बना रहे हैं? आप इन चीज़ों का उपयोग किस तरह की परियोजनाओं पर कर रहे हैं? यह इस तरह का बहुत कुछ है:

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

मैं अपने ओपन सोर्स प्रोजेक्ट्स पर काम कर सकता हूँ। मैं अपनी पुस्तकों के लिए साथी साइटें बना सकता हूँ। मैं टूल्स पर काम कर सकता हूँ। मैं अपने स्वयं के ऐप्स बना सकता हूँ। और ये सभी बहुत, बहुत अलग तरह के एप्लिकेशन हैं जिन पर मैं काम कर रहा हूँ। और कभी-कभी उनमें केवल एक चीज समान होती है वह है टूल जिसका उपयोग मैं उन पर काम करने के लिए कर रहा हूँ, है ना? हो सकता है कि मैं माइग्रेशन पर काम कर रहा हूँ। दूसरी बार, मैं वास्तविक बड़े फीचर का काम कर रहा हो सकता हूँ। और काम का ब्लास्ट रेडियस भी बहुत, बहुत अलग हो सकता है।

इसलिए जैसे-जैसे आप एक ऐसी जगह पर पहुँचने के बारे में सोचना शुरू करते हैं जहाँ हम तेजी से बहुत सारे समानांतर काम कर रहे हैं, हम वेलोसिटी में सुधार करने की कोशिश कर रहे हैं, हम उत्पादकता में सुधार करने की कोशिश कर रहे हैं, और हम स्वायत्तता में सुधार करने की कोशिश कर रहे हैं, जिसका अर्थ है सिस्टम को ऐसी जगह पर लाना जहाँ हम उस पर अधिक भरोसा करते हैं, आपको यह सोचना होगा कि वे कौन से स्थान हैं जिनमें पूरी तरह से मानव कोड समीक्षा, मानव इनपुट की आवश्यकता होती है।

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

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

अब, कुछ लोगों से विरोध आ रहा है जो कहते हैं, अरे, ठीक है, मैं यह नहीं मानता कि आप इस सब में से बहुत कुछ को स्वचालित कर सकते हैं। इसका मतलब यह नहीं है कि हम यह सब स्वचालित कर रहे हैं, है ना? लेकिन उत्पन्न होने वाले कोड की मात्रा को देखते हुए, मुझे नहीं लगता कि मनुष्यों के लिए यह सब पढ़ना यथार्थवादी है, खासकर जब हम अक्सर रॉकेट नहीं बना रहे होते हैं, है ना? हम UI बना रहे हैं, हम फुल स्टैक एप्लिकेशन बना रहे हैं।

हमारा निर्णय, हमारा स्वाद उन जगहों पर सबसे अच्छा केंद्रित है जहाँ इसकी सबसे अधिक आवश्यकता है। जैसे, सिस्टम के सबसे जोखिम भरे हिस्से कौन से हैं? हमें मानवीय स्वाद कहाँ लागू करने की आवश्यकता है? और वह फ्रंट एंड में हो सकता है। वह इस बात में हो सकता है कि सिस्टम कैसे काम करता है। इसका 100% होना आवश्यक नहीं है।

मेरी संज्ञानात्मक बैंडविड्थ एजेंटों के साथ स्केल नहीं होती

वास्तविकता यह है कि, हाँ, हम अब समानांतर में दर्जनों, सैकड़ों, हजारों एजेंटों को फायर कर सकते हैं, लेकिन आपकी अपनी संज्ञानात्मक बैंडविड्थ उसी तरह स्केल नहीं होती है। यह संज्ञानात्मक या समझ ऋण में योगदान कर सकता है जिसके बारे में मैंने पहले बात की है।

यदि आप केवल पाँच, दस साल पहले याद करते हैं, तो इंजीनियरिंग समुदाय में संदर्भ स्विचिंग और इसकी लागत के बारे में बहुत चर्चा हुआ करती थी। हम बात करते थे कि कैसे लोग नफरत करते थे जब कोई सहकर्मी या कोई आपकी डेस्क पर आता था जब आप किसी कार्य के बीच में होते थे। फिर आपको अपनी फ्लो स्थिति में वापस आने में इतना समय लगता था क्योंकि आपको फिर से पकड़ना होता था कि मैं कहाँ था? मैं क्या कर रहा था? भले ही आपके पास थोड़ा सा अवशेष हो, फिर भी इसमें समय लगता था।

अब हम पहले की तुलना में और भी अधिक संदर्भ स्विच कर रहे हैं। किसी भी दिन, यदि मैं सॉफ्टवेयर फैक्ट्री के बाहर काम कर रहा हूँ, तो मैं एक समय में एजेंटों के साथ पाँच या दस अलग-अलग प्रोजेक्ट्स पर काम कर सकता हूँ, या एक ही प्रोजेक्ट पर एक समय में पाँच या दस अलग-अलग फीचर्स पर काम कर सकता हूँ। मेरे पास पाँच या दस अलग-अलग सत्र हो सकते हैं, आप प्रभावी रूप से कह सकते हैं।

इसका मतलब है कि मुझे उनमें से कम से कम कुछ पर शीर्ष पर रहने में सक्षम होना होगा। यह संभव है कि मैं कुछ कार्यों को अधिक स्वायत्तता देने में सक्षम हो जाऊँगा यदि मुझे विश्वास है कि मैंने कार्य को पर्याप्त रूप से परिभाषित किया है, मैंने परिणाम को परिभाषित किया है, यह कैसे सत्यापित करेगा कि यह पर्याप्त रूप से किया गया है। लेकिन फिर ऐसे कार्य होंगे जहाँ शायद मुझे आवश्यक रूप से ऐसा महसूस न हो और इसमें अधिक जोखिम या अधिक बारीकियाँ शामिल हों। मुझे ध्यान देना होगा।

अपने समीक्षक के लिए सॉफ्टवेयर फैक्ट्री को अनुकूलित करने पर विचार करें। यह देखते हुए कि उन दृष्टिकोणों में से प्रत्येक अभी भी अपने आउटपुट को एक व्यक्ति के ध्यान में रूट करता है, आपको पूछना चाहिए कि फैक्ट्री उन निर्णयों को कितना सस्ता बना रही है जो आपको अभी भी लेने हैं।

एक गलत-प्रोजेक्ट गलती

मुझे याद है जब मैं अपने एजेंटों के साथ कई समानांतर प्रोजेक्ट्स पर काम कर रहा था, और ऐसे समय आए हैं जब मैंने गलती से ऐसी चीज़ें की हैं, जैसे, हो सकता है कि मैं एक वेब ऐप पर काम कर रहा था जहाँ मैं एक डार्क मोड जोड़ना चाहता था, और इसलिए मेरे दिमाग में था, ठीक है, यह इसका आकार कैसा दिखना चाहिए। लेकिन मैं गलती से एक अलग प्रोजेक्ट के सत्र में चला गया, और मैंने वही प्रॉम्प्ट डालना शुरू कर दिया।

इसलिए मैंने किसी ऐसी चीज़ के लिए डार्क मोड लागू करना शुरू कर दिया जिसे इसकी बिल्कुल भी आवश्यकता नहीं थी। और इसलिए मैं वह गलती कर सकता हूँ। मैं नहीं चाहता कि मेरी सॉफ्टवेयर फैक्ट्री उस तरह की गलती करे।

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

जब हरा भ्रामक होता है

इन प्रणालियों में भी, आप बहुत सावधान रहना चाहते हैं, है ना? हम में से कई लोगों ने देखा है कि जब आपने AI से एक परीक्षा पास करने में मदद करने के लिए कहा है, जैसे हम एक प्रोग्रामिंग टेस्ट, एक यूनिट टेस्ट के बारे में बात कर रहे हैं, तो यह उस स्थिति को संतुष्ट करने के लिए यूनिट टेस्ट को बदल सकता है, या यह उस स्थिति को पास करने के लिए कोड के तर्क को बदल सकता है। इसका मतलब यह नहीं है कि इसने वास्तव में कार्यात्मक व्यवहार और परीक्षण को क्या परीक्षण करना चाहिए था, दोनों को संरेखित करने के लिए आपके इरादे का पालन किया है, है ना?

सिर्फ इसलिए कि एक सॉफ्टवेयर फैक्ट्री दिखा रही है कि सब कुछ हरा है, इसका मतलब यह नहीं है कि यह वास्तव में हरा है, खासकर शुरुआत में जब आप इन चीज़ों को स्थापित कर रहे होते हैं। आपको यह सुनिश्चित करने के लिए बहुत ध्यान देने की आवश्यकता है कि आपकी जाँचें, आपके सत्यापन, ये सभी सही तरीके से आकार दिए गए हैं। वे वही कर रहे हैं जो आप उनसे करने की उम्मीद करते हैं। आप नहीं चाहते कि वे भ्रामक हों।

आप ऐसी स्थिति नहीं चाहते जहाँ आपके पास ऐसे परीक्षण हों जिन्होंने कहा, अरे, वास्तव में, मैंने जाकर बदल दिया है कि कौन से प्रमाणीकरण प्रदाता समर्थित हैं। आपने मुझे उदाहरण के लिए GitHub को एक प्रमाणीकरण प्रदाता के रूप में जोड़ने के लिए कहा, लेकिन अरे, मेरे UI में केवल तीन के लिए जगह थी, इसलिए मैंने जाकर दूसरे में से एक को हटा दिया है। और अरे, वैसे, वह वह था जो आपके ग्राहक वास्तव में चाहते थे। इसलिए आपको बस यह बहुत स्पष्ट होने की आवश्यकता है कि आप इन प्रणालियों को कैसे काम करना चाहते हैं।

वैसे सुरक्षा भी बहुत महत्वपूर्ण है और यदि आपकी फैक्ट्री अविश्वसनीय इनपुट जैसे GitHub इश्यू/Slack संदेश पढ़ती है तो यह प्रतिकूल हो सकता है और इसमें सप्लाई चेन अटैक जैसी समस्याएं शामिल हो सकती हैं। सॉफ्टवेयर फैक्ट्री के आसपास के कुछ उत्पाद, जैसे Vercel Sandbox/AI ADK Factory, अपने एजेंटों को पृथक सैंडबॉक्स में चलाते हैं जिनमें केवल वही रहस्य होते हैं जिनकी एक कार्य को आवश्यकता होती है। इस तरह एक समझौता किया गया रन उस तक नहीं पहुँच सकता जिसकी नौकरी को आवश्यकता नहीं है। आपकी सुरक्षा स्तरित हो जाती है।

कौन से पुराने प्रोजेक्ट दूसरे जीवन के लायक हैं?

मुझे यह भी लगता है कि आजकल हम कैसे काम करते हैं, इसका एक बड़ा हिस्सा यह तय करना है कि क्या अस्तित्व में होना चाहिए। यदि आप AI से कई साल पहले याद करते हैं, तो बहुत सारे परित्यक्त सॉफ्टवेयर इंजीनियरिंग प्रोजेक्ट थे, बहुत सारे परित्यक्त वीकेंड प्रोजेक्ट, व्यक्तिगत प्रोजेक्ट जहाँ वे लॉन्च नहीं होते थे क्योंकि हमारे पास उन्हें खत्म करने का समय नहीं था। हमारे पास उन्हें बाहर निकालने को प्राथमिकता देने की बैंडविड्थ नहीं थी क्योंकि वे हमारे लिए उतने महत्वपूर्ण नहीं थे या हमें समय नहीं मिल पाता था।

अब हमारे लिए उन प्रोजेक्ट्स को पूरा करना काफी आसान है, लेकिन वही मानवीय निर्णय का सवाल आता है। क्या उन प्रोजेक्ट्स को अस्तित्व में रहने का अधिकार है? क्या उन्हें लॉन्च किया जाना चाहिए? क्योंकि आप उन्हें दुनिया में डालते हैं और भले ही इसके केवल पाँच उपयोगकर्ता हों, हो सकता है कि आपको इसे बनाए रखना पड़े। हो सकता है कि अब आपके पास एक गुणवत्ता सीमा हो जिसे आप बनाए रखना चाहते हैं।

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

फिर आपको परीक्षण जोड़ने होंगे यदि आपके पास परीक्षण नहीं थे ताकि आप जान सकें कि कम से कम वह व्यवहार मौजूद रहेगा यदि आप किसी तरह से प्रोजेक्ट को अपग्रेड कर रहे हैं, या यदि आप इसे अधिक आधुनिक भाषा या फ्रेमवर्क या ऐसी किसी चीज़ में माइग्रेट कर रहे हैं।

फिर आप खुद से पूछने लगते हैं, ठीक है, शायद, एक बेवकूफी भरा उदाहरण, लेकिन शायद मैंने पुराने दिनों में इसके लिए Twitter Bootstrap का उपयोग किया था, लेकिन अब हर कोई Tailwind और shadcn का उपयोग कर रहा है, इसलिए मुझे UI को फिर से लागू करना होगा। और आप देखेंगे कि अचानक यह आपको अधिक समय ले रहा है, है ना? हाँ, एजेंट इसमें से बहुत कुछ तेजी से कर सकता है, लेकिन अब आपको उत्पाद समझ और स्वाद और इन सभी चीज़ों को शामिल करना होगा।

आप अभी भी सवाल करते हैं, ठीक है, यह किसके लिए है? क्या इसका कोई बाजार है? क्या यह अपने लिए है? क्या यह दूसरे लोगों के लिए है? यदि मैं इसे दुनिया में डाल रहा हूँ, तो क्या यह अभी भी उतना ही दिलचस्प होगा, यह देखते हुए कि अब कोई भी इन चीज़ों को इतनी जल्दी स्पिन कर सकता है?

इसलिए मुझे लगता है कि मानवीय प्रश्न कि क्या इन चीज़ों को अस्तित्व में रहने का अधिकार है? हम अपने स्वाद और निर्णय को कैसे शामिल करें? मुझे लगता है कि ये चीज़ें अत्यंत महत्वपूर्ण बनी हुई हैं। यह वह जगह है जहाँ मानवीय ध्यान का वह दुर्लभ संसाधन वास्तव में आता है। पुराने दिनों में, हमारे पास दिन में केवल सीमित संख्या में घंटे होते थे। हमारी मीटिंग होती थी। हमें डिज़ाइन और कोडिंग आदि के लिए समय का बजट बनाना होता था।

अब जब हमारी मदद करने के लिए एजेंट हैं, तो मुझे लगता है कि आपको वास्तव में बहुत स्पष्ट होना होगा कि आप अपना समय कहाँ और क्यों बिता रहे हैं।

जब मैंने एक नमूना बनाया तो क्या हुआ

तो मैं 82 मिनट के फैक्ट्री रन के बारे में बात करने जा रहा हूँ। लोग काफी समय से मुझसे पूछ रहे हैं, आप जानते हैं, "मैं सॉफ्टवेयर फैक्ट्री कैसे बनाऊँ?" या, "मैं Claude Code या Codex का उपयोग करने का आदी हूँ। मैं अपने सेटअप को सॉफ्टवेयर फैक्ट्री का उपयोग करने के लिए कैसे विकसित करूँ?"

तो पहली बात जो मैं कह रहा हूँ वह है, "आप ठीक हो सकते हैं। आपका काम वास्तव में फैक्ट्री की आवश्यकता के बिना पूरी तरह से ठीक हो सकता है।" लेकिन मैं लोगों को एक संदर्भ सेटअप देना चाहता था जिसे वे देख सकें। तो मैंने जो एक साथ रखा है वह एक रिपॉजिटरी है जिसे Factory कहा जाता है जिसे आप जाकर देख सकते हैं। मैंने एक डेमो एप्लिकेशन और वर्कशॉप भी एक साथ रखा है।

अब, पिछले कुछ वर्षों से, कई चीज़ों के लिए मेरा गो-टू डेमो एप्लिकेशन एक मूवी ऐप रहा है। मैं एक बड़ा मूवी प्रशंसक हूँ। मुझे मूवी देखना पसंद है। मैं हर समय मूवी देखता हूँ, और इसलिए मेरे पास एक डेमो एप्लिकेशन है, जो वास्तव में एक बहुत ही सरल मूवी ऐप के रूप में शुरू होता है। और मैं चाहता हूँ कि फैक्ट्री कई फीचर्स को लागू करने में सक्षम हो। कुछ अलग-अलग फीचर्स हैं। मुझे एक पसंदीदा फीचर चाहिए। मैं चाहता हूँ कि यह शायद खोज करने में सक्षम हो, और शायद इसमें एक डार्क थीम भी चाहिए, इस तरह की चीज़ें।

तो मेरी फैक्ट्री जाती है और इन चीज़ों के साथ काम करना शुरू करती है। आप कार्यान्वयन देख सकते हैं। इसका एक लाभ वास्तविक समस्याओं को पकड़ना था। ये समस्याएँ ऐसी चीज़ें नहीं हो सकती थीं जिन्हें मैंने पकड़ा होता यदि मैंने इसे एक-शॉट कार्यान्वयन करने के लिए कहा होता।

शायद 60 मिनट के आसपास, मुझे लग रहा था, "वाह, यह असामान्य रूप से धीमी गति से चल रहा है।" मैंने फैक्ट्री का उपयोग करके अपने हार्नेस से पूछा, "चीज़ें धीमी क्यों चल रही हैं?" इसने कहा, "यह वास्तव में पूरी तरह से ठीक है। सभी सत्यापनकर्ता अभी भी चल रहे हैं।"

आपने उम्मीद की होगी कि अलग-अलग कार्यों में 10 मिनट, 15 मिनट, 20 मिनट लगेंगे, लेकिन एक बार जब आप सत्यापन, पुनर्प्रयास, ब्राउज़र जाँच, मानव समीक्षा, उन अतिरिक्त देरी में से कोई भी शामिल करना शुरू करते हैं, तो उनमें दो से चार गुना अधिक समय लग सकता है।

मुझे लगता है कि ये बेहतर गुणवत्ता और सिस्टम में बेहतर विश्वास में योगदान कर सकते हैं। माप के दृष्टिकोण से, आप प्रति मर्ज किए गए PR की लागत और कोड शेल्फ लाइफ को समझ ऋण मेट्रिक्स के रूप में देख सकते हैं।

आपको यह भी सोचने की आवश्यकता है कि उपयोगी देरी बनाम फैक्ट्री ओवरहेड क्या है। सत्यापनकर्ताओं ने, मेरे मामले में, कुछ वास्तविक समस्याओं को पकड़ा। थोड़ा सा समय शायद उस सबूत को तैयार करने में लगा जो मैं चाहता था। इसका कुछ हिस्सा फैक्ट्री चलाने में ओवरहेड था। मैंने इसे अनुकूलित करने में वास्तव में कोई समय नहीं बिताया, लेकिन एक फैक्ट्री जो बहुत सारी जाँचें चलाती है जिन्हें आप मूल्यवान नहीं पाते हैं, इसका मतलब यह नहीं है कि यह उच्च गुणवत्ता वाली है।

आप यह अध्ययन करना चाहते हैं कि किसी भी दोहराई गई जाँच के लिए, क्या वे अप्रासंगिक हैं? क्या वे शोरगुल वाली हैं? क्या वे वास्तव में सिस्टम को सुरक्षित बना रही हैं?

सत्यापन को एक बजट की आवश्यकता है

जिस तरह से मैं सत्यापन के लिए बजट के बारे में सोचता हूँ, यह मूल रूप से वही है जिसके बारे में हम बात कर रहे हैं। हम एक सत्यापन बजट के बारे में बात कर रहे हैं। मैं इसके बारे में उसी तरह सोचता हूँ जैसे मैंने ऐतिहासिक रूप से प्रदर्शन बजट के बारे में सोचा है।

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

हमारे परीक्षणों का पूरा सूट ड्राफ्ट PR को एक साथ रखे जाने से ठीक पहले या उसके बाद चलाया जा सकता है। इसमें म्यूटेशन टेस्टिंग, ब्राउज़र टेस्टिंग, सुरक्षा जाँच, ऐसी कोई भी चीज़ शामिल हो सकती है।

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

जब एक रन शिप नहीं होता

मैंने ऊपर जो कुछ भी लिखा है, वह जाँचों से संबंधित है।

अपनी सॉफ्टवेयर फैक्ट्री में, Vercel प्रत्येक एजेंट रन को "success", "flawed", "blocked" या "manual" के रूप में चिह्नित करता है और केवल "success" प्रोडक्शन में शिप होता है। बाकी सिस्टम में फिर से प्रवेश करते हैं। मैं भी इसी तरह के शब्दों में रनों के बारे में सोच रहा हूँ।

यहाँ "flawed" का अर्थ है कि गलत चीज़ लागू की गई थी या हो सकता है कि उसके पास पूरा संदर्भ न हो, इसलिए इसे ठीक करना होगा। Blocked का अर्थ है कि वातावरण में एक क्रेडेंशियल गायब रहा होगा इसलिए आपको इसे प्रदान करना होगा। Manual एक सीमा है जिसे फैक्ट्री को अभी तक पार करने की अनुमति नहीं हो सकती है।

यहाँ तीन में से दो चीज़ों में यांत्रिक सुधार हो सकते हैं और आखिरी विश्वास के बारे में है।

जबकि यह बहुत अच्छा है, छँटाई आपको लागत नहीं दिखाती है। TMDB ऐप के साथ अपने फैक्ट्री कार्यान्वयन पर वापस आते हैं, बिना किसी अस्वीकृति के क्विक फाइंडर में 7 मिनट लगे। Favorites, बीच में दो अस्वीकृतियों और एक मानवीय निर्णय के साथ, 56 लगे। एक ही फैक्ट्री। इसलिए मैं प्रति-चरण समय के साथ वर्गीकरण को जोड़ूंगा, अन्यथा आप जानते हैं कि एक रन दोषपूर्ण वापस आया, बिना यह जाने कि पता लगाने में आपको कितना खर्च आया। दूसरी चीज़ जो मैं ठीक करूंगा वह है सीमा पर हैंडऑफ़: मेरी नमूना फैक्ट्री ने पहले मुद्दे को रोक दिया और इसे factory:needs-info में स्थानांतरित कर दिया, जो सही था, लेकिन मुझे नहीं पता था कि अपना उत्तर कहाँ रखूँ। एक मैनुअल रन तब समाप्त नहीं होता जब फैक्ट्री रुकती है, बल्कि जब मानव को पता होता है कि आगे क्या करना है।

स्वायत्तता एक एकल सेटिंग नहीं है

मैंने कुछ हफ्ते पहले एजेंटिक ऑटोनॉमी और स्वायत्तता के बारे में कैसे सोचना है, इस पर एक लेख लिखा था क्योंकि स्वायत्तता हर एक प्रोजेक्ट के लिए एक एकल सेटिंग नहीं होने वाली है।

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

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

वह फीचर जिसे मुझे फिर से सीखना पड़ा

एक फीचर था जिसे मैं एक दिन टाल रहा था जब मैं Claude के साथ कई सत्रों का उपयोग कर रहा था, और मैं एक समय में कुछ अलग-अलग प्रोजेक्ट्स पर, प्रति प्रोजेक्ट कुछ अलग-अलग फीचर्स पर काम कर रहा था। और इसलिए Claude ने उस फीचर को लागू कर दिया था जिस पर मैं काम कर रहा था। ऐसा लग रहा था कि परीक्षण पास हो रहे हैं। मैंने सत्यापन के बारे में बहुत नहीं सोचा था, लेकिन परीक्षण पास हो गए, और इसलिए मैंने सोचा कि यह काम कर गया। मैंने इसे मर्ज कर दिया।

और इसलिए यह एक पसंदीदा फीचर था। मैंने सोचा कि यह वास्तव में काफी अच्छा था। मैंने इसे ब्राउज़र में जाँचने की कोशिश की। ऐसा लग रहा था कि यह ठीक है, लेकिन कुछ दिनों बाद, मैं वास्तव में कोड पर वापस लौटा क्योंकि कुछ बदलाव थे जो मैं सोच रहा था कि मैं इसमें कर सकता हूँ।

मैं सिर्फ अपने एजेंट से बदलाव करने के लिए नहीं कहना चाहता था, क्योंकि यह काम करने का एक सूक्ष्म तरीका था। आप आइकन पर टैप करते हैं, और यह टैप पर सही प्रभाव नहीं दिखाता था, इसलिए मैं इसे ठीक करना चाहता था। मैं समझना चाहता था कि यह कैसे काम करता है ताकि मैं अपने एजेंट को सही ढंग से मार्गदर्शन कर सकूं।

मैं कोड पर वापस गया, और मैं आपको यह नहीं समझा सकता कि फीचर कैसे काम करता था। यह रिपॉजिटरी मेरी थी, है ना? मैंने बदलाव को मंजूरी दी थी। मैं समझता था कि इसका बहुत सारा हिस्सा कैसे काम करता है, रिपो का बहुत सारा हिस्सा, लेकिन मेरी समझ उस सारे कोड के साथ तालमेल नहीं रख पाई थी जो जमा हो रहा था।

मैं यह समझने में विफल रहा कि यह जो फीचर जोड़ा गया था, वह वास्तव में कैसे काम करता था, UI कैसे काम करता था, उस पर प्रभाव कैसे काम करता था। मुझे इस फीचर को फिर से करना पड़ा और वास्तव में कदम-दर-कदम जाना पड़ा, "यह कैसे काम करता है? मैं इसे कैसे समझ सकता हूं?"

समानांतर काम समझ को क्या करता है

जब आप समानांतर काम कर रहे होते हैं, तो यह इस समग्र समस्या को बढ़ा देता है, और जब आप इसे सॉफ्टवेयर फैक्ट्री में कर रहे होते हैं तो यह और भी अधिक बढ़ जाता है। जब आप पांच या दस सत्र कर रहे होते हैं, तो वे सिर्फ एक समीक्षा वॉल्यूम समस्या से कहीं अधिक पैदा करते हैं। वे कई मानसिक मॉडल बनाते हैं जो काफी ठंडे पड़ सकते हैं जब आप कहीं और काम कर रहे होते हैं।

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

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

यह कुछ ऐसा है जो मुझे लगता है कि आपके लिए एक उपयोगी सीख हो सकती है, जहां यह महत्वपूर्ण है, अपने एजेंट से अपने प्रक्षेपवक्र के बारे में जानकारी, या किसी समस्या के बारे में उसके दृष्टिकोण के बारे में दिलचस्प सबक संग्रहीत करने के लिए कहने पर विचार करें ताकि आप बाद में उस पर वापस जा सकें।

यह कुछ ऐसा हो सकता है या नहीं भी हो सकता है जिसे आप रिपो में कमिट करने का निर्णय लेते हैं। आप इसे स्थानीय रख सकते हैं यदि आप चाहते हैं, आप इसे एक टीम के साथ साझा कर सकते हैं यदि आप चाहते हैं, लेकिन यह कुछ ऐसा हो सकता है जिससे बाद में परामर्श लिया जा सके। बजाय इसके कि आप इस पर भरोसा करें कि यह शायद एक सत्र में है, या आपको शायद बाद में याद आए।

यह वास्तव में क्या बनाता है?

@threepointone और @bentlegen ने सॉफ्टवेयर फैक्ट्रियों पर कुछ विचार पोस्ट किए जिनसे मैं पूरी तरह सहमत था:

करने की मशीनरी से मोहित होना, मशीनरी को अनुकूलित करना और यह भूल जाना आसान है कि इसे क्या उत्पादन करना था। यदि आपकी फैक्ट्री ज्यादातर एक बेहतर फैक्ट्री का उत्पादन करती है, तो आपने ऐसा सॉफ्टवेयर बनाया है जिसका उत्पाद स्वयं है।

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

स्वामित्व गायब नहीं होता

इन सबके नीचे एक व्यापक सिद्धांत है।

मनुष्यों द्वारा भौतिक रूप से टाइप किए गए कोड का प्रतिशत नाटकीय रूप से गिर सकता है। मुझे नहीं लगता कि मानव स्वामित्व को इसके साथ गिरने की आवश्यकता है।

• कोई अभी भी समस्या चुनता है।
• कोई अभी भी आर्किटेक्चर चुनता है।
• कोई अभी भी गुणवत्ता मानक निर्धारित करता है।
• कोई तय करता है कि कौन से सत्यापन संकेत भरोसे के लायक हैं।
• कोई तय करता है कि शिप करने के लिए सबूत कब पर्याप्त है।

और जब परिणामी सिस्टम विफल हो जाता है, तो "एजेंट ने इसे लिखा" काम नहीं करता है। यही कारण है कि मुझे नहीं लगता कि सॉफ्टवेयर इंजीनियरिंग के भविष्य को मनुष्यों के लूप से बाहर निकलने के रूप में सबसे अच्छा वर्णित किया गया है। इसके बजाय, मानव निर्णय को स्थानांतरित किया जा रहा है।

हमें लोगों को लूप के उन हिस्सों से हटा देना चाहिए जहां मशीनें मजबूत, तेज, अधिक नियतात्मक संकेत उत्पन्न कर सकती हैं। साथ ही, हमें लोगों को उन स्थानों पर केंद्रित करना चाहिए जहां संदर्भ, स्वाद, जोखिम और दीर्घकालिक स्वामित्व सबसे अधिक मायने रखता है।

सबसे अच्छी सॉफ्टवेयर फैक्ट्रियों को इस बात से परिभाषित नहीं किया जाएगा कि वे मानवीय भागीदारी को कितनी पूरी तरह से समाप्त करती हैं।

उन्हें इस बात से परिभाषित किया जाएगा कि वे इसे कितनी बुद्धिमानी से रखती हैं।

मानव निर्णय को इरादे, सिस्टम आकार और गुणवत्ता मानक पर अपस्ट्रीम रखें। कोड की समीक्षा करें जहां स्वचालित बैक-प्रेशर कमजोर हो जाता है या परिणाम व्यक्तिपरक हो जाते हैं। हर नियतात्मक संकेत को जितनी जल्दी हो सके और लगातार लूप में धकेलें। जानबूझकर बाधाओं को कसें और ढीला करें क्योंकि सिस्टम विश्वास अर्जित करता है या खोता है।

एक मानव को अभी भी यह स्वामित्व लेना होगा कि कोड अंततः क्या शिप करता है। शिप करने के लिए पर्याप्त अच्छा कोड अभी भी किसी ऐसे व्यक्ति से शुरू होता है जो परवाह करता है कि इसे अस्तित्व में होना चाहिए या नहीं।