फ़रवरी 2026 तक: coding agents के उपयोग और workflows की तुलना

 (calv.info)
37 पॉइंट द्वारा GN⁺ 2026-02-23 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • coding agent चुनने का मुख्य मानदंड अब सिर्फ model performance नहीं, बल्कि यूज़र के पास उपलब्ध समय और autonomous execution time बनता जा रहा है, और Claude Code तथा Codex को स्थिति के अनुसार साथ-साथ इस्तेमाल किया जा रहा है
  • Opus की ताकत context window management और tool usage में है, और यह कई sub-agents को एक साथ चला सकता है, जिससे तेज़ी से exploration और planning में मदद मिलती है
  • Codex code correctness में Opus से बेहतर है, लेकिन context windows के बीच task delegation की कमी के कारण इसकी processing speed धीमी पड़ती है
  • skill automation के ज़रिए planning → implementation → review → bug fix loop को चरणबद्ध तरीके से बनाया गया, और शुरुआत से सब कुछ design करने के बजाय बार-बार होने वाले manual काम को धीरे-धीरे automate करना अधिक प्रभावी रहा
  • अंततः लक्ष्य ऐसा भविष्य है जहाँ agents 24/7 autonomously काम करें, लेकिन context window की सीमाएँ और prompt injection resistance अभी बड़ी बाधाएँ हैं

Background

  • Codex web version से जुड़े काम किए थे, और जुलाई 2025 में OpenAI छोड़ा
  • YC Lightcone Podcast के बाद coding agents के उपयोग की विस्तृत रणनीतियों को व्यवस्थित करने के लिए यह लेख लिखा गया
  • agent चुनने का मानदंड model performance से हटकर autonomous execution time और काम की अहमियत पर केंद्रित हो रहा है
  • Claude Max, ChatGPT Pro, और Cursor Pro+ तीनों की subscription ली हुई है, और productivity के मुकाबले इनकी cost efficiency काफ़ी अच्छी है

मुख्य सिद्धांत: context को समझना

  • coding agents का सही उपयोग करने के लिए context को समझना ज़रूरी है
  • agent कितना भी अच्छा हो, अंत में वह next token prediction ही करता है, और सभी tokens को context window के भीतर आना होता है
  • इससे निकलने वाले मुख्य सिद्धांत:
    • समस्या को context window के हिसाब से उचित आकार में बाँटना चाहिए; बहुत बड़ी समस्या में ज़्यादा समय लगता है और नतीजे भी खराब होते हैं
    • Compaction एक lossy technique है; कौन-सी जानकारी रखनी है और क्या छोड़ना है, यह agent तय करता है, और compaction बढ़ने पर performance गिरने की प्रवृत्ति होती है
    • planning documents जैसे माध्यमों से context को filesystem में externalize करने पर agent पूरी conversation context भरे बिना ज़रूरत के अनुसार पढ़ और याद रख सकता है
    • context window के 'smart half' में बने रहना ज़रूरी है; छोटे context data पर training बेहतर होती है, इसलिए कम भरी window में बेहतर परिणाम मिलते हैं — Dex Horthy इसे 'dumb zone' से बाहर रहना कहते हैं
    • अगर agent कोई relevant file या package miss कर दे, तो काम अनपेक्षित दिशा में जा सकता है; codebase structure और architecture की 'progressive disclosure' इसमें मदद करती है — OpenAI कई markdown files को किस तरह structure करता है इस पर एक blog post भी है
  • model की performance और speed सिर्फ model की raw capability पर नहीं, बल्कि कई context windows को manage करने और sub-agent/team delegation की क्षमता पर भी निर्भर करती है

Opus: context management, tool usage, और human-like feel

  • Claude Code को planning, terminal orchestration, और git/GitHub tasks management के मुख्य tool की तरह इस्तेमाल किया जाता है
  • Opus को कई context windows के बीच बहुत कुशलता से काम करने के लिए train किया गया है, इसलिए Claude Code इस्तेमाल करते समय यह Codex से तेज़ महसूस होता है
  • अक्सर देखा गया है कि Opus Explore या Task calls जैसे कई sub-agents एक साथ चलाता है
    • Explore tool Haiku इस्तेमाल करता है, इसलिए यह बड़ी मात्रा में tokens को तेज़ी से process करके relevant context Opus तक पहुँचाता है
  • gh, git, और अलग-अलग MCP servers जैसे local tools के उपयोग पर इसकी training भी अच्छी है
    • /chrome extension से bug verification भी किया जा सकता है, लेकिन यह धीमा और unstable हो सकता है
  • Claude Code का permission model Codex की तुलना में समझना आसान है — Codex model bash में commands को script करने की प्रवृत्ति रखता है, इसलिए individual CLI tools की whitelisting मुश्किल होती है
  • Claude Code के UX के छोटे लेकिन उपयोगी फ़ायदे: terminal title को task के अनुसार update करना, status bar में current PR दिखाना, छोटे status messages आदि
  • Opus, Codex की तुलना में इंसानों के लिए समझने में आसान PR descriptions और विस्तृत architecture diagrams बनाने में बेहतर है
  • code structure की व्याख्या चाहिए हो तो ज़्यादातर Claude Code इस्तेमाल किया जाता है
  • planning के समय Opus ज़्यादा 'creative' है; यह ऐसी चीज़ें सुझा देता है जिनका यूज़र ने ज़िक्र नहीं किया या अस्पष्ट हिस्सों की ओर ध्यान दिलाता है

