Lines of Code को बस एक बेहतर PR मिल गया
(curlewis.co.nz)- डेवलपर productivity का आकलन code की मात्रा से नहीं, बल्कि customer value, revenue, और reliability जैसे outcome metrics से किया जाना चाहिए
- Google, Anthropic, OpenAI, और Cursor के हालिया AI coding दावे सभी code generation ratio या lines of code जैसी मात्रात्मक बातों पर केंद्रित हैं
- GitHub Copilot का पुराना 55% faster work completion दावा एक verifiable outcome था, लेकिन “AI द्वारा लिखा गया code का अनुपात” सुधार हुआ या नहीं, इससे अलग भी बढ़ सकता है
- वास्तविक शोध मिश्रित है: Cui et al. के +26% completion rate से लेकर METR के "19% slower" और बाद की वापसी, तथा 90% कंपनियों द्वारा measurable effect न मिलने वाले सर्वे तक, organization-level effect लगभग 10% के आसपास दिखता है
- AI अपनाना ज़रूरी है, लेकिन performance measurement को DORA metrics, reliability, meaningful change velocity, revenue, और customer value जैसे verified standards पर आधारित होना चाहिए
lines of code metric की वापसी
- 15 साल पहले किसी SaaS कंपनी में दो senior developers में से एक ने दूसरे की तुलना में 40% अधिक code लिखा हो, सिर्फ इससे उसे बेहतर developer नहीं कहा जा सकता
- असल मायने यह रखता है कि क्या ship हुआ और उसने customers, revenue, और stability में क्या योगदान दिया; lines of code और PR count को दशकों से खराब measurement methods माना जाता रहा है
- 2026 में industry जिन प्रमुख numbers को आगे कर रही है, वे सभी AI-written code ratio पर केंद्रित हैं
- Google: नए code का 75% AI generated
- Anthropic: merged production code का लगभग 80% Claude ने लिखा, और engineers हर quarter में "8x more code" deploy कर रहे हैं
- OpenAI: इसी तरह लगभग 80%
- Cursor: “हर दिन 100 million lines से अधिक enterprise code लिखना”
- ये सभी numbers पूरी तरह volume claims हैं, और "AI द्वारा लिखा गया code का अनुपात" दरअसल lines of code का सिर्फ अधिक polished PR version है
- यह भी महत्वपूर्ण है कि ये सभी कंपनियाँ AI vendors हैं, इसलिए adoption rate को बढ़ा-चढ़ाकर दिखाने की प्रेरणा स्वाभाविक है
पहले performance के दावे किए जाते थे
- कुछ साल पहले मुख्य metrics का फर्क सिर्फ scale में नहीं, उनके प्रकार में था
- GitHub का प्रमुख दावा था कि Copilot के साथ काम 55% faster complete होता है
- इस पर काफी आलोचना हुई, लेकिन यह एक outcome claim था: bold, falsifiable, और value से जुड़ा — गलत हो तो उसे गलत साबित किया जा सकता था
- 2026 के दावे इस तरह बने हैं कि वे असफल साबित ही नहीं होते
- "75% code AI ने लिखा" यह बात सच हो सकती है और लगातार बढ़ भी सकती है, भले ही faster deployment, incidents में कमी, या customer satisfaction जैसी कोई वास्तविक सुधार न हो
- volume metrics सिर्फ तभी निराश करते हैं जब adoption रुक जाए; और adoption वास्तविक है, इस पर अधिकांश लोग सहमत हैं
- दावे बड़े हुए हैं, लेकिन उनका मतलब छोटा हो गया है
जो billboard तक नहीं पहुँचता
- इस बीच जो हुआ, वह यह है कि outcome evidence अधिक जटिल हो गया
-
adoption के पक्ष में परिणाम
- Cui et al.: लगभग 5,000 developers पर अध्ययन में completed tasks +26%, खासकर junior developers में सबसे बड़ा सुधार — इस पर लगभग कोई विवाद नहीं
-
उलटी दिशा में evidence
-
METR की position reversal
- फरवरी 2026 में METR ने व्यावहारिक रूप से अपनी बात वापस ली — follow-up estimate में निष्कर्ष speedup की ओर पलट गया (हालाँकि error bars बहुत चौड़ी थीं)
- developers अब AI के बिना काम करने से इनकार कर रहे थे, और agent-based work के समय का विश्वसनीय self-report नहीं दे पा रहे थे, इसलिए research design ही छोड़ दिया गया
- ताज़ा निष्कर्ष: 2026 में AI के developer speed बढ़ाने की संभावना अधिक है, लेकिन इसे साफ-सुथरे तरीके से मापना संभव नहीं
-
enterprise-level effect
- NBER का लगभग 6,000 executives पर survey: 69% कंपनियाँ AI का उपयोग कर रही हैं, लेकिन लगभग 10 में 9 ने कोई measurable productivity effect नहीं बताया
- cross-study consensus यह है कि organization level पर लगभग 10% improvement दिखती है — उपयोगी, लेकिन ऐसा नहीं कि "अब developers की ज़रूरत नहीं"
- जो skeptics अब भी सिर्फ "19% slower" quote करते हैं, वे भी cherry-picking कर रहे हैं; research लगातार update हो रही है और industry ने सिर्फ measurement target बदल दिया है
vanity metrics का AI version
- यह सिर्फ AI vendor claims की समस्या नहीं है
-
maturity models और ladders
- Carnegie Mellon SEI और Accenture ने कुछ दिन पहले AI Adoption Maturity Model लॉन्च किया — 5 levels, 8 dimensions, और "95% organizations को return नहीं मिल रहा" आँकड़े का marketing में उपयोग
- Steve Yegge का "8 levels of AI-assisted development" ranking इस आधार पर करता है कि कौन-सा tool इस्तेमाल हो रहा है और कितना supervision है
- हर tool vendor maturity ladder जारी कर रहा है, और सबसे ऊपर का स्तर आमतौर पर "हमारा product अधिक इस्तेमाल करना" निकलता है
- ये ladders वास्तव में adoption intensity को मापते हैं, लेकिन उसे maturity कहकर पेश करते हैं — वही चीज़, बस नई packaging में
-
definitions की गड़बड़ी
- जब Augment ने 219 engineering leaders से "AI-native engineering" की definition पूछी, तो 219 अलग-अलग जवाब मिले
-
Anthropic का दोहरा चेहरा
- एक ओर "8x more code shipped" का दावा, और दूसरी ओर इस साल के सबसे rigorous studies में से एक
- RCT result: AI-assisted developers ने अभी-अभी ship किए गए code की understanding में 17% कम score किया, और statistically significant productivity gain नहीं मिला
- research team evidence को update कर रही है, जबकि marketing team volume गिन रही है — दोनों बातें एक साथ सच हैं
इस मुद्दे पर ध्यान क्यों देना चाहिए
- ये numbers सिर्फ सजावट नहीं हैं; ये budget, performance expectations, और workforce planning को प्रभावित करते हैं
-
AI के नाम पर layoffs
- फरवरी में Jack Dorsey ने Block workforce का 40% से अधिक (4,000+ लोग) घटाया, और AI को स्पष्ट मुख्य तर्क के रूप में पेश किया — "smaller teams उन tools के साथ अधिक और बेहतर काम कर सकती हैं जिन्हें हम बना रहे हैं"
- कुछ हफ्तों बाद Atlassian ने 10% (लगभग 1,600 लोग) cut किया, और माना कि "यह दिखाना ईमानदार नहीं होगा कि AI skill mix या roles की संख्या नहीं बदलता"
- Dorsey ने उसी घोषणा में यह भी कहा कि business मजबूत है और gross profit बढ़ रहा है
-
productivity claims पर सवाल
- अगर "AI से सभी अधिक productive हो गए हैं, इसलिए कम लोगों की ज़रूरत है", तो उसका evidence दिखना चाहिए — और लेखक के अनुसार अभी ऐसा evidence मौजूद नहीं है
- यह दिखाना होगा कि workforce का कोई हिस्सा सचमुच idle या underutilized था; product/SaaS कंपनियों के पास तो अंतहीन roadmap होती है, इसलिए अतिरिक्त capacity का उपयोग customer value और speed में होना चाहिए — जो MAU, conversion, और revenue में दिखना चाहिए
- layoffs चुनना यह संकेत देता है कि productivity claim असल में पहले से लिए गए किसी दूसरे फैसले (overhiring, investor pressure) के लिए PR support का काम कर रहा है
- efficiency-based cuts कभी-कभी उचित हो सकते हैं, लेकिन तब token count, "AI-written code ratio", या maturity ladder level नहीं, बल्कि पहले से मौजूद individual performance systems का उपयोग होना चाहिए
- यदि selection vanity metrics पर आधारित है, तो वह selection बस lipstick लगाया हुआ lottery है
निष्कर्ष
- यह anti-AI तर्क नहीं है; रुख यह है कि हर engineer को हर दिन AI का उपयोग करना चाहिए
- चाहे उसे AI-first कहें या AI-proficient, ज़रूरी यह है कि नए tools और latest models को जिज्ञासा के साथ लगातार आजमाया जाए
- industry पहले भी higher-level languages, IDEs, autocomplete, agile, और devops को absorb कर चुकी है; हर दौर में पुराने तरीकों से चिपके रहने वाले लोग थे, पर अंततः सब जुड़े
- इस बार फर्क है speed — "cloud" adoption को आप वर्षों टालकर भी बच सकते थे, लेकिन AI के मामले में शायद सिर्फ कुछ महीने हों
- AI adoption starting line है, scoreboard नहीं
- engineering performance को कैसे मापना है, यह पहले से पता है — DORA metrics, reliability, meaningful change ratio, और अंततः revenue तथा customer value
- verified methods छोड़कर AI vanity scores अपनाने का कोई कारण नहीं
- vendor pitches, executive reviews, और LinkedIn feed में पूछा जाने वाला सवाल: "क्या यह outcome है या volume?"
- काम करने का तरीका AI-first होना चाहिए, लेकिन measurement का तरीका battle-tested होना चाहिए
1 टिप्पणियां
Hacker News की राय
लगता है यह अजीब धारा फ़रवरी 2026 की OpenAI ब्लॉग पोस्ट [1] पर जाकर चरम पर पहुँची। यह हाल की फ्रंट-पेज पोस्ट [2] है, जिसमें ऐसी किसी चीज़ को बनाने की प्रक्रिया बताई गई है जिसे एजेंट ने 100% लिखा है
लेकिन वह चीज़ असल में क्या है, और उपयोगकर्ता को क्या मूल्य देती है, इसका कोई विवरण नहीं है। सबसे नज़दीकी विवरण बस इतना है: “इस प्रोडक्ट का आंतरिक रूप से सैकड़ों लोगों ने उपयोग किया है, और कुछ internal power users इसे हर दिन इस्तेमाल करते हैं”
फिर भी 10 लाख lines of code होने की बात शुरुआती कुछ सौ शब्दों के भीतर दो बार दोहराई गई है
[1] https://openai.com/index/harness-engineering/
[2] https://news.ycombinator.com/item?id=48416264
और अगर इसमें “10 लाख lines of code” हैं और “एजेंट ने 100% लिखा” है, तो और भी ज़्यादा ऐसा ही लगता है। नहीं तो यह विभागीय wiki के लिए JS menu भी हो सकता है, जो असल में jquery को MS JScript में फिर से बनाकर JS 5 में ट्रांसपाइल करता हो
LLM चाहे जितना शक्तिशाली हो, इसकी maintainability भी लगभग न के बराबर लगती है
https://github.com/openai/symphony
पॉडकास्ट इंटरव्यू में कहा गया कि यह एक Electron app है जिसे उपयोगकर्ता डाउनलोड करते हैं, और इसी वजह से नियमित रूप से नए builds बनाए जाते हैं। यहाँ “Autonomous Merging Flow” सेक्शन देखें: https://www.latent.space/p/harness-eng
Microsoft की ओर के किसी व्यक्ति ने “हर engineer से हर महीने 10 लाख lines of code चाहिए” जैसी कोई बात पोस्ट की थी, वही बार-बार याद आती है। जिन ज़्यादातर engineers से मैंने इस पर बात की, उन्हें यह व्यंग्य जैसा लगा, लेकिन वास्तव में यह बिल्कुल व्यंग्य नहीं था, और LLM code generation को लेकर कई CEOs के रवैये को काफ़ी अच्छी तरह दर्शाता था
हालाँकि पिछले कुछ महीनों में maintain न की जा सकने वाली मात्रा में code lines पैदा करने का उन्माद थोड़ा ठंडा पड़ता दिख रहा है। अधिक व्यावहारिक और यथार्थवादी विचार सार्वजनिक रूप से ज़्यादा साझा हो रहे हैं, और लगता है कि वे कुछ tech कंपनियों के सबसे ऊपरी स्तर तक भी थोड़ा-थोड़ा पहुँच रहे हैं। शायद अभी सब कुछ पूरी तरह बर्बाद नहीं हुआ है
हक़ीक़त में ज़्यादातर code का test ही नहीं हुआ था
हर महीने 10 लाख lines / महीने में 25 दिन / दिन में 8 घंटे / घंटे में 60 मिनट
code review करने वाले व्यक्ति के लिए यह काफ़ी बड़ी समस्या लगती है
हर engineer से हर महीने 10 लाख lines of code बनवाना, बिना यह सोचे कि वे lines कंपनी के लिए पैसे कैसे कमाएँगी या उस प्रक्रिया में कितने tokens कितनी लागत पर जलेंगे, किसी भी तरह से कोई बहुत सोच-समझकर बनाई गई योजना नहीं लगती
इसके उलट technical debt उसी तरह management को नहीं पकड़ पाता। debt को आम तौर पर ऐसी चीज़ माना जाता है जो समस्या बन सकती है, लेकिन जब तक वह समस्या न बने तब तक उससे बचने या उसे निपटाने की ज़रूरत नहीं, इसलिए उसे टाला जाता रहता है
जहाँ मैं काम करता हूँ, उन दोनों छोटी कंपनियों में मैंने यही देखा है। कुछ महीने पहले हमें Claude Cowork मिला था, और सब लोग बहुत उत्साहित थे; आज भी रोज़ इस्तेमाल करते हैं, लेकिन उम्मीद की गई जादुई क्षमता की तुलना में काफ़ी निराश हैं
शिकायतें यह हैं कि आउटपुट साधारण और शब्दबहुल है, बहुत बुनियादी चीज़ें भी गलत कर देता है, बार-बार token limits से टकराता है, और खुद कर लेना ज़्यादा तेज़ पड़ता है इसलिए लोग फिर हाथ से करने लगते हैं
शुरुआत में टूल का गलत इस्तेमाल कुछ हद तक हो सकता है, लेकिन लोग समझ रहे हैं कि AI CEOs, LinkedIn के धंधेबाज़ों, और YouTube के AI सप्लीमेंट बेचने वालों की बातों और वास्तविकता के बीच अभी भी फ़ासला है
अगर कोई कंपनी कहती है, “AI ने सबको ज़्यादा productive बना दिया है, इसलिए कम लोगों की ज़रूरत है”, तो मैं उसका सबूत देखना चाहूँगा। अभी मुझे नहीं लगता कि ऐसा कोई सबूत मौजूद है
असल में वे बकवास कर रहे हैं, और COVID काल की overhiring को पलटने के बहाने के रूप में AI का इस्तेमाल कर रहे हैं। साथ ही निवेशकों को यह दिखा रहे हैं कि उन्होंने नई फैशनेबल technology अपना ली है और अब वे ज़्यादा lean और cost-efficient संगठन हैं
मुझे लगा था कि निवेशक फैशनेबल technology अपनाने से ज़्यादा profits को महत्व देते हैं
और जो कंपनी यह कहती है, “हम भी वही चमकदार technology इस्तेमाल करते हैं जिसे बेडरूम में बैठा कोई भी मूर्ख इस्तेमाल कर सकता है!”, वह पूरी तरह गैर-प्रतिस्पर्धी कंपनी भी है
हमारे उद्योग ने दशकों तक यह समझाया कि “हम जो काम करते हैं वह जटिल है और समय लेता है, इसलिए productivity को आसानी से मापा नहीं जा सकता,” लेकिन जैसे ही AI आया, अचानक lines of code, Nx multiplier, और प्रति सप्ताह tickets जैसी चीज़ों को उपयोगी या वस्तुनिष्ठ metrics की तरह पूजा जाने लगीं — यह अंतहीन रूप से हास्यास्पद है
lines of code जैसे metrics को ठुकराने की वजह नहीं बदली है। असली बात code output नहीं, बल्कि quality output है। AI में भी वही समस्याएँ हैं जो इंसानों में होती हैं। फिर भी किसी कारण से हम अपनी सीखी हुई बातों को फेंक रहे हैं, और यह थोड़ा शर्मनाक है
क्योंकि ढीले तौर पर जुड़े हुए लेकिन आक्रामक और बहुत माँग करने वाले managers हमेशा से रहे हैं। ऐसे managers, जिनका मुख्य काम कर्मचारियों से और ज़्यादा मेहनत निचोड़ना है और जो coordination वगैरह में योगदान नहीं देते, उनका भी दुखद रूप से आर्थिक मूल्य होता है
इसलिए वास्तविक performance और lines of code जैसी measurements — इन दोनों दृष्टिकोणों का overlap करने वाला धुंधला क्षेत्र हमेशा मौजूद रहा है
AI ऐसे ढीले तौर पर जुड़े लेकिन सिर्फ़ माँग करने वाले managers को संतुष्ट करने के लिए सभी tools दे देता है। इसलिए अब lines of code और feature additions को metric की तरह पसंद करने वाले लोगों की संख्या और बढ़ेगी। क्योंकि अब यह आसान हो गया है
अगर एक A+ senior developer 8 महीनों तक कोई feature बनाता है, लेकिन वह आखिरकार ship नहीं होता या MVP रद्द हो जाता है, तो उस A+ senior developer को बर्बाद किया गया, और उसकी productivity उसी project में शामिल दो B+ engineers के बराबर रह जाती है
यह वास्तव में बहुत आम समस्या है, लेकिन hiring या project resource allocation में इसे आम तौर पर नज़रअंदाज़ किया जाता है। AI इसे अर्थपूर्ण तरीके से बदलेगा, ऐसा नहीं लगता
team शायद काम बहुत जल्दी खत्म कर सके, लेकिन ऊपर की bureaucratic layers संभवतः वैसी ही रहेंगी, और तब AI coding से मिलने वाला लाभ मामूली हो जाएगा। AI के हिसाब से ढलने के लिए company को ऊपर से नीचे तक फिर से बनाना पड़ेगा, और ऐसा शायद ही कभी होगा
आख़िर में AI को धकेलने वाला हिस्सा अजीब तरह से बिना आधार का है। न कारण, न लक्ष्य, न लाभ के दावे का आधार — बस “AI इस्तेमाल करो, developers को नई चीज़ें अपनानी चाहिए” जैसी बात है
हाल में मैंने एक और लेख पढ़ा जो छोटे से संदर्भ में AI की आलोचना करता हुआ लगता था, लेकिन अंत में AI विज्ञापन बनकर खत्म हो गया, और दोनों को जोड़ने वाली कोई बात उसमें नहीं थी
investors और बड़े ग्राहक भी बड़े contracts पर हस्ताक्षर करने से पहले दोबारा सोचेंगे
इसलिए AI का इस्तेमाल करना ही चाहिए। लागत और लाभ की छोटी-छोटी गणना में नहीं फँसना चाहिए। दुनिया इसी दिशा में जा रही है, और अगर software development से रोज़ी कमानी है, तो तुम्हें भी इसी दिशा में होना चाहिए
“इस बार फ़र्क गति का है। cloud को कुछ साल देर से अपनाकर भी जिया जा सकता था। AI में शायद कुछ महीने हों” — यह हिस्सा अजीब लगता है
लेखक मानो यह समझता है कि AI कंपनियाँ अपने products की अनिवार्यता को लेकर जो pro-AI दावे करती हैं, वे unfalsifiable हैं, लेकिन तुरंत ही पीछे हटकर कहता है, “रुको, यह मत समझना कि मैं anti-AI हूँ”
ऊपर का दावा उस productivity दावे से ज़्यादा कठोर कैसे है जिसकी लेख के बाकी हिस्से में आलोचना की गई है? कि अगर कुछ महीनों में AI नहीं अपनाया, तो “बचा” नहीं जा सकेगा?
AI CEO कहे तब भी वह सच नहीं हो जाता, और AI CEO की बकवास की ओर इशारा करने वाला कोई व्यक्ति किसी वजह से वही बात कहे, तब भी वह सच नहीं हो जाती
यह कहना कि AI की वजह से लोगों को निकाला जा रहा है, व्याख्या के लिए बहुत ज़्यादा खुला दावा है, और इससे ज़िम्मेदारी खुद से हटाकर AI पर डाल दी जाती है। हक़ीक़त में, CEO ने जो किया, उसका दोष AI पर नहीं डालना चाहिए। वे कर्मचारियों को AI के हिसाब से फिर से train कर सकते थे, लेकिन उन्होंने ऐसा नहीं किया। क्यों? शायद इसलिए कि वजह AI थी ही नहीं
मैंने इसे सच में खुद लिखा था; जैसा कि मैं और जगह कहता हूँ, यह “AI slop” से नहीं बना था, इसलिए शायद अंत का हिस्सा “मानवीय रूप से sloppy” हो गया
यह सही है कि “रुको” वाला हिस्सा मैं ठोस आधार से नहीं समझा पाया, लेकिन फिर भी मेरा मानना है कि लोगों को AI आज़माना चाहिए। experiment करो, और यह खोजो कि किस तरह यह तुम्हारे लिए मददगार है। एक जैसे engineers के बीच भी value निकालने के तरीकों का spectrum बहुत व्यापक था
tools को ठीक से आज़माने की cost लगभग शून्य है, और “सोच-समझकर adopt करो और verified boring तरीकों से measure करो” वाला रुख “अगर adopt नहीं किया तो मर जाओगे” के बराबर नहीं है
जब कोई कंपनी कहती है, “AI ने सभी को अधिक productive बना दिया है, इसलिए अब कम लोगों की ज़रूरत है,” तो निहित अर्थ में वह यह कह रही होती है कि कंपनी खुद अधिक productive नहीं होना चाहती।
उसका मतलब यह है कि वह कम लोगों को कम भुगतान करके वही productivity चाहती है।
प्रति unit productivity पर employer को मिलने वाले पैसे और employee को मिलने वाले पैसे के बीच यह असंतुलन क्यों है?
अगर कम लोगों से वही output मिलता है, तो कंपनी या देश की productivity में सुधार हुआ है।
अगर कम लोगों के साथ वही productivity रहे, तो output भी उसी अनुपात में घटेगा, इसलिए कंपनी को कोई लाभ नहीं होगा, और fixed cost होने पर स्थिति और खराब भी हो सकती है।
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
मेरे हिसाब से code lines का महत्व लगभग उतना ही है जितना office में बिताए समय का। महामारी से पहले लोग हमेशा कहते थे, “अगर कोई office में नहीं है, तो हमें कैसे पता चले कि वह काम कर रहा है?”
इसका जवाब आसान है। हर employee के मूल्यांकन में इस्तेमाल होने वाले output metrics से देखिए कि वह business में क्या योगदान दे रहा है।
मुझे लगता है कि code lines को अब भी debt के बजाय asset की तरह देखे जाने में हम engineers की बड़ी जिम्मेदारी है। हमें अपने बनाए हुए पर गर्व होता है, लेकिन जब यह बताना हो कि कोई चीज कितनी “बड़ी” है, तो हमें किसी metric की ज़रूरत पड़ती है, और अंत में हम उसी metric पर लौट आते हैं जिसे गिनना सबसे आसान है।
शब्दावली बदलनी होगी। खासकर “...और इसकी cost code की N lines थी” जैसे वाक्य ज़्यादा इस्तेमाल करने चाहिए। यह भी बताना चाहिए कि वे code lines कहाँ खर्च हुईं।
“हमने नया feature X implement किया, और इसमें सिर्फ 200 lines लगीं।”
“उस bug को ढूँढना वाकई बहुत मुश्किल था, लेकिन आखिर में सिर्फ 6 lines of code लगीं।”
“X case में हम जो कर रहे थे, वह Y case में नहीं किया, और बाद में पता चला कि वह distinction ही ज़रूरी नहीं थी। इसलिए issue ठीक करते हुए हमने एक साथ 20 lines of code बचा लीं।”
code lines वह कीमत हैं जो हम चुकाते हैं। हम यह बताए बिना कि हमने क्या खरीदा, सिर्फ 200 डॉलर खर्च करने पर गर्व नहीं करते। फिर code lines के मामले में ऐसा क्यों करते हैं?
“देर से आवेदन किया, इसलिए 200 डॉलर extra देने पड़े” और “हाथ से रंगा हुआ कारीगर-निर्मित ceramic lamp holder सिर्फ 200 डॉलर में खरीद लिया; Amazon की factory-made चीज़ 1,200 डॉलर से भी ज़्यादा की है” — ये दोनों बिल्कुल अलग बातें हैं, और code में भी ठीक यही अंतर लागू होता है।