13 लाख लाइनें, हर हफ़्ते 630 PR: वाइब-कोडेड कोडबेस को टिकाऊ कैसे रखें

जुलाई 2026 में, Robert C. Martin ने लिखा कि वे अपने कोडिंग एजेंट्स द्वारा तैयार किया गया कोड अब नहीं पढ़ते।

इस बयान ने काफ़ी ध्यान खींचा। लेकिन उनके काम करने के तरीके को समझने के लिए उनकी पोस्ट का बाक़ी हिस्सा ज़्यादा मायने रखता है। Martin एजेंट्स के चारों ओर यूनिट टेस्ट, Gherkin एक्सेप्टेंस टेस्ट, QA प्रक्रियाएँ, म्यूटेशन टेस्टिंग, कवरेज जाँच और गुणवत्ता मेट्रिक्स खड़े करते हैं। कोड उस पूरी व्यवस्था से गुज़रकर उनका भरोसा कमाता है।

कुछ महीने पहले भी उन्होंने ऐसी ही बात कही थी। कार्यान्वयन की जाँच करने के बजाय वे टेस्ट कवरेज, डिपेंडेंसी संरचना, साइक्लोमैटिक जटिलता, मॉड्यूल का आकार और म्यूटेशन टेस्टिंग के नतीजे देखते हैं। जब लोगों ने इसे समीक्षा पूरी तरह छोड़ देने के रूप में समझा, तो उन्होंने स्पष्ट किया: "मैं बहुत समीक्षा करता हूँ — बस कोड की नहीं।"

उनकी टिप्पणियाँ AI-प्रधान सॉफ़्टवेयर विकास की एक व्यावहारिक समस्या बताती हैं। कोडिंग एजेंट लोगों के पढ़ पाने की गति से तेज़ बदलाव तैयार कर सकते हैं। जैसे ही उत्पन्न कोड की मात्रा टीम की समीक्षा क्षमता से आगे निकलती है, पंक्ति-दर-पंक्ति जाँच भरोसे का इकलौता स्रोत नहीं रह सकती।

vm0 पर हम पिछले आठ महीनों से इसी समस्या से जूझ रहे हैं। हमारी रिपॉज़िटरी का अधिकांश इम्प्लीमेंटेशन एजेंट लिखते हैं — प्रचलित शब्दों में वाइब कोडिंग — जबकि छह इंजीनियर इसके लिए जवाबदेह बने रहते हैं कि वह कोड प्रोडक्शन में क्या करता है।

संक्षेप में

vm0 एक वाइब-कोडेड कोडबेस है: अधिकांश इम्प्लीमेंटेशन एजेंट लिखते हैं, और प्रोडक्शन में उसका व्यवहार छह इंजीनियरों की जवाबदेही है। आठ महीनों में रिपॉज़िटरी 1,329,170 लाइनों की है और एक ही हफ़्ते में 630 पुल रिक्वेस्ट मर्ज हुईं। पाँच तंत्र वह गुणवत्ता-भार उठाते हैं जो अकेले पंक्ति-दर-पंक्ति समीक्षा अब नहीं उठा सकती।

• अभिसरित परिवेश। इंजीनियर और एजेंट एक ही dev container में काम करते हैं, और हर पुल रिक्वेस्ट को अपनी डेटाबेस ब्रांच मिल सकती है। जो कमांड एजेंट के लिए चला, वही इंसान के लिए भी चलता है।
• निष्पादन-योग्य बंधन। सख़्त TypeScript, लगभग 135 टाइप किए गए API कॉन्ट्रैक्ट मॉड्यूल, Oxlint, ESLint और आर्किटेक्चर नियम, और ऐसा CI जो कोई चेतावनी स्वीकार नहीं करता। जो नियम मशीन जाँच सकती है, वह समीक्षा पर नहीं छोड़ा जाता।
• सीमाओं पर परीक्षण। पिरामिड की जगह टेस्टिंग ट्रॉफी: मॉड्यूल की सार्वजनिक सीमाओं से होकर इंटीग्रेशन टेस्ट, असली PostgreSQL और असली माइग्रेशन, मॉक सिर्फ़ बाहरी सिस्टम पर। टेस्ट कोड रिपॉज़िटरी का लगभग 36 प्रतिशत है।
• पूर्ण फ़ीडबैक लूप। एजेंट ऐप और डेटाबेस चलाते हैं, माइग्रेशन करते हैं और असली ब्राउज़र चलाते हैं, फिर चलाए गए कमांड, परखा गया रास्ता और स्क्रीनशॉट बताते हैं। पुल रिक्वेस्ट के मर्ज होने का माध्य समय लगभग 53 मिनट है।
• लगातार सफ़ाई। Knip मृत कोड को निर्धारित रूप से हटाता है, रोज़ चलने वाले वर्कफ़्लो वह AI स्लॉप हटाते हैं जिसे कोई लिंटर नाम नहीं दे सकता, और जो पैटर्न पर्याप्त बार लौटता है वह लिंट नियम या टाइप बंधन बन जाता है।

वाइब कोडिंग और एजेंटिक कोडिंग का असल मतलब

वाइब कोडिंग यानी LLM से कोड माँगना, जो निकले उसे चलाना, बदलाव माँगना, और उत्पन्न कोड पर ध्यान न देना। Martin Fowler की परिभाषा जानबूझकर संकीर्ण है, और वे इस बात को रेखांकित करते हैं कि "भूल जाइए कि कोड मौजूद भी है"। यह प्रोटोटाइप, फेंक देने लायक सॉफ़्टवेयर और सीमित परिणाम वाले छोटे उपकरणों के लिए ठीक है।

एजेंटिक कोडिंग, जिसे Fowler एजेंटिक प्रोग्रामिंग कहते हैं, वह है जो टीमें तब करती हैं जब उन्हें नतीजा बनाए रखना है। एजेंट रिपॉज़िटरी पढ़ता है, फ़ाइलें बदलता है, टेस्ट चलाता है और लंबे समय तक ख़ुद काम करता है, जबकि लोग संरचना और व्यवहार के मालिक बने रहते हैं और हर रन के प्रमाण देखते हैं: टेस्ट परिणाम, गुणवत्ता संकेत, प्रीव्यू और प्रोडक्शन व्यवहार।

