“एल्गोरिद्म ने ऐसा तय किया”: AI code के दौर में मेरा बनाया हुआ कमाई वाला app अचानक बंद क्यों हो सकता है

TL;DR

• YouTube की automated review संरचना AI app डेवलपर्स को भी प्रभावित कर सकती है

• खासकर अगर आप app या SaaS से monetization करते हैं, तो platform review risk बढ़ जाता है

• असली सवाल यह नहीं है कि “क्या AI code बना सकता है”

• बल्कि यह है कि किसने उसे समझा, review किया, और deploy करने की जिम्मेदारी ली

• मुख्य आँकड़े

  • METR: AI tools के इस्तेमाल पर skilled developers का काम पूरा होने में 19% अधिक समय लगा
  • Veracode: AI-generated code के 45% में ज्ञात security vulnerabilities मिलीं
  • CodeRabbit: AI co-authored code में major defects 1.7 गुना, security vulnerabilities 2.74 गुना
  • Vangala et al. 2026: AI agents वास्तविक runtime में अनुमान से 13.5 गुना अधिक dependencies मांग सकते हैं
  • 2027 तक technical debt का अनुमान 1.5 ट्रिलियन डॉलर, और 8,000 से अधिक startups को rework की जरूरत पड़ने का दावा

• निष्कर्ष: ज़रूरत है सत्यापित की जा सकने वाली जिम्मेदारी के रिकॉर्ड की

---

1. YouTube का मामला

YouTube ने 2024~2025 के आसपास repetitive और mass-produced content की monetization पर पाबंदियाँ कड़ी कीं।
आधिकारिक कारण थे content quality, originality, और repetitive content का प्रबंधन।

यहाँ असली बात policy नहीं, बल्कि enforcement structure है।

• platform automated review से content को classify करता है
• जिन creators को अचानक monetization बंद होने की सूचना मिलती है, उनके लिए ठोस निर्णय-आधार जानना मुश्किल होता है
• appeals अक्सर औपचारिकता बनकर रह जाती हैं
• दोबारा approval मिलने के मामले सीमित होते हैं
• नतीजतन नुकसान creator के हिस्से में आता है

अगर यही संरचना app stores, payment providers, और cloud जैसे software platforms पर लागू होती है, तो AI tools से बने apps या SaaS भी ऐसे ही जोखिम में आ सकते हैं।

• platform output का automated assessment करता है
• अगर उसे risky माना गया, तो restrictions लग सकती हैं
• developer के लिए ठोस निर्णय-आधार जानना मुश्किल हो सकता है
• appeal या objection की प्रक्रिया भी औपचारिक बन सकती है

---

2. यही संरचना अब IDE और deployment chain में आ रही है

जिम्मेदारी की संरचना मोटे तौर पर इस तरह बँटती है।

• AI tool provider: terms के जरिए accuracy, non-infringement, और output responsibility को सीमित करता है
• deployment platform: app store, cloud, payment provider आदि policy और risk assessment से risk manage करते हैं
• developer/operator: AI द्वारा बनाए गए code को स्वीकार कर deploy करने वाला अंतिम जिम्मेदार पक्ष

यह बात GitHub Copilot जैसे AI coding tools की terms structure में साफ दिखती है।

• service आमतौर पर “as-is” दी जाती है

• suggestion का इस्तेमाल करना है या नहीं, यह developer के फैसले पर छोड़ा जाता है

• भले ही AI tool ने generate किया हो, उसे accept और deploy developer ही करता है

• बड़े AI coding tools में भी broadly ऐसी ही responsibility structure होने की संभावना है

• इसलिए जब error, security issue, या operations incident होता है, तो अंतिम जिम्मेदारी developer या operator पर ही आती है

---

3. vibe coding की समस्या speed नहीं, छिपी हुई review cost है

vibe coding को सिर्फ productivity का सवाल नहीं, बल्कि जिम्मेदारी का सवाल मानना चाहिए।

