टेक कंपनियां सॉफ़्टवेयर डेवलपमेंट पर AI के प्रभाव को कैसे मापती हैं

 (newsletter.pragmaticengineer.com)
16 पॉइंट द्वारा GN⁺ 2025-09-22 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • AI coding tools के व्यापक अपनाव और बढ़ती लागत के बीच, प्रमुख टेक कंपनियां AI की वास्तविक उपयोगिता को संख्यात्मक रूप से कैसे मापती हैं इसे बहु-स्तरीय metrics के रूप में व्यवस्थित कर रही हैं
  • मुख्य बात है मौजूदा engineering के बुनियादी metrics (जैसे PR throughput, change failure rate) और AI-विशेष metrics (जैसे AI usage rate, time savings, CSAT) को साथ ट्रैक करने वाला hybrid approach
  • टीम/व्यक्ति/cohort के हिसाब से AI उपयोग स्तर के आधार पर विभाजन और पहले-बाद की तुलना के जरिए trends और correlations निकालने वाली experimental mindset पर जोर
  • quality·maintainability·developer experience को speed metrics के साथ लगातार मॉनिटर करके technical debt बढ़ने और अल्पकालिक लाभ के उलटे असर को रोकने के लिए संतुलित डिज़ाइन जरूरी है
  • लंबी अवधि में मापन को agent telemetry और non-coding work areas तक बढ़ाने के संकेत हैं, और अंततः सवाल यही है: क्या AI पहले से महत्वपूर्ण चीजों (quality, time to market, developer experience) को बेहतर बना रहा है?

AI impact discourse और measurement gap

  • LinkedIn आदि पर अक्सर दिखने की तरह, AI कंपनियों के software development के तरीके को बदल रहा है — ऐसे दावे बहुतायत में हैं
    • Google 25%, Microsoft 30% जैसी रिपोर्टें लगातार कह रही हैं कि बड़े पैमाने पर AI code वास्तव में production code के रूप में deploy हो रहा है
    • कुछ founders दावा करते हैं कि AI junior engineers की जगह ले सकता है, वहीं METR research समय की धारणा में विकृति और productivity में गिरावट की संभावना दिखाता है
  • मीडिया AI impact को “कितना code लिखा गया” तक सरल बनाकर पेश करता है, लेकिन इसका नतीजा यह है कि उद्योग इतिहास के सबसे बड़े technical debt के जमाव के जोखिम का सामना कर रहा है
  • LOC (lines of code) को productivity metric के रूप में अनुपयुक्त मानने पर सहमति होने के बावजूद, मापने में आसानी की वजह से यह फिर उभर रहा है, और quality, innovation, release speed, reliability जैसे मूल्यों पर पर्दा पड़ रहा है
  • फिलहाल कई engineering leaders क्या काम कर रहा है और क्या नहीं, इसे स्पष्ट रूप से जाने बिना AI tools पर बड़े फैसले ले रहे हैं
    • LeadDev की 2025 AI Impact Report के अनुसार 60% leaders ने ‘स्पष्ट metrics की कमी’ को सबसे बड़ी चुनौती बताया
    • जमीनी स्तर के leaders performance pressure और LOC-केंद्रित executives के बीच असंतोष महसूस कर रहे हैं, और ज़रूरी जानकारी और वास्तविक measurement के बीच की खाई लगातार बढ़ रही है
  • लेखक ने 10 साल से अधिक समय तक developer tools पर research किया है, और 2021 के बाद से productivity improvement और AI impact measurement advisory पर काम कर रहे हैं
    • DX CTO के रूप में जुड़ने के बाद उन्होंने सैकड़ों कंपनियों के साथ काम करते हुए DevEx, efficiency और AI impact analysis का नेतृत्व किया
  • 2025 की शुरुआत में 400 से अधिक कंपनियों के data के आधार पर AI Measurement Framework का सह-लेखन किया गया
    • यह AI अपनाव और उसके impact को मापने के लिए जरूरी recommended metrics set है, जिसे field research और data analysis के आधार पर बनाया गया है
  • इस लेख में 18 टेक कंपनियां वास्तव में AI impact को कैसे मापती हैं यह देखा गया है, और
    • Google, GitHub, Microsoft आदि के वास्तविक metrics examples
    • क्या प्रभावी है, यह समझने के उपयोगी तरीके
    • AI impact measurement methodology
    • AI impact metrics की definitions और guide साझा किए गए हैं

