Claude से लिखवाना और Codex से खंगालवाना — एक ही repo में दो agents को बाँटकर चलाने का व्यावहारिक पैटर्न

आजकल X·Discord पर "Claude Code और Codex को साथ में इस्तेमाल करते हैं" जैसी पोस्टें काफ़ी बढ़ गई हैं। सब लोग कहते हैं कि यह अच्छा है, तो मैंने भी लगभग एक महीने तक दोनों टूल्स को एक ही repo में इंस्टॉल करके चलाकर देखा। लेकिन जब इसे सच में अपनाने बैठा तो समझ नहीं आया कि setup कहाँ से शुरू करें, दोनों टूल्स के बीच ज़िम्मेदारियाँ कैसे बाँटें ताकि टकराव न हो, और AGENTS.md तथा CLAUDE.md में क्या एक ही चीज़ें भरनी चाहिए या नहीं। ऐसे decision points इतने ज़्यादा थे कि मैंने सोचा, जो लोग इसी दुविधा की वजह से शुरू ही नहीं कर पा रहे हैं, उनके trial and error को कम करने के लिए इसे 8 chapters वाले curriculum के रूप में व्यवस्थित कर दूँ.

यह dual-agent workflow सीधा है। अगर एक ही model से अपना code भी लिखवाएँ और उसी से review भी करवाएँ, तो वह अपने ही बनाए assumptions को वैसे ही मान लेता है और gaps पकड़ नहीं पाता। इसलिए उसके बगल में advisory (blocking X) reviewer के रूप में एक अलग model रखा जाता है। Claude Code मुख्य लेखक है, Codex advisory reviewer। कौन ज़्यादा smart है यह मुद्दा नहीं है; असली बात यह है कि model अलग हैं। और जैसे ही दोनों एक-दूसरे के gate बन जाते हैं, workflow टूट जाता है, इसलिए advisory को कभी भी blocking नहीं बनाना सबसे बड़ा नियम है।

पृष्ठभूमि — इसे समेटते हुए फिर से देखे गए बदलाव

• पहले सवाल होता था: "सबसे अच्छा AI coding tool कौन सा है"
• अब सवाल है: "दो या उससे ज़्यादा tools को कैसे बाँटा जाए", "एक tool के blind spots को दूसरे tool से कैसे भरा जाए"
• Claude Code के slash commands·subagents, Codex के review/exec separation, और AGENTS.md जैसी context files उपलब्ध होने के बाद यह पहली बार ऐसा मोड़ है जहाँ इस dual structure को workflow में पक्का बैठाना एक व्यावहारिक विकल्प बन गया है

dual structure pattern की मुख्य बातें (एक महीने तक चलाकर जो सबसे प्रभावशाली लगा)

• advisory कभी भी blocking नहीं है — Codex अगर CRITICAL issue पकड़ भी ले, तब भी push पास हो जाता है। एक बार blocking बना दिया तो model down होते ही पूरा काम रुक जाता है, और एक false positive के बाद user --no-verify से पूरा hook ही bypass करने लगते हैं
• CLAUDE.md / AGENTS.md में एक जैसी बातें नहीं भरनी चाहिए — लेखक के लिए "कैसे बनाना है", reviewer के लिए "किस बात पर शक करना है"। अगर 80% से ज़्यादा overlap है, तो यह संकेत है कि असल में सही बँटवारा नहीं हुआ
• codex review --base बनाम codex exec को use case के हिसाब से बाँटें — review सीधे git पढ़ता है, इसलिए साफ़-सुथरा है, लेकिन बड़े PR में tokens तेज़ी से बढ़ते हैं; exec में diff को सीधे prompt में डालकर cost control किया जा सकता है। 100 files से ज़्यादा बदलाव हों तो exec पर switch करने का पैटर्न उपयोगी लगा
• pre-push hook में secrets के लिए दो-स्तरीय defense line — file patterns (.env, *.pem, secrets/) पर push abort, inline regex (sk-, ghp_, AKIA…) पर सिर्फ़ warning। advisory का "never block" model output का नियम है; secret files का push एक अलग security incident है, इसलिए वहाँ block करना ही सही है
• graceful degradation को एक wrapper से absorb करें — default में JSON envelope + --raw Markdown, bash-native timeout, और हमेशा exit 0। caller सिर्फ़ status देखकर branch करे

एक महीने इस्तेमाल करने के बाद जो बदला

• merge से ठीक पहले पकड़े जाने वाले bugs बढ़ गए। Claude जिस हिस्से पर पूरे भरोसे से कहता था कि "अच्छा लिखा है", वहाँ Codex ने race condition और छूटा हुआ null check पकड़ा — ऐसे cases काफ़ी बार आए
• PR डालने के अगले दिन फिर खोलकर "अरे, यह मैंने ऐसे क्यों लिखा था" जैसा महसूस होना लगभग बंद हो गया। एक अलग नज़र पहले ही पड़ चुकी होती है, इसलिए regression review की लागत घटती है
• अपने ही code को खुद घूरते रहने वाली self-review fatigue साफ़ तौर पर कम हुई। मानो एक human reviewer और जुड़ गया हो
• migration SQL या payment flow जैसी मुश्किल से rollback होने वाली changes से ठीक पहले कोई दूसरा model एक बार और देख लेता है — मनोवैज्ञानिक रूप से यही सबसे बड़ा फ़र्क लगा

