सॉफ्टवेयर फैक्ट्रियां विफल क्यों होती हैं: व्यवस्था को फिर से पटरी पर लाना

यह सॉफ्टवेयर फैक्ट्रियाँ क्यों विफल होती हैं का दूसरा भाग है*

इस पोस्ट का वीडियो संस्करण यूट्यूब पर लाइव है: https://www.youtube.com/watch?v=Ib5GBkD555M

लाइट्स वापस चालू करना

भाग 1 में, मैंने गहराई से बताया कि क्यों मॉडलों पर समय के साथ कोडबेस की गुणवत्ता बनाए रखने के लिए भरोसा नहीं किया जा सकता। क्यों कोई भी हार्नेस इंजीनियरिंग या टोकनमैक्सिंग मॉडल-ट्रेनिंग और बेंचमार्क समस्या को हल नहीं करेगी। क्यों कोड गुणवत्ता के लिए "मॉडल एज़ जज" उतना अच्छा काम नहीं करता जितना कुछ लोग आपको बताना चाहते हैं।

फिलहाल, जज आप ही हैं – तो हम कोड रिव्यू वापस ला रहे हैं।

हम उसी चीज़ को अपना रहे हैं जो हम AI से पहले से करते आ रहे हैं, यानी पहले से थोड़ी सी योजना बनाना, ताकि लंबी और कठिन समीक्षा की संभावना कम हो सके।

हम लीवरेज ढूंढने जा रहे हैं, और हम इसमें मदद के लिए AI का उपयोग करने जा रहे हैं, 4 चरणों में:

• उत्पाद आवश्यकताएँ
• सिस्टम आर्किटेक्चर
• प्रोग्राम डिज़ाइन
• वर्टिकल स्लाइस

उत्पाद समीक्षा

सब कुछ एक उत्पाद समीक्षा से शुरू होता है: एक छोटा दस्तावेज़ जो यह तय करता है कि हम क्या बना रहे हैं और क्यों। लक्ष्य यह है कि दो वाक्यों या एक लंबे वॉयस नोट को लेकर उसे अर्ध-संरचित रूप में बदला जा सके।

पहले, हम हल करने की समस्या पर सहमत होते हैं – उपयोगकर्ता की भाषा में, वास्तविक उपयोगकर्ता की परेशानी। दूसरा, सफलता कैसी दिखती है – शिप करने के बाद हम क्या पढ़ सकते हैं ताकि यह तय कर सकें कि चीज़ बनाने लायक थी। आदर्श रूप से यह एक उपयोगकर्ता परिणाम है जैसे "XYZ वर्कफ़्लो को कम समय में कर सकता है" या "ऑनबोर्डिंग माइलस्टोन ABC तक पहले पहुँचता है"। कभी-कभी यह निचले स्तर का होता है जैसे एरर रेट या लेटेंसी नंबर, कभी-कभी बस "X के बारे में सपोर्ट टिकट बंद हो जाते हैं।"

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

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

यहाँ एक वास्तविक उदाहरण है जो प्रगति पर है – दस्तावेज़ एक JSON आउटलाइन के साथ फीचर को पिन करता है, फिर वास्तविक स्क्रीन के दो मोटे HTML मॉकअप:

https://x.com/dexhorthy/status/2078592010852982977

बेशक, हर चीज़ को उत्पाद समीक्षा नहीं मिलती। एक कॉपी ट्वीक, एक वन-ऑफ स्क्रिप्ट, एक स्पष्ट रिप्रो वाला बग – हम अभी भी उन्हें सीधे एजेंट को वनशॉट करते हैं। यह उन बदलावों के लिए है जहाँ एजेंट द्वारा हमारे इरादे को गलत समझना महंगा है।