Codex: बेहद मज़बूत code correctness

  • Codex की सबसे बड़ी ताकत code correctness है, और model का अधिक उपयोग करने वाले दूसरे developers भी इससे सहमत हैं
  • GPT-5.3-Codex-xhigh या high पर चलाने पर Codex के code में bugs स्पष्ट रूप से कम होते हैं
  • Opus की बार-बार दिखने वाली गलतियों के उदाहरण:
    • React component unit test पास कर जाता है, लेकिन ऊपरी <App> में जोड़ना भूल जाता है
    • साफ़ दिखने वाली off-by-one error पकड़ नहीं पाता
    • सूक्ष्म dangling references या race condition
  • लंबे समय तक लगा कि दोनों models के बीच फ़र्क़ नज़रअंदाज़ करने लायक है, लेकिन Codex और Cursor Bugbot की automated review के जरिए काफ़ी PR देखने के बाद OpenAI models की code quality बेहतर लगी
    • खुद A/B test करना हो तो branch checkout करके Claude Code के /code-review और Codex के /review की तुलना की जा सकती है
  • लेकिन Codex धीमा है — मुख्य वजह context windows के बीच task delegation की कमी है, और token latency भी अधिक महसूस होती है
    • experimental sub-agent support (/experimental toggle) इस्तेमाल करने पर काम तो करता है, लेकिन Claude जितना smooth नहीं है और parallelism भी अभी कम है
  • नतीजतन पैटर्न यह है कि शुरुआत Claude Code से की जाती है, उसे window में खुला रखा जाता है, और actual coding phase में Codex पर switch किया जाता है

उपयोगी tools और setup

  • इस समय greenfield codebase पर काम हो रहा है, जो production codebase की तुलना में कहीं छोटा और token-efficient है
  • repo structure: हर repo में plans/ folder, जिसमें numbered planning docs रखे जाते हैं; apps/ folder से services को अलग किया जाता है; turborepo से TypeScript monorepo manage किया जाता है; और bun से तेज़ install होता है
  • Ghostty: Mitchellh का terminal, तेज़, native और लगातार बेहतर हो रहा है — पहले tmux के साथ कई Claude/Codex instances चलाए जाते थे, लेकिन अब उसी terminal tab में कई panes इस्तेमाल होते हैं
  • Vercel पर Next.js, और API के लिए Cloudflare Durable Objects: database को पहले से partition करके on-demand जगाया जाता है, और concurrent writes की चिंता कम रहती है — छोटे data chunks के साथ काम करने वाले agents के दौर में infra के नज़रिए से यह उपयुक्त है
    • Cloudflare cloudflare/actors library के ज़रिए compute और छोटे co-located storage को जोड़ने वाली दिशा में विस्तार कर रहा है
  • Worktrees: code हल्का होने के कारण parallel worktrees का उपयोग किया जाता है, और हर एक में bun install → bun run dev से local verification किया जाता है — इससे जुड़े plans, env vars, और updates copy करके नई branch शुरू करने के लिए worktree skill इस्तेमाल होता है
    • coding agents से पहले ज़्यादातर सिर्फ branches इस्तेमाल होती थीं, लेकिन worktree और Claude Code का संयोजन बहुत उपयोगी साबित हुआ
  • Plan, Implement, Review: लगभग हमेशा model को planning से शुरुआत करने के लिए कहा जाता है — 1) context को एक context window से बाहर externalize करना 2) क्या किया गया उसका review करना या सवाल पूछना संभव बनाना — अगर agent रुक जाए तो नए context window में plan फिर से शुरू किया जा सकता है
  • Preview deploys: हर branch को नई Web + API deployment मिलती है, जिससे parallel execution और तेज़ testing आसान होती है — इस feature के बिना काम करना मुश्किल लगता है
  • Cursor Bugbot और Codex Code Review: architecture level पर code को समझकर spot checks किए जाते हैं, लेकिन अब हर PR की हर line खुद नहीं पढ़ी जाती — सूक्ष्म bugs पकड़ने में agents बेहतर हैं
    • एक समय Claude Code, Cursor Bugbot, और Codex तीनों इस्तेमाल होते थे, लेकिन Claude Code वास्तविक issues पकड़ने में कमज़ोर रहा, इसलिए Cursor default option बन गया, जबकि Codex के results भी अच्छे माने गए

