मुझे खेद है, लेकिन आपको अभी भी सोचना होगा
AI code generators मौजूदा applications को भाषाओं के बीच तेजी से पोर्ट करने में मदद कर रहे हैं, लेकिन engineers का कहना है कि hands-off rewrites अक्सर सूक्ष्म bugs, degraded performance और महत्वपूर्ण design trade-offs के नुकसान को जन्म देते हैं। कई लोगों का तर्क है कि आपको फिर भी systems को समझना, requirements को स्पष्ट करना, और code को सावधानी से review करना होता है; वरना “workslop” effort को authors से reviewers की ओर खिसका देता है और दीर्घकालिक reliability व maintainability को जोखिम में डालता है। दूसरों के लिए यह एक व्यापक प्रवृत्ति का हिस्सा है: हर जगह AI इस्तेमाल करने का प्रबंधन दबाव, verification bottlenecks का बढ़ना, और यह अनिश्चितता कि क्या रोज़मर्रा के software काम में सावधानी से सोचना मूल्यवान बना रहेगा।
AI पोर्ट्स और “हैंड्स-ऑफ” री-राइट्स की सीमाएँ
- बहुतों ने उम्मीद की थी कि LLM-आधारित पोर्टिंग (जैसे, Ruby → Rust/Elixir) एक आदर्श उपयोग-क्षेत्र होगा: टेस्ट + मौजूदा इम्प्लीमेंटेशन + स्पष्ट लक्ष्य।
- व्यवहार में, पोर्ट्स में अर्थगत बहाव, आर्किटेक्चरल असंगतियाँ, प्रदर्शन में गिरावट, और टूटे हुए अनुमान दिखे (जैसे, caching बनाम CSRF, type systems, concurrency)।
- टिप्पणीकारों का तर्क है कि यह पुष्टि करता है कि अभी भी domain, trade-offs, और target-language idioms की मानवीय समझ चाहिए, न कि सिर्फ अंधा अनुवाद।
सोचना, trade-offs, और सिस्टम विश्वसनीयता
- कई लोगों ने जोर दिया कि असली काम trade-offs करना है: compatibility बनाम speed, latency बनाम throughput, memory limits, स्वीकार्य failure modes।
- AI निर्णय लागू करने में मदद कर सकता है, लेकिन (अभी तक) उन निर्णयों का स्वामी नहीं हो सकता; अस्पष्ट prompts मनमाने विकल्पों की ओर ले जाते हैं।
- कुछ का तर्क है कि frontier models अब clarifying questions पूछते हैं और पुराने व्यवहार पर आधारित आलोचना अब outdated है; अन्य इससे असहमत हैं।
कोड की गुणवत्ता, “workslop,” और review बोझ
- सस्ती generation और महंगी verification एक बार-बार सामने आने वाला विषय है।
- reviewers बहुत बड़े LLM-generated changesets का वर्णन करते हैं जो brittle, shallow, या mis-architected होते हैं, जिससे thinking authors से reviewers की ओर खिसक जाती है।
- Brandolini’s law का उल्लेख किया गया: slop पैदा करना उसे खारिज या सुधारने की तुलना में कहीं आसान है, खासकर “हर चीज़ के लिए AI इस्तेमाल करो” के प्रबंधन दबाव के तहत।
संगठनात्मक प्रोत्साहन और नैतिकता
- कुछ कार्यस्थलों में reported रूप से manual coding या AI पर skepticism को stigmatize किया जाता है, भले ही AI output गलत हो।
- चिंता है कि व्यवसाय लागत कम होने पर खराब software को तर्कसंगत रूप से स्वीकार कर सकते हैं, और quality के बजाय stickiness, lock-in, या lobbying पर निर्भर रह सकते हैं।
AI का अच्छा उपयोग कैसे करें
- सुझाए गए पैटर्न:
- boilerplate, मजबूत tests वाले ports, और साधारण glue के लिए AI का भारी उपयोग करें।
- architecture, non-functional requirements, और test design पर humans को नियंत्रण में रखें।
- समझ बनाए रखने के लिए AI-सुझाए गए changes को manually type करें या step through करें।
- AI-heavy बनाम AI-light projects (stability, bugs, performance) पर empirical studies में रुचि है।
व्यापक भविष्य: thinking, UBI, और hacker culture
- इस पर बहस है कि क्या AI + संभावित UBI अधिक लोगों को सोचने के लिए मुक्त करेगा, या capital इसे दबा देगा।
- कुछ लोग मानते हैं कि “hacker culture” और human inventors अप्रासंगिक हो जाएंगे; अन्य जोर देते हैं कि AI अभी भी गहरी engineering judgment की जगह लेने से बहुत दूर है.