curriculum की संरचना (8 chapters, 5 parts)

• Part 1 दो agents के साथ काम करने की सोच · 1 chapter — single agent के blind spots, cost justification के मानदंड
• Part 2 environment और context · 2 chapters — VSCode + Claude Code + Codex CLI base setup, AGENTS.md vs CLAUDE.md का बँटवारा
• Part 3 review automation patterns · 3 chapters — advisory wrapper script, slash command multi-phase pipeline, pre-push hook automation
• Part 4 operations guide · 1 chapter — काम के प्रकार के अनुसार tool selection tree, cost·model guide, Security & Privacy section
• Part 5 boilerplate · 1 chapter — wrapper·hook·CLAUDE.md/AGENTS.md templates का एक bundle, जिसे अपने repo में सीधे रखा जा सके

इसे समेटते समय जो बात सबसे ज़्यादा महसूस हुई

• dual structure की असली value यह है कि "दो tools एक-दूसरे के gate न बनें"। एक बार blocking की अनुमति दी, तो एक पक्ष down होते ही काम रुक जाता है; और एक false positive के बाद user पूरा hook bypass करने लगते हैं, जिससे hook खुद ही बेअसर हो जाता है
• AI tools जितने तेज़ होते जा रहे हैं, उतना ही यह लग रहा है कि "कौन सा tool इस्तेमाल करते हैं" से ज़्यादा अहम बात यह है कि "कई tools के blind spots को एक-दूसरे पर चढ़ाकर कैसे ढका जाए"। यह बिल्कुल वैसा ही ढाँचा है जैसा किसी code review को एक से ज़्यादा लोगों से करवाने का कारण होता है
• जिन लोगों को AI coding tools के साथ काम करते हुए अपने ही code की खुद दोबारा समीक्षा करना भरोसेमंद नहीं लग रहा था, या जो Claude Code और Codex को साथ में इंस्टॉल करने का फैसला टाल रहे थे, उनके लिए यह साझा करना उपयोगी हो सकता है। अगर कहीं मैंने कुछ गलत समझा या गलत समेटा हो, तो comments में बताएँ, मैं उसे reflect कर दूँगा.

[ajh508]

मैं trilateral-validation नाम का एक validation स्किल बनाकर इस्तेमाल करता हूँ, जिसमें Claude subagent (fresh context) + Codex + Gemini तक जोड़कर verification कराता हूँ.
छोटी-मोटी errors नहीं, बल्कि ऐसे experiments या designs जिनमें direction ही बदलनी पड़े, उनमें main development Claude से कराता हूँ, और GitHub app लगाकर gpt 5.5pro से validation कराता हूँ. (क्योंकि Codex pro model को support नहीं करता...)
मैं production development नहीं करता, सिर्फ research करता हूँ, इसलिए इस बारे में सोचा नहीं था, लेकिन लगता है git hook भी एक बार लगाकर देखना चाहिए.

[ku9cu]

सुना है कुछ लोग ऐसा करते हैं, लेकिन यह जानने की उत्सुकता है कि वे इसे किस तरह करते होंगे।
क्या वे दोनों tools को अलग-अलग agents के रूप में बांधकर नहीं रखते, बल्कि developer ज़रूरत पड़ने पर हर बार उन्हें सीधे अलग से call करता है,
या फिर Git Hook के समय अपने-आप Codex review करे, ऐसी कोई setting लगाकर इसे संभालते हैं—यह जानना चाहता हूँ।

[neostom432]

हम दोनों का इस्तेमाल करने वाले सेटअप पर आकर टिक गए हैं।

हम slash command flow के अंदर Codex cross-review phase डालते हैं (/ship के अंदर planning → implementation → validation → Codex review → reporting के क्रम में), और साथ ही pre-push hook में भी वही review जोड़ते हैं। अगर सिर्फ slash command रखें, तो जल्दी में लोग बस push कर देते हैं और review छूट जाता है; और अगर सिर्फ hook रखें, तो नतीजा push से ठीक पहले आता है, इसलिए देर हो जाती है।

दोनों रास्तों में हम Codex CLI को सीधे नहीं बुलाते, बल्कि एक बार wrap की हुई bash script (codex-review.sh) को दोनों तरफ से एक ही तरह से call करते हैं। वही script timeout, authentication check, secret check, और output format को एक जगह संभाल लेती है, इसलिए चाहे slash command हो या hook, call करने वाली side साफ-सुथरी रहती है।

असली बात यह है कि हम Codex review result के आधार पर कभी भी block नहीं करते। CLI crash हो जाए या CRITICAL आए, तब भी push वैसे ही पास होने देते हैं और सिर्फ result दिखाते हैं। अगर इसे एक बार भी blocking बना दिया जाए, तो जब Codex किसी असल में ठीक code को गलती से issue बता दे, तब user push करने के लिए hook bypass करने वाला option (git push --no-verify) इस्तेमाल करने लगेगा। और अगर यह आदत बन गई, तो hook लगा होने के बावजूद उसका न चलना ही practically वही स्थिति हो जाती है। इसलिए जिन checks में blocking ज़रूरी है (lint·type·test, secret file push), उन्हें अलग gate में रखते हैं, और model की राय को सिर्फ reference के लिए छोड़ते हैं।

script, slash command, और hook का main body Track 4~6 chapters में जस का तस शामिल है, इसलिए चाहें तो उसे देख सकते हैं।