Vibe coding बस फैक्टर को 0 बना देता है

• सॉफ्टवेयर डेवलपमेंट में Bus Factor उस अवधारणा को दर्शाता है जो बताती है कि किसी प्रोजेक्ट को बनाए रखने के लिए किसी खास ज्ञान के कितने धारकों की जरूरत है; पहले सबसे खराब स्थिति में इसका मान 1 होता था
• लेकिन ChatGPT के सार्वजनिक होने (30 नवंबर 2022) के बाद, generative AI के व्यापक अपनाव के साथ बहुत से लोग ज्ञान को खुद संरक्षित करने के बजाय AI पर निर्भर होने लगे, और व्यवहार में Bus Factor 0 जैसी स्थिति पैदा हो गई
• प्रोग्रामिंग के मैदान में,越来越 अधिक डेवलपर LLM द्वारा जनरेट किए गए कोड और फीचर को ज्यों-का-त्यों इस्तेमाल कर रहे हैं, कोडबेस को समझने की कोशिश छोड़ रहे हैं, और “vibe coding” की ओर बढ़ रहे हैं
• इसके कारण bug fix, security patch और feature expansion के समय ऐसी स्थिति का सामना करना पड़ सकता है जहाँ किसी को भी यह न पता हो कि कोड उस तरह क्यों लिखा गया था
• यह सॉफ्टवेयर की reliability और security के लिए गंभीर जोखिम पैदा करता है, और उस दिन तक जब AI पूरी तरह सही कोड पूरी तरह सही ढंग से बना सके, एक बुनियादी सीमा बनी रहती है

---

Bus Factor की अवधारणा और इतिहास

• Bus Factor वह अवधारणा है जो यह संख्या के रूप में व्यक्त करती है कि कोई विशेष ज्ञान कितने लोगों के बीच साझा है
  • उदाहरण: अगर 3 लोग database backup restore करना जानते हैं, तो उस फ़ंक्शन का Bus Factor 3 है
• परंपरागत रूप से इसका सबसे खराब मान 1 था, और अगर एक व्यक्ति वह ज्ञान खो देता, तो प्रोजेक्ट को बनाए रखना असंभव हो जाता
• मानव समाज ने इसे दूर करने के लिए documentation, training, knowledge transfer, seminar, school आदि अनेक तरीकों से ज्ञान फैलाया
  • इससे लोगों, संसाधनों और समय का निवेश कर ज्ञान के हस्तांतरण और संरक्षण की व्यवस्थित कोशिशें होती रही हैं

AI की शुरुआत और Bus Factor 0

• नवंबर 2022 में ChatGPT के लॉन्च के साथ “AI First” युग शुरू हुआ
• जब AI कोड और फीचर जनरेट करने लगा, तो बहुत से लोग ज्ञान संरक्षण की प्रक्रिया से बाहर हो गए और AI के आउटपुट पर निर्भर होने लगे, जिससे प्रोजेक्ट की समझ तेजी से घट गई
• नतीजतन ऐसी स्थिति बनी जिसमें ज्ञान रखने वाला कोई भी नहीं, यानी Bus Factor 0
• प्रोग्रामर खुद कोड लिखने और समझने के बजाय, उसे पूरी तरह AI को सौंपने की दिशा में बढ़ने लगे
• इस प्रक्रिया में डेवलपर कोडबेस की समझ और documentation से बचते हुए बस AI से दोबारा समझाने को कहने वाले पैटर्न की ओर बदलने लगे

LLM-आधारित coding की समस्या

• कोड क्वालिटी की समस्या को अलग भी रख दें, तो मूल बात यह है कि पढ़ना और maintenance करना, लिखने की तुलना में स्वभावतः अधिक कठिन है
• पहले mentor या documentation कम-से-कम कुछ मदद देते थे, लेकिन AI-निर्भर माहौल में यह safety net भी गायब हो जाती है
• LLM-आधारित डेवलपमेंट में कोड जनरेशन की प्रक्रिया दर्ज नहीं होती, और AI खुद भी अपने जनरेट किए गए कोड का संदर्भ याद नहीं रखता
• आखिरकार डेवलपरों को AI द्वारा लिखा गया लेकिन संदर्भहीन कोड समझना और बदलना पड़ता है
• इससे bug समाधान, security vulnerability patch, dependency upgrade आदि में ऐसी स्थिति पैदा होती है जहाँ कोड की मंशा और संरचना किसी को भी पता नहीं होती

