AI के युग में द मिथिकल मैन-मंथ
AI कोडिंग टूल्स और स्वायत्त एजेंट कोड जनरेशन को बेहद तेज़ कर रहे हैं, लेकिन कई इंजीनियरों का तर्क है कि Fred Brooks की पुरानी अंतर्दृष्टि अब भी सही है: बाधा टाइपिंग नहीं, बल्कि समन्वय, समझ, और सत्यापन है। टिप्पणीकार AI को एक amplifier के रूप में वर्णित करते हैं जो मज़बूत डेवलपर्स को कहीं अधिक उत्पादक बनाता है, जबकि कमज़ोर डेवलपर्स को अधिक बिना-जाँची “slop” ship करने देता है; और चेतावनी देते हैं कि AI आउटपुट की समीक्षा और एकीकरण संज्ञानात्मक रूप से थकाने वाला और संगठनात्मक रूप से नाज़ुक हो सकता है। व्यापक सहमति यह है कि छोटी, अच्छी तरह orchestrated टीमें और सीमित दायरे वाले कार्य सबसे अधिक लाभान्वित होते हैं, जबकि साझा codebase में एजेंटों को naive तरीके से parallelize करने से जटिलता, technical debt, और गलत संरेखित features बढ़ने का जोखिम है.
मिथिकल मैन-मंथ अब भी लागू होता है (अधिकांशतः)
- कई लोग तर्क देते हैं कि Brooks का मूल बिंदु आज भी सही है: कठिन हिस्सा टाइपिंग नहीं, बल्कि समन्वय, साझा समझ, और डिज़ाइन की सुसंगति है।
- AI कोड जनरेशन को सस्ता बनाता है, लेकिन समीक्षा करना, एकीकृत करना, और यह याद रखना कि निर्णय क्यों लिए गए थे, अभी भी मानवीय बाधाएँ हैं।
- कुछ लोगों को AI विकास अधिक मानसिक रूप से थकाने वाला लगता है: तेज़ चक्र, अधिक निर्णय, और बड़े बदलावों पर लगातार सतर्कता।
- सावधानीपूर्ण ऑर्केस्ट्रेशन के बिना समानांतर एजेंटों को “बहुत सारे बावर्ची” वाली समस्या को बस और तेज़ी से दोहराते हुए देखा जाता है।
एजेंट, समानांतरता, और ऑर्केस्ट्रेशन
- रिपोर्टें अलग-अलग हैं: कुछ कहते हैं कि कई एजेंट एक-दूसरे के काम में दखल देते हैं, शोरगुल वाले टेस्ट बनाते हैं, और लूप में एक-दूसरे का कोड फिर से लिख देते हैं।
- अन्य का दावा है कि बड़े मॉडल योजनाओं, git worktrees, और स्पष्ट कार्य-सीमाओं का उपयोग करके उप-एजेंटों का अच्छा समन्वय कर सकते हैं, ताकि कई एजेंट समानांतर में उत्पादक रूप से चलें।
- इस पर बहस है कि क्या सस्ते उप-मॉडल वास्तव में टोकन बचाते हैं, क्योंकि सुपरवाइज़र मॉडल को फिर भी उनका आउटपुट दोबारा पढ़ना और समीक्षा करना पड़ता है।
- LLMs को खराब self-managers के रूप में वर्णित किया गया है: वे योजनाओं को अति-विशिष्ट बना देते हैं, उप-इष्टतम डिज़ाइनों में खुद को लॉक कर लेते हैं, और पहले की धारणाओं पर शायद ही कभी सवाल उठाते हैं।
“गलत उत्तर तेज़ी से” और प्रोटोटाइपिंग
- कई लोग खराब-लेकिन-चलने वाले POCs को तेज़ी से बनाने में बहुत मूल्य देखते हैं, ताकि आवश्यकताएँ स्पष्ट हों और stakeholders एकमत हों, बजाय महँगी, अस्पष्ट बैठकों के।
- लाभ: ठोस डेमो गलतफहमियाँ उजागर करते हैं, उपयोगकर्ता यह बताने में बेहतर होते हैं कि उन्हें क्या पसंद नहीं है, और जब कोड सस्ता हो तो sunk-cost bias कम होता है।
- जोखिम: चमकदार प्रोटोटाइप stakeholders को throwaways को शिप करने योग्य समझने के लिए लुभा सकते हैं; POCs जटिलता छिपा सकते हैं और पर्याप्त गहरी सोच के बिना टीमों को गलत रास्तों पर धकेल सकते हैं।
- सहमति: एक बार में पूर्णता लाने से iteration बेहतर है, लेकिन सत्यापन, परीक्षण, और मानवीय निर्णय फिर भी महत्वपूर्ण हैं।
उत्पादकता, गुणवत्ता, और टीम गतिशीलता
- कुछ लोग ≥10x “debugged LOC” उत्पादकता की रिपोर्ट करते हैं; अन्य बढ़ी हुई घटनाएँ, फुलावट, और विश्वसनीयता तथा सरलता में गिरावट देखते हैं।
- AI को व्यापक रूप से एक amplifier बताया गया है: मज़बूत, प्रेरित डेवलपर्स बेहद अधिक प्रभावी हो जाते हैं; कमज़ोर या उदासीन डेवलपर्स अधिक बिना-जाँची स्लोप तेज़ी से ship करते हैं।
- Review fatigue एक बड़ा दर्द-बिंदु है; इंजीनियर खुद को PR reviewers और QA तक सीमित महसूस करते हैं, जिसे कई लोग निरुत्साहजनक मानते हैं।
- एकल इंजीनियर + एजेंट या बहुत छोटी टीमें increasingly optimal मानी जाती हैं; AI के साथ बड़ी टीमों में coordination overload का जोखिम है।
संज्ञानात्मक और सांस्कृतिक चिंताएँ
- कुछ लोगों को “engineering director” की भूमिका—निर्दिष्ट करना, आलोचना करना, परिष्कृत करना—लाइन-बाय-लाइन कोडिंग से अधिक पसंद है।
- दूसरों को एजेंटों के साथ इंटरैक्शन उबाऊ लगता है, चिंता होती है कि इससे उनकी तर्कशक्ति और craftsmanship कमज़ोर हो रही है, और वे खुद कोड लिखना पसंद करते हैं।
- कई लोग चिंता करते हैं कि संगठनात्मक प्रोत्साहन (गुणवत्ता के बजाय velocity) और AI मिलकर tech debt और “shadow IT” को टिकाऊ प्रणालियों के बजाय तेज़ी से बढ़ाएँगे।