फ़र्क़ इसमें नहीं कि मॉडल कितना कोड लिखता है, बल्कि इसमें कि मानवीय ध्यान कहाँ जाता है।

	वाइब कोडिंग	एजेंटिक कोडिंग
एजेंट की स्वायत्तता	प्रॉम्प्ट, चलाना, फिर प्रॉम्प्ट	रिपॉज़िटरी पढ़ना, बदलना, परखना, दोहराना
कोड कौन पढ़ता है	कोई नहीं	जोखिम वाले हिस्से इंसान पढ़ते हैं
क्या सत्यापित होता है	नतीजा सही दिखता है या नहीं	टाइप, कॉन्ट्रैक्ट, टेस्ट, प्रीव्यू, प्रोडक्शन संकेत
कहाँ उपयुक्त	प्रोटोटाइप और अस्थायी उपकरण	रखरखाव की अवधि वाला सॉफ़्टवेयर
सामान्य विफलता	ऐसा कोड जिसे कोई नहीं समझता	मात्रा के मुक़ाबले बहुत कमज़ोर सत्यापन

रिपॉज़िटरी संपादित करने वाले एजेंट एक बड़े बदलाव की एक शाखा भर हैं; ग़ैर-डेवलपर पक्ष पर हमने अलग से लिखा है।

हम vm0 को अक्सर वाइब-कोडेड परियोजना कहते हैं क्योंकि यह वाक्यांश "मुख्यतः AI द्वारा लिखे सॉफ़्टवेयर" का आम संक्षेप बन गया है। Fowler की शब्दावली में यह एजेंटिक कोडिंग के अधिक निकट है। हमारे इंजीनियर पहले से कम इम्प्लीमेंटेशन टाइप करते हैं, पर आर्किटेक्चर, रखरखाव लागत और प्रोडक्शन व्यवहार आज भी उन्हीं का है।

कोड जनरेशन जितनी तेज़ हुई, उस ज़िम्मेदारी का उतना ही हिस्सा विकास परिवेश, टाइप सिस्टम, टेस्ट सूट और स्वचालित रखरखाव वर्कफ़्लो में चला गया।

वाइब-कोडेड कोडबेस में आठ महीने की वृद्धि

vm0 रिपॉज़िटरी नवंबर 2025 में बनाई गई थी। हमारी नवीनतम साप्ताहिक इंजीनियरिंग स्केल रिपोर्ट के समय यह लगभग साढ़े आठ महीने पुरानी थी।

रिपॉज़िटरी में था:

मीट्रिक	संख्या
ग़ैर-ख़ाली तार्किक पंक्तियाँ	1,329,170
प्रोडक्शन पंक्तियाँ	850,913
टेस्ट पंक्तियाँ	478,257
सोर्स फ़ाइलें	5,549
टेस्ट फ़ाइलें	1,327
पैकेज	44
मुख्य ब्रांच पर कमिट	14,005

ये आँकड़े 20 से 26 जुलाई 2026 के सप्ताह की हमारी साप्ताहिक इंजीनियरिंग स्केल रिपोर्ट से हैं, जो सीधे मोनोरेपो से मापे गए।

टेस्ट कोड मापी गई कोडबेस का लगभग 36 प्रतिशत था। यह कोड मात्रा का हिस्सा है, टेस्ट कवरेज का आँकड़ा नहीं, पर इससे अंदाज़ा मिलता है कि सत्यापन के इर्द-गिर्द कितना कार्यान्वयन जमा हुआ है।

हाल के तीन पूरे सप्ताहों में छह इंजीनियरों ने क्रमशः 541, 640 और 631 कमिट किए। 20–26 जुलाई के सप्ताह में GitHub ने 630 मर्ज हुए पुल रिक्वेस्ट दर्ज किए। इनमें से 556 छह इंजीनियरों ने लिखे, बाक़ी 74 रिलीज़ ऑटोमेशन ने।

पुल रिक्वेस्ट खुलने से मर्ज होने तक का माध्य समय लगभग 53 मिनट था। 90वाँ पर्सेंटाइल लगभग 7.4 घंटे रहा।

बदलाव की इस रफ़्तार पर मानवीय समीक्षा उपयोगी तो रहती है, पर पूरी गुणवत्ता व्यवस्था नहीं उठा सकती। हमें किसी बदलाव के जीवनचक्र के कई बिंदुओं पर स्वतंत्र संकेत चाहिए।

हमारे मौजूदा तरीक़े में पाँच बार-बार लौटते विषय हैं: अभिसरित परिवेश, निष्पादन-योग्य बाध्यताएँ, सीमा-केंद्रित टेस्ट, पूर्ण फ़ीडबैक लूप, और सतत सफ़ाई।

dev container के साथ विकास परिवेश को अभिसरित करना

पुनरुत्पादन में कठिन कई विफलताएँ ऐसी स्थिति से आती हैं जो पुल रिक्वेस्ट में कभी दिखती ही नहीं।

किसी डेवलपर के पास बिना दस्तावेज़ वाला एनवायरनमेंट वेरिएबल, ग्लोबली इंस्टॉल किया टूल, पुरानी कॉन्फ़िगरेशन फ़ाइल, या महीनों से चल रहा डेटाबेस हो सकता है। लोग इन ब्योरों के आदी हो जाते हैं। एजेंट आम तौर पर उन्हें देख नहीं पाते।

हमने धीरे-धीरे होस्ट मशीन को मानक विकास परिवेश मानना बंद कर दिया। इंजीनियर और एजेंट dev container के भीतर काम करते हैं। डेवलपमेंट इमेज में प्रोजेक्ट टूलचेन, PostgreSQL, pgvector, Chromium और ब्राउज़र-ऑटोमेशन यूटिलिटीज़ शामिल हैं।

CI उन्हीं मल्टी-स्टेज Dockerfile परिवार से बनी, संस्करणित टूलचेन इमेजों पर चलती है। डेवलपमेंट और CI इमेज अलग उद्देश्य पूरे करती हैं, और प्रोडक्शन का अपना डिप्लॉयमेंट आकार है। उपयोगी गुण है अभिसरण: टूल संस्करण, डिपेंडेंसी और रनटाइम मान्यताएँ स्पष्ट और संस्करणित हैं।

