समझ अब नई बाधा है
जैसे-जैसे AI coding assistants codebases में इंसानों की आरामदायक समीक्षा क्षमता से कहीं ज़्यादा बदलाव भर रहे हैं, कई engineers तर्क देते हैं कि software development में अब typing speed नहीं, बल्कि comprehension ही मुख्य बाधा है। Commenters rapid LLM-generated code और human ability के बीच बढ़ती खाई का वर्णन करते हैं—architectures को समझने, risks का आकलन करने, और long-term quality बनाए रखने में—साथ ही “vibe-coded” systems, tech debt, और brittle tooling को लेकर चिंता जताते हैं। सुझाए गए जवाबों में stricter specs, छोटे PRs, बेहतर testing, और ऐसे नए workflows व tools शामिल हैं जो AI का उपयोग code को सिर्फ लिखने के बजाय उसे explain, visualize, और interrogate करने में करें।
सॉफ़्टवेयर कार्य में समझ की भूमिका
- कई लोग तर्क देते हैं कि समझ हमेशा से बाधा रही है; LLMs बस इसे और स्पष्ट तथा बढ़ा देते हैं, क्योंकि वे बहुत अधिक कोड बहुत तेज़ी से बनाते हैं।
- कुछ अन्य लोगों के अनुसार बाधा का स्थान बदल गया है: अब हम कोड लिखते समय समझ बनाने के बजाय, कोड जनरेट होने के बाद समझ को “बैकलोड” करते हैं।
- कुछ लोग “X नई बाधा है” वाली रूपरेखा का विरोध करते हैं, यह कहते हुए कि कभी कोई एकल बाधा थी ही नहीं; उपयोगकर्ता मूल्य और अच्छे उत्पाद निर्णय अब भी मुख्य सीमाएँ हैं।
पढ़ना, स्वामित्व, और “कोड मत पढ़ो”
- कई डेवलपर सभी production commits को पढ़ने और समझने पर ज़ोर देते हैं; वे इसे गैर-परक्राम्य ज़िम्मेदारी मानते हैं।
- कुछ अन्य लोग स्वीकार करते हैं कि कम-जोखिम वाले CRUD काम के लिए वे बिना समीक्षा वाला “slop” ship करते हैं और लक्षित tests पर निर्भर रहते हैं।
- “कोड मत पढ़ो” वाला रुख गति के लिए आकर्षक माना जाता है, लेकिन लंबे समय में व्यापक रूप से खतरनाक समझा जाता है, खासकर जटिल या सुरक्षा-संबंधी प्रणालियों में।
कोड जनरेटर के रूप में LLMs: गुणवत्ता और ऋण
- सामान्य शिकायतें: verbose, ज़्यादा engineered diffs; दोहराई गई logic; स्पष्ट सरल समाधानों को चूकना; सूक्ष्म algorithmic गलतियाँ।
- कुछ लोग रिपोर्ट करते हैं कि codebases unreadable “vibe-coded” गड़बड़ियों में बदल रही हैं, जहाँ code को सुरक्षित रूप से छूने के लिए केवल LLMs ही बचते हैं।
- अन्य लोग नोट करते हैं कि यह pre-LLM “काम करता है लेकिन model तोड़ता है” समस्याओं का ही विस्तार है, बस अब यह अधिक गति के साथ हो रहा है।
PRs, Specs, और व्याख्याएँ
- Auto-generated PR descriptions अक्सर लंबी, यांत्रिक, और यह बताने में विफल होने के लिए आलोचित होती हैं कि परिवर्तन अस्तित्व में क्यों है।
- कुछ टीमें descriptions को छोटे “क्या + क्यों” सारांशों तक सफलतापूर्वक सीमित करती हैं, कभी-कभी LLM द्वारा लिखी गई लेकिन मानव-मान्य।
- एक बार-बार उभरने वाला विषय: intent का स्वामित्व मनुष्यों के पास होना चाहिए। SPEC.md / “spec-driven development” जैसे दृष्टिकोण पहले समझ को specs में रखने की कोशिश करते हैं, फिर agents को implement करने देते हैं।
Testing, Assurance, और Tooling
- एक वर्ग का तर्क है कि आप LLMs को contractors की तरह मान सकते हैं: code की अति-व्याख्या न करें, बस मजबूत tests और QA बनाइए।
- अन्य लोग practice के मौजूदा समूहों (unit tests, fuzzing, formal methods, static analysis) की ओर ध्यान दिलाते हैं और सुझाव देते हैं कि LLMs को code generate करने के अलावा वहाँ भी मदद करनी चाहिए।
- समझ के लिए प्रस्तावित सहायक उपकरणों में explain-diff tools, “grill-with-docs” workflows, time-travel debugging, और test coverage को behaviors के मानचित्र की तरह उपयोग करना शामिल है।
संगठनात्मक और सांस्कृतिक गतिशीलताएँ
- कई टिप्पणियाँ throughput, token usage, और visible AI adoption को maintainability से ऊपर optimize करने के दबाव का वर्णन करती हैं।
- “mass psychosis” को लेकर चिंता है: engineers और managers disengaged हैं, और AI-generated PRs को approve कर रहे हैं जिन्हें वे समझते नहीं।
- अन्य लोग emerging “agent management” को program/people management जैसा देखते हैं: काम को तोड़ना, expectations तय करना, और यह जानना कि कब भरोसा करना है बनाम बारीकियों में उतरना है।