बिल्ड्स खुद को कैसे सत्यापित करते हैं

0:00 — एक बिल्ड पूरा होता है। एजेंट कहता है कि यह हो गया, जो कोड लिखे जाने के बारे में एक दावा है, इस बारे में नहीं कि कोड काम करता है या नहीं। AI बिल्डर के हर उपयोगकर्ता ने इन दोनों दावों के बीच का अंतर कम से कम एक बार महसूस किया है: प्रीव्यू खुलता है, तीसरे बटन पर क्लिक किया जाता है, कुछ नहीं होता। मैंने एक डेमो रूम को ठीक उसी पल पर चुप होते देखा है। इसलिए किसी इंसान के देखने से पहले, बिल्ड लगभग छह मिनट की एक चेन से गुज़रता है जो खुद से बहस करती है। यहां बताया गया है कि यह वास्तव में कैसा दिखता है, एक बिल्ड को ट्रेस करते हुए जो हमने बिगड़ते और फिर ठीक होते देखा।

0:02 — कोड रिव्यू शुरू होता है। यह वह एजेंट नहीं है जिसने कोड लिखा और अब अपना खुद का होमवर्क दोबारा पढ़ रहा है — बल्कि एक अलग एजेंट है, अलग प्रॉम्प्ट, बिल्ड पास होने में कोई हिस्सेदारी नहीं। यह अलगाव उतना ज़्यादा मायने रखता है जितना सुनने में लगता है। एक एजेंट जिसने दोपहर 2:14 बजे तय किया कि एरर हैंडलिंग के बिना एक fetch कॉल ठीक है, वह 2:15 बजे भी ऐसा ही सोचेगा अगर आप उससे अपना काम जांचने को कहें। एक नया रिव्यूअर जिसे बताया गया है "जो टूटा है उसे ढूंढो, फ़ाइल का हवाला दो," वह उस चिड़चिड़े सीनियर इंजीनियर की तरह व्यवहार करता है जिसे आप वास्तव में इस ड्यूटी पर चाहते हैं। एक पिछले बिल्ड में इसने एक कार्ट टोटल पकड़ा जो चुपचाप कभी अपडेट नहीं होता था — `updateTotal` `Cart.jsx` में डिफ़ाइन तो था लेकिन क्वांटिटी-चेंज हैंडलर से कभी जुड़ा नहीं था, इसलिए फ़ंक्शन मौजूद था और बस कभी चला ही नहीं। यही वह कैटेगरी है जिसके लिए कोड रिव्यू है — ऐसी चीज़ें जिन्हें कंपाइलर अनदेखा कर देता है।

0:04 — सिक्योरिटी ऑडिट। जानबूझकर, यह सुनने में जितना लगता है उससे कहीं संकरा है — यह पेनटेस्ट नहीं है, यह उन कुछ गलतियों के लिए एक पैटर्न हंट है जो AI-जनरेटेड कोड में वास्तव में दिखाई देती हैं। स्ट्रिंग-कॉन्कैटनेटेड SQL। सिर्फ़ क्लाइंट-साइड वैलिडेशन पर इस तरह भरोसा करना जैसे कि यही पूरी कहानी हो। और खास मामला: एक हार्डकोडेड API key, क्योंकि जिस एजेंट ने फीचर लिखा था उसके सामने एनवायरनमेंट-वेरिएबल कन्वेंशन मौजूद नहीं था और उसने वही तरीका अपनाया जो काम कर गया। हम इसे इतनी बार देखते हैं कि यह अब हैरानी की बात भी नहीं रही।

0:07 — लिंक और SEO। बेजान, और यह वह चीज़ पकड़ता है जिसे कोई तब तक नोटिस नहीं करता जब तक ग्राहक नहीं करता: एक नैव लिंक जो /pricing की ओर इशारा करता है जबकि पेज वास्तव में यहां जनरेट हुआ था /price, एक साइटमैप एंट्री जो किसी 404 होने वाले पेज के लिए है, एक मेटा डिस्क्रिप्शन जो अभी भी टेम्पलेट प्लेसहोल्डर टेक्स्ट रख रहा है। इनमें से कुछ भी बिल्ड को नहीं तोड़ता। लेकिन यह सब चुपचाप उस चीज़ को खत्म कर देता है जिसके लिए हमारे ज़्यादातर यूज़र्स ने साइट बनाई थी — खोजे जाना, क्लिक किया जाना।