इससे एक सीधी अपेक्षा बनती है। एजेंट जो कमांड चलाता है, उसे उसी डेवलपमेंट कंटेनर में कोई इंजीनियर दोहरा सके। जो जाँचें विकास के दौरान पास होती हैं, वे CI में लगभग उसी टूलचेन के तहत चलें।

यही विचार हम डेटा पर भी लागू करते हैं। हर पुल-रिक्वेस्ट प्रीव्यू का अपना डेटाबेस ब्रांच हो सकता है और उस पर असली माइग्रेशन और सीड चरण चल सकते हैं। एजेंट डेटा बना सकता है, बदल सकता है और विनाशकारी टेस्ट दोहरा सकता है — न किसी डेवलपर का मौजूदा डेटाबेस उधार लेकर, न किसी दूसरे पुल रिक्वेस्ट की स्थिति विरासत में लेकर।

परिवेश के बदलाव रिपॉज़िटरी से होकर जाते हैं। टूल अपग्रेड, ब्राउज़र संस्करण और डेटाबेस एक्सटेंशन उसी तरह समीक्षित और प्रसारित होते हैं जैसे एप्लिकेशन कोड।

टाइप और लिंट नियमों में इंजीनियरिंग मानकों को निष्पादन-योग्य बनाना

लिखित मानक लोगों को डिज़ाइन निर्णय समझने में मदद करते हैं। यह गारंटी देने में वे कम कारगर हैं कि हर बदलाव उन निर्णयों का पालन करे — ख़ासकर लंबे एजेंट सत्रों में।

स्थिर नियमों को हम टाइप सिस्टम, लिंटर और CI में डालते हैं, जब भी नियम को भरोसे के साथ व्यक्त किया जा सके।

vm0 सख़्त TypeScript सेटिंग्स इस्तेमाल करता है, जिनमें strict और noUncheckedIndexedAccess शामिल हैं। कुछ पैकेज अप्रयुक्त मानों और अंतर्निहित रिटर्न के लिए अतिरिक्त जाँचें भी चालू करते हैं।

API में स्कीमा-फ़र्स्ट, टाइप किया गया REST कॉन्ट्रैक्ट लेयर है, जो tRPC की टाइप मशीनरी और Zod स्कीमा से बना है। Drizzle डेटाबेस एक्सेस को TypeScript टाइप्स से जोड़ता है। इस समीक्षा के समय रिपॉज़िटरी में लगभग 135 कॉन्ट्रैक्ट मॉड्यूल थे।

ये चुनाव ग़लत उत्पाद निर्णय नहीं पकड़ते। पर इंटरफ़ेस के खिसकने को जल्दी सामने ले आते हैं। जब कोई फ़ील्ड या रिस्पॉन्स बदलता है, तो संबंधित कॉलर आम तौर पर स्थैतिक विश्लेषण में ही विफल हो जाते हैं। उससे मिलने वाली त्रुटि आम तौर पर इतनी विशिष्ट होती है कि एजेंट अगले चक्र में उसका उपयोग कर सके।

लिंटिंग नियमों के दूसरे समूह को सँभालती है। प्लेटफ़ॉर्म Oxlint, टाइप-सचेत जाँचें और ESLint चलाता है, साथ ही प्रोजेक्ट-विशिष्ट आर्किटेक्चरल नियम। CI कोई चेतावनी स्वीकार नहीं करती। जो चेतावनियाँ अनिश्चित काल तक बनी रह सकती हैं, वे पृष्ठभूमि शोर बन जाती हैं — और पृष्ठभूमि शोर को लोग भी आसानी से अनदेखा करते हैं और एजेंट भी।

जब कोई समस्या दोहराई जाती है, तो हम सोचते हैं कि जाँच कहाँ बैठनी चाहिए:

1. क्या टाइप सिस्टम इसे व्यक्त कर सकता है?
2. क्या कोई लिंटर या संरचनात्मक टूल इसे सटीकता से पकड़ सकता है?
3. क्या इसके लिए पूरी रिपॉज़िटरी पर अर्थगत विवेक चाहिए?

पहले दो हर बदलाव पर तेज़ और नियतात्मक फ़ीडबैक देते हैं। तीसरे समूह को हम आगे बताए गए आवर्ती वर्कफ़्लोज़ से सँभालते हैं।

AI-जनित कोड में त्रुटि-प्रवण पैटर्नों को सीमित करना

कुछ भाषा सुविधाओं के वैध उपयोग भी हैं और वे एजेंट-निर्मित नाज़ुक कोड में अक्सर दिखती भी हैं।

try/catch किसी त्रुटि-सीमा को धुँधला कर सकता है। जब एजेंट किसी विफलता से टकराता है, तो catch ब्लॉक और फ़ॉलबैक जोड़ना मौजूदा रास्ता चलाते रहने का आसान तरीक़ा है — मूल त्रुटि खोकर। Promise के .then() और .catch() को async/await के साथ मिलाने से नियंत्रण-प्रवाह कई शैलियों में बिखर जाता है।

React का useEffect स्टेट प्रबंधन में वैसी ही समस्या बनाता है। इसका उपयोग अक्सर स्टेट कॉपी करने, सत्य के दो स्रोतों को समकालिक करने, या ऐसी क्रम-निर्भरता कूटबद्ध करने में होता है जो डेटा मॉडल से देखना कठिन है।

मुख्य वेब प्लेटफ़ॉर्म इन पैटर्नों को डिफ़ॉल्ट रूप से सीमित करता है। कोई उचित अपवाद रह सकता है, पर उसके साथ स्पष्ट व्याख्या होनी चाहिए।

मुख्य वेब प्लेटफ़ॉर्म के प्रोडक्शन कोड में इस समय कोई useEffect नहीं है। हम निर्भरताओं और साइड इफ़ेक्ट्स को अधिक स्पष्ट रूप से मॉडल करने के लिए ccstate और अन्य प्रभाव-रहित पैटर्न इस्तेमाल करते हैं। मोनोरेपो में अन्यत्र, मुख्यतः साझा UI और डेस्कटॉप कोड में, कुछ गिने-चुने प्रोडक्शन useEffect कॉल अब भी मौजूद हैं — इसलिए दावे का दायरा मायने रखता है।

