अब किसी भी सॉफ्टवेयर टीम को ‘छोटी’ नहीं कहा जा सकता
यह दावा कि AI coding agents हर engineering group को सैकड़ों parallel changes करके एक “बड़ी टीम” में बदल देंगे, भारी संदेह का सामना कर रहा है। टिप्पणीकारों का तर्क है कि systems को agents को खिलाने के लिए हज़ारों microservices में बाँटना मुख्यतः complexity को operations में स्थानांतरित करता है, coordination को कठिन बनाता है, और PR counts के लिए optimized कम-गुणवत्ता वाले code की बाढ़ का जोखिम बढ़ाता है, न कि user value के लिए। कई लोग LLMs को individual developers और अच्छी तरह architected छोटे monoliths के लिए शक्तिशाली tools मानते हैं, लेकिन चेतावनी देते हैं कि agents पर अत्यधिक निर्भरता maintainability, product focus, और human software engineers की दीर्घकालिक भूमिका को खतरे में डालती है.
एजेंट, “छोटी टीमें,” और उत्पादकता मेट्रिक्स
- कई टिप्पणीकारों को संदेह है कि एजेंटों के ज़रिए दिन में 100 PRs करने वाली “छोटी टीमें” वास्तव में कोई सार्थक प्रगति हैं।
- उच्च PR/commit संख्या को आसानी से छेड़छाड़ किए जा सकने वाले vanity metrics माना जा रहा है, जो AI युग में user value से और भी दूर हो गए हैं।
- कुछ संगठनों में अब कथित तौर पर “laggards” पर AI को और ज़्यादा उपयोग करने का दबाव डाला जा रहा है, भले ही AI-जनित काम को चुपचाप दोबारा करना पड़े।
AI के साथ microservices बनाम monoliths
- कई लोगों का तर्क है कि microservices operational complexity बढ़ाते हैं (deployments, networking, retries, consistency, versioning) लेकिन inherent product complexity को कम नहीं करते।
- कई लोग कहते हैं कि अच्छी तरह संरचित monoliths, modular code और स्पष्ट boundaries के साथ, अब भी बेहतर हैं, खासकर क्योंकि एक LLM अधिक context संभाल सकता है।
- अन्य लोग दावा करते हैं कि fine-grained services (यहाँ तक कि “nano-services”) LLM context limits और agent parallelism के साथ बेहतर मेल खाते हैं, लेकिन इस पर विवाद है।
गुणवत्ता, correctness, और coordination
- इस बात पर कड़ा संदेह है कि agents सुरक्षित रूप से हज़ारों services में बदलाव कर सकते हैं: agents के पास पूरे सिस्टम का context नहीं होता और वे सूक्ष्म cross-service breakage पैदा कर सकते हैं।
- Parallel “agent swarms” साधारण merge conflicts की बजाय semantic conflicts का जोखिम पैदा करते हैं, जिससे integration और release coordination और कठिन हो जाती है।
- कुछ लोग maintenance के लिए AI का उपयोग सुझाते हैं: invariants को लागू करना, code को सरल बनाना, या व्यवस्थित रूप से tech debt कम करना — लेकिन अन्य लोग बताते हैं कि models context बढ़ने पर अक्सर invariants को अनदेखा कर देते हैं।
Developer experience और job impact
- अनुभव अलग-अलग हैं: कुछ solo/small-team developers दावा करते हैं कि LLMs ने उन्हें नाटकीय productivity और यहाँ तक कि पूरे app rewrites करने में सक्षम बनाया; अन्य इनके बिना भी प्रभावी हैं।
- भविष्य की भूमिकाओं पर बहस: “आप prompt engineer हैं या fired” जैसी सोच से लेकर यह दृष्टिकोण कि system design, understanding, और craftsmanship अब भी आवश्यक हैं।
- चिंता यह है कि senior लोगों के architectural ज्ञान को opaque AI-generated changes से बदला जाना, अनुभवी स्टाफ के churn के बाद outages बढ़ा सकता है।
नैतिक, आर्थिक, और सामाजिक चिंताएँ
- बाहरी LLM vendors पर निर्भरता, अप्रत्याशित लागत, privacy risks, copyright मुद्दों, और skill atrophy को लेकर चिंताएँ।
- कुछ लोगों को लगता है कि AI-चालित productivity समाज की ज़रूरतों से असंगत है (“more crud apps,” “better” software नहीं), और यह investor FOMO तथा “tokenmaxxing” से प्रेरित है।
- अन्य लोग तर्क देते हैं कि AI एक स्थायी, परिवर्तनकारी तकनीकी लहर है; capex का एक “winter” हो सकता है, लेकिन pre-AI software development की वापसी नहीं होगी।