Skills: automation की कुंजी

  • कई skills और shared AGENTS.md/CLAUDE.md को claudefiles नाम के repo में define किया गया है
  • skill जोड़ने का नियम: जल्दबाज़ी में नहीं, बल्कि किसी workflow को कई बार दोहराने और उसके स्थिर होने के बाद ही skill जोड़ी जाती है
  • AGENTS/CLAUDE.md model की overall दिशा तय करने में उपयोगी है, और skills के दो मुख्य उद्देश्य हैं:
    1. workflow chaining और automation — planning → stepwise implementation → review को अलग-अलग skills बनाकर उन्हें क्रम से चलाने वाला meta-skill बनाना
    2. context window splitting — Claude Code में skill call पर context: fork सेट करने से इसे नए context window में चलाया जा सकता है, जिससे 'master orchestrator' और sub-agents अलग किए जा सकते हैं
  • skills बहुत context-efficient हैं; MCP calls जहाँ हज़ारों tokens ले सकते हैं, वहीं skills आमतौर पर ~50-100 tokens में काम कर लेते हैं

Skill automation का evolution

  • शुरुआत में skill marketplace के विचार में दिलचस्पी थी, जहाँ frontend design, security checks, architecture review जैसी चीज़ें install की जा सकें, लेकिन काम करते-करते दूसरों द्वारा लिखी गई ज़्यादातर skills छोड़ दी गईं
  • इसके बजाय पहले manual काम करने और फिर यह सोचने का तरीका अपनाया गया कि इसे automate कैसे किया जाए
  • skills के विकास की प्रक्रिया:
    • /commit: model को commit और push के लिए अलग-अलग तरीक़े से निर्देश देने के बजाय एक skill में समेकित किया गया — सीधे Claude Code से लिया गया
    • /worktree: agent को अलग worktree में काम करवाने के लिए, plan number के आधार पर (जैसे 00034-add-user-auth) नया worktree बनाना
    • /implement: plan के किसी step को execute करने और फिर /commit चलाने वाले दोहराए जाने वाले काम को एक skill में जोड़ना
    • /implement-all: current worktree path को किसी plan number से जोड़कर सभी steps अपने-आप implement करना — रात में चलाने के लिए /ralph-loop के साथ तब तक चलता रहता है जब तक सारे steps पूरे न हो जाएँ; local /codex-review से codex --review process बनती है
    • /address-bugs: GitHub API से last commit के बाद आए Cursor + Codex comments खोजकर bugs verify और fix करने की कोशिश
    • /pr-pass: /implement-all के ख़त्म होने पर चलाया जाता है, और 1) remote push 2) सभी CI pass होने का इंतज़ार 3) /address-bugs चलाना, फिर ज़रूरत हो तो step 1 दोहराना
    • /focus: plans directory, अधूरे PRs, और worktrees देखकर memory refresh करना और काम को track करने में मदद
  • अगर इस process को शुरुआत से पूरा बनाने की कोशिश की जाती, तो शायद सफलता नहीं मिलती; असली कुंजी यह थी कि समय के साथ छोटे-छोटे automation opportunities पहचानकर इसे धीरे-धीरे बनाया गया

दूसरे tools

  • हाल में Codex App इस्तेमाल किया गया और इसके details व छोटे touches का अच्छा प्रभाव पड़ा — फिर भी CLI tool की flexibility पसंद होने के कारण पूरी तरह switch नहीं किया गया
  • Cowork भी आज़माया गया, लेकिन उसे ठीक से चलाना मुश्किल रहा; दोनों ही मामलों में sandboxing model बड़ा अंतर पैदा करता है
  • asynchronous tasks के लिए कभी-कभी web interface इस्तेमाल होता है, लेकिन धीरे-धीरे CLI पर निर्भरता बढ़ रही है — यह 6 महीने पहले के उस समय के उलट है जब मुख्य रूप से Cursor और उसके built-in agent/extension features इस्तेमाल होते थे
  • frontend UI काम के लिए pencil.dev इस्तेमाल हो रहा है — local Claude Code में shell out करके existing subscriptions का पुन: उपयोग करने वाला इसका deployment model दिलचस्प है
  • अब एक अधिक structured issue tracker की ज़रूरत महसूस होती है; David Cramer का Dex और Steve Yegge का beads आशाजनक लगते हैं, लेकिन अभी ज़रूरत से ज़्यादा complex महसूस होते हैं
  • Playwright जैसे automated e2e MCP फिलहाल इस्तेमाल नहीं किए जाते