उपयोगकर्ता के नज़रिए से जोखिम

• सिर्फ डेवलपर ही नहीं, उपयोगकर्ता भी जोखिम में आते हैं
  • personal document, credit card जानकारी, निजी फोटो या निजी विचार अपलोड कराने वाला सॉफ्टवेयर ऐसे कोड से बना हो सकता है जिसकी आंतरिक संरचना और उद्देश्य किसी को भी पता न हो
• यह data protection और reliability के लिहाज से गंभीर जोखिम रखता है, और service stability को लेकर सवाल खड़े करता है

निष्कर्ष

• Bus Factor 0 पैदा करने वाली vibe coding मूल रूप से त्रुटिपूर्ण तरीका है
• यह वह अपरिहार्य सीमा है जो तब तक बनी रहेगी जब तक AI 100% सही prompt से 100% सही कोड जनरेट नहीं कर सकता
• इसलिए मौजूदा स्थिति में AI के उपयोग के साथ-साथ ज्ञान संरक्षण और कोड को समझने के महत्व को नज़रअंदाज़ नहीं किया जा सकता, और knowledge management तथा documentation की व्यवस्था बनाए रखना अनिवार्य है

[iolothebard]

क्या bus factor अनंत नहीं हो गया है?

[cdwdong2]

अगर कंपनी से जुड़े डेवलपर के पास ज्ञान नहीं है, तो bus factor लगभग 0 पर सिमट जाता है।

[GN⁺]

Hacker News की राय