ये नियम इसी रिपॉज़िटरी की दोहराई गई विफलताओं से निकले हैं। जब कोई पैटर्न बार-बार वही रखरखाव समस्या पैदा करता है, तो हम उसे समीक्षा-सलाह से हटाकर निष्पादन-योग्य बाध्यता बना देते हैं।

मॉड्यूल सीमाओं पर परीक्षण: पिरामिड नहीं, टेस्टिंग ट्रॉफी

vm0 पारंपरिक टेस्ट पिरामिड का पालन नहीं करता। हमारी टेस्टिंग गाइड एक टेस्टिंग ट्रॉफ़ी बताती है: आधार पर स्थैतिक विश्लेषण, प्रमुख परत के रूप में इंटीग्रेशन टेस्ट, और महत्वपूर्ण यूज़र जर्नी के लिए कुछ ही एंड-टू-एंड टेस्ट।

यूनिट टेस्ट अपेक्षाकृत कम हैं। हम उन्हें सुरक्षा-संवेदनशील लॉजिक, एल्गोरिद्म और स्टेट मशीनों के लिए चुन-चुनकर उपयोग करते हैं। अधिकांश व्यावसायिक व्यवहार मॉड्यूल की सार्वजनिक सीमा से होकर परखा जाता है।

API टेस्ट असली एप्लिकेशन को उसके कॉन्ट्रैक्ट्स के ज़रिए कॉल करते हैं। जहाँ व्यावहारिक हो, टेस्ट डेटा प्रोडक्शन एंडपॉइंट्स से तैयार होता है, और दावे सार्वजनिक व्यवहार पर किए जाते हैं। टेस्ट सीधे किसी आंतरिक सेवा तक पहुँचने या डेटाबेस टेबल बदलने से बचते हैं, क्योंकि इससे वे मौजूदा कार्यान्वयन से बँध जाते हैं।

आंतरिक बुनियादी ढाँचा वहाँ असली रहता है जहाँ लागत उचित हो:

• PostgreSQL और pgvector
• डेटाबेस माइग्रेशन
• फ़ाइल सिस्टम
• आंतरिक सेवाएँ
• बाहरी-सिस्टम सीमाओं पर मॉक

ये इंटीग्रेशन टेस्ट अत्यधिक पृथक यूनिट टेस्ट से धीमे चलते हैं और अधिक पूर्ण परिवेश माँगते हैं। बदले में वे "टेस्ट पास हो गया" और "एप्लिकेशन असली डेटाबेस के साथ यह काम कर सकता है" के बीच की दूरी घटाते हैं।

सीमा-परीक्षण बड़े आंतरिक रीफ़ैक्टर की गुंजाइश छोड़ते हैं। एजेंट मॉड्यूल पुनर्गठित कर सकता है, सेवा को बाँट सकता है या डेटा-एक्सेस परत बदल सकता है, जबकि सार्वजनिक व्यवहार सुरक्षित रहता है।

Uncle Bob अलग मिश्रण पसंद करते हैं — यूनिट टेस्ट, Gherkin और म्यूटेशन टेस्टिंग का भारी उपयोग। साझा सिद्धांत है स्वतंत्र सत्यापन। जिस प्रक्रिया ने कोड बनाया, वही यह दावा करने वाली इकलौती स्रोत नहीं होनी चाहिए कि कोड काम करता है।

कोडिंग एजेंट्स को पूर्ण फ़ीडबैक लूप देना

हमारे शुरुआती कोडिंग-एजेंट रन अक्सर एक जानी-पहचानी रिपोर्ट पर ख़त्म होते थे: कोड बदल दिया गया और TypeScript पास है; कृपया एप्लिकेशन चलाकर पेज देख लें।

इससे विकास लूप का आधा हिस्सा इंजीनियर के पास रह जाता है। किसी को अब भी डेटाबेस तैयार करना है, सेवाएँ चलानी हैं, ब्राउज़र खोलना है, डेटा बनाना है, विफलता देखनी है और उसे एजेंट को वापस समझाना है।

अब एजेंट्स के पास इतना विकास परिवेश है कि वे इसका बड़ा हिस्सा ख़ुद कर सकें। वे एप्लिकेशन और डेटाबेस चालू कर सकते हैं, माइग्रेशन चला सकते हैं, टेस्ट डेटा बना सकते हैं, पुल-रिक्वेस्ट प्रीव्यू खोल सकते हैं और असली ब्राउज़र इंटरैक्शन कर सकते हैं।

ब्राउज़र सत्यापन उन समस्याओं का एक वर्ग पकड़ता है जिन्हें टाइप जाँच और API टेस्ट ठीक से नहीं ढँकते: टूटा नेविगेशन, लोडिंग स्थितियाँ जो कभी नहीं थमतीं, अनुमति त्रुटियाँ जो केवल पूर्ण प्रवाह में दिखती हैं, और दृश्य प्रतिगमन।

रन के अंत में एजेंट बताता है कि उसने कौन-से कमांड चलाए, कौन-सा रास्ता परखा और क्या देखा। यूज़र-इंटरफ़ेस बदलावों के लिए वह स्क्रीनशॉट भी जोड़ सकता है। इंजीनियर उस प्रमाण को देखकर तय कर सकता है कि ख़ुद प्रीव्यू खोलना है या नहीं।

स्क्रीनशॉट कोई टेस्ट नहीं है और यह साबित नहीं करता कि और कोई ख़राबी नहीं है। पर यह एजेंट का संदर्भ दोबारा जोड़ने की लागत घटाता है। किसी छोटे इंटरफ़ेस बदलाव के लिए, दोहराने योग्य चरण और एक अंतिम स्क्रीनशॉट "शायद ठीक हो गया होगा" वाले संदेश से कहीं अधिक उपयोगी हैं।

एजेंट के काम की गुणवत्ता काफ़ी हद तक इस पर निर्भर करती है कि वह किसी व्यक्ति की प्रतीक्षा किए बिना कितना फ़ीडबैक हासिल कर सकता है।