labs के लिए सलाह

  • Anthropic के लिए feedback

    • model: Opus में human-like feel, engineering tools का उपयोग, context splitting, और "यूज़र शायद जो भूल गया हो" जैसी चीज़ें सुझाने की क्षमता मज़बूत है, लेकिन code correctness कमज़ोर है — उम्मीद है कि 'Opus Strict' mode के रूप में base model पर RL को और मज़बूत करके performance सुधारी जाएगी
      • शुरुआत Opus से की जाती है, लेकिन code Codex लिखता है; अगर budget limit हो, तो Codex चुना जाएगा
    • product harness: लगभग शिकायत करने लायक कुछ नहीं; Boris और Cat के ideas बहुत अच्छे हैं
      • agent skills standard अपनाने का अनुरोध — कई CLIs के बीच directory symlinks संभालना असुविधाजनक है
      • --stream-json के output format को public करने का अनुरोध — यूज़र की तरफ़ से sandbox में Claude Code चलाने में रुचि है, लेकिन format बदलने की आशंका और path settings, Codex/Cursor/Gemini जैसे दूसरे CLI tools की तुलना में ज़्यादा झंझट वाली हैं

  • OpenAI के लिए feedback

    • model: सबसे ज़रूरी सुधार context windows के बीच splitting और sub-agent delegation है — Opus planning में जो "माँगे गए से ज़्यादा" करता है, वह अवधारणा भी उपयोगी होगी
    • product harness पर विस्तृत feedback:
      • sandboxing model, Claude Code की तुलना में समझना मुश्किल है — model scripting की कोशिश करता है, इसलिए approval requests बढ़ जाती हैं, और --yolo mode को लेकर चिंता रहती है
      • Claude Code की तरह CLI में built-in user guide जोड़ने का अनुरोध — ताकि skill locations, supported fields, sandboxing model settings वगैरह के बारे में पूछा जा सके
      • /review को packaged command के बजाय general skill में बदलने का अनुरोध — ताकि model इसे dynamically call कर सके
      • execution के दौरान terminal tab title को task के अनुसार बदलने का अनुरोध — दर्जनों codex tabs में भ्रम पैदा होता है
      • PR descriptions और commit descriptions के लिए विशेष training की ज़रूरत — Codex का concise स्वभाव अच्छा है, लेकिन explanations को विस्तार चाहिए
      • skill definitions में context: fork support जोड़ने का अनुरोध
      • pane में links line wrap होने पर भी clickable बने रहें, यह सुधार माँगा गया
      • status bar के नीचे current worktree/PR/branch name दिखाने का अनुरोध

आगे की दिशा

  • Steve Yegge की Gas Town post का हवाला दिया गया — तर्क यह है कि हमेशा maximum tokens इस्तेमाल होंगे, worker pool 24/7 चलता रहेगा, और बहुत-सी plans बनाई और छोड़ी जाएँगी
    • abstraction सही है या नहीं, इससे अलग, दिशा के स्तर पर यह बिल्कुल सही मानी गई है
  • आदर्श भविष्य: laptop या cloud sandbox background में लगातार ideas process करे, और यूज़र केवल दिशा तय करे, research करे, या results की review करे
    • coding agents के साथ काम करना engineering manager की भूमिका जैसा महसूस होता है, लेकिन agent की motivation या personality की चिंता नहीं करनी पड़ती
  • अभी हम इस भविष्य के काफ़ी क़रीब पहुँच चुके हैं — Twitter पर इसे बढ़ा-चढ़ाकर बताया जाता है, लेकिन व्यवहार में सोने से पहले Codex में 3-4 tasks शुरू करके सुबह review करना अब routine बन चुका है
    • फिर भी अभी agents को 24/7 चलाने का स्तर नहीं आया है
  • और आगे बढ़ने से रोकने वाली दो बड़ी बाधाएँ:
    1. context window size/orchestration — agent एक ही context window में हमेशा compress/reuse नहीं कर सकता; ज़्यादा smart harness या delegation mechanism की ज़रूरत है
    2. prompt injection resistance — agent कुछ ही मिनटों में approval माँग लेता है, और --yolo mode पर भरोसा नहीं किया जा सकता, हालाँकि permissions/domains के कुछ subsets स्वीकार्य हो सकते हैं
  • पहली समस्या पर Cursor कई context windows में फैले agent swarm की सीमा को आगे बढ़ा रहा है, और दूसरी समस्या सक्रिय research का क्षेत्र है
    • sandbox execution अभी सबसे अच्छा workaround है, लेकिन setup अब भी झंझट भरा है, और अगर agent के पास open internet access और privileged data एक साथ हो, तो Simon Willison के बताए 'Lethal Trifecta' का ख़तरा रहता है
  • एक solo engineer के रूप में अब सही ideas ही bottleneck बन गए हैं, और आगे चलकर ideas, architecture, और project sequencing ही शानदार products बनाने की मुख्य सीमाएँ बन सकती हैं

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.