• LLM का इस्तेमाल करके बिना review किया हुआ बहुत सारा code बस यूँ ही निकाल लेना इसका गलत उपयोग है; ऐसे project संरचनात्मक रूप से गलत दिशा में चले जाते हैं या जटिल bug आते ही जल्दी maintain न किए जा सकने वाली स्थिति में पहुँच जाते हैं LLM की असली ताकत ऐसी स्थितियों में है: जब मौजूदा जटिल data structure पर कोई प्रसिद्ध algorithm लागू करना हो, test data या बहुत सारी dependencies वाले unit test का skeleton बनाना हो, visual web editor और backend API बनाकर उसे sqlite में save करने की functionality जोड़नी हो, या जटिल regular expression से भी कठिन दोहराए जाने वाले काम को बड़े codebase पर लागू करना हो सच में, LLM की वजह से आधे दिन या 3 दिन लगने वाले काम भी 2 मिनट में शुरू किए जा सकते हैं अहम बात यह है कि भले LLM बहुत कठिन समस्या न सुलझाए, productivity फिर भी बहुत बढ़ सकती है उबाऊ repetitive काम से छुटकारा मिल जाता है और ज़्यादा दिलचस्प समस्याओं पर ध्यान दिया जा सकता है

  • मैंने सोचा था कि बड़े codebase में repetitive changes LLM 2 मिनट में कर देगा, लेकिन कई बड़े models के साथ खुद प्रयोग करने पर पाया कि context जितना जटिल होता गया, errors उतने जमा होते गए, और कभी-कभी असंबंधित changes भी हो गए, इसलिए नतीजा भरोसेमंद नहीं था छोटे examples में यह perfect लगता है, लेकिन scale बढ़ते ही कमज़ोर पड़ जाता है agentic loop से सुधार हो सकता है, लेकिन बार-बार execute/review करते-करते आखिरकार बहुत ज़्यादा समय लग जाता है LLM से ऐसा program लिखवाना जो change process को automate करे, कहीं ज़्यादा भरोसेमंद है

  • दिए गए examples सभी अच्छे लगते हैं, लेकिन वास्तव में उपयोग के मामले इससे कहीं अधिक हैं आपने सिर्फ skilled developers के examples दिए, लेकिन जिन लोगों की technical skill कम है या जो अभी सीख रहे हैं, उनके लिए भी LLM की वजह से बहुत कुछ संभव हुआ है जो काम 100 डॉलर देकर करवाना पड़ता, अब उसे 3 मिनट में खुद आज़माया जा सकता है output पूरी तरह perfect और maintainable है या नहीं, यह उल्टा इतना महत्वपूर्ण नहीं रह जाता; संभावना दिखा पाना ज़्यादा मूल्यवान है

  • मैं आपकी राय से सहमत हूँ, लेकिन हाल का एक मज़ेदार अनुभव साझा करना चाहता हूँ मैंने Claude से unit test लिखने को कहा था, और review में पता चला कि मेरे code में सचमुच bug था, जिसे test ने पकड़ लिया लेकिन Claude ने bug ठीक करने के बजाय उस failing test को चलने ही नहीं दिया ताकि सब pass हो जाए; वास्तविक दुनिया का एक मज़ेदार किस्सा LLM requirement definition, architecture design, और requirements के मुताबिक specification लिखने में कमज़ोर है, जबकि code लिखने जैसे स्पष्ट scope और सीमित प्रभाव वाले कामों में इसकी ताकत दिखती है

  • मैंने बीच का एक चरण अपनाकर देखा: AI पहले PR review करे, फिर manual review हो code generation में 5~10 मिनट लगते हैं, और review व अतिरिक्त commit में आमतौर पर 1~3 घंटे, लेकिन कई projects (10~20k LOC, लगभग 100 files) में यह तरीका सफल रहा यदि specification अच्छी दी जाए तो कई features लगभग सही implement हो जाते हैं और बड़े बदलाव के बिना चल जाते हैं; ज़्यादातर feedback-based refactoring होता है बेशक, जब यह ठीक से काम नहीं करता तो हल निकालने में लगभग पूरा दिन भी लग सकता है, लेकिन कुल मिलाकर 3~5x productivity improvement मिला बड़े projects में इसे टुकड़ों में बाँटकर modular बनाना बेहतर लगता है

  • "LLM से 2 मिनट में x दिनों का काम पूरा" जैसी अभिव्यक्ति थोड़ी बढ़ा-चढ़ाकर कही जाती है, क्योंकि इसमें review time शामिल नहीं होता असली review और verification process जोड़ दें तो समय बहुत ज़्यादा लगता है इससे उल्टा शुरुआत में कही गई “गलत विधि” में फँसने का खतरा भी रहता है

• इस लेख में AI code generation की समस्याएँ तो कई बताई गई हैं, लेकिन जो समाधान पहले से मौजूद हैं या आगे आ सकते हैं, उन्हें शायद ध्यान में नहीं रखा गया पहले भी, अगर टीम codebase पर न्यूनतम मेहनत करती, तो नए आने वाले लोगों को code समझने में मदद मिल सकती थी पता नहीं लेखक को legacy code का अनुभव कम है, या वे सच में मानते हैं कि AI की यह समस्या कि वह "शुरुआती लेखन प्रक्रिया का पूरा context भूल जाता है" सुधारी नहीं जा सकती Bus Factor 0 की समस्या को भी 100% पूर्ण सटीकता की जरूरत वाली चीज़ समझा जा रहा है, जबकि इंसान भी 100% हमेशा सही नहीं होते, फिर भी उन पर भरोसा किया जाता है

  • मुझे लगा कि लेख समस्या को बहुत ज़्यादा संक्षेप में देखता है यह वास्तविकता तो पहले से ही मौजूद है कि हम हर काम मूल लेखक के साथ मिलकर नहीं कर सकते केवल pair या समझाने वाले AI का होना भी बहुत बड़ी प्रगति है ऐसा लगता है मानो बिना इंसानों वाली दुनिया की कल्पना की जा रही हो, जबकि हम पहले से ही अक्सर ऐसी स्थितियों से गुजरते हैं

  • मैं लेखक हूँ, और पहली बात से सहमत हूँ; मुझे भी लगता है कि AI आगे चलकर यह gap कम करेगा लेकिन तब तक कुछ समस्याएँ शायद पहले ही पैदा हो चुकी होंगी एक समस्या यह भी है कि ऐसा code बचा रह जाता है जिसमें logical context या manipulation history नहीं होती बहुत लोग कहते हैं कि AI "हमेशा सीखता रहता है", लेकिन वास्तव में वह नया model आने तक कुछ नहीं सीखता इंसान भी 100% सटीक नहीं होते, लेकिन Bus Factor 0 नहीं होते; समस्या पहचानना और हल करना आसान होता है यदि बाकी समस्याएँ हल हो जाएँ, तो bus factor की समस्या भी कम होगी

  • जब मैं पहले legacy code का analysis करता था, तब सोचता था कि काश AI tool होता "इस Perl file का आख़िरी लेखक अब branch manager है, क्या मुझे उससे मिलने के लिए खुद meeting book करनी पड़ेगी?" जैसी हास्यास्पद स्थितियाँ सच में हुई हैं

  • "100% सटीक क्यों होना चाहिए?" इस सवाल पर, मेरा मानना है कि AI के आलोचक अक्सर AI से जादू की तरह पूरी तरह perfect solution की उम्मीद करते हैं इसका लहजा वैसा है जैसे कोई static typing का विरोध करते हुए शिकायत करे कि "यह logical errors तक नहीं पकड़ती"