0:09 — एक्सेसिबिलिटी। यह एक ऑटोमेटेड axe-core पास है, पूरी मैनुअल ऑडिट नहीं, और यह ईमानदार होने लायक है कि इस ट्रेड-ऑफ़ से क्या मिलता है। axe-core कंट्रास्ट अनुपात, गुम alt टेक्स्ट, बिना लेबल के फॉर्म इनपुट, टैब-ऑर्डर ट्रैप — यानी मैकेनिकल लेयर पकड़ता है, यह पूर्ण WCAG रिव्यू में फ़्लैग होने वाली चीज़ों का लगभग 30-40% है। यह ऐसी स्क्रीन रीडर अनुभव नहीं पकड़ेगा जो तकनीकी रूप से कंप्लायंट है लेकिन उपयोग में वास्तव में भ्रमित करने वाला है। हमने ऑटोमेटेड-ओनली इसलिए चुना क्योंकि यह सेकंडों में चलता है और यहां जो ज़्यादातर बनता है वह मार्केटिंग साइट्स और छोटे टूल्स हैं, न कि वह तरह का ऐप्लिकेशन जहां आंशिक ऑडिट किसी के लिए असली जोखिम हो।

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

0:13 — ब्राउज़र-में जांच, और यहीं हमारा बिल्ड वास्तव में टूटा। यह लेयर बना पाना सबसे मुश्किल है क्योंकि यह कोड नहीं पढ़ती, बल्कि एक असली ब्राउज़र चलाती है — क्लिक करती है, टाइप करती है, इंतज़ार करती है, जांचती है कि DOM वैसे ही बदला जैसा होना चाहिए था। जिस बिल्ड की बात हो रही थी वह एक इडल गेम था, और गेम्स को यहां एक अतिरिक्त पास मिलता है क्योंकि एक गेम पिक्सेल-परफ़ेक्ट रेंडर हो सकता है और फिर भी अनप्लेएबल हो सकता है — स्कोर डिस्प्ले पूरी तरह ठीक दिख सकता है जबकि स्कोरिंग लॉजिक से पूरी तरह डिस्कनेक्ट हो। वेरिफ़ायर ने इसे खेला। स्कोर ठीक अपडेट हुआ। ऑडियो से कोई आवाज़ नहीं आई।

तीन राउंड, फिर एस्केलेशन

यह फाइंडिंग हमारे पास बग रिपोर्ट के रूप में नहीं आई — यह सीधे फिक्स पास में गई, और चेन ने दोबारा वेरिफ़ाई किया, बिल्ड के भीतर तीन राउंड तक। राउंड एक: फिक्स ने मिक्सर इनिशियलाइज़ेशन को छुआ, जो पहले से ठीक था, इसलिए ऑडियो साइलेंट रहा। राउंड दो: एक अलग फिक्स ने एक लोडिंग-स्टेट एज केस को संबोधित किया जो नज़दीकी लगा, और — यह जितना आप उम्मीद करेंगे उससे ज़्यादा होता है — मूल समस्या हल न करते हुए एक नई छोटी समस्या पैदा कर दी। राउंड तीन: अब भी साइलेंट, और इस बिंदु पर आप आमतौर पर या तो वाकई कुछ मुश्किल देख रहे होते हैं या एक फ़ॉल्स अलार्म, और यह मुश्किल वाला ही था।

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

अगली बार मैं क्या छोड़ूँगा

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

इस नियम की एक असली कीमत है, और मैं इसे छुपाऊंगा नहीं: एक अस्पष्ट-लेकिन-सच्ची चिंता जैसे "यह API डिज़ाइन छह महीने में किसी को परेशान करेगा" अब नज़रअंदाज़ हो जाती है, क्योंकि एक वेरिफ़ायर इसे किसी ठोस फेलियर से नहीं जोड़ सकता। हमने इस ट्रेड-ऑफ़ के साथ समझौता कर लिया है। एक चेन जो आर्किटेक्चर रिव्यू भी करती है वह हर एक बिल्ड पर चलने के लिए काफ़ी तेज़ नहीं है, और स्पीड ही पूरी वजह है कि इसे किसी इंसान से कराने के बजाय ऑटोमेटिक रूप से चलाया जा रहा है।

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

इनमें से कुछ भी मुफ़्त नहीं है, और कुछ भी अचूक नहीं है। छह लेयर्स प्लस जितने भी फिक्स राउंड लगें, हर बिल्ड में असली समय जुड़ जाता है — एक मिनट से कम में पूरा होने और कई मिनटों में पूरा होने के बीच का अंतर। हम मानते हैं कि यह उस किसी भी चीज़ के लिए सही ट्रेड-ऑफ़ है जिसे आप अपने ग्राहकों के सामने रखने वाले हैं, लेकिन "तेज़" और "वेरिफ़ाइड" विपरीत दिशाओं में खींचते हैं, और हमने वेरिफ़ाइड को चुना। वेरिफ़ायर भी LLM ही हैं, इसलिए वे कभी-कभी किसी ऐसी चीज़ को फ़्लैग कर देते हैं जो वास्तव में टूटी नहीं है, या किसी ऐसी चीज़ को चूक जाते हैं जो टूटी है। एविडेंस रूल और मल्टी-राउंड लूप इसके खिलाफ़ हेज हैं, गारंटी नहीं।

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