ट्रंक-बेस्ड डेवलपमेंट से ब्रांचों को छोटा रखना

तेज़ कोड जनरेशन ब्रांचों का बड़ा भंडार बना सकता है।

लंबे समय तक जीवित फ़ीचर ब्रांच मर्ज टकराव, दोहराया काम और बासी संदर्भ जमा करती हैं। जैसे-जैसे पुल रिक्वेस्ट बड़े होते हैं, समीक्षा कठिन और धीमी होती जाती है। हम ट्रंक-आधारित विकास अपनाते हैं ताकि ब्रांच छोटी रहें और main के इर्द-गिर्द लगातार एकीकरण होता रहे।

हमारी मुख्य-ब्रांच नियमावली माँगती है:

• बदलावों के लिए पुल रिक्वेस्ट
• रैखिक इतिहास और स्क्वैश मर्ज
• एक मर्ज क्यू
• Turbo, Rust और सुरक्षा जाँचें
• अनिवार्य गेटों को नियमित रूप से बायपास न करना

ऑटोमेशन भी वही रास्ता अपनाता है। एजेंट पुल रिक्वेस्ट बना सकता है, और कुछ कम-जोखिम रखरखाव कार्यों में स्वतः मर्ज चालू हो सकता है, पर बदलाव फिर भी CI और मर्ज क्यू से गुज़रता है।

पुल रिक्वेस्ट का आकार और आयु यह समझने में मदद करते हैं कि एक सप्ताह में 630 कैसे मर्ज हो सके। छोटा बदलाव कम संदर्भ ढोता है, सत्यापित करना आसान होता है, और उत्पाद कार्य या किसी दूसरी स्वचालित मरम्मत से टकराने की संभावना कम रखता है।

रिपॉज़िटरी की गार्बेज कलेक्शन के रूप में Knip: मृत कोड हटाना

कोड जनरेशन स्वाभाविक रूप से फ़ाइलें और अमूर्तन जोड़ता है। हटाने के लिए अक्सर अलग प्रॉम्प्ट चाहिए।

रीफ़ैक्टर के बाद पुरानी फ़ाइलें रिपॉज़िटरी में बची रह सकती हैं। किसी फ़ीचर को हटाने पर एक्सपोर्ट, डिपेंडेंसी और एंट्री पॉइंट पीछे छूट सकते हैं। ये अवशेष शायद ही टेस्ट तोड़ते हैं, पर समय के साथ कोडबेस में चलना कठिन बना देते हैं।

हम Knip से अप्रयुक्त फ़ाइलें, एक्सपोर्ट, डिपेंडेंसी और एंट्री पॉइंट ढूँढ़ते हैं। TypeScript पुष्टि कर सकता है कि कोड वैध है; Knip पूछता है कि क्या वह अब भी सिस्टम में भाग ले रहा है।

इस अवशेष की कोडिंग एजेंट्स के लिए अतिरिक्त लागत है। रिपॉज़िटरी उनके सबसे महत्वपूर्ण संदर्भ स्रोतों में से एक है। कोई पुराना हेल्पर या छोड़ा गया कार्यान्वयन अगले पढ़ने वाले एजेंट को स्वीकृत पैटर्न जैसा लग सकता है।

मृत कोड हटाने से भविष्य के रन को मिलने वाले इनपुट भी सुधरते हैं। Knip इस काम का नियतात्मक हिस्सा इतनी तेज़ी से निपटाता है कि वह नियमित गुणवत्ता जाँच बन सके।

"AI स्लॉप" की सफ़ाई करने वाले आवर्ती वर्कफ़्लो

Knip और ESLint की सीमाएँ स्पष्ट हैं। ह्रास के कई रूपों के लिए प्रोजेक्ट संदर्भ और अर्थगत विवेक चाहिए।

हम इस अवशेष के लिए व्यावहारिक लेबल "AI स्लॉप" इस्तेमाल करते हैं: अनावश्यक फ़ॉलबैक, दोहराए गए अमूर्तन, सार्वजनिक सीमा को बायपास करते टेस्ट, या असंभव स्थितियों के लिए रक्षात्मक शाखाएँ। हर उदाहरण अलग से हानिरहित लग सकता है। कुल मिलाकर वे रिपॉज़िटरी को समझना कठिन बनाते हैं और भविष्य के एजेंट्स को ख़राब उदाहरण देते हैं।

vm0 पर कई आवर्ती वर्कफ़्लो इन पैटर्नों को खँगालते हैं।

दैनिक AI-स्लॉप सफ़ाई नया अवशेष ढूँढ़ती है और उच्च-विश्वास, कम-जोखिम वाले कुछ ही सुधार चुनती है। अन्य वर्कफ़्लो उन API टेस्टों की जाँच करते हैं जो आंतरिक सेवाओं तक पहुँचते हैं, साथ ही React और ccstate के एंटीपैटर्न और सुरक्षित रूप से निपटाई जा सकने वाली तकनीकी उधारी।

हर वर्कफ़्लो अपने बदलाव सीमित रखता है। वह पुल रिक्वेस्ट खोलता है, फिर सामान्य टाइप जाँचों, लिंट नियमों, टेस्ट और मर्ज क्यू पर भरोसा करता है। स्वतः मर्ज के लिए कॉन्फ़िगर किया पुल रिक्वेस्ट भी वही गेट पार करता है।

ये वर्कफ़्लो एक ही बार में पूरी तकनीकी उधारी चुकाने की कोशिश नहीं करते। रोज़ का छोटा बैच कुछ महीनों में एक बड़ी सफ़ाई से सत्यापित करना आसान और कम विघटनकारी होता है।

जब कोई आवर्ती वर्कफ़्लो एक ही पैटर्न पर्याप्त बार पकड़ लेता है, तो हम उस जाँच को ESLint, Knip या टाइप सिस्टम में ले जाने पर विचार करते हैं। अर्थगत वर्कफ़्लो नियम को देखने और निखारने की जगह है, इससे पहले कि वह सस्ती नियतात्मक जाँच बने।

ये आवर्ती vm0 वर्कफ़्लो एक तय समय-सारणी पर चलते हैं।

अस्थिर टेस्ट विफलताओं को स्वचालित मरम्मत में बदलना

