- प्रोसेस optimization के प्रवाह में AI को लेकर अवास्तविक अपेक्षाएँ फैल रही हैं, लेकिन केवल AI अपनाने भर से प्रोसेसिंग की गति बेहतर नहीं होती
- software development में ज़्यादा समय लगने की असली वजह coding की गति नहीं, बल्कि अस्पष्ट requirements को स्पष्ट problem definition में बदलने की प्रक्रिया है
- AI code generation भी इसी upstream problem का सामना करता है, और सही नतीजों के लिए domain और product experts की गहरी भागीदारी अनिवार्य है
- AI उपयोग की तुलना वाले उदाहरणों में अक्सर छूट जाने वाली handholding प्रक्रिया ही वास्तविक productivity gap बनाती है, और अगर human developers को भी वही विस्तृत दस्तावेज़ मिलें तो उनकी productivity भी तेज़ी से बढ़ती है
- वास्तविक process acceleration के लिए The Goal की सीख के अनुसार "bottleneck को predictable और high-quality inputs देना" पहली प्राथमिकता होनी चाहिए
बाज़ार मंदी के बीच process optimization और AI अपेक्षाएँ
- जब बाज़ार मंदी में होता है, तब अधिकांश संगठन कम से कम आंशिक रूप से process optimization पर ध्यान देने लगते हैं; हाल के समय में इसमें AI का तत्व और अवास्तविक अपेक्षाएँ भी जुड़ गई हैं
- The Toyota Way और The Goal यह याद दिलाती हैं कि कई process optimizations में यह गलतफहमी हो जाती है कि ध्यान किस पर होना चाहिए
- जो हिस्सा सबसे ज़्यादा समय लेता है, वह सुधार शुरू करने का संकेत हो सकता है, लेकिन यह मान लेना सही नहीं कि समस्या वास्तव में वहीं पैदा हो रही है
- अगर बस अधिक लोगों को लगा दिया जाए या यह उम्मीद की जाए कि AI गति को बहुत बढ़ा देगा, तो असली वजह नज़र नहीं आती कि काम धीमा क्यों है
- process को तेज़ करने के लिए पहले यह देखना चाहिए कि काम करने वालों के पास वास्तव में काम शुरू और खत्म करने के लिए ज़रूरी inputs और conditions हैं या नहीं
दृश्य bottleneck (The visual bottleneck)
- Gantt chart के उदाहरण से यह दृश्य रूप में देखा जा सकता है कि सबसे ज़्यादा समय लेने वाला चरण software development है
- सामान्यतः BPMN का उपयोग किया जाता है, लेकिन समझाने को आसान बनाने के लिए यहाँ Gantt chart दिया गया है
- अगर लक्ष्य project throughput सुधारना है, तो सबसे लंबे चरण को पहले देखना अपने-आप में सही तरीका है
- समस्या इस बात में है कि लोग इसे हल कैसे करते हैं
- समस्या पर और लोग झोंक देना (throw people at the problem)
- यह मान लेना कि AI इसे बहुत तेज़ बना देगा
- लेकिन वे "यह चरण इतना लंबा क्यों है" इस पर ध्यान नहीं देते; और उससे भी महत्वपूर्ण यह है कि अधिक समय लगने का मतलब यह नहीं कि समस्या की जड़ उसी चरण में हो
upstream में समस्या हल करना
- यहाँ software development का उदाहरण लिया गया है, लेकिन यह बात उन सभी प्रक्रियाओं पर समान रूप से लागू होती है जो अपेक्षा से अधिक समय लेती हैं
- software development सिर्फ typing speed बढ़ाने से तेज़ नहीं होता; अगर ऐसा होता, तो सब लोग typing classes ले रहे होते
- software development का मूल काम समस्या को ऐसे solution में अनुवाद करना है जिसे computer अपने-आप हल कर सके, और वह भी जहाँ तक संभव हो सुरक्षित और scalable तरीके से
- इसके लिए समस्या की समग्र समझ ज़रूरी है
- अगर तरीका waterfall के क़रीब है, तो feature document या scope document चाहिए
- अगर तरीका agile है, तो domain expert के साथ लगातार iteration चाहिए
- वास्तव में development को धीमा करने वाली चीज़ यह प्रक्रिया है कि सिर्फ शीर्षक वाले अस्पष्ट feature request का असली मतलब क्या है, इसे समझा जाए
- "sale पूरा होने पर user को mail भेजें (send mail to user once sale is completed)" जैसी request भी तुरंत implement की जा सकने वाली requirement नहीं है
- mail भेजी जा सकती है, लेकिन mail में क्या होना चाहिए
- अगर sale process में कोई समस्या हुई हो, तो क्या error mail भेजनी चाहिए
- sale किस बिंदु पर "completed" मानी जाएगी
यह दावा कि सब कुछ AI को सौंपा जा सकता है
- अक्सर यह दावा सुनने को मिलता है कि AI code generation से development चरण को बायपास किया जा सकता है, और software developer सिर्फ project manager की भूमिका निभा सकता है
- बहुत से लोग उम्मीद करते हैं कि software development का मौजूदा लंबा चरण घटकर लगभग 3 दिन के AI development चरण में बदल जाएगा
- लोगों के मन में AI development के नतीजे की एक कल्पना होती है, लेकिन व्यवहार में यह ऐसे काम नहीं करता; यह भी वही upstream issues झेलता है
- यह सही है कि AI तेज़ी से code generate कर सकता है (यह अच्छी बात है या नहीं, यह अलग बहस है), लेकिन तेज़ generation का मतलब सही code generation नहीं होता
- human vs AI development की तुलना में हमेशा नज़रअंदाज़ की जाने वाली चीज़ है AI को सही ढंग से काम कराने के लिए ज़रूरी handholding प्रक्रिया
- यह तरीका पारंपरिक तरीके से तेज़ हो सकता है, लेकिन यह निष्पक्ष तुलना नहीं है
- AI development को काम करने लायक बनाने के लिए domain experts और product experts की कहीं अधिक गहरी भागीदारी चाहिए
- हर feature को बहुत छोटे-छोटे विवरण तक लिखना पड़ता है
- हर bug fix के लिए भी यह विस्तार से बताना पड़ता है कि वांछित परिणाम क्या है
- यही वह चीज़ है जिसकी माँग software developers अपने पेशे की शुरुआत से करते आए हैं, यानी समस्या और अंतिम परिणाम का विस्तृत overview
- अगर human developers को भी इसी स्तर के feature/scope documents दिए जाएँ, तो उनकी productivity भी नाटकीय रूप से बढ़ जाएगी
वास्तव में process speed कैसे बढ़ाई जाए
- process speed बढ़ानी हो, तो यह सुनिश्चित करना होगा कि जिन लोगों को काम करना है, उनके पास वास्तव में वह काम करने के लिए सभी साधन मौजूद हों
- अगर legal approval process धीमी है, तो पहले यह देखना चाहिए कि legal approval process शुरू करने के लिए क्या-क्या चाहिए
- अगर अधूरे दस्तावेज़ों की वजह से पाँच लोगों के पीछे भागना पड़ता है, तो विभाग में और lawyers जोड़ देने से गति नहीं बढ़ेगी
- The Goal की एक बड़ी सीख यह है कि bottleneck को predictable और high-quality inputs मिलनी चाहिए
- "bottlenecks should receive predictable, high-quality inputs"
- process automation का पहला शुरुआती बिंदु bottleneck section खुद नहीं, बल्कि bottleneck तक पहुँचने वाले input quality और predictability को बेहतर बनाना होना चाहिए
1 टिप्पणियां
Hacker News की राय
लोग कहते हैं कि software development शुरू से यही चाहता था कि “समस्या और इच्छित परिणाम का विस्तार से वर्णन मिल जाए”, लेकिन असल में वही खुद software engineering है
2026 में भी यह उम्मीद छोड़ देनी चाहिए कि सिर्फ पर्याप्त रूप से विस्तृत requirements और specs मिल जाने पर एक ही बार में परफेक्ट समाधान बनाया जा सकता है
मेरे अनुभव में AI की वजह से features या ideas पर बहुत तेज़ी से iterate करना संभव हुआ है, और अब friction ज़्यादातर दूसरी teams के साथ alignment और coordination में पैदा होती है
process को तेज़ करना है तो coordination cost कम करनी होगी और individuals व teams को निर्णय लेने और उसे लागू करने का ज़्यादा अधिकार देना होगा
Anthropic के पास परफेक्ट spec, reference implementation, और इंसानों द्वारा कई सालों में लिखे गए हज़ारों tests थे, फिर भी वह C compiler जैसी साधारण चीज़ भी नहीं बना पाया
मौजूदा models, परफेक्ट specs और परफेक्ट tests होने पर भी, किसी सावधान इंसानी निगरानी के बिना कोई गैर-तुच्छ production software बनाने के लिए पर्याप्त नहीं हैं
अगर परफेक्ट specs और इंसानों द्वारा लिखे गए परफेक्ट test suite भी न हों, तो काम और कठिन हो जाता है, और शायद 2027 तक संभव हो पाए
मुझे अक्सर दोपहर में product person द्वारा सोचा गया काम मिलता है, और वे सिर्फ happy path की परवाह करते हैं, कभी-कभी तो उसके भी सिर्फ एक हिस्से की
हम एक global company हैं, इसलिए हर देश के नियम और क़ानून मानने पड़ते हैं, लेकिन feature implement करने के बाद पता चलता है कि “असल में जिन markets में हम काम करते हैं, उनमें से 90% में इसे क़ानूनी रूप से किया ही नहीं जा सकता”, और फिर हमें disable functionality जोड़नी पड़ती है
उसके बाद वे लौटकर कहते हैं, “उनमें से कुछ markets में regulatory process से गुज़रकर यह संभव है, तो उसे उसी तरह implement कर दीजिए”
deadline सिर पर होती है, इसलिए आख़िर में समाधान को hacky तरीके से बदलना पड़ता है
यह software engineering नहीं है, और इसका software से भी कोई लेना-देना नहीं है
software engineer का काम requirements की सूची लेकर उन्हें पूरा करने का तरीका निकालना है, और requirements gathering software engineering की समस्या नहीं है
software implementation है, product behavior है, और जो बनाना है उसका behavior गंभीरता से बनाना शुरू करने से पहले पता होना चाहिए
अगर किसी ने सिर्फ एक हफ़्ता टालकर due diligence कर ली होती, तो scalable, आसानी से extend होने वाली, आसानी से maintain होने वाली, और भविष्य को आसान बनाने वाली architecture design की जा सकती थी
मुझे पहला program लिखे 40 साल से ज़्यादा हो गए, लेकिन मैंने कभी ऐसा नहीं देखा कि पहले spec पूरी कर ली जाए, फिर software लिखा जाए, और सब कुछ अच्छी तरह चल जाए
किसी भी गैर-तुच्छ engineering में सबसे कठिन हिस्सा समस्या को समझना होता है, और software के शुरुआती versions उसी समझ तक पहुँचने का माध्यम होते हैं
इसलिए मुझे नहीं लगता कि AI-आधारित “software factory” कभी सच में अच्छी तरह काम करेगी
आख़िर में हम फिर waterfall development पर लौट आते हैं, जहाँ architect UML diagrams बनाता है और programmers की टीम को मूलतः सरल implementation work सौंपता है, लेकिन वे अंततः गलत चीज़ implement कर देते हैं
AI पहली ग़लत version से कम ग़लत दूसरी version तक जल्दी पहुँचाने में बहुत अच्छा है
बस यह नहीं भूलना चाहिए कि मुख्य काम उस समस्या को समझना है जिसे हल करना है
अगर मुझे सिर्फ detailed specs ही मिलने हैं, तो मैं बस एक coding robot हूँ, और ऐसा काम junior को दे दिया जाता है
पहले की तरह मेरा काम उन requirements को पढ़ना, समझना, और जिस वास्तविकता को मैं जानता हूँ उसके आधार पर verify करना है
code के साथ भी यही बात है
पिछले कम-से-कम 20 सालों से software engineering का मूल सिद्धांत किसी पर भरोसा मत करो रहा है, और यह बदला नहीं है; इसमें अब भी बहुत समय और मेहनत लगती है
जब LLM पहली बार आए थे, तब लोगों को लगता था कि बस “Facebook clone बना दो” जैसा कुछ कह देना काफ़ी है
अब लोगों को समझ आ रहा है कि requirements को ज़्यादा सटीक और बेहतर तरह से define करना पड़ता है
यही हमेशा software का bottleneck रहा है
पहले नौकरी में मुझे सचमुच “data लाओ और user को दे दो” जैसी requirements मिलती थीं
कौन-सा data, कहाँ store है, किस format में return करना है—इनमें से कुछ भी define नहीं होता था, इसलिए product person के साथ लंबा समय लगाकर यह समझना पड़ता था कि वे सच में क्या चाहते हैं
LLM से अच्छा result पाने के लिए भी यही करना पड़ता है, और अस्पष्ट requirements अस्पष्ट results देती हैं
वे template भरते हैं कि कौन-सी समस्या क्यों है, जैसे backend में X field है लेकिन frontend में नहीं, data कहाँ से और कैसे लाना है, और acceptance criteria क्या हैं
पहले वे आलस या “developer खुद समझ जाएगा” वाली सोच के कारण ऐसा नहीं करते थे
उसके बाद developer इस Jira ticket की सामग्री को अपनी पसंद के LLM agent में copy-paste कर सकता है, या Atlassian MCP के ज़रिए LLM उसे अपने-आप पढ़ सकता है
इससे developers को बहुत मदद मिली है और requirements भी बहुत साफ़ हो गई हैं
सच कहूँ तो सिर्फ पहले step को देखकर लगता है कि PMs पहले ही feature implementation के आधे रास्ते तक पहुँच चुके हैं, इसलिए भविष्य में शायद PMs ज़्यादातर काम खुद करने लगें और कुछ developers पूरी implementation करने वालों की जगह SDET जैसे बनकर रह जाएँ
वहाँ vibe coding की मुख्य विशेषताएँ और आज जो अनुभव हम कर रहे हैं, उनका काफ़ी सटीक वर्णन है
बात यह है कि कुछ सावधानी से चुने गए domains में शुरुआती सफलता मिलती है, लेकिन उन domains के बाहर फैलने पर उत्पादकता में तर्कसंगत, पर क्रांतिकारी नहीं, वृद्धि दिखती है
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
मैंने कभी “Facebook clone बना दो” जैसे prompt नहीं लिखे; उसकी जगह मैंने बताया कि चीज़ कैसे काम करनी चाहिए
उदाहरण के लिए, मैंने एक Python script माँगी जो
/etc/hostsपढ़े,.confमें configured किसी खास host value को ढूँढे, हर configuration को नाम दे, current environment को पहचाने, Ubuntu 22 के default GNOME में ऊपर दाईं ओर icon बनाए, उस पर click करने पर configuration names की सूची दिखाए, और किसी option के चुने जाने पर/etc/hostsका backup लेकर सिर्फ specific hostname line बदलेइससे लगभग एक ही बार में एक simple GNOME app indicator environment switcher बन गया, और बस कुछ lines ठीक करनी पड़ीं तो ज़्यादातर काम करने लगा
अगर LLM को सही spec दी जाए तो वह अच्छा बनाता है, और आप चाहें तो अपनी ज़रूरत समझाने के लिए कोई नकली DSL भी बना लें, वह फिर भी समझ लेता है
पहले process के विफल होने की वजह यह थी कि requirements लिखने वाला business intent को समझ नहीं पाता था या लापरवाह था, इसलिए अस्पष्ट या खराब requirements निकलती थीं
LLM वही अस्पष्ट या खराब requirements लेकर उन्हें बस विश्वसनीय दिखने वाला बना देता है, लेकिन थोड़ा गहराई में जाएँ तो समस्या दिख जाती है
“‘data लाना’ से आपका क्या मतलब है?” जैसे सवाल आते हैं
LLM बस कहता है, “ज़रूर! data लाकर user को देने वाला complete code यह रहा,” और बात ख़त्म
यह लेख मानता है कि AI सिर्फ development phase को प्रभावित करता है, लेकिन यह निश्चित रूप से सही नहीं है
idea generation, legal, documentation, development, और deployment सहित सभी phases की रफ़्तार बढ़ाई जा सकती है
idea generation में ideas को उछाला-पलटा जा सकता है, knowledge base से मिलान किया जा सकता है, और design docs बनाए जा सकते हैं; documentation में दस्तावेज़ों का बड़ा हिस्सा generate किया जा सकता है
development तो है ही, और deployment में deployment manifests, testing tools, और cloud platform से जुड़ा ज्ञान तैयार किया जा सकता है
हर phase AI से बेहतर और तेज़ हो सकता है; सब कुछ नहीं तो बहुत कुछ ज़रूर
development में भी समस्या को सबसे बेहतर समझने और समाधान बनाने वाला हिस्सा है, लेकिन कुछ हिस्से बस pure grunt work होते हैं
अगर आपको पता है कि button को X करना है, तो उस button को design करना, place करना, hover और press states की edge cases सोचना, और backend से wire करना ऐसा grunt work है जिसे छोड़ा जा सकता है; और यही सिद्धांत लगभग हर चरण पर लागू होता है
जब भी कोई नया महत्वपूर्ण feature जोड़ना होता है, तो आमतौर पर business stakeholders के साथ कई दिन, हफ़्ते, या महीनों तक meetings करनी पड़ती हैं ताकि यह समझा जा सके कि system X, Y, Z के बीच काम कैसे flow करता है और कौन-सी exceptions महत्वपूर्ण हैं
जैसे subset A को ऐसे handle करना है, B को वैसे, लेकिन आख़िरी stage में दोनों groups को merge करना है, सिवाय C के जिसे special process 97 चाहिए
उस समझ के आधार पर कई systems में फैला हुआ system solution design आता है, जिसमें internal systems और vendor systems का मिश्रण होता है, और हर system की customization सीमा अलग होती है, जो final solution के आकार को कई दिशाओं में धकेलती है
coding speed बढ़ाने में निश्चित रूप से value है, लेकिन वह puzzle का सिर्फ एक टुकड़ा है, और मौजूदा LLM domain knowledge इकट्ठा करने और solution define करने में मदद नहीं कर पाते
एक और बात है: अब ज़्यादा roles वाले लोग भी उन समस्याओं के लिए software tools बना सकते हैं जिन्हें पहले physical procedures के ज़रिए मेहनत से धकेलकर हल किया जाता था
हम एक छोटे manufacturer हैं, इसलिए यह गहरे software engineering अनुभव माँगने वाले विशाल enterprise projects जैसी स्थिति नहीं है, लेकिन simple software tools जगह-जगह process और productivity सुधार रहे हैं
जब shipping manager उन समस्याओं को custom tools से हल कर पाता है जिन्हें पहले बहुत सारे labor hours जला कर संभालना पड़ता था, तो वाकई हैरतअंगेज़ चीज़ें होती हैं
हम software development में AI का काफ़ी इस्तेमाल करते हैं, लेकिन हम तेज़ी से ship नहीं कर रहे; बल्कि लगता है कि लगभग उतने ही या किसी और कारण से और धीमे हो गए हैं
एक अजीब-सा एहसास है कि जैसे किसी utopia का इंतज़ार हो रहा हो, लेकिन वह आता नहीं, और ठीक-ठीक समस्या कहाँ है यह बताना भी मुश्किल है
बल्कि ऐसी असहमति और अविश्वास ही market में opportunities और breakout points बनाते हैं
अगर किसी project के participants का औसत IQ 140 है, तो IQ 150 वाला AI pipeline के हर individual की नकल कर सकता है
जो लोग कहते हैं AI यह नहीं कर सकता, वह नहीं कर सकता, उन्हें यह स्वीकार करना चाहिए कि यह IQ gap लगातार बढ़ रहा है
एक तरफ़, यह लेख बड़ी organizations में technical work करने वाले बहुत-से लोगों की सोच और ground reality को साफ़-सुथरे ढंग से बयान करता है
मैं लेखक से 110% सहमत हूँ, और चाहता हूँ कि दूसरे लोग भी इस लेख की बात समझें
दूसरी तरफ़, HN पर भी और असल नौकरी में भी, मुझे लगता है कि हाल में ऐसी बातें दर्जनों बार हो चुकी हैं
leaders के पास AI सचमुच speed बढ़ाएगा ऐसा दिखावा करने के सामाजिक और वित्तीय incentives हैं, इसलिए वे किसी एक blog post से convinced नहीं होंगे
इसलिए अब बस यही किया जा सकता है कि उनके AI projects fail हों या पुराने projects की तरह ही slow चलें, और उम्मीद की जाए कि वे कुछ सीखें
company में ऐसे लेख share करने में भी हिचक होती है, क्योंकि लगता है कि status quo से न मेल खाने वाली बातों को अच्छी तरह नहीं लिया जाता
मेरे हिसाब से visuals और Gantt charts ठीक वही PM वाली भाषा हैं जिसे PMs समझ सकते हैं
जब तक C-level और investors innovation signaling करते रहेंगे, तब तक यह तुरंत नहीं सुलझेगा, लेकिन ऐसी चीज़ें हमेशा नहीं चल सकतीं
इसलिए इन दिनों मैं बागवानी कर रहा हूँ और agentic tools के साथ personal coding projects पर अटका हुआ समय बिता रहा हूँ
जैसे शुरुआत से high-performance OLTP database बनाना, नया logical relational persistent programming environment बनाना, और अजीब math-based synthesizer तथा FPGA soft processor बनाना
आम लोग जो सामान्य काम करते हैं, वही सब
इसलिए मुझे पता है कि एक व्यक्ति के हाथ में ये tools क्या कर सकते हैं, और यह सचमुच चौंकाने वाला है
लेकिन जब नौकरी करने वाले दोस्तों से सुनता हूँ कि minimum token quotas तय किए जा रहे हैं, “star AI coder” leaderboards बन रहे हैं, और कहा जा रहा है “code review मत करो”, “हाथ से coding मत करो”, तो सिर हिलाना पड़ता है
सर्दियों में मैंने थोड़ा contract work किया था; ठीक था, लेकिन founder हर weekend पूरे नए project को vibe coding से बना रहा था, और code review घटकर LLMs की duel जैसी चीज़ बन गई थी
ये tools teamwork या असली team software engineering के लिए बहुत अच्छे नहीं हैं
industry के settle होने तक मैं बस पीछे हटकर देखता रहूँगा
काम करने लायक जगहें शायद वही होंगी जहाँ लोग “धीरे करो!” कह सकें, और जहाँ इतने उम्रदराज़ व समझदार लोग हों कि ऐसा कहकर भी टिक सकें
तब तक Ontario के Hamilton क्षेत्र में कटी हुई rhubarb की एक गड्डी 5 डॉलर में उपलब्ध है
asparagus भी है, और बहुत है
इसमें एक दिलचस्प द्वैत है
जिन कामों में मैं पहले से अच्छा हूँ, उनमें LLM का प्रभाव अपेक्षाकृत कम है, लेकिन जिन कामों में मैं अच्छा नहीं हूँ, उनमें यह बहुत बड़ा game changer है
बड़ी companies project के लिए ज़रूरी ज़्यादातर roles hire कर सकती हैं, इसलिए कुल प्रभाव अपेक्षाकृत छोटा होगा
ज़्यादा से ज़्यादा एक व्यक्ति पाँच लोगों का काम औसत दर्जे से कर लेगा, labor cost घटेगी, और बदले में product खराब होगा
short-term gain और long-term cost का मेल क्या होगा, यह तो साफ़ है
लेकिन छोटे studios या independent developers के लिए LLM बहुत बड़ा बदलाव है
पाँच लोगों का काम औसत तरीके से ही सही, कर पाना, बिना उन roles के somehow टिके रहने, third-party assets या दूसरे content पर निर्भर रहने, या उससे भी बुरा, तुरत-फुरत में बहुत खराब काम कर बैठने की तुलना में बहुत बड़ी छलांग है
लगभग हर ऐसे program का UI देख लीजिए जो साफ़ बताता है कि उसे किसी programmer ने designer के बिना layout किया है
या फिर वे लोग जो Dribbble से कुछ copy करने की कोशिश करते हैं लेकिन skill कम पड़ जाती है
AI के साथ आप अचानक सब कुछ और सबको विश्वसनीय ढंग से copy कर सकते हैं, और सच कहें तो यही लगभग AI के काम करने का मूल तरीका है
यह किसी textbook definition जैसा लगता है
व्यक्तिगत रूप से मेरा अनुभव बिल्कुल उल्टा है
LLM सिर्फ तब मददगार होता है जब मुझे पहले से ठीक-ठीक पता हो कि मैं क्या कर रहा हूँ
लोग यह ठीक से नहीं समझते कि गैर-तुच्छ software development में coding 50% भी नहीं होती
coding phase अक्सर सबसे आसान हिस्सा होता है और इसे junior developer को दे दिया जाता है
बड़ी organizations में ज़्यादातर product changes कई systems और लोगों की operations को पार करते हैं
senior और mid-level लोग अपना समय ज़्यादातर local priorities को मौजूदा cybernetic entity के भीतर एक नई arrangement में fit करने, और अपनी-अपनी priorities रखने वाली दूसरी teams से उस नए vision पर सहमति लेने में बिताते हैं
इसमें स्वाभाविक रूप से बहुत सारे trade-offs और politics शामिल होते हैं
senior engineers अपने ज़िम्मे के systems पर “weight” बढ़ने से बचते हैं, और scope creep या उनके इच्छित direction से हटाव को रोकने के लिए कड़ा संघर्ष करते हैं
इसलिए compromise चाहिए होता है, या priority तय कराने के लिए management तक escalation करनी पड़ती है
AI यह भी हल कर पाएगा या नहीं, पता नहीं, लेकिन वह कहीं ज़्यादा कठिन काम है
अब वह tool caller भी है, इसलिए coding agents lint, type checks, tests चला सकते हैं और errors ठीक कर सकते हैं, Sentry जैसी observability platforms में जाकर root cause ढूँढ सकते हैं, benchmarks चला कर slow code या hot paths पहचान सकते हैं, और जिन libraries का इस्तेमाल हो रहा है उनके नए major versions के migration docs पढ़कर उन्हें लागू भी कर सकते हैं, ताकि system up to date रहे
अगर इन चीज़ों को agent पर backpressure डालने और system को बेहतर समझने के लिए नहीं जोड़ा गया, तो वह बस एक बेवकूफ़ LLM code writer बनकर रह जाएगा
लेकिन models और harnesses जिस तेज़ी से सुधर रहे हैं, उसमें साफ़ है कि यह उससे बहुत आगे जा सकता है
यह लेख मोटे तौर पर सही है, और इस बात का संकेत भी देता है कि अगर AI से process तेज़ करना है तो कहाँ focus करना चाहिए
उदाहरण के लिए, एक product manager ने कहा कि वह ऐसे भविष्य की कल्पना करता है जहाँ stakeholders के साथ meeting ख़त्म होते ही interactive prototype तैयार न हो तो उसे failure माना जाए; मुझे लगता है दिशा सही है
एक और बात जिसकी मुझे उम्मीद है, वह यह कि vibe coding “Excel 2.0” बन जाएगी
यह conversational apps को काफ़ी हद तक self-service बना देगी, और IT को उसे बेहतर security guarantees, उचित access control और logging, scalability, change management वगैरह के साथ बदलने की स्थायी लड़ाई लड़नी पड़ेगी
बड़े ऐतिहासिक परिप्रेक्ष्य से देखें, तो हर क्रांतिकारी बदलाव शुरुआत में “steam horse” पैदा करता है
जब steam engine का आविष्कार हुआ था, तब लोग कल्पना करते थे कि transport का भविष्य ऐसे घोड़े-जैसी चीज़ों का होगा जो steam से चलें और मौजूदा गाड़ियाँ खींचें
बाद में ही हम transport के function को उसकी form से अलग करके समझ पाए
मैंने मूल रूप से MOOC की बात करते समय steam horse कहना शुरू किया था, और MOOC उसी तरह का एक विशुद्ध steam-horse idea था
prototype बनाने के लिए code की ज़रूरत नहीं होती
जैसे किसी scene को कैद करने के लिए actors और camera ज़रूरी नहीं; कुछ sketches भी काफ़ी होते हैं
दिखाया गया Gantt असल में waterfall model या ऐसी किसी दूसरी methodology का उदाहरण है जो मानती है कि software का कोई final destination होता है
आज का 99.999% software ऐसे नहीं बनता
आधुनिक software development का कोई destination नहीं होता
हर 2 हफ़्ते में business यह बदल देता है कि software को क्या करना है
नए features, नए integrations, बदले हुए functions, upgraded या replaced components, बड़ा scale, अलग hosting—यह सब लगातार आता रहता है
कुछ सालों बाद software मूलतः बदल चुका होता है, और quality व testing खिड़की से बाहर जा चुके होते हैं
फिर सिर्फ patchwork changes से निपटना ही नहीं, entropy से लड़ने वाली लगातार पीड़ा भी चलती रहती है
software एक जीवित प्राणी बन जाता है जो घायल होता है, जिसकी जीवनशैली बदलती है, और जो बूढ़ा होता जाता है
company उस राक्षस की caretaker बन जाती है, जैसे कोई zoo keeper किसी उदास जानवर को ज़िंदा रखने की कोशिश कर रहा हो
इंसान आदतों का प्राणी है, इसलिए AI इस्तेमाल करने पर भी वही समस्याएँ बनी रहेंगी
हाँ, सब कुछ थोड़ा तेज़ होगा और code review शायद code को थोड़ा बेहतर बनाए
साथ ही अच्छे tests की कमी और और तेज़ deploy करने की इच्छा हर चीज़ को थोड़ा और ख़राब भी करेगी
इस push-pull का नतीजा यह होगा कि software quality लगभग वैसी ही रहेगी, लेकिन चीज़ें थोड़ा तेज़ चलेंगी
आख़िरकार process तेज़ तो होगा, लेकिन बाकी सब अब भी तकलीफ़देह रहेगा, इसलिए किसी को बड़ा फ़र्क महसूस नहीं होगा
बल्कि ज़्यादा संभावना है कि सब लोग और जल्दी burnout होंगे
जटिलता के पीछे कारण होते हैं, और उन कारणों को हटाए बिना complexity नहीं हटाई जा सकती
business problems को tools से हल नहीं किया जा सकता
“AI code जल्दी generate कर सकता है, लेकिन इसका मतलब यह नहीं कि वह सही code generate करता है” — इस बात पर मेरा अनुभव है कि code लगभग हमेशा सही होता है
जो बात मुझे पसंद नहीं आती, वह यह है कि code को जोड़ा कैसे जाता है
अगर आप codebase को काफ़ी अच्छी तरह जानते हैं, तो आपको पता होता है कि चीज़ें कहाँ जोड़नी हैं, कैसे नाम देना है, कितनी comments कहाँ डालनी हैं—एक तरह की रस्में होती हैं
अगर agent यह ठीक से नहीं कर पाता, तो मेरे जैसे लोग चिढ़ जाते हैं, और लगता है कि AGENTS.md में लिख देने पर भी यह विफल हो जाता है
“अगर इंसानी developers को भी उतनी ही feature/scope documentation दी जाए, तो उनकी productivity भी आसमान छू लेगी” — IT में लगभग 20 साल काम करने के बाद भी मैं नहीं मानता कि यह सच में हो सकता है
और अगर होता भी है, तो इतना कम होता है कि चर्चा लायक नहीं
बस किसी पहले से बने system की नकल करने में लगने वाली मेहनत और उसी system को शून्य से बनाने की मेहनत की तुलना कर लीजिए
खासकर जब input bug या performance issue हो, तब यह अक्सर hallucinate करता है, और अगर हाथ पकड़कर न चलाया जाए तो गलत diagnosis देता है
फिर भी, अगर आप देखते रहें कि यह क्या कर रहा है और इसे सही दिशा में धक्का दें, तो root cause analysis और analysis में यह काफ़ी अच्छा और कुशल हो सकता है
मेरा मानना है कि इंसान की मशीन की तुलना में information को digest और analyze करने की speed की सीमाएँ होती हैं, इसलिए productivity gains की भी एक छत होती है
AI को process bypass करने की ज़रूरत नहीं है, फिर भी यह speed बढ़ा सकता है
refactoring, boilerplate code लिखने, पहले न दिखी हुई errors पकड़ने, और ऐसी चीज़ों में मदद कर सकता है जिन्हें linter नहीं पकड़ता
कई comments से ऐसा लगता है कि या तो लोग widely known standard processes का इस्तेमाल नहीं करते, या वे मान लेते हैं कि AI इस्तेमाल करने पर उन standards का पालन करने की ज़रूरत नहीं रहती
क्या ज़्यादा code और features ship किए जा सकते हैं? अगर अच्छी requirements और पर्याप्त tests हों, तो बिल्कुल
AI द्वारा लिखा गया हर code review और testing से गुज़रना चाहिए, और उसे अलग-अलग commits व pull requests में बाँटना चाहिए
जो लोग हज़ारों lines वाला PR उठाते हैं, वे red flag हैं
AI के बिना भी ऐसा नहीं किया जाता, तो फिर AI के साथ क्यों किया जाए
बड़े rewrites या refactors ही मशहूर exceptions हैं, लेकिन तब भी मैं मानता हूँ कि switch-over के लिए अलग-अलग commits होने चाहिए ताकि change process को देखा जा सके और बेहतर निर्णय लिया जा सके
अगर कोई मुझे एक विशाल one-shot commit या PR दिखाए, तो मैं उसे reject कर दूँगा
चीज़ों को ऐसे टुकड़ों में बाँटना चाहिए जिन्हें एक सामान्य developer audit कर सके