1. 18 कंपनियों के वास्तविक measurement metrics

  • Google, GitHub, Microsoft, Dropbox, Monzo, Atlassian, Adyen, Booking.com, Grammarly आदि 18 कंपनियों के cases image के रूप में साझा किए गए हैं
  • कंपनियां अलग-अलग approaches अपनाती हैं, लेकिन आम तौर पर वे कुछ core metric groups पर ध्यान देती हैं

  • 1. usage metrics (Adoption & Usage)

    • DAU/WAU/MAU: लगभग सभी कंपनियां AI tools के daily, weekly और monthly active users को track करती हैं
    • usage intensity/usage events: Google, eBay आदि code writing, chat responses, यहाँ तक कि agentic actions तक को granular तरीके से मापते हैं
    • AI tool CSAT: Dropbox, Webflow, Grammarly समेत कई कंपनियां satisfaction surveys भी चलाती हैं

  • 2. productivity metrics (Throughput & Time Savings)

    • PR throughput: GitHub, Dropbox, Webflow, CircleCI समेत कई कंपनियां इसे समान रूप से track करती हैं
    • time savings: प्रति engineer साप्ताहिक बचाए गए समय का measurement (Dropbox, Monzo, Toast, Xero आदि)
    • PR cycle time: Microsoft, CircleCI, Xero, Grammarly आदि में उपयोग

  • 3. quality/stability metrics (Quality & Reliability)

    • Change Failure Rate: GitHub, Dropbox, Adyen, Booking.com, Webflow आदि में यह सबसे आम quality metric है
    • code maintainability/quality perception: GitHub, Adyen, CircleCI आदि इसे DevEx से जोड़कर मूल्यांकन करते हैं
    • bug/revert rate: Glassdoor (bugs की संख्या), Toast (PR revert rate)

  • 4. developer experience metrics (Developer Experience)

    • developer satisfaction/surveys (DevEx, DXI): Atlassian, Webflow, CarGurus, Vanguard आदि में उपयोग
    • Bad Developer Days (BDD): Microsoft ने friction मापने के लिए रचनात्मक रूप से ‘bad developer day’ की अवधारणा अपनाई
    • cognitive load·developer friction: Google, eBay आदि

  • 5. cost और investment metrics (Spend & ROI)

    • AI spending (total & per developer): Dropbox, Grammarly, Shopify जैसे cases में कुछ कंपनियां लागत track करती हैं
    • Capacity worked (utilization rate): Glassdoor मापता है कि tool अपनी maximum potential के मुकाबले कितना इस्तेमाल हुआ

  • 6. innovation/experimentation metrics (Innovation & Experimentation)

    • Innovation ratio / velocity: GitHub, Microsoft, Webflow आदि innovation speed को metric में बदलते हैं
    • A/B tests की संख्या: Glassdoor monthly A/B tests की संख्या को core metric मानता है
  • time savings, PR throughput, change failure rate, active users, innovation rate जैसे outcome metrics और usage behavior metrics को साथ-साथ track किया जाता है
  • अलग-अलग संगठनों में priorities और product context के अनुसार metrics का संयोजन बदलता है, और एक भी universal metric मौजूद नहीं है