वर्कफ़्लो का एक और समूह GitHub Actions की विफलताओं से शुरू होता है।

जब मुख्य ब्रांच या मर्ज क्यू में कोई टेस्ट विफल होता है, तो एक वर्कफ़्लो लॉग पढ़ता है, अस्थिरता के प्रमाण खोजता है, और रीट्राई, समय तथा परिवेशगत कारक देखता है। यदि प्रमाण किसी विशिष्ट मरम्मत का समर्थन करते हैं, तो वह टेस्ट या कार्यान्वयन अपडेट करता है, पुल रिक्वेस्ट खोलता है और पूरा CI रास्ता दोबारा चलाता है।

रीट्राई पर पास हो जाना मूल विफलता को हानिरहित नहीं बनाता। जो टीमें रीट्राई बटन पर निर्भर होती हैं, वे धीरे-धीरे लाल बिल्ड पर भरोसा खो देती हैं। ऐसा होते ही विफल जाँचें भी पृष्ठभूमि शोर का एक और रूप बन जाती हैं।

स्वचालित मरम्मत वर्कफ़्लो रुक-रुककर होने वाली विफलता को ट्रेस करने योग्य कोड बदलाव में बदल देता है। निदान, पैच और सत्यापन पुल रिक्वेस्ट में दिखते रहते हैं। इंजीनियर अधिक जोखिम वाले बदलाव जाँच सकते हैं, जबकि मज़बूत प्रमाण वाले सीमित सुधार मर्ज क्यू से आगे बढ़ सकते हैं।

हमारी गुणवत्ता व्यवस्था में फ़िलहाल तीन व्यापक परतें हैं:

चरण	तंत्र	विशिष्ट चिंताएँ
लिखते समय	TypeScript, कॉन्ट्रैक्ट, Drizzle, ESLint	टाइप त्रुटियाँ, इंटरफ़ेस खिसकना, ज्ञात कोड पैटर्न
मर्ज से पहले	Knip, इंटीग्रेशन टेस्ट, असली डेटाबेस, प्रीव्यू, मर्ज क्यू	मृत कोड, मॉड्यूल व्यवहार, पूर्ण रनटाइम परिणाम
मर्ज के बाद	निर्धारित और घटना-चालित vm0 वर्कफ़्लो	AI स्लॉप, अर्थगत एंटीपैटर्न, अस्थिर टेस्ट, आर्किटेक्चरल खिसकाव

परतें एक-दूसरे को पोसती हैं। वर्कफ़्लो से मिली समस्याएँ स्थैतिक नियम बन सकती हैं। CI या प्रोडक्शन में मिली विफलताएँ टेस्ट और नए इंजीनियरिंग दिशानिर्देश बन सकती हैं।

एजेंट लगातार चलाने की लागत होती है, और उसे कम करने पर हमने अलग से लिखा है।

AI-जनित कोड की समीक्षा में मानवीय ध्यान कहाँ जाता है

vm0 के इंजीनियर अब भी कोड पढ़ते हैं, ख़ासकर आर्किटेक्चरल बदलावों, सुरक्षा-संवेदनशील काम, भुगतान और डेटा माइग्रेशन में। हमने "कभी कोड मत पढ़ो" को टीम नियम नहीं बनाया।

जो बदला है वह ध्यान का बँटवारा है। कोड पढ़ना अब कॉन्ट्रैक्ट, टेस्ट सीमाओं, प्रीव्यू व्यवहार, स्क्रीनशॉट, गुणवत्ता मेट्रिक्स और वर्कफ़्लो निदान के बीच एक संकेत भर है।

कई निर्णयों के लिए अब भी अनुभवी विवेक चाहिए:

• क्या आवश्यकता पूर्ण है
• मॉड्यूल सीमाएँ कहाँ होनी चाहिए
• कौन-सी विफलताएँ पुनर्प्राप्य हैं
• कोई ख़राबी कितना व्यावसायिक प्रभाव पैदा कर सकती है
• क्या सुरक्षा मॉडल उपयुक्त है
• मौजूदा नियम किस नए विफलता पैटर्न को नहीं ढँकते

इंजीनियर एजेंट्स के इर्द-गिर्द का परिवेश भी सँभालते हैं। जब कोई समस्या दोहराई जाती है, तो हम तय करते हैं कि टाइप बाध्यता जोड़नी है, लिंट नियम, टेस्ट या आवर्ती वर्कफ़्लो। विकास प्रणाली अपने आप में एक महत्वपूर्ण इंजीनियरिंग कलाकृति बन चुकी है।

पठनीय कोड अब भी मायने रखता है। अगला पाठक कोई इंजीनियर हो सकता है या कोई दूसरा एजेंट। उलझा हुआ कोड अधिक संदर्भ खाता है, भविष्य के बदलावों का दायरा बढ़ाता है, और सत्यापन को कम भरोसेमंद बनाता है।

ऐसा ही बदलाव डिज़ाइन की तरफ़ हुआ, जहाँ design-as-code ने दृश्य निर्णयों को उसी रिपॉज़िटरी और उसी समीक्षा-मार्ग में ला दिया।

सुरक्षा और वे बदलाव जिनकी रफ़्तार नहीं बढ़ती

रफ़्तार हर जगह एक जैसी नहीं होती। vm0 के पास बदलावों की एक छोटी सूची है जो अपनी ही गति से चलते हैं: सुरक्षा-संवेदनशील काम, भुगतान, डेटा माइग्रेशन और आर्किटेक्चर के निर्णय। इन्हें एक इंजीनियर पंक्ति-दर-पंक्ति पढ़ता है, चाहे उन्हें किसी ने भी लिखा हो।

हमारे अनुभव में AI-जनित कोड का सुरक्षा जोखिम विचित्र कमज़ोरियों से कम और ऐसे प्रशंसनीय दिखने वाले कोड से अधिक जुड़ा है जिसका कोई मालिक नहीं। जो नियंत्रण मायने रखते हैं वे साधारण हैं, बशर्ते लगातार लागू हों:

• यूनिट टेस्ट, जिन्हें हम वैसे कम इस्तेमाल करते हैं, सुरक्षा-संवेदनशील लॉजिक, एल्गोरिद्म और स्टेट मशीनों के लिए जानबूझकर इस्तेमाल होते हैं।
• टेस्ट केवल बाहरी सिस्टम की सीमाओं पर मॉक करते हैं। आंतरिक इन्फ़्रास्ट्रक्चर असली रहता है, इसलिए आंतरिक कॉन्ट्रैक्ट तोड़ने वाला बदलाव प्रोडक्शन के बजाय CI में गिरता है।
• एजेंट dev container के भीतर, हर पुल रिक्वेस्ट की अपनी डेटाबेस ब्रांच पर काम करते हैं — न किसी डेवलपर की मशीन पर, न साझा डेटाबेस पर।
• मर्ज क्यू और अनिवार्य जाँचों का कोई नियमित बायपास नहीं है, उस पुल रिक्वेस्ट के लिए भी नहीं जिसे एजेंट ने खोला और स्वतः-मर्ज के लिए चिह्नित किया।
• try/catch डिफ़ॉल्ट रूप से सीमित है, ताकि मौजूदा रास्ता चलाते रहने के लिए एजेंट द्वारा जोड़े गए फ़ॉलबैक में कोई विफलता दब न जाए।

क्रेडेंशियल संभालना एक अलग डिज़ाइन समस्या है जिसका उत्तर भी अलग है: टोकन को एजेंट की पहुँच से बाहर रखने वाले ब्रोकर पैटर्न पर हमने अलग लेख लिखा है।

इनमें से कुछ भी अपने आप जनित कोड को सुरक्षित नहीं बनाता। यह उन बदलावों का दायरा घटाता है जहाँ मानवीय निर्णय ही एकमात्र नियंत्रण है, और उस दायरे को स्पष्ट कर देता है।

ये आँकड़े क्या नहीं दिखाते

साप्ताहिक रिपोर्ट रिपॉज़िटरी का पैमाना और डिलीवरी की गति दिखाती है। यह अपने आप प्रोडक्शन विश्वसनीयता नहीं दिखाती।

रनटाइम गुणवत्ता पर असर आँकने के लिए उपलब्धता, प्रोडक्शन त्रुटि दर, घटना संख्या, बदलाव-विफलता दर, रोलबैक आवृत्ति और औसत पुनर्प्राप्ति समय चाहिए। हरी CI डिलीवरी प्रक्रिया के एक हिस्से का ब्योरा देती है।

हम उन परिणाम-मापों को जुटाना जारी रखे हुए हैं। इंजीनियरिंग पद्धतियाँ बताती हैं कि सिस्टम जोखिम कैसे सँभालता है; प्रोडक्शन डेटा दिखाता है कि वह सँभाल कितनी अच्छी तरह काम करती है।

अक्सर पूछे जाने वाले प्रश्न

वाइब कोडिंग क्या है? वाइब कोडिंग यानी LLM से कोड माँगना, जो लौटे उसे चलाना, बदलाव माँगना और उत्पन्न कोड को न पढ़ना। Fowler की परिभाषा जानबूझकर संकीर्ण है: व्यक्ति को "भूल जाना" है कि कोड मौजूद भी है। यह प्रोटोटाइप, फेंक देने लायक सॉफ़्टवेयर और सीमित परिणाम वाले उपकरणों पर फ़िट बैठता है।

एजेंटिक कोडिंग क्या है? एजेंटिक कोडिंग AI-सहायित विकास का लंबा चलने वाला रूप है, जिसमें एजेंट रिपॉज़िटरी पढ़ता है, फ़ाइलें बदलता है, टेस्ट चलाता है और लंबे समय तक ख़ुद दोहराता है। लोग आर्किटेक्चर और व्यवहार के मालिक बने रहते हैं और हर लिखी पंक्ति के बजाय रन के प्रमाण देखते हैं।

वाइब कोडिंग और एजेंटिक कोडिंग में क्या अंतर है? ध्यान का, लेखकत्व का नहीं। वाइब कोडिंग में कोड कभी जाँचा नहीं जाता। एजेंटिक कोडिंग में एजेंट ख़ुद काम करता है जबकि इंजीनियर आसपास के प्रमाण देखते हैं: टेस्ट परिणाम, गुणवत्ता संकेत, प्रीव्यू और प्रोडक्शन व्यवहार। vm0 को आम तौर पर वाइब-कोडेड कहा जाता है; Fowler की शब्दावली में यह एजेंटिक कोडिंग है।

AI स्लॉप क्या है? AI स्लॉप वह अवशेष है जो AI-जनित कोड छोड़ता है: अनावश्यक फ़ॉलबैक, दोहराए गए अमूर्तन, सार्वजनिक सीमा को बायपास करने वाले टेस्ट, असंभव स्थितियों के लिए रक्षात्मक शाखाएँ। हर एक अलग से हानिरहित लगता है। मिलकर वे रिपॉज़िटरी को समझना कठिन बनाते हैं और अगले एजेंट को ख़राब उदाहरण देते हैं।

हर हफ़्ते 630 पुल रिक्वेस्ट पर AI-जनित कोड की समीक्षा कैसे होती है? पंक्ति-दर-पंक्ति नहीं। vm0 में मानवीय समीक्षा वहाँ जाती है जहाँ निर्णय चाहिए: आर्किटेक्चर, सुरक्षा-संवेदनशील काम, भुगतान, डेटा माइग्रेशन। बाक़ी को तंत्र सँभालते हैं: सख़्त टाइप और कॉन्ट्रैक्ट, मॉड्यूल सीमाओं पर इंटीग्रेशन टेस्ट, हर पुल रिक्वेस्ट के प्रीव्यू में असली डेटाबेस, ब्राउज़र सत्यापन, Knip, और बिना नियमित बायपास वाली मर्ज क्यू।

बड़े पैमाने पर वाइब कोडिंग की सर्वोत्तम प्रथाएँ क्या हैं? vm0 में आठ महीनों से पाँच बातें टिकी हैं: विकास परिवेश को अभिसरित करना ताकि एजेंट और लोग एक ही कमांड चलाएँ; मानकों को दस्तावेज़ों के बजाय टाइप, लिंटर और CI में निष्पादन-योग्य बनाना; असली इन्फ़्रास्ट्रक्चर के विरुद्ध मॉड्यूल सीमाओं पर परीक्षण; एजेंट को ब्राउज़र सहित पूर्ण फ़ीडबैक लूप देना; और कभी-कभार बड़ी सफ़ाई के बजाय लगातार सफ़ाई।

