- 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 को मज़बूत करने के लिए होना चाहिए; नहीं तो आसान काम और आसान, मुश्किल काम और मुश्किल होने वाली संरचना और मज़बूत हो जाएगी
3 टिप्पणियां
> AI डेवलपमेंट को मुश्किल नहीं बनाता
> बल्कि यह उन सचमुच मुश्किल हिस्सों को सामने लाता है जिन्हें लोग अब तक नज़रअंदाज़ करते आए थे
> पिछले 15 वर्षों से डेवलपर्स पहले से ही “vibe coding का human version” कर रहे थे — Stack Overflow से copy-paste करना, बिना योजना के refactor करना, और “बस मेरे laptop पर चलना चाहिए” वाली सोच के साथ काम करना
> अब जब AI वही कर रहा है, तो अचानक सभी लोग योजना बनाने और tests लिखने की कोशिश कर रहे हैं
> अगर रफ्तार धीमी भी पड़े, लेकिन quality बेहतर होती है, तो वही असली प्रगति है
मेरे हिसाब से, जो डेवलपर पहले सिर्फ copy-paste करते थे, वे LLM इस्तेमाल करके भी copy-paste ही करते हैं
और जो डेवलपर पहले से quality पर बहुत ध्यान देते थे, लगता है अब वे और भी ज़्यादा ध्यान दे रहे हैं
Hacker News की राय
AI सहायक टूल्स के साथ कोडिंग करना, पारंपरिक human-centered coding से पूरी तरह अलग एक नई skill है
हमारे पास जो language, framework, और development principles हैं, वे इंसानी सीमाओं को पार करने के लिए बने थे, लेकिन AI की सीमाएँ अलग हैं
जटिल समस्याएँ हल करते समय सिर्फ prompt देकर result लेना काफी नहीं था; संवाद और iterative design के ज़रिए problem space को explore करना उपयोगी था
AI की गलतियाँ या hallucination उल्टा इस बात का संकेत बनती हैं कि मैं समस्या को सही से समझ रहा हूँ या नहीं
मैंने vibe coding तरीके से retro emulator और assembler बनाकर देखे, और कम prompt में भी अच्छे नतीजे मिले
लेकिन जब मैंने पहले बनाए गए एक खास industrial app के proprietary हिस्से पर कोशिश की, तो कितने भी prompt दूँ, नतीजा बहुत खराब था
GitHub पर हज़ारों emulator examples हैं, लेकिन जो मैं करना चाहता था उसके कोई examples ही नहीं थे
निष्कर्ष सरल है — कुछ चीज़ें आसान हैं, और कुछ बिल्कुल नहीं होतीं
अगर GitHub पर बहुत examples हैं, तो वे LLM के latent space में भी होते हैं, इसलिए उन्हें कभी भी निकाला जा सकता है
तुमने जो कोशिश की, उसमें बस ऐसे examples नहीं थे
industry-specific framework को vibe coding से संभालना मुश्किल है, लेकिन समस्या को सरल बनाने पर AI कहीं तेज़ी से मदद करता है
vibe coding को पूरी तरह अपना लिया जाए तो शानदार नतीजे निकल सकते हैं, लेकिन technical debt इतना बढ़ जाता है कि आखिर में मशीन का गुलाम बनने जैसा लगता है
अगर AI हज़ारों lines का code लिख दे, तो उसकी structure को समझना या review करना बहुत मुश्किल हो जाता है
आखिरकार disposable code और software बढ़ेंगे — किसी खास समस्या को हल करने वाले apps बनाना आसान होगा, लेकिन sustainable SaaS के लिए बड़ा जोखिम रहेगा
AI एक force multiplier देने वाला tool है
अगर codebase की नींव खराब है, तो AI भी उसी style को ज्यों का त्यों copy करता है
उल्टा अगर clean और consistent foundation हो, तो AI उस quality को बनाए रखते हुए हैरान करने लायक अच्छा काम करता है
आखिर में कुंजी foundation ही है
ज़्यादातर codebase maintain करना मुश्किल और expand करना कठिन होता है, इसलिए AI बस उस समस्या को और उजागर करता है
architecture की तरह, अगर नींव कमज़ोर हो तो कितना भी अच्छा tool हो, उसकी सीमा रहती है
इससे बाद में आने वाले developers भी project का context पूरी तरह समझ सके
आखिरकार AI से सही काम करवाने के लिए पहले core abstraction को ठीक करना पड़ता है
requirements बदलती रहती हैं, और efficiency के लिए compromises होते हैं
आखिर में समय और opportunity cost quality से ऊपर आ जाते हैं — क्योंकि इंसान योजना पर पूरी तरह नहीं टिक पाता
AI झंझट वाले हिस्सों को कम झंझट वाला बना देता है
लेकिन LLM से बहस करना समय की बर्बादी है
छोटे units में बदलाव करो, ठीक चले तो commit करो, नहीं चले तो फेंककर फिर कोशिश करो — यही ज़्यादा प्रभावी है
AI सर्वशक्तिमान नहीं है, और सही tool चुनना महत्वपूर्ण है
अगर बंदूक पकड़े बच्चे के साथ खेलना है, तो bulletproof jacket पहननी चाहिए
अक्सर कहा जाता है कि “दूसरों का code पढ़ना, लिखने से ज़्यादा कठिन है”, लेकिन मुझे यह अजीब लगता है
कोई function जिसे खुद लिखने में आधा दिन लगे, उसे पढ़कर review करने में 10~15 मिनट काफी होते हैं
सही code को verify करना, उसे बनाने से कहीं आसान है
सिर्फ पढ़ना आसान है, लेकिन structure समझकर improvement points ढूँढने वाली editing कहीं ज़्यादा मेहनत माँगती है
क्योंकि लिखते समय का context गायब हो जाता है
असल में पढ़ना कठिन होने से ज़्यादा बात यह है कि लोग नया लिखना ज़्यादा पसंद करते हैं
सही mindset यह है कि “AI सब कुछ आसान बना देता है, लेकिन वह खुद एक नई skill है और उसे सीखना कठिन है”
अभी AI का दौर ENIAC era जैसा है, जहाँ high-level languages या operating system जैसी अवधारणाएँ अभी मौजूद नहीं हैं
आगे चलकर context engineering नाम की एक discipline उभरेगी, और आज का तरीका बहुत primitive लगेगा
अगर structure ठीक से बनाई जाए, तो AI की क्षमता लगभग असीम लगती है
“AI से किया” का मतलब असल में “किसी बाहरी कंपनी के CPU resources का बड़े पैमाने पर इस्तेमाल किया” है
जब तक मेरे पास पूरी तरह मेरी मालिकाना AI agent नहीं आ जाती, मुझे यह सच्ची प्रगति से ज़्यादा planet-scale resource theft के क़रीब लगता है
AI development को कठिन नहीं बनाता
बल्कि यह उन वास्तव में कठिन हिस्सों को सामने लाता है जिन्हें लोग अब तक नज़रअंदाज़ करते आए थे
पिछले 15 सालों से developers पहले ही “human version of vibe coding” कर रहे थे — Stack Overflow से copy-paste करना, बिना योजना refactor करना, और “मेरे laptop पर चलता है तो ठीक है” वाले तरीके से काम करना
अब जब AI वही कर रहा है, तो अचानक सब planning करने और tests लिखने लगे हैं
अगर चीज़ें धीमी हों लेकिन quality बेहतर हो, तो वही असली प्रगति है
अभी की ‘marathon के भीतर sprint’ वाली culture AI की वजह से और तेज़ हो रही है
लेकिन AI को बिना supervision इस्तेमाल किया जाए, तो वह जल्दी भटक जाता है, और किसी और के लिखे code को पढ़ना अपने code को ठीक करने से कहीं ज़्यादा थकाऊ होता है
मैंने AI से कहा, “इस file में tests जोड़ो”, तो 500-line की file 100 lines की रह गई
कारण पूछा तो उसने जवाब दिया, “असल file थी ही नहीं”
जब मैंने git history दिखाई, तो उसने माफ़ी माँगी और कहा, “मुझे पहले यह जांचना चाहिए था कि वह मौजूद है या नहीं”
कल मैंने कहा, “उस file को भूल जाओ”, तो उसने सचमुच file delete कर दी
थोड़ा-बहुत rollback cost AI की value के मुकाबले स्वीकार करने लायक है