2. मजबूत आधार: AI impact measurement का core

  • AI से कोड लिखने पर भी अच्छे software के मानदंड नहीं बदलते। Quality, maintainability और speed अब भी मुख्य हैं
    • इसलिए Change Failure Rate, PR throughput, PR cycle time, developer experience (DevEx) जैसे मौजूदा metrics अब भी महत्वपूर्ण हैं
  • पूरी तरह नए metrics की ज़रूरत नहीं है
    • असली सवाल यह है: “क्या AI उन चीज़ों को बेहतर बना रहा है जो पहले से महत्वपूर्ण थीं?”
    • LOC या adoption rate जैसे surface-level metrics पर रुक जाने से AI impact को ठीक से समझा नहीं जा सकता
  • AI के इस्तेमाल में वास्तव में क्या हो रहा है, यह समझने के लिए नए target metrics की ज़रूरत है
    • AI कहाँ, कितना और किस तरह इस्तेमाल हो रहा है, यह समझकर budget, tool rollout, security और compliance जैसे निर्णयों में उसका उपयोग किया जा सकता है
  • AI metrics ये दिखाते हैं:
    • AI tools अपनाने वाले developers की संख्या और प्रकार कितने हैं?
    • AI कितने कामों और किस तरह के कामों को प्रभावित कर रहा है?
    • लागत कितनी है?
  • मुख्य engineering metrics ये दिखाते हैं:
    • क्या टीम तेज़ी से ship कर रही है
    • क्या quality और reliability बढ़ रही है / घट रही है
    • क्या code maintainability घट रही है
    • क्या AI tools developer workflow में friction कम कर रहे हैं

  • Dropbox के उदाहरण को देखें

    • AI metrics
      • DAU/WAU (दैनिक·साप्ताहिक सक्रिय उपयोगकर्ता)
      • AI tool CSAT (संतुष्टि)
      • प्रति engineer समय की बचत
      • AI पर खर्च
    • Core metrics (Core 4 Framework का उपयोग)
      • Change Failure Rate
      • PR throughput
    • परिणाम
      • साप्ताहिक नियमित AI उपयोगकर्ता = कुल engineers का 90% (industry average 50% से अधिक)
      • AI के नियमित उपयोगकर्ताओं में PR merge 20% बढ़ा + Change Failure Rate घटी
      • सिर्फ adoption rate नहीं, बल्कि यह देखना मुख्य है कि क्या यह organization, team और individual performance में वास्तविक योगदान दे रहा है

3. AI उपयोग स्तर के अनुसार metrics का विश्लेषण

  • यह समझने के लिए कि AI developers के काम करने के तरीके में क्या बदलाव ला रहा है, कई तरह के comparative analyses किए जाते हैं
    • AI users बनाम non-users की तुलना
    • AI tool अपनाने से पहले और बाद के मुख्य engineering metrics की तुलना
    • एक ही user group को ट्रैक करने वाले cohort analysis के ज़रिए AI adoption के बाद के बदलावों का अवलोकन
  • डेटा को सूक्ष्म रूप से विभाजित (slicing & dicing) करके patterns निकाले जाते हैं
    • role, tenure, region, primary language जैसी विशेषताओं के आधार पर analysis
    • उदाहरण: junior developers में PR लिखने की संख्या बढ़ती है, जबकि senior developers में review का हिस्सा बढ़ने से speed धीमी हो जाती है
    • इससे उन groups की पहचान की जा सकती है जिन्हें अतिरिक्त training/support चाहिए और वे groups भी जिन पर AI का प्रभाव सबसे ज़्यादा है
    • Webflow का उदाहरण
      • 3 साल से अधिक tenure वाले developers के group में AI उपयोग पर समय-बचत का प्रभाव सबसे बड़ा था
      • Cursor, Augment Code जैसे tools के उपयोग पर PR throughput 20% बढ़ा (AI users बनाम non-users तुलना)
  • मज़बूत baseline की आवश्यकता
    • जिन organizations के पास developer productivity metrics का आधार नहीं है, उनके लिए AI impact को मापना कठिन है
    • Core 4 framework (Dropbox, Adyen, Booking.com आदि द्वारा उपयोग) से जल्दी baseline हासिल की जा सकती है
    • system data, experience sampling data और regular surveys को साथ में उपयोग करके अधिक विश्वसनीय तुलना की जा सकती है
  • लगातार tracking और experimental mindset ही मुख्य हैं
    • one-time measurement का कोई खास मतलब नहीं; time-series tracking के ज़रिए trends और patterns को समझना चाहिए
    • सफल कंपनियों में एक समान बात: स्पष्ट लक्ष्य तय करना और data के माध्यम से hypotheses को validate करना
    • data पर अंधाधुंध निर्भर हुए बिना, goal-oriented experimental mindset बनाए रखना