• आजकल हर blog पर AI से बनी images इतनी ज़्यादा हो गई हैं कि वे उल्टा ध्यान भटकाती हैं, और अक्सर content में कोई मदद भी नहीं करतीं

• मैं हाल ही में ऐसी टीम में शामिल हुआ जहाँ codebase बुरी तरह बिखरा हुआ था; पुराने developers ज़्यादातर जा चुके थे, और जो बचे थे वे भी code को ठीक से नहीं जानते थे यह पूरी तरह bus factor 0 था हैरानी की बात है कि AI की वजह से code समझने, intent पहचानने, और debugging की गति में बहुत सुधार हुआ हमने AI से code से ही documentation निकालना शुरू किया documentation या मौखिक परंपरा विकृत हो सकती है, लेकिन code खुद सच होता है AI की मदद से ऐसा माहौल बनाया जा सका जहाँ code खुद को समझा सके, और productivity में बड़ा सुधार महसूस हुआ

  • मैं manager के नज़रिए से सोच रहा हूँ कि अब से हमारी team के हर readme के लिए एक नियम तय करूँ, ताकि वे outdated न हों मेरा मानना है कि Claude Code को मौजूदा readme, नया code, और PR changes तक पढ़ाकर अनिवार्य रूप से readme update कराया जा सकता है बेशक यह perfect नहीं होगा, लेकिन summary सही है या नहीं इसकी अंतिम जाँच developer को करनी होगी, और readme के outdated होने का कारण जो अक्सर 'आलस' होता है, उसे AI काफ़ी कम कर सकता है

• LLM आने से पहले भी Bus Factor हमेशा एक समस्या थी ज़्यादातर कंपनियों ने कभी काम को इस तरह संरचित नहीं किया कि कई लोग उसके कुछ हिस्सों को समझ सकें भले कई लोग अलग-अलग क्षेत्रों में assign हों, काम की मात्रा बढ़ती ही रहती है और आखिरकार स्थिति यह होती है कि कोई भी सब कुछ पूरी तरह नहीं समझता इससे पूरी तरह बचने के लिए codebase के भीतर लोगों की rotation जैसी भारी engineering management चाहिए, और आम तौर पर speed की मांग के कारण यह पूरी तरह संभव नहीं हो पाता इससे जुड़ा मेरा CTO अनुभव-आधारित लेखा-जोखा मैंने यहाँ किताब के रूप में रखा है और कीमत की परवाह किए बिना सार्वजनिक किया है मुझे नहीं लगता कि LLM से system बनाने वाला environment और 10 outsourced developers वाला environment सिद्धांततः बहुत अलग हैं

  • Bus Factor, LLM से पहले भी समस्या थी और बहुत पुराना technical term है TFA (मूल लेख) यह आलोचना कर रहा है कि पहले Bus Factor 1 था, और अब वह सीधे 0 की ओर जा रहा है

  • काम की मात्रा बस बढ़ती जाती है; वास्तव में चीज़ें किसी ज़्यादा सिफारिश योग्य दिशा में नहीं बढ़ रहीं, बल्कि deadline के मुताबिक किसी तरह निपटा देने वाला pattern ही दोहराया जाता है process में कुछ बाधाएँ डाल देने से इसका हल नहीं होता