AI-जनित कोड के सुरक्षा जोखिम क्या हैं? आम जोखिम कोई विचित्र कमज़ोरी नहीं, बल्कि प्रशंसनीय दिखने वाला वह कोड है जिसका कोई मालिक नहीं। vm0 सुरक्षा-संवेदनशील काम, भुगतान और डेटा माइग्रेशन को मानवीय समीक्षा पर रखता है, उस लॉजिक के लिए यूनिट टेस्ट जानबूझकर इस्तेमाल करता है, टेस्ट में आंतरिक इन्फ़्रास्ट्रक्चर असली रखता है, विफलता दबाने वाले try/catch जैसे पैटर्न सीमित करता है, और अनिवार्य जाँचों का नियमित बायपास नहीं होने देता।

क्या AI-जनित कोड तकनीकी ऋण पैदा करता है? एक ख़ास तरह का: ऐसा कोड जो अब भी कंपाइल होता है और टेस्ट पास करता है पर सिस्टम में भाग नहीं लेता, और साथ में ऐसा शब्दार्थ अवशेष जिसे कोई लिंटर नाम नहीं दे सकता। निर्धारित हिस्सा Knip हटा देता है। बाक़ी को आवर्ती वर्कफ़्लो रोज़ छोटे बैचों में सँभालते हैं, और जो पैटर्न पर्याप्त बार लौटता है वह लिंट नियम या टाइप बंधन बन जाता है।

vm0 का कितना कोड AI लिखता है? अधिकांश इम्प्लीमेंटेशन। 20 से 26 जुलाई 2026 के सप्ताह में मर्ज हुईं 630 पुल रिक्वेस्ट में से 556 छह इंजीनियरों के नाम थीं और बाक़ी रिलीज़ ऑटोमेशन की, और उनके भीतर का ज़्यादातर कोड एजेंट ने लिखा। इंजीनियरों के पास जो रहता है वह है आर्किटेक्चर, बंधन और प्रोडक्शन व्यवहार।

टेस्टिंग ट्रॉफी क्या है, और टेस्ट पिरामिड क्यों नहीं? टेस्टिंग ट्रॉफी में आधार पर स्थैतिक विश्लेषण, प्रमुख परत के रूप में इंटीग्रेशन टेस्ट, और ऊपर कुछ एंड-टू-एंड टेस्ट होते हैं। vm0 इसे इसलिए अपनाता है क्योंकि मॉड्यूल की सार्वजनिक सीमा से लिखे टेस्ट तब भी व्यवहार की रक्षा करते रहते हैं जब एजेंट नीचे का इम्प्लीमेंटेशन दोबारा गढ़ रहा हो — बड़ी यूनिट-टेस्ट परत यह नहीं कर पाती।

AI से लिखी रिपॉज़िटरी में मृत कोड कैसे खोजें? कोड जनरेशन फ़ाइलें और अमूर्तन जोड़ता है; हटाने के लिए आम तौर पर अलग निर्देश चाहिए। vm0 Knip को नियमित जाँच के रूप में चलाता है ताकि अप्रयुक्त फ़ाइलें, एक्सपोर्ट, निर्भरताएँ और एंट्री पॉइंट मिलें। TypeScript बताता है कि कोड वैध है; Knip पूछता है कि वह अब भी सिस्टम में भाग लेता है या नहीं — मृत कोड के लिए यही सवाल मायने रखता है।

क्या वाइब-कोडेड कोड प्रोडक्शन के लिए सुरक्षित है? यह इस पर निर्भर करता है कि उसे कौन सत्यापित करता है, न कि किसने टाइप किया। जिन संकेतों की हम माँग करते हैं वे नहीं बदले: टाइप और कॉन्ट्रैक्ट, सार्वजनिक सीमाओं से होकर टेस्ट, वास्तविक इन्फ़्रास्ट्रक्चर, और एक पाइपलाइन जिसका हरा होना ज़रूरी है। इस लेख के आँकड़े रिपॉज़िटरी के पैमाने और डिलीवरी गति बताते हैं; उपलब्धता, त्रुटि दर और चेंज-फ़ेल्योर दर प्रोडक्शन का प्रश्न सुलझाते हैं, और उन्हें हम अब भी जुटा रहे हैं।

आठ महीने बाद

आठ महीने किसी अंतिम पद्धति की घोषणा के लिए बहुत जल्दी हैं। मॉडल, एजेंट टूल और रिपॉज़िटरी बदलते रहते हैं, और उनके साथ हमारे नियम तथा वर्कफ़्लो भी।

एक बदलाव अभी से स्पष्ट है। जैसे-जैसे कोड जनरेशन तेज़ हुआ, परिवेश, बाध्यताओं, टेस्टों और फ़ीडबैक तंत्र ने गुणवत्ता का अधिक भार उठा लिया। इंजीनियर कार्यान्वयन टाइप करने में कम और व्यवहार परिभाषित करने, सीमाएँ डिज़ाइन करने तथा सत्यापन सुधारने में अधिक समय देते हैं।

vm0 की कोडबेस आगे भी बढ़ती रहेगी। Knip नियतात्मक अवशेष हटाता है। स्थैतिक नियम उन विफलता पैटर्नों को रोकते हैं जिन्हें हम पहले से समझते हैं। इंटीग्रेशन टेस्ट मॉड्यूल व्यवहार की रक्षा करते हैं। आवर्ती वर्कफ़्लो उस ह्रास को सँभालते हैं जिसे हम अभी यांत्रिक रूप से व्यक्त नहीं कर सकते।

कोड अब भी मायने रखता है। बस अब हम यह तय करने के लिए अधिक मशीन-निष्पादन-योग्य प्रमाण इस्तेमाल करते हैं कि कोई बदलाव मुख्य ब्रांच पर आना चाहिए या नहीं, और उसका कार्यान्वयन रिपॉज़िटरी में बना रहना चाहिए या नहीं।