4. Maintainability, quality और developer experience के लिए सावधानी

  • AI-assisted development अब भी एक नया क्षेत्र है
    • long-term code quality और maintainability पर इसके प्रभाव को साबित करने वाला data अभी कम है
    • short-term speed gains और long-term technical debt risk के बीच संतुलन मुख्य चुनौती है
  • एक-दूसरे को संतुलित करने वाले metrics को साथ में track करना चाहिए
    • ज़्यादातर कंपनियाँ Change Failure Rate और PR throughput को एक साथ track करती हैं
    • अगर speed बढ़े लेकिन quality घटे, तो यह तुरंत समस्या का संकेत बनता है
    • quality और maintainability की निगरानी के लिए अतिरिक्त metrics
      • Change confidence: deployment के समय code stability को लेकर developer का भरोसा
      • Code maintainability: code को समझने और बदलने की आसानी
      • Perception of quality: team स्तर पर code quality और practices को लेकर developers की धारणा
  • System metrics और self-reported metrics के संयोजन की ज़रूरत
    • system data: PR throughput, deployment frequency आदि
    • self-reported data: change confidence, maintainability आदि → long-term नकारात्मक प्रभावों को रोकने के लिए मुख्य संकेत
  • नियमित developer experience (DevEx) survey की सिफारिश
    • survey उदाहरण के ज़रिए quality, maintainability और AI usage के बीच संबंध को track किया जा सकता है
    • unstructured feedback भी मौजूदा समस्याओं को पहचानने और समाधान पर चर्चा करने में उपयोगी है
  • Developer experience (DevEx) का वास्तविक अर्थ
    • यह “ping-pong·beer” जैसी perks की अवधारणा नहीं, बल्कि पूरी development process से friction हटाना है
    • इसका लक्ष्य planning → development → testing → deployment → operations की पूरी प्रक्रिया में efficiency सुनिश्चित करना है
    • AI tools code writing और testing में friction कम कर सकते हैं, लेकिन review, incident response और maintenance में नया friction जोड़ने का जोखिम भी है
  • मैदानी insight (CircleCI की Shelly Stuart)
    • output metric (PR throughput) यह दिखाता है कि क्या हो रहा है, लेकिन developer satisfaction यह दिखाती है कि वह टिकाऊ है या नहीं
    • AI adoption शुरुआती असुविधा ला सकता है, इसलिए satisfaction tracking short-term friction बनाम long-term value को अलग करने का मुख्य साधन है
    • 75% कंपनियाँ AI tools की CSAT/संतुष्टि को भी track करती हैं → speed से अधिक sustainable development culture बनाने पर फोकस