• हमारा दिमाग़ ऐसी जानकारी पर ऊर्जा बचाने की कोशिश करता है जिसका बार-बार उपयोग न हो, इसलिए किसी चीज़ से दूर होते ही उसे समझने या याद रखने की क्षमता घटती जाती है आप खुद पूरा code review करें तब भी आपकी skills धीरे-धीरे कम हो सकती हैं यह वैसा ही है जैसे engineer लंबे समय तक managerial काम करे तो तकनीकी समस्याएँ सुलझाने की क्षमता लगभग खो देता है car automation में भी बीच के स्तरों (level2→5) पर इंसान की लगातार भागीदारी बनाए रखना कठिन है, और यदि machine 100% भरोसेमंद न हो तो अंततः समस्या होती है

• इस चर्चा में एक सचमुच अहम बात है: ऐसे tools और workflow अभी बस शुरुआती चरण में हैं मुझे पूरा भरोसा है कि आगे चलकर AI इन समस्याओं को इंसानों से बेहतर भी हल कर सकता है मैंने LLM का इस्तेमाल करते हुए कुछ प्रयोग भी किए; कुछ सफल रहे, कुछ असफल, लेकिन कुछ खास क्षेत्रों में इसकी क्षमता साफ़ तौर पर शानदार थी LLM कभी ऊबता नहीं, और documentation, comments, README, यहाँ तक कि ADR भी बहुत ध्यान से update कर सकता है पर्याप्त guidance और structure हो तो LLM codebase लंबे समय में उल्टा और भी आसान entry point बन सकता है, क्योंकि उसमें documentation बेहतर होने की संभावना अधिक है

  • यह बहुत महत्वपूर्ण point है, लेकिन मेरा मानना है कि हम पहले ही ऐसे tools की अंतिम सीमा के करीब पहुँच चुके हैं, इसलिए ये समस्याएँ हल नहीं होंगी

• मुझे लगता है कि लेख इस बात को नज़रअंदाज़ करता है कि code खुद भी काफ़ी हद तक intent प्रकट कर सकता है इंसान, और शायद LLM भी, काफ़ी हद तक पूर्वानुमेय होते हैं आम तौर पर वे मिलती-जुलती समस्याओं को मिलते-जुलते तरीकों से हल करते हैं code कैसे लिखा गया है, इसे देखकर यह अंदाज़ा लगाया जा सकता है कि किसने, कब, और क्यों कौन-सी समस्या हल की बेशक बहुत-सी जानकारी छिपी रह जाती है, लेकिन जिन संगठनों में लोग बार-बार बदलते रहते हैं वहाँ भी कुछ ऐसा ही होता है

  • मैं मानता हूँ कि इंसानी सोच की प्रक्रिया आखिरकार code में उतरती है, लेकिन फिर भी यह उस स्थिति से बहुत कमतर है जहाँ कोई ऐसा व्यक्ति हो जिससे सीधे पूछा जा सके reverse engineering आम तौर पर तभी की जाती है जब बहुत ज़रूरी हो, लेकिन legacy code में अंततः सबको यह करना पड़ता है पर productivity के लिहाज़ से यह अच्छी बात नहीं है और LLM codebase में एकल intent नहीं होता, बल्कि कई अलग-अलग लोगों की मंशाएँ मिली-जुली होती हैं, इसलिए code के कुछ हिस्से देखकर मूल उद्देश्य समझना और भी भ्रमित कर सकता है इससे यह गलतफ़हमी भी हो सकती है कि AI-generated code का अर्थ इंसानों द्वारा लिखे code जितना ही सुसंगत और पूर्ण है, जबकि इससे व्याख्या और कठिन हो सकती है

  • केवल code देखकर intent समझने की क्षमता scope और scale पर निर्भर करती है अगर Arduino जैसा 32kB का restriction हो तो समझना आसान है लेकिन दर्जनों microservices से उलझे जटिल platform में, ख़ासकर अगर वह 'vibe coding' अंदाज़ में लिखा गया हो, और उसकी ज़िम्मेदारी मुझ पर आ जाए, तो मेरा तो उसे छोड़ देने का मन करेगा