इस और श्रृंखला के सभी दस्तावेज़ों के लिए, हम लेखक-ऑप्ट-इन समीक्षाएँ करते हैं। यदि आप समीक्षा के दौरान समय बचाना चाहते हैं, तो आप उस व्यक्ति को चुनते हैं जो PR की समीक्षा करेगा, और उनके साथ उत्पाद/तकनीकी विशिष्टताओं पर चर्चा करते हैं, या तो async रूप में दस्तावेज़ टिप्पणियों के माध्यम से (हम इसके लिए humanlayer का उपयोग करते हैं, लेकिन आप इसे github/notion/plannotator आदि में भी आसानी से कर सकते हैं)।

सिस्टम आर्किटेक्चर

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

यदि आप समीक्षा के दौरान समय बचाना चाहते हैं, तो आप उस व्यक्ति को चुनते हैं जो PR की समीक्षा करेगा, और कोडिंग भाग में आने से पहले उनके साथ उत्पाद/तकनीकी विशिष्टताओं पर चर्चा करते हैं।

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

कॉन्ट्रैक्ट / एंडपॉइंट आकार:

डेटा मॉडल और ट्रांसफ़ॉर्मेशन:

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

प्रोग्राम डिज़ाइन

आर्किटेक्चर के बाद हम वह करते हैं जिसे मैं एजेंटिक कोडिंग में आपराधिक रूप से कम महत्व दिया गया मानता हूँ: प्रोग्राम डिज़ाइन।

अधिकांश लोग मानते हैं कि एक बार आर्किटेक्चर सही हो जाने के बाद, मॉडल बस पका सकता है। आप आगे बढ़कर ऐसा कर सकते हैं, लेकिन हो सकता है कि आपको जो वापस मिले वह पसंद न आए।

लेकिन जो मैं अच्छा काम करते हुए देख रहा हूँ वह यह है कि किसी भी (मानव या एजेंट) के कार्यान्वयन लिखने से पहले, हम आर्किटेक्चर से एक स्तर नीचे कोड के आकार में जाते हैं: टाइप्स, मेथड सिग्नेचर, प्रोग्राम लेआउट और कॉल स्टैक।

हमारे प्रोग्राम डिज़ाइन कौशल का पहला संस्करण बेकार था। इसे पढ़ना कठिन था, यह थकाऊ था। हमने mermaid आज़माया, जिसका अपना स्थान है, लेकिन जो हमें वास्तव में पसंद है वह हैं स्यूडोकोड में हल्के विज़ुअलाइज़ेशन:

कॉल-स्टैक ट्री, किसी भी ऑर्केस्ट्रेशन या कंट्रोल-फ़्लो बदलाव के लिए। जब दिलचस्प हिस्सा वही हो जो बदल रहा है, तो diff सिंटैक्स का उपयोग करें:

Dillon Mulroy अपनी योजना प्रक्रिया के भाग के रूप में कॉल ग्राफ़ का उपयोग करने के बारे में बात करते हैं, और मुझे लगता है कि यह बिल्कुल सही है।

फ़ाइल-ट्री डिफ़ - ताकि आप अपने कोडबेस के लेआउट और चीज़ें कहाँ रहती हैं, से जुड़े रह सकें

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

इनमें से किसी को भी तैयार होने में अधिक समय नहीं लगता (मॉडल उनका मसौदा तैयार करता है, आप इससे बहस करते हैं), और उनमें से हर एक एक निर्णय है जो आप अन्यथा कोड समीक्षा के दौरान परोक्ष रूप से ले रहे होंगे – अपना मन बदलने के सबसे महंगे संभावित समय पर।

वर्टिकल स्लाइस

इसके बाद हमें वह करना पसंद है जिसे मैं "वर्टिकल स्लाइस" कहता हूँ - Matt Pocock और मेरी जनवरी 2026 में एक लाइव स्ट्रीम पर वर्टिकल स्लाइस या "ट्रेसर बुलेट" के बारे में चैट हुई थी - इसे ट्रेसर बुलेट भी कहा जाता है।

मॉडल को वह पसंद है जिसे मैं "क्षैतिज योजनाएँ" कहता हूँ - स्टैक-क्रम में काम करना:

1. डेटाबेस माइग्रेशन
2. सर्विस लेयर
3. API
4. फ्रंटएंड

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

AI से पहले, किसी के लिए रास्ते में कुछ जाँचे बिना 2000+ लाइन कोड या 500 लाइन कोड लिखना दुर्लभ था।

मुझे उस अंतर को नोटिस करने में कुछ समय लगा जिसका मैं आदी था - जब मैं AI से पहले कोड लिखता था, तो मैं हमेशा बीच में शुरू करता था और बाहर की ओर काम करता था। मोटे तौर पर:

1. API कॉन्ट्रैक्ट बनाएँ और मॉक डेटा परोसें, curl से परीक्षण करें
2. मॉक डेटा का उपभोग करने के लिए फ्रंटएंड बनाएँ, ब्राउज़र में पुनरावृत्ति+पॉलिश करें
3. API को सर्विस लेयर से वायर करें (सेवाएँ मॉक डेटा/व्यवहार प्रदान करती हैं)
4. डेटाबेस माइग्रेशन जोड़ें, सेवाओं को डेटाबेस से वायर करें
5. बहुत सारा बिजनेस लॉजिक जोड़ें
6. बहुत सारी एरर हैंडलिंग जोड़ें

और मैं प्रत्येक चरण में परीक्षण/पुनरावृत्ति/पॉलिश कर रहा होता था।

यदि मैं कोड की बहुत परवाह करता हूँ या कोडबेस के इस भाग में अच्छा काम करने की मॉडल की क्षमता के बारे में संशय में हूँ, तो मैं प्रत्येक चरण में कोड की समीक्षा भी कर रहा हूँ। 100-200 लाइनों की जाँच करना और पुनर्निर्देशित करना बहुत सस्ता है।

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

30 मिनट की योजना समीक्षा के घंटों से बचाती है

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

1. उत्पाद डिज़ाइन
2. सिस्टम आर्किटेक्चर
3. प्रोग्राम डिज़ाइन
4. वर्टिकल स्लाइस

जाहिर है, हम शिप की जाने वाली हर चीज़ के लिए यह पूरी प्रक्रिया नहीं करते (नीचे साइडक्वेस्ट देखें)। मेरा अनुमान है कि वितरण लगभग इस प्रकार है:

• ~40% कार्य वनशॉट या 1-2 राउंड हल्की प्रतिक्रिया के साथ वनशॉट होते हैं
• मध्यम कार्यों के लिए, हम सभी एक योजना दस्तावेज़ में उत्पाद/सिस्टम डिज़ाइन करते हैं, और काम को चरणों में तोड़ने की जहमत नहीं उठाते
• बड़ी चीज़ों के लिए, हम सभी चरण करते हैं। हम उन चीज़ों के लिए उत्पाद भाग को छोड़ देंगे जहाँ यह समझ में नहीं आता जैसे बड़े रिफैक्टर।

और अधिकांश मामलों में, मैं एक मॉडल को एक बार में 1-3 स्लाइस करने के लिए भेजूंगा, और जाते समय कोड की समीक्षा करूंगा। शुरुआत में पुनर्निर्देशित करना बहुत आसान है, चाहे वह आंतरिक हो या वास्तविक कार्यक्षमता, बजाय इसके कि 2k+ लाइन कोड के दूसरी तरफ पहुँचें और पता न हो कि क्या टूटा है।

आप शायद महसूस करते हैं कि आपके पास बहुत अधिक पुल रिक्वेस्ट हैं

आपके पास बहुत अधिक PR नहीं हैं। आपके पास बहुत अधिक खराब PR हैं।

हम सभी ने AI से बहुत पहले से, बहुत सारे PR की समीक्षा की है जिन्हें फिर से काम करने की आवश्यकता थी।

लेकिन एक अच्छा PR समीक्षा करने में आनंददायक होता है। आप हर फ़ाइल के माध्यम से स्क्रॉल कर रहे हैं, कोड साफ है, यह सॉफ्टवेयर के बारे में आपके सभी निर्णयों/चर्चाओं/कठिन-जीती राय का पालन करता है।

