JavaScript फ्रेमवर्क की छिपी AI लागत

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

Nolan Lawson, जो सालों से फ्रंटएंड की लोककथाओं को असली बेंचमार्क से बदलने में लगे हैं, ने हाल ही में वह सीधा काम किया जो किसी ने करने की ज़हमत नहीं उठाई थी। उन्होंने एक छोटा लेकिन गैर-मामूली Pokémon ऐप तैयार करवाया, जिसमें सर्च, फ़िल्टरिंग, डिटेल पेज और PokéAPI का डेटा है, और एक कोडिंग एजेंट से उसे बारह अलग-अलग तरीकों से बनवाया: Astro, Next.js, Nuxt, SvelteKit, React Router, SolidStart, Qwik, Angular, TanStack Start, htmx के साथ Hono, Lit के साथ Gracile, और बिना किसी UI फ़्रेमवर्क वाला सादा Vite। हर फ़्रेमवर्क के लिए एक ही प्रॉम्प्ट के साथ पाँच स्वतंत्र रन हुए, हर बिल्ड को एक कन्फ़ॉर्मेंस सूट से जाँचा गया ताकि एजेंट धोखा न दे सके, और नतीजों को लागत, समय, टोकन और Lighthouse मेट्रिक्स पर आँका गया। यह कोई परफ़ेक्ट प्रयोग नहीं है, और Lawson खुद यह मानते हैं। लेकिन यह पहली ईमानदार कोशिश है जो मैंने देखी है, उस फ़ैसले पर कीमत का टैग लगाने की, जो ज़्यादातर टीमें सिर्फ़ वाइब्स पर लेती हैं।

बेंचमार्क ने असल में क्या मापा

सेटअप जानबूझकर निष्पक्ष रखा गया था। एजेंट को स्पेक दिया गया, बताया गया कि किसी दिए गए फ़्रेमवर्क का नवीनतम संस्करण इस्तेमाल करे, और आर्किटेक्चर खुद चुनने दिया गया, SSR या CSR, जो चाहे। जहाँ कोई फ़्रेमवर्क आधिकारिक MCP सर्वर, एजेंट स्किल या प्लगइन देता है, वह उपलब्ध कराया गया, ताकि कोई फ़्रेमवर्क यह न कह सके कि ट्रेनिंग डेटा में उसे कम दिखाया गया। कन्फ़ॉर्मेंस टेस्ट रॉ DOM की बजाय accessibility tree पर चले, जो मायने रखता था क्योंकि एक प्रतियोगी shadow DOM से रेंडर करता है। हर फ़्रेमवर्क के पाँच रन हुए और नतीजे मीडियन में दिए गए हैं, सिवाय Angular के, जो दो बार टेस्ट होने लायक ऐप ही नहीं बना पाया, इसलिए उसके कुछ आँकड़े तीन रन से आए हैं।

• बिल्ड लागत प्रति ऐप मीडियन में लगभग $2.67 से $4.97 तक रही, यानी सबसे सस्ते और सबसे महंगे फ़्रेमवर्क के बीच लगभग 2 गुना का अंतर।
• टोकन खपत ने वही कहानी और ज़ोर से कही: सबसे सस्ते स्टैक पर लगभग 4 मिलियन टोकन, और सबसे महंगे पर लगभग 10 मिलियन।
• वास्तविक समय (wall-clock time) लागत के साथ लगभग एक-सा चला, तेज़ सिरे पर लगभग 8 मिनट से धीमे सिरे पर 17 मिनट तक।
• SvelteKit, Gracile+Lit और Angular लगातार सबसे महंगे बिल्ड रहे। Astro और Hono+htmx की जोड़ी लगातार सस्ती रही।
• हैरानी की बात, बिना फ़्रेमवर्क वाला Vite बिल्ड कई असली फ़्रेमवर्क से पीछे रहा। मशीन के लिए भी कुछ स्ट्रक्चर कुछ न होने से बेहतर है।

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

