सॉफ्टवेयर इंजीनियरिंग और GenAI पर आठ मिथक
यह दावा कि generative AI डेवलपर के दिन का लगभग 14% ही, यानी code टाइप करने वाले हिस्से को, तेज़ कर सकती है, काफ़ी विवादित है; कई engineers बताते हैं कि आधुनिक टूल्स अब research, design docs, debugging, test authoring, और product planning तक को तेज़ करते हैं। टिप्पणीकार इस पर बहस करते हैं कि क्या code अब भी असली bottleneck है, टीम कितना AI-generated “slop” और security risk सह सकती हैं, और lines of code या self-reported speedups क्या वाकई meaningful productivity metrics हैं। इसके नीचे hype, job displacement, और aggressive AI assistance से बने systems की long-term maintainability को लेकर एक व्यापक चिंता है.
डेवलपर के समय और वर्कफ़्लो पर प्रभाव
- कई लोग लेख के “AI सिर्फ़ 14% कोडिंग समय को छूता है” वाले फ्रेमिंग से असहमत हैं; उनका कहना है कि मौजूदा टूल्स केवल टाइपिंग से कहीं ज़्यादा तेज़ करते हैं: debugging, legacy code पढ़ना, test writing, scaffolding, docs, Jira/Linear admin, dashboards, और research।
- कुछ लोग बताते हैं कि वे अपना ज़्यादातर दिन “agents को drive” करने, outputs की समीक्षा करने, और काम को orchestrate करने में बिताते हैं; अब coding उनके समय का बड़ा हिस्सा है क्योंकि बाकी काम तेज़ हो गए हैं।
- दूसरे कहते हैं कि समस्या समझ में आने के बाद AI सिर्फ़ encoding को थोड़ा-बहुत तेज़ करता है, कुछ-कुछ smarter IDEs जैसा।
Code quality, review, and security
- AI-generated code पर कितना भरोसा किया जा सकता है, इस पर तीखी असहमति है।
- कुछ लोग चुनिंदा तौर पर सिर्फ़ “important” या security‑adjacent code की review करते हैं और बाकी के लिए tests या security scanners पर निर्भर रहते हैं।
- दूसरे इसे लापरवाही मानते हैं, खासकर user input या production data को छूने वाले endpoints के लिए; उन्हें “AI code bloat” और बहुत बड़े, मुश्किल से review होने वाले PRs दिखते हैं।
- चिंता है कि LLMs से आने वाली high volume के कारण thorough human review असंभव हो जाता है, जिससे teams ज़्यादा जोखिम वाले norms की ओर धकेली जाती हैं।
Productivity gains and metrics
- Lines of code को productivity का खराब metric माना जाता है, खासकर AI के लिए, हालांकि एक छोटा समूह curated projects में LoC को एक उपयोगी personal proxy मानता है।
- कई लोग बताते हैं कि AI productivity पर studies और surveys बहुत तेज़ी से outdated हो रहे हैं; early-2025 के काम का हवाला देना भ्रामक माना जाता है।
- कुछ लोग ज़ोर देते हैं कि productivity को system या outcome level पर मापा जाना चाहिए, code volume या token spend से नहीं।
Design, requirements, and meetings
- इस पर बहस है कि AI design cycles को छोटा करता है या लंबा:
- Pro: तेज़ research, auto-drafted design docs, और सस्ते prototypes, जिससे idea → test → refine loop कसा होता है।
- Con: यह “vibing” और gold-plated demos को बढ़ावा देता है जो finished लगते हैं लेकिन खराब या अनुपस्थित design को छिपाते हैं।
- कुछ लोगों का तर्क है कि अगर coding सस्ती हो जाती है, तो PRD का ज़्यादा हिस्सा meetings और documents की बजाय code/prototypes के ज़रिए किया जाएगा।
Organizational and career effects
- नेतृत्व के 10–100× productivity की उम्मीद करने और प्रति developer AI budgets इस्तेमाल करने की रिपोर्टें हैं; कई लोग इसे अवास्तविक या खतरनाक मानते हैं।
- असमान adoption के अवलोकन: कुछ engineers पूरी तरह “all in” हैं, जबकि दूसरे AI से बचते हैं या चुपचाप use करते हैं, कभी-कभी perceived competence penalties के कारण।
- कई लोग “code factories” में बँटने की संभावना देखते हैं जो AI-assisted slop पैदा करेंगी, और छोटे “artisanal” teams में जो critical systems बनाए रखेंगी।
Limitations, risks, and human factors
- hallucinations, गलत तरीके से संभाले गए edge cases, और जल्दी generated लेकिन कम समझे गए code से लंबे समय के tech debt को लेकर चिंताएँ।
- “cognitive surrender” की चिंता: AI पर इतना निर्भर हो जाना कि skill atrophy हो जाए और systems के बारे में reasoning करने की क्षमता खो जाए।
- कुछ developers बताते हैं कि जब उनके काम के बड़े हिस्से LLMs द्वारा generate होते हैं, खासकर side projects में, तो उन्हें कम खुशी और जुड़ाव महसूस होता है।