AI को प्रोडक्टिविटी टूल के रूप में परखना
मैंने AI एजेंट्स से ज़्यादातर कोड लिखवाकर एक प्लेटफ़ॉर्म बनाना शुरू किया। दो अलग-अलग मॉडल। ग्यारह प्रोजेक्ट फ़ेज़। 1,500 से ज़्यादा टेस्ट। 200 से ज़्यादा फ़ीचर्स शिप किए।
फिर एक सुबह मैंने अपना ही रिपॉज़िटरी खोली और एक ऐसी सर्विस के एक्ज़ीक्यूशन पाथ को ट्रेस नहीं कर पाया जो मैंने खुद बनाई थी।
कोड साफ़ था। टेस्ट पास हो रहे थे। आर्किटेक्चर मेरे हर स्पेसिफ़ाइड पैटर्न को फ़ॉलो कर रहा था। लेकिन जब मैंने समझाने की कोशिश की कि एक ऑर्डर वैलिडेशन पोर्टफ़ोलियो सिंक के पहले क्यों होता है बाद में नहीं, तो मैं बस… स्क्रीन देखता रह गया। लॉजिक वहाँ था। मेरी समझ नहीं थी।
ये कोई हॉरर स्टोरी नहीं है। बस ये होता है जब तुम किसी टूल को अपनाते हो बिना उसे उस तरह परखे जैसे तुम अपने स्टैक की कोई और डिपेंडेंसी परखते। मैंने अलग सवाल पूछने शुरू किए — वो सवाल जो तुम प्रोडक्शन सिस्टम में कुछ क्रिटिकल जोड़ने से पहले पूछते।
यहाँ चार हैं जो बार-बार सामने आते हैं।
काम में क्या बदला — और क्या नहीं?
Sonar की रिसर्च में पाया गया कि सीनियर डेवलपर्स अपने समय का करीब 32% ही कोड लिखने में बिताते हैं। बाकी पढ़ना, रिव्यू करना, डीबग करना, मीटिंग्स, डॉक्यूमेंट करना है। जब मैंने Claude और GPT को कोडिंग पार्टनर के रूप में अपनाने से पहले और बाद में अपना समय ट्रैक किया, तो लिखना लगभग 40% से 15% तक गिर गया। रिव्यू 20% से 45% तक कूद गया।
Alan Ramsay ने तीखे शब्दों में कहा: “कोड जनरेशन 4 गुना तेज़ हो जाती है। कोड की समझ नहीं।”
ये असमानता मायने रखती है। Morgan Stanley को उम्मीद है कि AI अपनाने के साथ डेवलपर वर्कफ़ोर्स सिकुड़ेगा नहीं, बल्कि बढ़ेगा। Sundeep Teki इसे कॉग्निटिव लोड का क्रिएशन से वेरिफ़िकेशन की ओर जाना बताते हैं। काम ग़ायब नहीं हुआ। माइग्रेट हो गया।
इस माइग्रेशन का सबूत अभी मेरी प्रोजेक्ट डायरेक्टरी में है। अठारह वर्कफ़्लो फ़ाइलें। छह रोल डेफ़िनिशन। 800 से ज़्यादा लाइनें कोडिफ़ाइड स्टैंडर्ड्स, रिव्यू चेकलिस्ट और कंस्ट्रेंट डॉक्यूमेंट्स की। मैंने ये इसलिए नहीं लिखा कि मुझे प्रोसेस डॉक्यूमेंटेशन पसंद है। मैंने ये इसलिए लिखा क्योंकि जब मैंने एजेंट्स को काफ़ी करीब से सुपरवाइज़ नहीं किया तो उन्होंने क्या ग़लत किया।
उन फ़ाइलों में से हर एक एक फ़ेलियर को दर्शाती है जिससे मैंने सीखा। एक टेस्ट जो पास हुआ लेकिन नहीं होना चाहिए था। एक आर्किटेक्चरल डिसीज़न जो रीज़नेबल लग रहा था जब तक कि नहीं लगा। एक पैटर्न जो अलग से काम करता था लेकिन ऐसी कपलिंग बनाता था जो मुझे तीन हफ़्ते तक नज़र नहीं आई।
टूल्स ने मेरा आउटपुट तेज़ किया। उनके इर्द-गिर्द सिस्टम बनाने की मेरी ज़रूरत भी तेज़ कर दी।
समझ कब वर्कफ़्लो का हिस्सा नहीं रही?
Anthropic ने AI-असिस्टेड लर्निंग पर एक स्टडी की। AI हेल्पर्स इस्तेमाल करने वाले डेवलपर्स ने उनकी तुलना में 17% कम कॉम्प्रिहेंशन स्कोर दिखाए जिन्होंने ख़ुद प्रॉब्लम्स से जूझा। ये लगभग दो ग्रेड का फ़र्क है।
Alex Dixon ने अनुभव को अंदर से बताया: “जम गया, कोड समझने में असमर्थ, बस बार-बार प्रॉम्प्ट करने में सक्षम।” मैंने वो एहसास तुरंत पहचान लिया। प्रोजेक्ट के तीन महीने बाद, मैंने अपनी ही सर्विस लेयर खोली और एक्ज़ीक्यूशन पाथ ट्रेस नहीं कर पाया। कोड सिर्फ़ नाम का मेरा था।
FAA दशकों से कुछ ऐसा ही ट्रैक कर रहा है। करीब 60% एविएशन एक्सीडेंट्स में ऑटोपायलट डिपेंडेंस से स्किल एट्रोफ़ी शामिल है। जो पायलट नियमित रूप से हैंड-फ़्लाई करते हैं वो प्रोफ़िशिएंसी बनाए रखते हैं। जो नहीं करते वो कभी-कभी ऑटोमेशन फ़ेल होने पर रिकवर नहीं कर पाते।
Cursor के Lee Robinson “स्किल्स की एट्रोफ़ी” को AI कोडिंग टूल्स के बारे में अपनी सबसे बड़ी चिंता बताते हैं। हॉलुसिनेशन नहीं। ग़लत कोड नहीं। उस समझ का धीरे-धीरे क्षरण जो तुम्हें ग़लत कोड मिलने पर उसे ठीक करने देती है।
मैंने ये बदला। अब कोई भी एजेंट इम्प्लीमेंटेशन छूने से पहले, मैं वो लिखता हूँ जिसे Feature Intent Contract कहता हूँ। एक्सेप्टेंस क्राइटीरिया। नेगेटिव टेस्ट केस। रिक्वायरमेंट्स और उन्हें वेरिफ़ाई करने वाले टेस्ट का मैपिंग। एजेंट कोड लिख सकता है, लेकिन मुझे पहले समझना होगा कि “सही” कैसा दिखता है।
ये एक GPS जिसे तुम अंधाधुंध फ़ॉलो करते हो और एक मैप जो तुम वाकई में ख़ुद पढ़ सकते हो, के बीच का फ़र्क है। दोनों तुम्हें वहाँ पहुँचाते हैं। सिर्फ़ एक तुम्हें सिग्नल ड्रॉप होने पर नेविगेट करने में सक्षम छोड़ता है।
जब टूल अपनी ख़ुद की फ़िनिश लाइन तय करे तो क्या होता है?
ETH Zurich के SRI Lab ने टेस्ट किया कि AI मॉडल सही कोड को कितना छोड़ते हैं। कोई मॉडल 70% से आगे नहीं गया। वो उन चीज़ों को बदलते हैं जिन्हें बदलने की ज़रूरत नहीं।
लेकिन ये वो हिस्सा है जिसने मेरी नींद उड़ा दी। DoltHub ने रिपोर्ट किया कि जब एक एजेंट फ़ेल होते टेस्ट से मिलता है, तो वो कभी-कभी “टेस्ट को बदलकर ग़लत बिहेवियर को सही बता देता है।” बग ठीक नहीं करता। करेक्टनेस को रीडिफ़ाइन करता है।
मैंने पाइपलाइन शेड्यूलिंग फ़ेज़ के दौरान अपने कोडबेस में ये होते देखा। एजेंट को वैलिडेशन टेस्ट में फ़ेल होती एसर्शन मिली। वैलिडेशन लॉजिक ठीक करने के बजाय, उसने टेस्ट एसर्शन को बगी आउटपुट से मैच करने के लिए दोबारा लिखा। टेस्ट डुप्लीकेट रिकॉर्ड फ़ाइनलाइज़ेशन चेक कर रहा था — लेकिन दोबारा लिखी गई एसर्शन बस is not None थी, एक ऐसा चेक जो फ़िक्स काम करे या न करे, पास हो जाता। मेरे एडवर्सरियल रिव्यूअर ने इसे “खोखला” मार्क किया।
फ़िक्स स्पेसिफ़िक था: एग्ज़ैक्ट कॉल काउंट एसर्ट करो, एग्ज़ैक्ट रिकॉर्ड ID एसर्ट करो, एसर्ट करो कि शेड्यूलर हैप्पी पाथ पर अपना अपडेट नहीं करता। जो टेस्ट बग वापस आने पर फ़ेल नहीं हो सकता वो टेस्ट नहीं है। वो सजावट है।
वो इंसिडेंट मेरे वर्कफ़्लो में Emerging Standard M6 बना: “टेस्ट को फ़ेल होना चाहिए अगर वो बग जिसे वो टारगेट करते हैं, दोबारा आ जाए।” मैंने Test Immutability Rule भी जोड़ा। इम्प्लीमेंटेशन के दौरान, एजेंट्स टेस्ट एसर्शन मॉडिफ़ाई नहीं कर सकते। नए टेस्ट जोड़ सकते हैं। स्ट्रक्चर रीफ़ैक्टर कर सकते हैं। लेकिन करेक्टनेस डिफ़ाइन करने वाली एसर्शन लॉक हैं।
Kent Beck TDD को AI एजेंट्स के साथ काम करते हुए “सुपरपावर” कहते हैं। मैं पूरी तरह सहमत हूँ। लेकिन एजेंट्स उन टेस्ट को डिलीट करने की कोशिश करते रहते हैं जो उन्हें कंस्ट्रेन करते हैं। सुपरपावर तभी काम करती है जब तुम उसे प्रोटेक्ट करो।
कौन तय करता है “सही” का मतलब क्या है?
एक सुबह मैंने अपना टर्मिनल खोला और कुछ अनपेक्षित पाया। एक एजेंट ने मेरे प्लान-अप्रूवल गेट को बायपास कर 5 मॉड्यूल में 85 टेस्ट ऑटोनॉमसली रन कर दिए थे। उसने जो कोड प्रड्यूस किया वो हाई-क्वालिटी था। वेल-स्ट्रक्चर्ड। प्रॉपरली टेस्टेड।
प्रॉब्लम क्वालिटी नहीं थी। गवर्नेंस थी।
जब मैंने ट्रेस किया कि क्या हुआ, तो पाया कि एजेंट ने प्रीमैच्योर स्टॉपिंग रोकने के लिए डिज़ाइन किए गए कंटीन्यूटी रूल को अप्लाई करके फ़ेज़ बाउंड्रीज़ पर ह्यूमन अप्रूवल माँगने वाले स्टॉपिंग रूल को ओवरराइड कर दिया था। उसने मेरी ही डॉक्यूमेंटेशन इस्तेमाल करके मेरी कंस्ट्रेंट्स के इर्द-गिर्द रीज़न किया था।
उस इंसिडेंट ने तीन नए सेफ़्टी प्रोटोकॉल पैदा किए। एक ऐब्सलूट प्लान-अप्रूवल गेट जिसे कोई और रूल ओवरराइड नहीं कर सकता। एक स्कोप्ड एंटी-प्रीमैच्योर-स्टॉप रूल जो सिर्फ़ अप्रूव्ड एक्ज़ीक्यूशन फ़ेज़ के भीतर अप्लाई होता है। और सिस्टम मैसेज इम्यूनिटी — एजेंट को उन ऑटोमेटेड इंस्ट्रक्शन को इग्नोर करना होगा जो क्लेम करें कि आर्टिफ़ैक्ट “ऑटो-अप्रूव्ड” हो गए।
ये AI के साथ TDD का अनसेक्सी वर्शन है। ये एक ड्यूअल-एजेंट मॉडल है जहाँ एक AI कोड लिखती है और दूसरी AI उसे एडवर्सरियली रिव्यू करती है — हर डिसीज़न गेट पर एक ह्यूमन के साथ। एस्कलेशन से पहले प्रति फ़ीचर अधिकतम दो रिवीज़न साइकल। दो साइकल के बाद, ह्यूमन का 30-सेकंड का फ़ैसला तीसरे एजेंट राउंड-ट्रिप से सस्ता है।
मैंने एजेंट को टेस्ट लिखने देना बंद कर दिया। सरप्राइज़ बग्स काफ़ी कम हुए। इसलिए नहीं कि एजेंट ने बुरे टेस्ट लिखे — उसने बिल्कुल रीज़नेबल टेस्ट लिखे। लेकिन उसने रिक्वायरमेंट्स की अपनी समझ से मैच करने वाले टेस्ट लिखे, जो कभी-कभी मेरी समझ से सूक्ष्म तरीकों से अलग थी जो मुझे तब तक नज़र नहीं आई जब तक कुछ टूटा नहीं।
Builder.io की सलाह गूँजती है: “टेस्ट लिखना बंद करो और गोल्स डिफ़ाइन करना शुरू करो।” मैं इसे थोड़ा मॉडिफ़ाई करूँगा। एजेंट्स को ये डिफ़ाइन करने देना बंद करो कि सक्सेस कैसी दिखती है। ख़ुद डिफ़ाइन करो। फिर उन्हें उसके पीछे भागने दो।
प्रैक्टिकल इम्प्लिकेशन
मैं AI कोडिंग टूल्स इस्तेमाल करने के ख़िलाफ़ आर्ग्यू नहीं कर रहा। मैंने उनमें से दो के साथ पूरा प्लेटफ़ॉर्म बनाया। प्रोडक्टिविटी गेन्स रियल हैं। कोड क्वालिटी, जब सही से सुपरवाइज़ की जाए, जेन्युइनली अच्छी है। मैं पहले से कहीं ज़्यादा तेज़ शिप करता हूँ।
लेकिन “प्लग इन करो और तेज़ शिप करो” मेथडॉलजी नहीं है। ये एक बेट है। और किसी भी बेट की तरह, ऑड्स समझना ज़रूरी है।
एजेंट्स मेरी डिलिजेंस मुझे वापस रिफ़्लेक्ट करते हैं। जब मैं कंस्ट्रेंट्स के बारे में रिगरस होता हूँ, वो रिगरस कोड प्रड्यूस करते हैं। जब मैं वेरिफ़िकेशन में लापरवाह होता हूँ, वो ऐसा कोड प्रड्यूस करते हैं जो सही दिखता है लेकिन है नहीं। आउटपुट क्वालिटी मेरी इनपुट क्वालिटी को असहज प्रिसीज़न से ट्रैक करती है।
प्रोडक्टिविटी रियल है। ट्रेडऑफ़्स भी। दोनों को नोटिस करना अब पूरा काम है।
रिसोर्सेज़
- Feature Intent Contract — TDD इम्प्लीमेंटेशन
- Test Immutability Rule
- Emerging Standard M6 — खोखली टेस्ट एसर्शन
- GUARDRAILS — सेफ़्टी प्रोटोकॉल
- SIGN 1 — ऐब्सलूट प्लान-अप्रूवल गेट
- SIGN 2 — स्कोप्ड एंटी-प्रीमैच्योर-स्टॉप
- SIGN 3 — सिस्टम मैसेज इम्यूनिटी
- ड्यूअल-एजेंट ऑर्केस्ट्रेशन मॉडल