- AI coding tools, code लिखने जैसे आसान काम को automate करते हुए, developers के लिए investigation, context समझना और verification जैसे मुश्किल काम ही छोड़ देते हैं — यह एक संरचनात्मक समस्या है
- developer का AI output को खुद समझे बिना यह कहना कि "AI ने मेरे लिए कर दिया", पुराने StackOverflow copy-paste जैसी ही एक ख़तरनाक चेतावनी है
- vibe coding prototyping के लिए उपयोगी है, लेकिन वास्तविक production environment में AI समय बचाने के बजाय उल्टा ज़्यादा खर्च करवा सकता है
- AI की मदद से एक बार जल्दी deploy कर देने पर वही नई baseline बन जाती है, जिससे लगातार sprint pressure और burnout की ओर ले जाने वाली management समस्या पैदा होती है
- मुख्य बात यह है कि AI को solution provider नहीं बल्कि investigation tool की तरह इस्तेमाल किया जाए, और हर code की ज़िम्मेदारी developer के पास ही बनी रहे
"AI ने मेरे लिए कर दिया" कहने की समस्या
- पहले developers StackOverflow answers, articles, और GitHub issues पढ़कर खुद context verify करने के बाद निष्कर्ष निकालते थे
- कोई यह नहीं कहता था कि "Google ने code लिख दिया" या "यह search में पहले नंबर पर था, इसलिए सही है"
- हाल के समय में "AI ने मेरे लिए कर दिया" जैसी अभिव्यक्ति सामने आने लगी है
- यह या तो वास्तव में हुई चीज़ को बढ़ा-चढ़ाकर बताती है, या इसका मतलब है कि developer ने खुद निष्कर्ष नहीं निकाला
- दोनों ही स्थिति समस्या हैं, और वही चिंता पैदा करती हैं जो StackOverflow से code copy-paste करने पर होती थी: क्या आपने paste किया हुआ code वास्तव में समझा है
vibe coding की सीमाएँ
- vibe coding शुरुआत में मज़ेदार लगता है, और prototyping या कम-जोखिम वाले personal projects में उपयोगी हो सकता है
- लेकिन वास्तविक काम में code की हर line का असर होता है
- एक personal project में AI agent से किसी खास file में tests जोड़ने को कहा गया, तो 500 lines की file 100 lines तक सिमट गई
- AI ने दावा किया कि उसने कोई और चीज़ delete नहीं की, फिर बाद में कहा कि वह file पहले से थी ही नहीं
- जब उसे git history दिखाई गई, तो उसने माफ़ी माँगी और माना कि पहले file के अस्तित्व की जाँच करनी चाहिए थी
- इस मामले में AI support ने समय बचाने के बजाय और ज़्यादा समय खर्च करवाया
- agent से बहस करने और file restore करने में, tests खुद लिखने से भी ज़्यादा समय लगा
- अगर यही बात healthcare codebase जैसे environment में हो, तो इसके गंभीर परिणाम हो सकते हैं
- AI को solution provider नहीं बल्कि investigation tool की तरह इस्तेमाल करना महत्वपूर्ण है, और AI कब ग़लत है इसे पहचानने के लिए अभ्यास चाहिए
मुश्किल हिस्सा और मुश्किल हो जाने की संरचना
- code लिखना developer के काम का मूलतः आसान हिस्सा था
- मुश्किल हिस्सा था investigation, context समझना, assumptions verify करना, और यह जानना कि कोई approach सही क्यों है
- जब आसान हिस्सा AI को दे दिया जाता है, तो काम कम नहीं होता, बल्कि सिर्फ मुश्किल काम बचता है
- अगर यह सोचकर investigation छोड़ दी जाए कि AI ने जवाब दे दिया है, तो AI output को evaluate करने का context ही नहीं बचता
- किसी दूसरे के code को पढ़ना और समझना, code लिखने से काफ़ी ज़्यादा मुश्किल काम है
- AI-generated code मूलतः किसी और का code ही है
- यानी developer अपना मज़बूत हिस्सा (लिखना) machine को दे देता है, और ज़्यादा मुश्किल हिस्सा (पढ़ना और review) अपने पास रखता है
- ऐसी स्थिति में review तो करना पड़ता है, लेकिन वह उस context के बिना जिसमें code खुद लिखते समय समझ बनती है
sprint expectations और burnout
- AI की मदद जैसी किसी वजह से अगर एक बार तेज़ी से deploy हो जाए, तो वही नई baseline बन जाती है और फिर हर बार उसी speed की अपेक्षा की जाती है
- बातचीत "तुमने यह कैसे किया?" से बदलकर "तुम हर बार ऐसा क्यों नहीं कर पाते?" में बदल जाती है
- यह engineering नहीं बल्कि management की समस्या है
- थका हुआ engineer edge cases मिस करता है, tests छोड़ देता है, और bugs release कर देता है
- ज़्यादा incidents → ज़्यादा pressure → ज़्यादा sprints का दुष्चक्र बनता है
- "AI 10x productivity देता है" जैसे दावों पर, हक़ीक़त में यह 0.1x engineer का 1x बन जाना भी हो सकता है
- तकनीकी रूप से 10x सही हो सकता है, लेकिन असली सवाल यह है कि यह productivity gain है या पहले कितनी कम investigation हो रही थी, उसका खुलासा
- burnout और low-quality code releases, AI की productivity gains को offset कर देते हैं
senior skills, junior trust
- AI coding agents की code लिखने की क्षमता senior-level हो सकती है, लेकिन उसके output पर भरोसा junior engineer-level के हिसाब से ही किया जाना चाहिए
- code अच्छा दिख सकता है और शायद काम भी करे, लेकिन अनुभव न होने की वजह से अधिक सावधानी से जाँचना ज़रूरी है
- एक तुलना के रूप में, AI coding agent ऐसा है जैसे बहुत तेज़ पढ़ने वाला कोई व्यक्ति अचानक team में शामिल हो गया हो
- वह investigation में मदद कर सकता है और code भी लिख सकता है, लेकिन पिछले हफ़्ते हुई वह महत्वपूर्ण meeting उसने attend नहीं की जिसमें background और context discuss हुआ था
code ownership का महत्व
- developer को सिर्फ अपने लिखे code का ही नहीं, बल्कि AI-generated code का भी ज़िम्मेदार ownership लेना चाहिए
- अगर अवास्तविक speed targets की वजह से AI output को copy-paste कर दिया जाता है, तो 6 महीने बाद जब कोई नया team member उस code को समझने की कोशिश करेगा या रात 2 बजे outage होगा, तब समस्या सामने आएगी
- "AI ने लिखा था" किसी भी स्थिति में मददगार जवाब नहीं है
AI मुश्किल हिस्से में कैसे मदद कर सकता है
- production bug का एक उदाहरण: बड़े release के तुरंत बाद user ने timezone display edge-case bug report किया
- ज़िम्मेदार developer को 30 मिनट बाद class के लिए जाना था, और बाकी लोग पहले ही काम से जा चुके थे
- AI का उपयोग करके investigation की गई; उसने बताया कि bug हाल के changes से जुड़ा है और reproduce करने का तरीका समझाया
- कारण यह था कि कुछ deprecated methods, मौजूदा timezone-aware methods से पहले apply हो रहे थे, इसलिए timezone conversion सही नहीं हो रही थी
- 15 मिनट के भीतर root cause, solution ideas, और investigation notes को GitHub issue में दर्ज कर दिया गया
- ज़िम्मेदार developer ने fix verify किया, और दूसरे team member ने testing और deployment पूरा किया
- बिना किसी emergency के, बिना overtime के समस्या हल हो गई
- इस उदाहरण का मुख्य बिंदु यह है कि AI investigation के दोहराए जाने वाले काम कर सकता है, जबकि इंसान context देता है और verification करता है
- AI का इस्तेमाल investigation, verification और context understanding को मज़बूत करने के लिए होना चाहिए; नहीं तो आसान काम और आसान, मुश्किल काम और मुश्किल होने वाली संरचना और मज़बूत हो जाएगी
अभी कोई टिप्पणी नहीं है.