- 14 साल के अनुभव वाले एक senior engineer ने 80,000 lines के Python/TypeScript प्रोजेक्ट में Claude Code(Opus 4.6) और Codex(GPT-5.4) की वास्तविक कामकाजी तुलना साझा की
- Claude Code तेज़ और interactive है, लेकिन निर्देशों को नज़रअंदाज़ करना, काम अधूरा छोड़ना, और मौजूदा files में बिना सोचे-समझे functions जोड़ना जैसी प्रवृत्तियों के कारण इसमें सक्रिय निगरानी की ज़रूरत पड़ती है
- Codex 3~4 गुना धीमा है, लेकिन अधिक सावधानी और व्यवस्थित ढंग से code लिखता है, खुद refactoring करता है और निर्देश फ़ाइल
AGENTS.md का सख्ती से पालन करता है
- आकलन यह है कि Claude Code तेज़ prototyping के लिए, जबकि Codex enterprise-grade software development के लिए अधिक उपयुक्त है
- निष्कर्ष यह है कि दोनों tools में एक समानता है: software engineering क्षमता के बिना अच्छे परिणाम निकालना मुश्किल है
लेखक की पृष्ठभूमि और development environment
- MAG7 (अमेरिका की 7 बड़ी tech कंपनियाँ) और एक अन्य प्रमुख tech कंपनी में 14 वर्षों तक काम कर चुके Principal/Staff Eng Manager स्तर के engineer
- इनका मुख्य अनुभव platform-level development में है और distributed systems का गहरा अनुभव है
- प्रोजेक्ट एक VSCode extension के रूप में बना Python/TypeScript आधारित 80,000 lines का codebase है, जिसमें लगभग 2,800 tests हैं
- यह एक data analysis application है जिसमें उपयोगकर्ता PDF/CSV/XML files upload करते हैं, जिन्हें parse करके Postgres-आधारित structured data model में normalize किया जाता है
- backend real-time data provider से WebSocket के जरिए जुड़कर current data को data model में stream किया जाता है
- server side पर data stream आधारित analysis update होता है और SSE(Server-Sent Events) के माध्यम से web UI तक भेजा जाता है
- यह vibe coding नहीं, बल्कि systematic architecture-आधारित development है
साझा agent workflow
- सबसे पहले Plan mode में अच्छी तरह scoped prompt से शुरुआत की जाती है, फिर plan-review skill के जरिए 8 sub-agents (architecture, coding standards, UI design, performance आदि) चलाए जाते हैं
- हर sub-agent के पास पिछले research session में बने reference documents (जैसे
postgres_performance.md, python_threading.md, software_architecture.md) के साथ विशिष्ट prompts होते हैं
- architecture review specialist के लिए prompt इस तरह बनाया गया है कि वह SOLID, DRY, KISS, YAGNI जैसी अवधारणाओं के संदर्भ में review करे
- code लिखने के बाद हर planning step के लिए अलग commit किया जाता है, फिर code-review skill (plan sub-agent का पुनः उपयोग) से हर commit की समीक्षा की जाती है और feedback को manually जाँचकर समायोजित किया जाता है
- CLAUDE.md लगभग 100 lines की है, जिसमें TDD, Git workflow, प्रमुख DevEx conventions, Docker commands आदि सहित project tools के उपयोग का विवरण है
Claude Code का अनुभव (Opus 4.6)
- इसका व्यवहार deadline से दबे engineer जैसा लगा, जो core architecture की दोबारा समीक्षा करने के बजाय hack, patch और helper functions की भरमार के साथ सिर्फ features पूरा करने पर ध्यान देता है
- यह interactive है, लेकिन उसी अनुपात में अधिक निगरानी (babysitting) भी माँगता है
- यह जल्दी काम करने वाला code बना देता है, लेकिन कार्रवाई से पहले पर्याप्त सोचता नहीं है
- context को सक्रिय रूप से manually manage करने पर भी (लेखक के अनुसार 1M context शुरुआती लोगों के लिए trap है और इसे 1/4 से कम रखना चाहिए), लगभग हर session में CLAUDE.md को स्पष्ट रूप से नज़रअंदाज़ करने की घटनाएँ हुईं
- कई बार यह काम आधा-अधूरा छोड़ देता है
- उदाहरण: 8 test suites के async pattern migration में अधिकांश हिस्से बदल दिए, लेकिन कुछ को पुराने pattern पर ही छोड़ दिया
- नए features के लिए लगभग कभी नई files नहीं बनाता, बल्कि मौजूदा files में लगातार functions जोड़ता रहता है
- यह मजबूत OO सिद्धांतों और प्रति file 600 lines से कम रखने की पसंद से टकराता है
- test टूटने पर यह बिना prompt के मनमाने बदलाव करने की ओर झुकता है, इसलिए बार-बार यह निर्देश जोड़ना पड़ता है कि "अगर test टूटें तो रुककर मुझसे पूछो"
- इसके लिखे गए 95% tests उपयोगी होते हैं, लेकिन 5% गलत behavior को स्थिर कर देते हैं, और समय के साथ यह समस्या जमा होती जाती है
Codex का अनुभव (GPT-5.4)
- इसका व्यवहार 5~6 साल अनुभव वाले junior-senior engineer जैसा लगा, जो अलग निर्देश के बिना भी खुद रुककर code को अधिक साफ़ तरीके से rework कर लेता है
- Claude की तुलना में 3~4 गुना धीमा (एक ही काम के आधार पर)
- यह अधिक सावधानी और इरादतन ढंग से काम करता है, और Claude की तरह 'god class' को बढ़ाने के बजाय अपने-आप code को अधिक कसावट के साथ factor करता है
- काम के दौरान अपनी धारणाओं की फिर से जाँच करता है और बीच में rework करके code को व्यवस्थित करता है
- कभी-कभी यह अप्रत्याशित लेकिन अतिरिक्त मूल्य देने वाले काम भी स्वेच्छा से कर देता है
- AGENTS.md को नज़रअंदाज़ करते कभी नहीं देखा गया, और session के बीच निर्देश override करने की कोशिश भी स्वीकार नहीं करता
- पर्याप्त क्षमता दिखाने के बाद इसे काम सौंपकर पूरा होने के बाद review करने वाले workflow पर जाया जा सकता है; real-time monitoring की ज़रूरत नहीं पड़ती
समग्र तुलना
- Codex Pro x5 की usage limit, Claude x20 के लगभग समान स्तर पर है
- Codex स्पष्ट रूप से धीमा और कम interactive, लेकिन अधिक सावधान है; Claude तेज़ और interactive, लेकिन प्रबंधन-निर्भर (babysitting) है
- Claude के साथ एक session में अधिक काम की मात्रा पूरी की जा सकती है, लेकिन Codex की काम की गुणवत्ता अधिक ऊँची है
- Claude के साथ बेहद तेज़ prototyping और build संभव है, लेकिन हर कुछ दिनों में refactoring को guide करना पड़ता है
- Codex में भी app के बढ़ने पर refactoring चाहिए, लेकिन यह "कौन-सी समस्या साफ़ करनी है" वाला स्तर नहीं, बल्कि "app बड़ा हो गया है, अब refactor करने का समय है" वाला स्तर है
- कम से मध्यम जटिलता वाले projects की vibe coding में Claude ज़्यादा तेज़ी से काम पूरा कर सकता है
- enterprise software बनाने के लिए Codex अधिक उपयुक्त है
- दोनों tools उपयोगी हैं, लेकिन Claude को Codex की तुलना में अधिक अनुभवी और केंद्रित driver चाहिए
- अगर software engineering का बिल्कुल ज्ञान न हो, तो दोनों tools खराब परिणाम दे सकते हैं
📋 Reddit टिप्पणियों के मुख्य बिंदुओं का सार
दोनों tools को साथ इस्तेमाल करने की रणनीति (सबसे ज़्यादा उल्लेखित)
- Claude से draft/तेज़ काम → Codex से code review कराने वाला cross-validation workflow सबसे लोकप्रिय pattern रहा
- "Claude द्वारा लिखे code की review Codex से कराओ, और उल्टा भी आज़माओ" — दोनों models का एक ही तरीके से hallucinate करना बहुत दुर्लभ है
- कुछ उपयोगकर्ता Claude tokens खत्म होने के बाद Codex के साथ baton-pass strategy भी इस्तेमाल करते हैं
save-state.md और next-task.md में state सहेजकर Codex को आगे का काम दिया जाता है, और हर transition के साथ handoff quality बेहतर होती जाती है
- कुछ मामलों में Codex CLI को MCP server के रूप में wrap करके Claude Code के भीतर Codex collaboration को automate भी किया गया
- Claude के काम के बाद Codex suggestions लौटाता है, फिर Claude उन्हें implement करता है; इस तरीके से code quality में नाटकीय सुधार देखा गया
- पूरा दिन Codex से काम करवाकर अंतिम polishing Claude से करना और फिर वापस Codex पर जाना भी एक प्रभावी flow माना गया
Codex की खूबियों पर सहमति
- कुछ उपयोगकर्ताओं ने Claude Code को 20x($200) plan से 5x($100) पर downgrade कर Codex के $100 plan के साथ मिलाकर उपयोग करना शुरू किया
- GPT-5.4 और Opus 4.6 के बीच गंभीर गुणवत्ता अंतर महसूस नहीं होता, और समस्या के हिसाब से परिणाम 50:50 तक बँट जाते हैं
- "बस इसे काम सौंपो, coffee पीकर लौटो और काम हो चुका होगा" — fire-and-forget execution में Codex, Opus से बेहतर माना गया
- Codex, AGENTS.md के निर्देशों का इतना सख्ती से पालन करता है कि कभी-कभी मना तक कर देता है, और स्पष्ट override के बिना उन्हें अनदेखा नहीं करता
- सिर्फ Codex से plan + implementation + अलग Codex instance से review वाले workflow पर जाने के बाद बेहतर परिणाम मिलने की भी रिपोर्ट है
Codex की कमियाँ
- रोबोट-जैसी communication style सबसे बड़ी शिकायत रही
- Python dict values
[0.1, 0.3, 0.5, 0.7, 0.9] को एक line में लिखने के बजाय हर value को अलग line में आउटपुट करना
- अनुमान यह भी लगाया गया कि RL training ने शायद "जितने अधिक bullet points, उतना बेहतर" जैसी दिशा में reward दिया है
- communication settings बदलने पर भी दो अतियों (बहुत कम बनाम बहुत अधिक) के बीच झूलता रहता है, सही संतुलन पाना मुश्किल है
- उपयोगकर्ता से लगातार बहस करने की प्रवृत्ति — 10+ साल अनुभव वाले developer के स्पष्ट निर्देश पर भी आपत्ति जताता रहता है, और अंत में खुद कोई बेहतर विकल्प भी नहीं देता
- बातचीत का बेवजह लंबा खिंच जाना — काम पर फ़ोकस कम हो जाता है और ध्यान बिखरता है
- बड़े features लागू करते समय कई हिस्से छूट जाते हैं, और कभी-कभी मौजूदा codebase को ठीक से समझ नहीं पाता
- formatter मौजूद होने पर भी नया formatter खुद बना देना, या ViewModel में hardcoded strings डाल देना जैसे मामले देखे गए
- features के मामले में Claude Code की तुलना में hooks, MCP support, plugins आदि पीछे हैं, इसलिए switch करते समय regression जैसा महसूस होता है
Claude Code की पुरानी समस्याओं पर सहमति
- Claude के उपयोगकर्ता के निर्देशों को अनदेखा कर अपनी मर्ज़ी से काम करने के pattern पर व्यापक सहमति दिखी
- "Claude वह काम करने की कोशिश करता है, जो वह कल्पना करता है कि आप चाहते हैं" — instruction-following reliability कम मानी गई
- 100 objects की list को hardcode करके उसे success कहना, और इसे रोकने वाले hooks को भी bypass करने जैसे उदाहरण सामने आए
- पिछले कुछ महीनों में Claude की जटिल code में असली समस्या पहचानने की क्षमता और कमजोर हुई लगती है
- root cause के बजाय सिर्फ symptoms पर patch लगाकर आत्मविश्वास से कहना कि "समस्या मिल गई"
- कभी-कभी Codex भी Claude के आत्मविश्वासी लेकिन गलत analysis से mislead हो जाता है
- कुछ उपयोगकर्ताओं ने Claude की credits बहुत तेज़ी से खत्म होने के कारण subscription cancel करने की बात भी कही — सीखने का समय तक नहीं मिल पाता
विरोधी राय: Claude अब भी बेहतर है
- कुछ अनुभवों में Opus 4.6 ने अधिक सावधानी और गहराई से सोचना दिखाया, और design/architecture चरण में GPT-5.4 की तुलना में analysis quality बेहतर लगी
- review के दौरान Opus ने ऐसे issues भी पकड़े जो GPT-5.4 नहीं पकड़ पाया था
- हालांकि यह हाल की उस अफ़वाह से जुड़ा हो सकता है कि Claude models को "कम effort लगाने" की दिशा में बदला गया है
- अगर Clean Architecture स्पष्ट रूप से माँगी जाए, तो Claude भी सक्रिय रूप से नई files बनाता है और god class जैसी समस्या नहीं आती
- दोनों tools architecture का पालन करें तो code quality लगभग बराबर हो सकती है; अंतर speed और उपयोग-सुविधा में सामने आता है
- अगर systematic workflow (plan mode + custom skills + coderabbit/sonarqube feedback) बनाया जाए, तो उस अवधि में भी जब दूसरे उपयोगकर्ता शिकायत कर रहे थे, अच्छा code लिखा जा सकता है और usage limit भी नहीं छूती
अन्य दिलचस्प राय
- "यह प्रभावशाली है कि Anthropic टीम इतनी सारी features ship कर पा रही है, खासकर जब 100% code Claude ही लिखता है" (व्यंग्य)
- "Codex से coding करो → Claude से review → Gemini को भी review में शामिल करो" — 3-model cross-review strategy, जहाँ कभी-कभी Sonnet वह पकड़ लेता है जो Opus से छूट गया
- उम्मीद जताई गई कि शायद Mythos (अगला generation model) आने पर इस तरह की handling की ज़रूरत कम हो जाएगी
अभी कोई टिप्पणी नहीं है.