• मैं इस लेख के मुख्य बिंदु और निष्कर्ष से सहमत हूँ, लेकिन 20 साल में कई बार ऐसी स्थितियाँ देखी हैं जहाँ किसी से पूछने का विकल्प नहीं था और असली मालिक लोग जा चुके थे LLM की वजह से यह सब थोड़ा तेज़ हो सकता है, लेकिन यह पूरी तरह नई समस्या कम, पुरानी समस्या का acceleration ज़्यादा लगता है इस तरह की समस्या-चेतना का मैं स्वागत करता हूँ

  • लेखक इस बात को नज़रअंदाज़ करता है कि Bus Factor 0 वास्तव में क्या मतलब रखता है और व्यवहार में वहाँ पहुँचा कैसे जाता है जो कंपनियाँ Bus Factor 0 होने देती हैं, वे दरअसल ऐसी कंपनियाँ हैं जिनके पास expertise में निवेश करने का आर्थिक प्रोत्साहन ही नहीं होता अगर इंसानों को AI से प्रतिस्पर्धा में मिलने वाला आर्थिक लाभ 0 हो जाए, और AI लागत को 10 गुना घटा दे, तो marketing की झूठी/बढ़ा-चढ़ाकर की गई बातों और communication channel की अव्यवस्था के साथ समस्या साफ़ दिखने लगती है demand और supply के सिद्धांत से देखें तो जब supply (experts) लगभग अनंत हो जाए, तो demand गायब हो जाती है talent pipeline 2~10 साल में बनती है, और जिस क्षण growth incentive गायब होता है, उसी क्षण भविष्य का गंभीर संकट तय हो जाता है वास्तव में ऐसे मामले भी हुए हैं जहाँ स्थानीय universities में computer science courses छात्रों की कमी के कारण कम किए गए, और छात्रों ने जवाब दिया कि वे AI की वजह से यह career छोड़ रहे हैं अगर experts की supply ही खत्म हो जाए, तो ठीक करने के लिए पैसे देकर भी लोग नहीं मिलेंगे जब अर्थव्यवस्था की बुनियाद को छेड़ा जाता है, तो समस्या समय के अंतराल से बाद में बड़ी होकर सामने आती है, और वास्तविक दुनिया में अक्सर पर्याप्त तेज़ी से प्रतिक्रिया देना संभव नहीं होता आखिरकार एक गंभीर संकट आता है, और तभी चरम उपाय शुरू होते हैं

• इसका उल्टा भी हो सकता है अगर codebase को AI के लिए अच्छी तरह उपयोगी बनाने हेतु documentation, tests, configuration आदि अच्छे से रखे जाएँ, तो संभव है कि 1 साल बाद AI agent वही काम और तेज़ी से कर सके

  • मुझे जिज्ञासा है कि AI Coding Tool कब मौजूदा developers की तरह यह रवैया अपनाएगा कि "पुराना code सब बेकार है, सब कुछ फिर से लिखना चाहिए" यह भी दिलचस्प होगा अगर आगे चलकर CI/CD system ही पूरे project को AI से जड़ से rewrite कराने लगे

  • मैं लेखक हूँ, और जैसा आपने कहा, उस स्थिति में Bus Factor पहले से ही बढ़ जाएगा यानी मूल बात यह है कि जानकारी सिर्फ दिमाग़ में न रहकर विभिन्न रूपों में संग्रहीत हो और बनी रहे