दूसरी ओर, यदि एक पुल रिक्वेस्ट को भी 20% रीवर्क की आवश्यकता है (और यह उदार है, मैं कहूंगा कि अधिकांश AI वनशॉट PR 50% के करीब हैं), तो यह प्रस्तुतकर्ता और समीक्षक दोनों पर एक बौद्धिक बोझ और भावनात्मक बोझ दोनों है। (भले ही प्रस्तुतकर्ता AI हो, किसी ने शायद इस काम को शुरू किया हो या AI परिणाम को वाइब पॉलिश किया हो या कम से कम, परिणाम की परवाह करता हो)।

आपका समय बचाने के लिए (हम लगभग अंत में हैं), मैंने एक साइड क्वेस्ट में इसके बारे में और अधिक रैंबल किया:

"समय कहाँ जाता है"

बाधाओं का एक सिद्धांत (2026 संस्करण)

यहाँ मुख्य थीसिस से थोड़ा निराश होना आसान है: "अभी के लिए हम कोड पढ़ने में फंसे हुए हैं।"

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

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

मॉडल कुछ चीज़ों में अच्छे हैं, दूसरों में इतने नहीं। आप इन बाधाओं के आलोक में अपनी प्रक्रिया को कैसे अनुकूलित करते हैं?

यह संभव है कि आप 10-100 गुना तेजी से आगे बढ़ने की कोशिश में बहुत व्यस्त हैं और खुद को समझा रहे हैं कि कोड गुणवत्ता अब मायने नहीं रखती, जबकि आप बाधाओं को अपना सकते हैं और 2-3 गुना तेजी से, सुरक्षित रूप से आगे बढ़ सकते हैं।

मेरी तरह की समापन सलाह मूल रूप से यह है:

1. बाधाओं को अच्छी तरह से जानें, मॉडलों के साथ बहुत काम करके अंतर्ज्ञान विकसित करें
2. इन बाधाओं के क्षेत्र के भीतर प्रणालियों को अनुकूलित करें
3. लीवरेज खोजें
4. कोड पढ़ें, भाड़ में जाए

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

पढ़ने के लिए धन्यवाद

-dex

PS हम इसके बारे में जुनूनी हैं

हम humanlayer.com बना रहे हैं, एक एजेंटिक IDE और सहयोग प्लेटफ़ॉर्म जो आपको मानव (या मानव के काफी करीब) स्तर की कोड गुणवत्ता बनाए रखते हुए 2-3 गुना तेजी से आगे बढ़ने में मदद करने के लिए है।

हम दो विचारों की ओर निर्माण कर रहे हैं: "आपके सॉफ्टवेयर फैक्ट्री के लिए बिल्डिंग ब्लॉक्स" और "सॉफ्टवेयर रखरखाव के लिए बेहतर वेरिफ़ायर" (शायद बेहतर मॉडल भी)।

HumanLayer 3 लोगों तक की छोटी टीमों के लिए मुफ्त है, और यदि आप शुरू करने में सहायता चाहते हैं, तो आप हमारे discord में आ सकते हैं या हमें founders@humanlayer.dev पर एक लाइन छोड़ सकते हैं

प्रेरणा के लिए @calvinfo, मेरे सह-संस्थापक @0xBlacklight, @swyx और @aiDotEngineer की टीम को इन विचारों का पता लगाने के लिए मुझे एक क्षेत्र देने के लिए, और हमारे सभी अविश्वसनीय ग्राहकों, निवेशकों, दोस्तों और परिवार को हमारा उत्साहवर्धन करने के लिए एक त्वरित शाउट आउट।

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

PPS अन्य संसाधन

पॉडकास्ट और लेख:

• Dex और Gergely द प्रैग्मेटिक इंजीनियर पर कॉन्टेक्स्ट इंजीनियरिंग और सॉफ्टवेयर फैक्ट्रियों पर चर्चा करते हैं - जुलाई 2026
• Dex और Matt Pocock एवरग्रीन AI कोडिंग सलाह (और राल्फ लूप्स) पर चर्चा करते हैं - जनवरी 2026

AI दैट वर्क्स एपिसोड:

• बेंचमार्क कुछ भी साबित नहीं करते
• AI कोडिंग के लिए उत्पाद विशिष्टताएँ
• बेहतर बैकप्रेशर के लिए लर्निंग टेस्ट
• AI कोडिंग के लिए 12-फैक्टर एजेंट सिद्धांतों को लागू करना

इस पोस्ट के लिंक:

• सॉफ्टवेयर फैक्ट्रियाँ क्यों विफल होती हैं मुख्य भाषण — AI इंजीनियर वर्ल्ड्स फेयर 2026
• StrongDM की लाइट्स-ऑफ सॉफ्टवेयर फैक्ट्री
• OpenAI: हार्नेस इंजीनियरिंग (फरवरी 2026)
• Ryan Lopopolo on Symphony (वार्ता, अप्रैल 2026)
• AI इंजीनियर यूरोप में मारियो: "स्लॉप की दुनिया में पाई बनाना"
• FT: कोडिंग-एजेंट दुर्घटनाओं से अमेज़न आउटेज
• Matt Pocock: कोडबेस बिखर रहे हैं
• Faros AI: AI त्वरण व्हिपलैश रिपोर्ट
• कोडिंग एजेंटों के लिए उन्नत संदर्भ इंजीनियरिंग (वार्ता 8/25)
• कोई वाइब्स की अनुमति नहीं (वार्ता 11/25)
• RPI के बारे में हमें सब कुछ गलत मिला (वार्ता 3/26)
• Awesome-RLVR - सुदृढीकरण सीखने के संसाधन
• कोडिंग एजेंटों के लिए उन्नत संदर्भ इंजीनियरिंग (लेख)
• 12-फैक्टर एजेंट
• Addy Osmani वाइब-कोडिंग बनाम रखरखाव पर
• NATO सॉफ्टवेयर इंजीनियरिंग सम्मेलन, 1968
• DoD DevSecOps संदर्भ डिज़ाइन (PDF)
• Ramp का कोडिंग-एजेंट प्लेटफ़ॉर्म
• Stripe: Minions, वन-शॉट एंड-टू-एंड कोडिंग एजेंट
• WorkOS: प्रोजेक्ट होराइज़न
• Brex (लेटेंट स्पेस)
• Dan Shapiro: सॉफ्टवेयर फैक्ट्री के पाँच स्तर
• Simon Willison StrongDM के सॉफ्टवेयर फैक्ट्री पर
• "समुद्र को उबालना"
• शॉटगन सर्जरी (refactoring.guru)
• John Ousterhout — सॉफ्टवेयर डिज़ाइन का एक दर्शन
• Robert C. Martin — स्वच्छ कोड
• Martin Fowler — रिफैक्टरिंग
• aider
• cline
• codebuff
• SWE-एजेंट पेपर (2024)
• OpenAI Codex वार्ता (नवंबर)
• Calvin French-Owen — AI काउंसिल वार्ता
• SWE-bench बहुभाषी (डेटासेट)
• AIE वर्ल्ड्स फेयर 2026 - द ग्रेट लूप्स डिबेट ("हाइप अनुशासन से आगे निकल रहा है")
• SWE-मैराथन (प्रचुर AI)
• DeepSWE (डेटाकर्व)
• फ्रंटियर कोड (कॉग्निशन)
• म्यूटेशन टेस्टिंग (विकिपीडिया)
• Dillon Mulroy योजना में कॉल ग्राफ़ पर
• Dex × Matt Pocock: वर्टिकल स्लाइस / ट्रेसर बुलेट (लाइवस्ट्रीम, जनवरी 2026)
• "सोचने की कड़ी मेहनत को आउटसोर्स नहीं किया जा सकता" (Jake Nations)