कुछ फ़्रेमवर्क एजेंट को महंगा क्यों बनाते हैं

सालों तक मॉडल ट्रेन और इवैल्यूएट करने के बाद, मुझे नतीजे उतने रहस्यमय नहीं लगते जितने दिखते हैं। तीन तंत्र लगभग पूरे अंतर को समझा देते हैं, और इनमें से किसी का संबंध पारंपरिक अर्थ में कौन सा फ़्रेमवर्क “बेहतर” है, इससे नहीं है।

ट्रेनिंग-डेटा की घनता ही भाग्य है

एजेंटिक युग में React का सबसे बड़ा फ़ायदा उसका प्रोग्रामिंग मॉडल नहीं है, बल्कि यह कि एक दशक के ट्यूटोरियल, GitHub रिपो और Stack Overflow के जवाबों ने उसके मुहावरों को हर फ़्रंटियर मॉडल के वेट्स में संपीड़ित कर दिया है। React लिखने वाला एजेंट ज़्यादातर याद कर रहा होता है। Gracile लिखने वाला एजेंट ज़्यादातर खोज रहा होता है: बेंचमार्क रनों में, जो एजेंट फ़्रेमवर्क को नहीं जानते थे, वे फ़्रेमवर्क की रिपॉज़िटरी क्लोन करने या node_modules से उसका कंपाइल किया हुआ सोर्स पढ़ने लगे। यानी यूज़र का कोड बनने से पहले ही प्राथमिक शिक्षा में टोकन जल गए। यही गतिशीलता आम तौर पर डेवलपर्स के ज्ञान तक पहुँचने का तरीका भी बदल रही है। मैंने लिखा था कि Stack Overflow के फीके पड़ने के साथ डेवलपर ज्ञान के कॉर्पस का क्या होता है, और फ़्रेमवर्क वाला पहलू उसका एक तीखा विशेष मामला है: कम लोकप्रिय टूल्स में सिर्फ़ समुदाय की कमी नहीं होती, मॉडल के अंदर उनकी मौजूदगी भी नहीं होती।

API चर्न एक आवर्ती टोकन टैक्स है

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

लूप में वर्बोसिटी जुड़ती जाती है

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

आपके फ़्रेमवर्क का हर ब्रेकिंग चेंज अब एक ऐसा टैक्स है जिसे कोई न कोई टोकन में चुकाता है, और चेंजलॉग पढ़ने वाले इंसान से अलग, मॉडल इसे हर सत्र में चुकाता है।

एजेंट बेंचमार्क्स की पासे वाली समस्या

यहीं मेरी पुरानी ML इवैल्यूएशन की आदतें काम आती हैं, क्योंकि पूरे अध्ययन की सबसे अहम बात उसकी error bars हैं। LLM आउटपुट एक बिंदु नहीं, एक वितरण है। React Router की मीडियन बिल्ड लागत Hono+htmx से लगभग एक डॉलर ज़्यादा थी, फिर भी React Router का सबसे सस्ता अकेला रन Hono के सबसे महंगे रन से भी कम था। रेंज काफ़ी हद तक ओवरलैप करती हैं। SvelteKit के रन लगभग $3.20 से $6.80 तक डोले। कभी-कभी एजेंट बस कम पासा फेंकता है, भटक जाता है, और फ़्रेमवर्क से कोई लेना-देना न होने वाली वजहों से कुछ मिलियन टोकन फूँक देता है।