5. अनोखे metrics और दिलचस्प रुझान

  • Microsoft: Bad Developer Day (BDD)
    • रोज़मर्रा के काम में होने वाले friction और थकान को रीयल-टाइम में मापने की अवधारणा
    • incident response और compliance प्रोसेसिंग, मीटिंग और email के बीच स्विच करने की लागत, work management systems में खर्च होने वाला समय आदि ऐसे कारक हैं जो दिन को खराब बनाते हैं
    • PR activity (coding time का proxy metric) के साथ संतुलित करके, कम-वैल्यू वाले कुछ काम मौजूद हों तब भी अगर coding के लिए एक निश्चित समय मिल जाए तो उसे अच्छा दिन माना जाता है
    • लक्ष्य: यह देखना कि AI tools BDD की आवृत्ति और गंभीरता को कम कर रहे हैं या नहीं
  • Glassdoor: प्रयोग और tool utilization मापना
    • मासिक A/B टेस्ट की संख्या से ट्रैक किया जाता है कि AI innovation और experimentation की रफ्तार बढ़ा रहा है या नहीं
    • power users को internal AI evangelists के रूप में विकसित करने की रणनीति भी साथ चलती है
    • Capacity worked (utilization): tool के संभावित उपयोग की तुलना में वास्तविक उपयोग को मापकर adoption saturation point और budget reallocation पर निर्णय
  • Acceptance Rate में गिरावट
    • पहले यह एक मुख्य AI metric था, लेकिन यह केवल suggestion accept किए जाने के क्षण को देखता है, इसलिए इसका दायरा संकीर्ण है
    • यह maintainability, bug generation, code rollback, developer की perceived productivity जैसी बातों को नहीं दर्शाता
    • अब इसे आम तौर पर top-level metric के रूप में कम इस्तेमाल किया जाता है, हालांकि कुछ अपवाद हैं:
      • GitHub: Copilot सुधार और product decision-making में उपयोग
      • T-Mobile: AI code किस हद तक वास्तविक production में जाता है, इसका अनुमान
      • Atlassian: developer satisfaction और suggestion quality के सहायक metric के रूप में उपयोग
  • लागत और निवेश विश्लेषण
    • अधिकांश कंपनियां developers का मनोबल गिरने से रोकने के लिए usage cost को आक्रामक रूप से ट्रैक नहीं करतीं
    • Shopify AI Leaderboard के ज़रिए अधिक token खर्च करने वाले developers को बधाई देने का तरीका अपनाता है
    • ICONIQ 2025 State of AI Report: 2025 में कंपनियों के भीतर AI productivity budget के 2024 की तुलना में दोगुना होने का अनुमान
      • कुछ संगठन hiring budget घटाकर उसे AI tools budget में reallocate कर रहे हैं
  • agent telemetry की कमी
    • अभी measurement लगभग नहीं के बराबर है, लेकिन अगले 12 महीनों में adoption की संभावना अधिक है
    • जैसे-जैसे autonomous agent workflows फैलेंगे, behavior, accuracy, regression rate आदि को मापने की ज़रूरत बढ़ेगी
  • non-coding activities की measurement की कमी
    • अभी focus code writing support तक सीमित है; ChatGPT planning sessions या Jira issue handling जैसी चीज़ें अक्सर शामिल नहीं होतीं
    • 2026 तक पूरे SDLC के सभी चरणों में AI उपयोग बढ़ने के साथ measurement को भी evolve करना होगा
    • code review, vulnerability scanning जैसी ठोस गतिविधियों को मापना आसान है, जबकि abstract कामों को मापना कठिन
    • self-reported measurement ("इस सप्ताह AI से आपने कितना समय बचाया?") के दायरे के विस्तार की उम्मीद है

6. AI impact को कैसे मापना चाहिए?

  • AI Measurement Framework
    • DevEx Framework के सह-लेखक Abi Noda के साथ विकसित
    • लगभग 400 कंपनियों के field data और पिछले 10+ वर्षों के developer productivity research के आधार पर तैयार
    • AI metrics और core metrics को जोड़कर speed, quality, maintainability और developer experience (DevEx) का साथ में मूल्यांकन
    • single metric (जैसे AI-generated code ratio) headline के लिए उपयुक्त हो सकता है, लेकिन यह performance measurement का पर्याप्त साधन नहीं है
  • qualitative + quantitative data दोनों की ज़रूरत
    • system metrics (PR throughput, DAU/WAU, deployment frequency आदि) और self-reported metrics (CSAT, time savings, maintainability perception आदि) दोनों इकट्ठा करने पर ही multidimensional understanding संभव है
    • कई कंपनियां DX का उपयोग data collection और visualization के लिए करती हैं, हालांकि custom systems भी बनाए जा सकते हैं
  • data collection methods
    • system data (quantitative): AI tool के admin APIs (usage, spend, tokens, acceptance rate) + SCM, JIRA, CI/CD, build, incident management metrics
    • regular surveys (qualitative): quarterly/half-yearly surveys के ज़रिए DevEx, satisfaction, change confidence, maintainability आदि के long-term trends समझना, जिन्हें system metrics से पाना कठिन है
    • experience sampling (qualitative): workflow के बीच छोटे सवाल जोड़ना (जैसे PR submit करने के तुरंत बाद, "क्या आपने AI का उपयोग किया?", "क्या यह code समझना आसान था?")
  • execution priorities
    • regular surveys सबसे तेज़ शुरुआत बिंदु हैं: 1–2 हफ्तों में शुरुआती data मिल सकता है
    • जैसे परदा लगाने और rocket लॉन्च करने की precision अलग होती है, वैसे ही engineering decisions के लिए इतनी accuracy भी काफ़ी मायने रखती है जो पर्याप्त दिशा दे सके
    • बाद में अन्य data collection methods को साथ जोड़कर cross-validation करने से reliability बढ़ती है
  • additional resources
  • internal adoption के समय ध्यान देने योग्य बातें
    • adoption rate या किसी single metric का पीछा करने के बजाय यह देखना चाहिए कि क्या ग्राहकों तक high-quality software तेज़ी से पहुंचाने की क्षमता बेहतर हो रही है
    • मुख्य प्रश्न:
      > “क्या AI उन चीज़ों को बेहतर बना रहा है जो पहले से महत्वपूर्ण हैं (quality, release speed, developer experience)?”
    • leadership meetings में पूछे जाने वाले सवाल:
      • हमारी organization में engineering performance की परिभाषा क्या है?
      • AI tool adoption से पहले का performance data क्या हमारे पास है? अगर नहीं, तो baseline जल्दी कैसे तैयार करेंगे?
      • क्या हम AI activity को AI impact समझने की भूल तो नहीं कर रहे?
      • क्या हम speed, quality और maintainability के बीच संतुलन रख रहे हैं?
      • क्या developer experience पर पड़ने वाला असर दिखाई दे रहा है?
      • क्या हम system data और self-reported data दोनों को शामिल करने वाला multi-layered measurement approach चला रहे हैं?

