सॉफ्टवेयर फैक्ट्रियाँ क्यों विफल होती हैं (या: हार्नेस इंजीनियरिंग पर्याप्त नहीं है)

“सॉफ्टवेयर फैक्ट्रियों” की स्थिति और StrongDM संदर्भ

• कुछ टिप्पणीकार नोट करते हैं कि StrongDM का AI काम एक कंसल्टिंग फर्म में अलग हो गया, जिसे या तो सफलता के रूप में देखा जाता है (विचार मूल्यवान थे) या इस संकेत के रूप में कि उत्पाद को भारी सेवाओं की ज़रूरत थी।
• एक StrongDM लैब सदस्य स्पष्ट करता है कि उनका “weather report” नियमित अपडेट देख रहा है और दावा करता है कि अधिकांश सॉफ्टवेयर समस्याएँ उनकी factory तकनीकों के आगे झुक जाती हैं, खासकर नए मॉडल्स के साथ।
• अन्य लोग तर्क देते हैं कि हम अभी शुरुआती, प्रयोगात्मक दिनों में हैं; अभी कोई स्थिर “standard methodology” नहीं है।

कठोरता, मेंटेनबिलिटी, और स्पेक्स

• व्यापक सहमति: जो टीमें AI से सबसे अधिक लाभ उठाती हैं, उनके पास पहले से ही उच्च अनुशासन, साफ़ कोड, टेस्ट, और hygiene होती है।
• बहुत से लोग मेंटेनबिलिटी को मुख्य अनसुलझी समस्या मानते हैं: मॉडल फीचर्स लागू कर सकते हैं, लेकिन समय के साथ architecture और coupling को धीरे-धीरे बिगाड़ देते हैं।
• लोग agents को सीमित करने के लिए RFC-शैली के, normative specs और typed constraints की खोज कर रहे हैं, लेकिन नोट करते हैं कि बहुत विस्तृत specs अंततः code जैसी लगने लगती हैं और स्पष्ट रूप से मेहनत नहीं बचातीं।
• कुछ लोग RL setups का प्रस्ताव रखते हैं जो codebase health के दीर्घकालिक लाभ को reward करें, लेकिन ध्यान दिलाते हैं कि “good design” के लिए कोई तेज़, objective oracle नहीं है।

Code review, PRs, और प्रक्रिया

• code review पर गहरी विभाजन रेखा:
  • एक पक्ष मानता है कि human review ज्ञान-साझाकरण, taste, design oversight, और compliance के लिए आवश्यक है; reviews का दिखावा करने के लिए LLMs का उपयोग कर्तव्य-परित्याग माना जाता है।
  • दूसरा पक्ष reviews को automate करता है और दावा करता है कि organizations को ज़्यादातर bug prevention और speed की परवाह होती है; तर्क देता है कि हमें diffs नहीं, बल्कि चल रहे software की review करनी चाहिए।
• कई लोग PR UX, बहुत बड़े agent-generated diffs, और “LLMese” comments की शिकायत करते हैं।
• कुछ लोग भारी automated checks, tests, linters, और आसान rollback के साथ PR gates को न्यूनतम करने की वकालत करते हैं; अन्य तर्क देते हैं कि ये अभी भी architecture और backwards-compatibility की समस्याएँ चूक जाते हैं।

Model capabilities, RL, और long-context

• इस बात पर मतभेद है कि frontier models (Opus, Fable, GPT-5.6, आदि) ने खेल को कितना बदला। कुछ लोग agents को पूरे फीचर्स सौंपने की बात करते हैं; अन्य कहते हैं कि lights-off प्रयासों ने अभी भी slop या आत्म-पोषित खराब designs पैदा किए।
• कई लोग देखते हैं कि models, जब स्पष्ट रूप से कहा जाए, refactor अच्छी तरह कर सकते हैं, लेकिन autonomously यह नहीं पहचानते कि refactors की ज़रूरत कब है।
• long-context व्यवहार मिश्रित है: कुछ को बहुत कम degradation दिखता है; अन्य उदाहरण दिखाते हैं जहाँ models बड़े contexts में साधारण workflows भूल जाते हैं।
• बहुत से लोग ज़ोर देते हैं कि आज RL मुख्यतः task success के लिए optimize करता है, design quality के लिए नहीं, इसलिए reward hacking और brittle tests आम हैं।

इंजीनियरों की भूमिका और “taste”

• कई टिप्पणियाँ एक software engineer की मुख्य नौकरी को system ownership, दीर्घकालिक design, और taste के रूप में परिभाषित करती हैं, न कि सिर्फ code टाइप करने के रूप में।
• अच्छी architecture को सूक्ष्म, मापने में कठिन, और दर्दनाक अनुभव से सीखा गया बताया जाता है; टिप्पणीकार संदेह करते हैं कि current models भरोसेमंद ढंग से ये design judgments दे सकते हैं।
• एक बार-बार आने वाला विषय: codebase patterns “implicit prompts” की तरह काम करते हैं, इसलिए मनुष्यों को abstractions और patterns की सतर्कता से रक्षा करनी चाहिए, वरना slop जमा होता जाता है।

आज factories कहाँ काम कर सकती हैं

• कई लोग “dark factories” को अधिक व्यावहारिक मानते हैं:
  • छोटे, कम-जोखिम वाले या hobby apps।
  • अल्पकालिक experiments और scripts।
• जटिल, राजस्व-संचालित, या regulated systems के लिए, अधिकांश लोग human-in-the-loop factories की वकालत करते हैं, जहाँ अधिक upfront planning (product, system, program design) और कड़े constraints हों, पूरी autonomy नहीं।