टूलिंग उपयोग का डेटा भी यही बात कहता है। फ़्रेमवर्क्स ने MCP सर्वर और स्किल फ़ाइलें भेजीं, और एजेंटों ने उन्हें इस्तेमाल किया... कभी-कभी। Nuxt का MCP सर्वर पाँच रनों में एक बार भी नहीं छुआ गया। TanStack Start की स्किल फ़ाइलें पाँच में से दो रनों में मिलीं। React Router का स्किल हर बार इस्तेमाल हुआ। वही प्रॉम्प्ट, वही हार्नेस, बिल्कुल अलग व्यवहार, यही इस टूल की स्टोकैस्टिक प्रकृति है। इसका मतलब है कि “फ़्रेमवर्क X एजेंट्स के लिए बहुत बेहतर है, मैंने अपना पूरा ऐप फिर से लिख दिया” वाला हर ट्विटर थ्रेड, जो एक दोपहर के वाइब-कोडिंग पर आधारित है, असल में शोर माप रहा है। एक रन एक किस्सा है। अगर आप AI लागत को आर्किटेक्चर के फ़ैसले पर असर डालने देने वाले हैं, और मेरे हिसाब से आपको देना चाहिए, तो किसी भी बात पर भरोसा करने से पहले दोहराए गए रनों के मीडियन की माँग करें, इस बेंचमार्क के बारे में भी।

आउटपुट क्वालिटी पर, सब कुछ ठीक-ठाक पर आ जाता है

सबसे हैरान करने वाली बात वह है जो बदली ही नहीं। Lighthouse Performance, Accessibility और Cumulative Layout Shift के स्कोर सभी बारह स्टैक्स में लगभग संतृप्त थे, लगभग हर जगह 99 और 100। साफ़ स्पेक और कन्फ़ॉर्मेंस सूट दिया जाए, तो आधुनिक एजेंट लगभग किसी भी फ़्रेमवर्क में सक्षम, एक्सेसिबल छोटे ऐप बना देते हैं। क्वालिटी का फ़्लोर इतना ऊपर उठ चुका है कि कंटेंट-केंद्रित साइट पर फ़्रेमवर्क आउटपुट में बहुत कम फ़र्क डालता है।

सिर्फ़ एक क्वालिटी मेट्रिक में असली अंतर था: भेजे गए JavaScript बाइट्स। islands-शैली के Astro और Hono+htmx बिल्ड में शून्य KiB, और सबसे भारी SPA आउटपुट में लगभग 142 KiB तक। Total Blocking Time हर जगह मामूली रहा, और LCP इतना शोरभरा था कि उससे ज़्यादा कुछ पढ़ना मुश्किल था। यहाँ दो ईमानदार चेतावनियाँ लागू होती हैं। टेस्ट ऐप Figma की बजाय Wikipedia के ज़्यादा करीब है, जो मल्टी-पेज आर्किटेक्चर को फ़ायदा देता है, और Lighthouse खुद SPAs के खिलाफ़ संरचनात्मक रूप से पक्षपाती है। फिर भी, वेनिला-JavaScript वाला नतीजा रुककर देखने लायक है: बिना किसी फ़्रेमवर्क के सादा Vite इस्तेमाल करने वाले एजेंट ने कई असली फ़्रेमवर्क से खराब स्कोर दिए, जिसमें किसी भी बिल्ड का सबसे ज़्यादा लेआउट शिफ़्ट भी शामिल है। फ़्रेमवर्क कन्वेंशन्स को एन्कोड करते हैं, और एजेंट कन्वेंशन्स पर भारी निर्भर होते हैं। मॉडल को एक जानी-पहचानी लीक दे दो, तो वह उसी में रहता है; खाली मैदान दो, तो वह जुगाड़ करता है, हमेशा अच्छी तरह नहीं।

यह बेंचमार्क आपको क्या नहीं बता सकता

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

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

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

आपके अपने स्टैक की AI लागत कैसे मापें

किसी और के बेंचमार्क से, इस बेंचमार्क समेत, अपने कोडबेस का अनुमान न लगाएँ। आपकी रिपो, आपका स्पेक और आपका पसंदीदा मॉडल अपना अलग वितरण पैदा करेंगे। अच्छी खबर यह है कि AI लागत मापना सचमुच आसान है, क्योंकि कोडिंग एजेंट पहले से वह सब रिपोर्ट करते हैं जो आपको चाहिए। अगर आप इंस्ट्रूमेंट करने से पहले समझना चाहते हैं कि लूप, कॉन्टेक्स्ट और परमिशन आपस में कैसे काम करते हैं, तो हमारा लेख एजेंटिक कोडिंग CLI असल में कैसे काम करता है एक अच्छी नींव है। फिर यह करें:

1. अपने असली काम का एक वर्टिकल स्लाइस चुनें, ऐसा फ़ीचर जो आपके डेटा लेयर, स्टेट मैनेजमेंट और UI को छुए, लैंडिंग पेज नहीं।
2. पहले कन्फ़ॉर्मेंस टेस्ट लिखें। टेस्ट आपका क्वालिटी गेट भी हैं और धोखाधड़ी रोकने का उपाय भी; बिना टेस्ट के एजेंट जल्दी जीत की घोषणा कर देता है।
3. हर उम्मीदवार स्टैक या कॉन्फ़िगरेशन पर एक ही प्रॉम्प्ट कम से कम पाँच बार चलाएँ। मीडियन और रेंज रिपोर्ट करें, कभी अकेला रन नहीं।
4. कुल टोकन (कैश रीड, इनपुट और आउटपुट में बँटे हुए), वास्तविक समय, लागत, और टूल कॉल व रिट्राई लूप की संख्या लॉग करें।
5. ट्रैक करें कि कितने टोकन डॉक्यूमेंटेशन रीड्स में जा रहे हैं, जैसे माइग्रेशन गाइड, चेंजलॉग और node_modules की खोजबीन। यही आपका ट्रेनिंग-डेटा-कमी वाला टैक्स है, सीधे मापा हुआ।
6. बड़े फ़्रेमवर्क अपग्रेड के बाद बेंचमार्क फिर से चलाएँ। जैसे-जैसे API बदलते हैं और ट्रेनिंग कटऑफ़ आगे बढ़ते हैं, AI लागत बदलती है।

हार्नेस खुद एक दोपहर की स्क्रिप्टिंग हो सकता है। यह मेरा इस्तेमाल किया हुआ ढाँचा है। CLI फ़्लैग्स की बारीकियाँ आपके एजेंट पर निर्भर करेंगी, लेकिन ढाँचा सार्वभौमिक है:

import json
import statistics
import subprocess
FRAMEWORKS = ["astro", "react-router", "sveltekit"]
RUNS = 5
SPEC = open("spec.md").read()
def build_once(framework: str) -> dict:
"""One full agent session: build the app, return usage stats."""
result = subprocess.run(
[
"agent-cli", "run",
"--prompt", SPEC,
"--context", f"Build this with the latest {framework}.",
"--output-format", "json",
],
capture_output=True,
text=True,
check=True,
)
return json.loads(result.stdout)
for framework in FRAMEWORKS:
runs = [build_once(framework) for _ in range(RUNS)]
costs = [r["cost_usd"] for r in runs]
tokens = [r["tokens_total"] for r in runs]
print(
f"{framework}: "
f"median ${statistics.median(costs):.2f} "
f"(range ${min(costs):.2f}-${max(costs):.2f}), "
f"median {statistics.median(tokens) / 1e6:.1f}M tokens"
)

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

व्यावहारिक निष्कर्ष

तो क्या आपको अपना Angular ऐप इसलिए Astro में बदल देना चाहिए कि एजेंट्स के लिए वह सस्ता पड़ता है? नहीं। डॉलर का अंतर छोटा है, वेरिएंस बड़ा है, टेस्ट ऐप एक खिलौना है, और आपका माइग्रेशन एक दशक में जितने टोकन बचाएगा, उससे ज़्यादा एजेंट टोकन खर्च कर देगा। “एजेंट्स के लिए” फ़्रेमवर्क माइग्रेशन बेचने वाला कोई भी व्यक्ति वही वाइब्स-आधारित तर्क दे रहा है जो इंडस्ट्री हमेशा से करती आई है, बस ऊपर एक नई वजह चिपका दी गई है।

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