7. Monzo AI impact को कैसे मापता है

  • शुरुआती अपनाने का चरण
    • पहला टूल GitHub Copilot था। यह GitHub लाइसेंस में शामिल था और VS Code में स्वाभाविक रूप से घुल-मिल गया, इसलिए सभी इंजीनियरों ने इसका उपयोग शुरू कर दिया
    • इसके बाद Cursor, Windsurf, Claude Code जैसे अलग-अलग टूल्स का समानांतर परीक्षण किया गया, जबकि Copilot-केंद्रित निवेश जारी रहा
  • AI टूल मूल्यांकन की सोच
    • तेज़ी से बदलते टूल ecosystem में प्रत्यक्ष अनुभव अनिवार्य है
    • टीम के सदस्यों को रोज़ाना वास्तविक कोड पर AI लागू करना चाहिए, और agent config files तक खुद बनाकर इस्तेमाल करनी चाहिए, तभी उसके प्रदर्शन का सही अंदाज़ा मिलता है
    • मूल्यांकन में वस्तुनिष्ठ मेट्रिक्स (उपयोग, प्रदर्शन) और व्यक्तिपरक सर्वेक्षण (DX संतुष्टि) दोनों का साथ में उपयोग किया जाता है
  • प्रभाव और महसूस की गई वैल्यू
    • इंजीनियरों को लगा कि AI की मदद से डॉक्यूमेंट खोज, सारांश और कोड समझना आसान हुआ और cognitive load कम हुआ
    • प्रतिस्पर्धी टैलेंट मार्केट में अगर बेहतरीन टूल्स न दिए जाएं तो डेवलपर्स के जाने का जोखिम बढ़ता है → इसलिए टूल उपलब्ध कराना खुद एक talent retention strategy है
  • मापन की कठिनाइयाँ
    • vendors द्वारा दिए जाने वाले आंकड़े अक्सर adoption rate जैसे सीमित मेट्रिक्स तक ही सीमित रहते हैं, जबकि वास्तविक business impact समझना मुश्किल होता है
    • A/B testing के ज़रिए इसे सटीक रूप से सत्यापित करना भी व्यावहारिक नहीं है
    • अलग-अलग टूल्स (GitHub, Gemini, Slack, Notion आदि) के उपयोग डेटा को एक साथ जोड़ना कठिन है → telemetry की सीमाएँ और vendor lock-in बड़ी बाधाएँ हैं
    • नतीजतन, अभी डेवलपर्स का प्रत्यक्ष अनुभव ही मुख्य संकेत है
  • जहाँ यह अच्छी तरह काम करता है
    • migration में बड़ा असर: कोड बदलाव वाले काम में 40~60% कमी महसूस हुई
    • data model annotation जैसे दोहराव वाले और manual कामों में LLM पहला ड्राफ्ट तैयार करता है, फिर इंजीनियर उसे सुधारते हैं → बड़े पैमाने पर श्रम की बचत
  • अनपेक्षित सीख
    • LLM लागत के प्रति संवेदनशीलता की कमी: यदि लोग वास्तविक token usage के बिल देखें, तो optimization की ज़रूरत और स्पष्ट महसूस होगी
    • उदाहरण: Copilot auto code review बहुत tokens खर्च करता है और परिणाम कम देता है, इसलिए इसे default रूप से बंद रखकर ज़रूरत पड़ने पर opt-in मॉडल में बदला गया
  • वे क्षेत्र जहाँ AI का उपयोग नहीं होता
    • ग्राहक डेटा से जुड़े काम: raw और de-identified data, दोनों पर AI का उपयोग प्रतिबंधित है
    • sensitive data वाले क्षेत्रों में data leakage risk को रोकना सर्वोच्च प्राथमिकता है
  • प्लेटफ़ॉर्म टीम की सोच
    • Guardrails उपलब्ध कराना: data protection जैसी सुरक्षित उपयोग-परिस्थितियाँ तैयार करना
    • केस साझा करना: सफलता/विफलता के उदाहरण और prompts के उपयोग के अनुभव पारदर्शी रूप से साझा करना
    • दोनों पक्षों पर ज़ोर: सकारात्मक और नकारात्मक दोनों बातें साझा कर संतुलित दृष्टिकोण बनाए रखना
    • LLM की सीमाएँ याद दिलाना: AI में भी इंसानों जैसी सीमाएँ होती हैं, इसलिए उस पर ज़रूरत से ज़्यादा भरोसा न किया जाए

