आप मैन्युअल रूप से Git कमांड टाइप करते हैं, इसलिए आप बेहतर इंजीनियर नहीं हैं
इंजीनियर Git commands, commit messages, और refactors जैसे “overhead” कार्य increasingly AI agents को सौंप रहे हैं, जिससे यह बहस छिड़ गई है कि क्या इससे उत्पादकता बढ़ती है या core skills और समझ कमज़ोर होती है। समर्थकों का तर्क है कि दोहराए जाने वाले यांत्रिक काम सौंपने से higher-level design, security, और systems thinking के लिए समय मिलता है, जबकि आलोचक चिंता जताते हैं कि code, version control, और documentation के लिए AI पर निर्भरता shallow comprehension, कमजोर collaboration, और unreadable histories की ओर ले जाती है। इस tooling बहस के नीचे एक व्यापक सवाल है: software engineering का कितना हिस्सा सुरक्षित रूप से abstract किया जा सकता है, उससे पहले कि developers mere button-pressers बन जाएँ, न कि वे लोग जो वास्तव में अपने systems को समझते और ठीक कर सकते हैं।
लेख के रुख पर समग्र प्रतिक्रिया
- कई लोगों को शीर्षक भड़काऊ या आदेशात्मक लगता है (“आप अपनी ज़िंदगी जला रहे हैं”), जो लोगों को AI की ओर आकर्षित करने के बजाय दूर धकेलता है।
- कई टिप्पणीकार बोरिंग, यांत्रिक कामों को AI को सौंपने से सहमत हैं, लेकिन जीवन-शैली सलाह वाले इस कट्टरपंथी फ्रेमिंग पर आपत्ति करते हैं।
- दूसरों को लगता है कि पोस्ट में “AI यह काम बेहतर करता है” जैसे दावों के लिए ठोस उदाहरण या सबूत नहीं हैं, और यह “मेरे X साल के अनुभव पर भरोसा करें” पर बहुत निर्भर है।
Git ऑपरेशनों और PR वर्कफ़्लो के लिए AI
- कुछ इंजीनियर Git का काम भारी मात्रा में एजेंट्स को सौंपते हैं (rebase, merge, branch cleanup, PR labeling, checklist updates), और इसे ज़्यादातर यांत्रिक ओवरहेड मानते हैं।
- दूसरे लोग trust/safety चिंताओं के कारण LLMs को सीधे Git execution से दूर रखते हैं, और उन्हें केवल सलाह या एक-बार के कमांड्स के लिए इस्तेमाल करते हैं।
- एक बार-बार आने वाला विचार: AI-चालित Git सुरक्षित और प्रभावी है अगर आप पहले से rebase, merge, और fast-forward जैसी अवधारणाएँ समझते हैं; अगर नहीं समझते, तो यह खतरनाक है।
Commit संदेश, टिप्पणियाँ, और संचार
- AI-लिखित commit messages और PR descriptions पर कड़ा विरोध:
- अक्सर बहुत लंबे, अप्रासंगिक, या वास्तविक intent को मिस कर देते हैं।
- Git history को खराब करते हैं, जिससे bisecting और code archaeology कठिन हो जाती है।
- प्रति-तर्क: LLMs सावधानी से prompt करने पर उत्कृष्ट summarizers हैं, और टीम भर में एक समान house style लागू करा सकते हैं।
- कई लोगों का तर्क है कि commits को मैन्युअल रूप से लिखना आपको बदलावों को समझने और उनकी ज़िम्मेदारी लेने के लिए मजबूर करता है, जिससे समग्र तकनीकी गुणवत्ता बेहतर होती है।
सोच को आउटसोर्स करना बनाम abstractions
- चिंता है कि AI को बहुत कुछ सौंपने से कौशल कमजोर हो जाते हैं और अपने ही कोड की समझ कम हो जाती है; “सोच को आउटसोर्स करना” बनाम “कठिन श्रम को टूल्स से हटाना।”
- दूसरे जवाब देते हैं कि abstractions एक संज्ञानात्मक आवश्यकता हैं; AI बस एक और abstraction layer है, जैसे उच्च-स्तरीय भाषाएँ या IDE refactors।
- सामान्य बीच का रास्ता:
- आपको कम से कम एक layer नीचे समझना चाहिए जहाँ आप काम करते हैं।
- अगर आप फिर भी diffs पढ़ते हैं, tests चलाते हैं, और judgment लागू करते हैं, तो AI grunt work के लिए ठीक है।
कौशल, उत्पादकता, और इंजीनियरिंग का भविष्य
- कुछ लोग बताते हैं कि AI-heavy workflows feature delivery को नाटकीय रूप से तेज नहीं करते, लेकिन design, security, और data modeling के लिए समय निकाल देते हैं, और bugs कम होते हैं।
- चिंता है कि अगर कोई भूमिका AI/IDE पर “next दबाने” तक सीमित हो जाती है, तो उसे आसानी से बदला या commoditized किया जा सकता है।
- low-level ज्ञान (git, CLI, Linux) को तब मूल्यवान माना जाता है जब चीज़ें टूटती हैं, हालांकि दूसरे अनुमान लगाते हैं कि मॉडल अंततः recovery tasks भी संभाल लेंगे।
मेटा-चर्चा: AI सामग्री और detection
- इस पर स्पष्ट झुंझलाहट कि हर लेख “AI slop” है, यह कहने की लगातार प्रवृत्ति और AI detectors पर अत्यधिक निर्भरता।
- सुझाया गया मानदंड: सामग्री का मूल्य और स्पष्टता के आधार पर मूल्यांकन करें, न कि इस आधार पर कि वह AI-assisted थी या नहीं।