तुम्हारी टीम चार अलग-अलग AI coding tools से कोड शिप करती है। शायद पाँच। Backend वाला भाई Claude Code पर कसम खाता है, frontend की टोली Cursor में जीती है, intern ने कॉलेज में GitHub Copilot खोजा और वहीं बस गया, और platform engineering में किसी ने चुपचाप JetBrains AI इंस्टॉल कर लिया। सब productive हैं। कोड compile होता है। CI पास होती है। कोई सवाल नहीं पूछता।
पर बात ये है: तुम्हारा codebase अब ऐसा novel लगता है जो चार ghostwriters ने लिखा हो जो कभी मिले ही नहीं। हर sentence grammatically सही है। पूरी किताब का कोई sense नहीं बनता।
बँटवारा अब official है
10 अप्रैल 2026 को JetBrains ने अपना AI Pulse survey पब्लिश किया — 10,000+ professional developers, आठ programming languages, statistically weighted। जो नंबर यहाँ मायने रखता है: Copilot 29% पर, Claude Code और Cursor 18% पर बराबर, JetBrains AI 11% पर। नब्बे प्रतिशत developers काम पर कम से कम एक AI tool इस्तेमाल करते हैं।
ये एक tool की जीत नहीं है। ये हर tool की जीत है — एक ही organization के अंदर।
और यहाँ मज़ा शुरू होता है: हर tool अपनी instruction file लेकर आया — एक config document जो AI को बताता है कि तुम्हारे specific project के लिए कोड कैसे लिखना है। Claude Code पढ़ता है CLAUDE.md। Copilot पढ़ता है copilot-instructions.md। Cursor पढ़ता है .cursor/rules/*.mdc। OpenAI का Codex CLI पढ़ता है AGENTS.md (अब Linux Foundation के under, 60,000+ open-source projects ने adopt किया)। Windsurf पढ़ता है .windsurf/rules/*.md। Gemini CLI पढ़ता है GEMINI.md।
छह tools। छह config formats। हर एक चुपचाप बाकी सबको ignore करता है। जैसा कि TokenCentric ने मार्च 2026 की comparison में नोट किया: "एक developer जो पाँच projects पर तीन AI tools के साथ काम करता है, वो पंद्रह config files maintain कर सकता है।"
चार AIs कैसे चार अलग codebases लिखते हैं
हर AI की अपनी personality है। Claude Code explicit error handling और functional composition पसंद करता है — छोटे functions, clear types, verbose लेकिन predictable। Copilot GitHub के statistical average को mirror करता है — वो कोड ऐसे लिखता है जैसा ज़्यादातर open-source कोड दिखता है, यानी हर मायने में average। Cursor models के बीच auto-route करता है (Claude, GPT, अपने fine-tunes), pull request के बीच में styles mix करता है — कौन सी model ने कौन सी file handle की, उस पर depend करता है।
इसमें कुछ भी गलत नहीं है। यही तो problem है। Linter — एक tool जो code में style violations चेक करता है — typos और formatting पकड़ता है। ये नहीं पकड़ता कि तुम्हारी authentication service errors को try-catch blocks से handle करती है, payment service Result types इस्तेमाल करती है, और notification service null return करती है। तीन approaches, सब valid, सब CI (Continuous Integration — automated tests जो code merge से पहले चलते हैं) पास कर रहे हैं, सब मिलकर एक ऐसा codebase बना रहे हैं जिसमें बिना नक्शे के कोई navigate नहीं कर सकता।
AI code quality पर सबसे हालिया large-scale study — CodeRabbit की दिसंबर 2025 की report, चार महीने बाद भी सबसे अच्छा data — ने 470 GitHub pull requests में नुकसान को quantify किया: AI-authored code में 1.7× ज़्यादा issues overall, 3× ज़्यादा readability problems, और 2.66× ज़्यादा formatting inconsistencies थीं human code से। और ये single-tool output measure कर रहा था। Multi-tool codebases इन inconsistencies को एक दूसरे के ऊपर stack करते हैं।
वो "अरे बाप रे" moment जो किसी को नहीं चाहिए था
Result bugs नहीं है। Bugs तो ढूँढे जा सकते हैं। Result है architectural incoherence — एक term जिसके इर्द-गिर्द Martin Fowler ने 7 अप्रैल 2026 को अपने "harness engineering" essay में बात की, जहाँ उन्होंने equation define किया: Agent = Model + Harness। Harness वो सब कुछ है जो AI model को surround करता है — config files, guardrails, instructions। Fowler ने माना: "Functional behaviour के लिए अच्छे harnesses figure out करने में अभी बहुत काम बाकी है।"
सीधी बात: ये अभी किसी ने solve नहीं किया है।
Graphite के CTO Greg Foster ने 26 मार्च की Stack Overflow पोस्ट में अलग तरीके से कहा: human engineers "code base का context implicitly absorb कर लेते हैं" coding करते हुए। वो देखते हैं कि बाकी service Result types इस्तेमाल करती है, तो वो भी Result types इस्तेमाल करते हैं। AI agents कुछ absorb नहीं करते — वो बस अपनी config file follow करते हैं, या इससे भी बुरा, अपने training data का सुझाव।
कीमत क्या है
कोई existing tool ये नहीं पकड़ता। ESLint syntax चेक करता है। Prettier formatting चेक करता है। Code review bugs पकड़ता है। कोई भी flag नहीं करता कि "ये file साफ़ तौर पर बगल वाली file से अलग AI ने लिखी है।"
और vendors से उम्मीद मत रखो कि वो ये gap bridge करेंगे। अगर Cursor अपने rules को Claude Code के config से compatible बना दे, तो switch करना आसान हो जाएगा। Fragmentation एक moat है, भले ही accidental हो।
Community projects compensate करने की कोशिश कर रहे हैं। rule-porter, जो फरवरी 2026 में GitHub पर आया, config formats के बीच convert करता है; rulesync, जो लगभग उसी समय आया, उन्हें unify करने की कोशिश करता है। दोनों roughly 75% clean conversion rates रिपोर्ट करते हैं। बाकी 25% वहाँ है जहाँ architectural intent रहता है, और वो translation में खो जाता है।
Google के Addy Osmani ने फरवरी 2026 में चेतावनी दी: "तुम्हारा architecture जितना clean होगा, AI उतना कम weird abstractions hallucinate करेगा।" इसका उल्टा भी सच है: तुम्हारा multi-AI codebase जितना messy होगा, हर अगला AI contribution उतना ही अजीब होता जाएगा। Entropy compound होती है।
तो करना क्या है
अगर तुम्हारी टीम multiple AI tools चलाती है — और statistically, चलाती है — तो तुम्हें एक चीज़ चाहिए: एक single, tool-agnostic style document जो हर AI पढ़े। छह config files नहीं। एक canonical source of truth कि तुम्हारा codebase errors कैसे handle करता है, APIs कैसे structure करता है, नाम कैसे रखता है, और dependencies कैसे organize करता है। फिर एक pre-commit hook — एक automated check जो code save होने से पहले चलता है — जो इन patterns को enforce करे, चाहे कोड किसी भी AI ने लिखा हो।
AGENTS.md standard, जो अब Linux Foundation के under है, universal format के सबसे करीब है। Perfect नहीं है, लेकिन cross-vendor backing वाला इकलौता है।
नया normal
तुम्हारे codebase में अब human authors से ज़्यादा AI authors हैं। Andrej Karpathy ने 26 जनवरी 2026 को साफ़ कहा था: "तुम 99% समय directly कोड नहीं लिख रहे हो… तुम agents orchestrate कर रहे हो।" ठीक है। लेकिन orchestras को एक conductor चाहिए, और एक score चाहिए। अभी ज़्यादातर teams में चार musicians चार अलग sheets से चार अलग keys में बजा रहे हैं — और audience "compile हो गया" सुनकर मान लेती है कि ये music है।
किसी को editorial policy लिखनी होगी इससे पहले कि repo खुद एक लिख ले। और वो सुंदर नहीं होगी।