निष्कर्ष और संकेत

  • AI impact का मापन अभी भी बहुत नया क्षेत्र है
    • उद्योग में कोई “सर्वश्रेष्ठ कार्यप्रणाली” मौजूद नहीं है
    • Microsoft और Google जैसी समान पैमाने और बाज़ार वाली कंपनियाँ भी अलग-अलग मेट्रिक्स का उपयोग करती हैं
    • हर कंपनी का अपना अलग तरीका और अपना “flavor” होता है
  • एक-दूसरे से टकराने वाले मेट्रिक्स को साथ मापना आम बात है
    • प्रमुख उदाहरण: change failure rate (reliability) और PR frequency (speed) को साथ ट्रैक करना
    • तेज़ deployment तभी मायने रखता है जब वह reliability को नुकसान न पहुँचाए, इसलिए दोनों आयामों का संतुलित मापन ज़रूरी है
  • AI टूल impact का मापन, developer productivity मापन जैसी ही कठिन समस्या है
    • productivity measurement ऐसा मुद्दा है जिससे उद्योग 10 साल से अधिक समय से जूझ रहा है
    • किसी एक metric से टीम की productivity नहीं समझाई जा सकती, और किसी खास metric के लिए optimization करने से वास्तविक productivity ज़रूरी नहीं कि बढ़े
    • 2023 में McKinsey ने दावा किया था कि उसने productivity measurement को “solve” कर लिया है, लेकिन Kent Beck और लेखक ने इस पर संदेह जताया → प्रतिक्रिया लेख
  • अभी स्पष्ट समाधान नहीं है, फिर भी प्रयोग ज़रूरी हैं
    • जब तक productivity measurement पूरी तरह हल नहीं होता, तब तक AI टूल impact measurement का पूरी तरह सुलझना भी मुश्किल है
    • फिर भी “AI coding tools व्यक्ति, टीम और कंपनी स्तर पर रोज़ाना/मासिक दक्षता को कैसे बदलते हैं?” इस सवाल का जवाब पाने के लिए लगातार प्रयोग और नए approaches आज़माने होंगे

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.