इसके प्रमुख आधार ये हैं।

• METR research

  • skilled developers ने अनुमान लगाया था कि AI के इस्तेमाल से वे 24% तेज़ हो जाएंगे
  • लेकिन वास्तव में काम पूरा होने में 19% अधिक समय लगा

• Veracode report

  • 100 से अधिक LLM का analysis
  • AI-generated code के 45% में ज्ञात security vulnerabilities मिलीं

• CodeRabbit analysis

  • 1 करोड़ से अधिक PR का analysis
  • AI co-authored code में major defects 1.7 गुना
  • security vulnerabilities 2.74 गुना

• Vangala et al. 2026 research

  • AI agents ज़रूरी dependencies को कम आँकते हैं
  • वास्तविक runtime में अनुमान से 13.5 गुना अधिक dependencies की जरूरत पड़ सकती है

सार यह है:

• code जल्दी बन सकता है
• लेकिन किसी न किसी को उस code को पढ़ना और समझना होगा
• अगर review छोड़ दिया जाए, तो उसकी कीमत debugging और maintenance cost के रूप में लौटती है
• security या dependency problems के वास्तविक service operations के दौरान फूटने की संभावना अधिक होती है

---

4. वास्तविक उदाहरण: Tea app और platform review risk

Tea app का मामला “AI कारण था” वाला मामला नहीं, बल्कि responsibility structure दिखाने वाला मामला है।

• 2025 में Tea app breach incident
• women’s safety app
• 72,000 sensitive images exposed हुईं
• कारण था Firebase configuration error और API authentication समस्या
• सार्वजनिक जिम्मेदारी operator/developer की तरफ ही रही

मुख्य बात यह नहीं है कि यह incident AI coding की वजह से हुआ था।
मुख्य बात यह है कि अगर बिना systematic review के deploy किए गए system में समस्या आती है, तो अंतिम जिम्मेदारी AI tool पर नहीं, बल्कि operator और developer पर ही रहती है।

आगे चलकर अगर app stores, payment providers, और cloud automated risk assessment का और अधिक इस्तेमाल करेंगे, तो ऐसी संरचना और मजबूत हो सकती है।

• AI output अपने-आप flag हो सकता है
• policy violation के फैसले अधिक बार पैदा हो सकते हैं
• developer/operator की appeals औपचारिकता बन सकती हैं
• वास्तविक जिम्मेदार व्यक्ति से सीधे संवाद करना मुश्किल हो सकता है
• मेहनत से बनाया गया app या monetized SaaS अचानक restrict हो सकता है

इसीलिए सिर्फ code quality नहीं, बल्कि जिम्मेदारी साबित कर सकने वाले records भी महत्वपूर्ण होते जा रहे हैं।

• architecture documents
• security review records
• dependency changes के कारण
• deployment approval records
• responsible parties

---

5. उपाय: सत्यापित की जा सकने वाली जिम्मेदारी के रिकॉर्ड

मूल लेख में जिस “कारीगर की मुहर” की बात है, वह व्यवहार में सत्यापित की जा सकने वाली जिम्मेदारी के रिकॉर्ड के अधिक करीब है।

ज़रूरी यह नहीं है कि आप घोषणा करें, “हमने AI का इस्तेमाल नहीं किया।”
ज़रूरी हैं नीचे दिए गए records।

• requirements किसने define कीं?
• कौन-सा हिस्सा AI ने generate किया?
• कौन-सा हिस्सा इंसान ने modify किया?
• इंसान ने वास्तव में क्या review किया?
• कौन-कौन से tests pass हुए?
• क्या security review किया गया?
• नई dependencies क्यों जोड़ी गईं?
• deployment approver कौन है?
• incident होने पर कौन समझा सकता है और उसे ठीक कर सकता है?

एक पंक्ति में सार

AI code बना सकता है, लेकिन उस code को समझने और deploy करने की जिम्मेदारी अब भी इंसान की ही है।