Claudex Loop چیست؟ کدنویسی مشترک Claude و Codex با بررسی دوطرفه

وقتی از هوش مصنوعی برای برنامه‌نویسی استفاده می‌کنیم، یک مشکل مهم وجود دارد:

مدلی که خودش یک تصمیم معماری گرفته یا کدی نوشته، ممکن است هنگام Review همان خروجی متوجه بعضی از اشتباهات خودش نشود.

این دقیقاً همان مشکلی است که پروژه متن‌باز Claudex Loop سعی می‌کند با همکاری Claude Code و OpenAI Codex کمتر کند.

به‌جای اینکه یک مدل همه مراحل را از طراحی تا Code Review انجام دهد، Claudex Loop بین دو Provider مستقل تقسیم کار می‌کند:

• یک مدل Requirements و Plan را آماده می‌کند.
• مدل دوم Plan را به‌صورت مستقل نقد می‌کند.
• یکی از مدل‌ها Implementation را انجام می‌دهد.
• مدلی که کد را ننوشته، Final Inspection را انجام می‌دهد.

ایده اصلی بسیار ساده است:

Whoever built it never grades it.

یعنی مدلی که پروژه را ساخته، داور نهایی همان کد نباشد.

در این مقاله از معین گیفت بررسی می‌کنیم Claudex Loop چیست، چطور Claude Code و Codex را کنار هم قرار می‌دهد، روش نصب آن چیست و آیا واقعاً استفاده از دو مدل می‌تواند خطاهای کدنویسی را کمتر کند.

Claudex Loop چیست؟

Claudex Loop یک پروژه متن‌باز برای ساخت Workflow مشترک بین:

• Claude Code
• OpenAI Codex CLI

است.

هدف پروژه این نیست که این دو مدل همزمان بدون ساختار روی یک Codebase کار کنند.

بلکه یک Workflow مشخص برای:

• Requirement Gathering
• Planning
• Adversarial Plan Review
• Implementation
• Independent Code Inspection

ایجاد می‌کند.

چرا استفاده از دو مدل می‌تواند مفید باشد؟

فرض کنید Claude یک Feature را طراحی کرده و تمام تصمیم‌های معماری را خودش گرفته است.

بعد از Implementation از همان Claude بپرسید:

کدی که خودت نوشتی را بررسی کن و مشکلاتش را پیدا کن.

Claude می‌تواند Bugs زیادی را پیدا کند، اما احتمال دارد بعضی فرضیات اولیه خودش را دوباره زیر سؤال نبرد.

در Claudex Loop، Plan یا Code به Provider دیگری داده می‌شود.

برای مثال:

Claude
   ↓
Plan
   ↓
Codex
   ↓
Adversarial Review

Codex از ابتدا درگیر تصمیم‌های Claude نبوده و می‌تواند Plan را با نگاه مستقل‌تری بررسی کند.

Workflow اصلی Claudex Loop

نسخه فعلی پروژه Workflow را به چند مرحله تقسیم می‌کند.

مرحله اول: Recon

قبل از طراحی Solution، Agent باید Codebase را بررسی کند.

مواردی مثل:

• ساختار پروژه
• Dependencyها
• فایل‌های مرتبط
• Call Siteها
• Shared State
• ADRها و Documentation موجود

بررسی می‌شوند.

هدف این است که Plan براساس Code واقعی پروژه نوشته شود، نه براساس حدس.

مرحله دوم: Requirements

Host فعلی مسئول مشخص کردن Requirementهاست.

اگر Workflow را از Claude Code شروع کرده باشید:

Claude = Coordinator

و اگر آن را داخل Codex شروع کنید:

Codex = Coordinator

Coordinator ابهام‌های مهم را مشخص می‌کند و Plan را آماده می‌کند.

مرحله سوم: Independent Plan Review

حالا Provider دیگر وارد می‌شود.

اگر Host شما Claude باشد:

Claude → Plan
Codex  → Review

و اگر از Codex شروع کرده باشید:

Codex  → Plan
Claude → Review

Reviewer قرار نیست فقط بگوید:

Plan خوب است.

بلکه باید Findings مشخص ارائه کند.

Review ساختاریافته است

Claudex Loop برای Review خروجی ساختاریافته می‌خواهد.

Reviewer باید Verdict مشخصی بدهد:

APPROVED
REVISE
BLOCKED

و در صورت وجود مشکل، مواردی مثل:

• Severity
• File Path
• Evidence
• Fix
• Coverage
• Limitations

را ثبت کند.

بنابراین Review فقط یک نظر کلی نیست.

مثلاً Codex چه چیزی را بررسی می‌کند؟

فرض کنید Claude برای سیستم Authentication چنین Planی ساخته باشد:

1. Replace session auth with JWT
2. Store token in localStorage
3. Add refresh endpoint
4. Protect API routes

Reviewer ممکن است بگوید:

REVISE

High:
Storing long-lived auth tokens in localStorage
increases exposure to XSS.

Medium:
The plan does not define refresh-token rotation.

Medium:
Logout/revocation behavior is unspecified.

Coordinator Findings را بررسی می‌کند و Plan را اصلاح می‌کند.

Review Loop محدود است

یکی از نکات خوب طراحی Claudex Loop این است که Review بی‌نهایت ادامه پیدا نمی‌کند.

نسخه فعلی به‌صورت پیش‌فرض حداکثر:

5 Plan Review Rounds

در نظر می‌گیرد.

این مقدار قابل تنظیم است.

بعد از تأیید Plan، چه کسی کدنویسی می‌کند؟

اینجا یکی از نکاتی است که در معرفی‌های کوتاه Claudex Loop معمولاً اشتباه توضیح داده می‌شود.

Builder ثابت نیست.

می‌توانید مشخص کنید:

builder=claude

یا:

builder=codex

در حالت پیش‌فرض، Host فعلی Builder است.

مثال اول؛ Claude می‌سازد و Codex بررسی می‌کند

Claude Code
     ↓
Requirements
     ↓
Plan
     ↓
Codex Review
     ↓
Claude Implementation
     ↓
Fresh Codex Inspection

مثال دوم؛ Codex می‌سازد و Claude بررسی می‌کند

اگر Workflow را از Claude شروع کنید اما Builder را Codex تعیین کنید:

Claude Code
     ↓
Requirements + Plan
     ↓
Codex Plan Review
     ↓
Codex Implementation
     ↓
Fresh Claude Inspection

این همان Workflowی است که معمولاً با جمله:

Claude طراحی می‌کند، Codex می‌سازد و Claude کد را بررسی می‌کند.

توصیف می‌شود.

اما این فقط یکی از Configurationهای ممکن است.

مهم‌ترین قانون؛ Builder خودش Inspector نیست

اصل اصلی Claudex Loop این است:

مدلی که Implementation را انجام داده، Final Inspection را انجام ندهد.

بنابراین:

چرا Final Inspection در Session تازه انجام می‌شود؟

Claudex Loop برای Inspection نهایی از یک Fresh Session استفاده می‌کند.

دلیلش این است که Reviewer نهایی کمتر تحت تأثیر Conversation قبلی و تصمیم‌های Builder قرار بگیرد.

یعنی هدف فقط عوض کردن نام مدل نیست؛ Context Review هم تا حد ممکن مستقل نگه داشته می‌شود.

چه چیزهایی در Final Inspection بررسی می‌شوند؟

بسته به پروژه، Inspector می‌تواند مواردی مثل:

• Bugهای منطقی
• Regression
• Edge Caseهای فراموش‌شده
• Security Issue
• عدم تطابق با Plan
• Missing Test
• Error Handling
• API Compatibility

را بررسی کند.

اگر Inspector مشکل پیدا کند چه می‌شود؟

Workflow می‌تواند وارد Fix Round شود.

نسخه فعلی Claudex Loop به‌صورت پیش‌فرض:

MAX_FIX_ROUNDS = 2

و:

MAX_INSPECTION_ROUNDS = 2

دارد.

یعنی فرآیند اصلاح و Reinspection هم Bounded است تا Loop بی‌نهایت ایجاد نشود.

مثال واقعی Workflow

فرض کنید می‌خواهید قابلیت Upload تصویر به پروژه اضافه کنید.

Workflow می‌تواند چنین باشد:

User:
Add image uploads with validation and S3 storage.

        ↓

Claude:
Inspect repository
Understand existing storage architecture
Create implementation plan

        ↓

Codex:
Review plan
Find missing validation
Find security risks
Check failure cases

        ↓

Claude:
Revise plan

        ↓

Codex:
Approve plan

        ↓

Claude:
Implement feature

        ↓

Fresh Codex:
Inspect actual code

        ↓

Claude:
Fix findings

        ↓

Codex:
Final inspection

آیا لازم است همیشه Claude Builder باشد؟

خیر.

مثلاً می‌توانید بگویید:

claudex this feature, builder=codex

در این حالت Codex Implementation را انجام می‌دهد و Claude Inspector خواهد بود.

یا:

claudex this feature, builder=claude

تا Claude Implementation را انجام دهد و Codex Review نهایی را برعهده بگیرد.

Claudex Route چیست؟

Repository فقط Claudex Loop ندارد.

یک Skill سبک‌تر با نام:

Claudex Route

هم ارائه شده است.

اگر نمی‌خواهید Workflow کامل اجرا شود، Claudex Route می‌تواند پیشنهاد دهد کدام مدل برای Task مناسب‌تر است.

برای مثال:

claudex-route:
Who should handle this migration?
Prioritize correctness.

یا:

claudex-route:
Get a second opinion on this plan.

پیش‌نیازهای نصب

برای Workflow کامل باید هر دو CLI روی سیستم نصب و Authenticate شده باشند:

• Claude Code
• Codex CLI
• Python 3.10 یا جدیدتر

پروژه خودش مستقیماً Hosted Model API را Call نمی‌کند.

در نتیجه برای Claudex Loop نیاز به API Key جدید جداگانه ندارید؛ هر CLI از Authentication خودش استفاده می‌کند.

قبل از نصب وضعیت CLIها را بررسی کنید

claude --version
claude auth status

codex --version
codex login status

python --version

اگر هر دو CLI آماده باشند، می‌توانید Plugin را نصب کنید.

نصب Claudex Loop در Claude Code

داخل Claude Code ابتدا Marketplace پروژه را اضافه کنید:

/plugin marketplace add chaseai-yt/claudex-loop

بعد Plugin را نصب کنید:

/plugin install claudex-loop@claudex-loop

حالا Workflowهای Claudex Loop در Claude Code قابل استفاده هستند.

اجرای Claudex Loop

برای اجرای Workflow کامل می‌توانید از:

/claudex-loop:claudex-loop

استفاده کنید.

یا برای Routing سریع:

/claudex-loop:claudex-route

Codex Review جداگانه

اگر فقط می‌خواهید Plan موجودتان توسط Codex بررسی شود:

/claudex-loop:codex-review

قابل استفاده است.

Codex Build جداگانه

اگر می‌خواهید Implementation مشخصاً توسط Codex انجام شود:

/claudex-loop:codex-build

وجود دارد.

نصب دستی برای Codex

اگر Claudex Loop را داخل Codex یا هر دو Host می‌خواهید، Repository را Clone کنید:

git clone https://github.com/chaseai-yt/claudex-loop.git

cd claudex-loop

در macOS و Linux:

mkdir -p ~/.agents/skills ~/.claude/skills

cp -R skills/. ~/.agents/skills/
cp -R skills/. ~/.claude/skills/

سپس Session جدیدی باز کنید.

داخل Codex:

$claudex-loop

و داخل Claude Code پس از نصب دستی:

/claudex-loop

قابل استفاده است.

ویندوز چطور؟

برای PowerShell:

New-Item -ItemType Directory -Force "$env:USERPROFILE\.agents\skills", "$env:USERPROFILE\.claude\skills" | Out-Null

Copy-Item -Recurse -Force skills\* "$env:USERPROFILE\.agents\skills\"

Copy-Item -Recurse -Force skills\* "$env:USERPROFILE\.claude\skills\"

نمونه دستورهای Claudex Loop

مثلاً:

claudex this feature — plan and implement it

اگر فقط Plan موجود را Review می‌کنید:

claudex this plan,
mode=review,
plan=docs/migration.md,
rounds=3

اگر می‌خواهید Codex Builder باشد:

claudex this feature,
builder=codex

یا Claude:

claudex this feature,
builder=claude

حتی مدل هر Role قابل انتخاب است

Claudex Loop اجازه می‌دهد Model مورد استفاده برای Roleهای مختلف را جداگانه تنظیم کنید.

پارامترهایی مثل:

reviewer_model
builder_model
inspector_model

وجود دارند.

همچنین Effort هر Role نیز قابل تنظیم است:

reviewer_effort
builder_effort
inspector_effort

بنابراین می‌توانید مثلاً یک Model قوی‌تر را فقط برای Final Inspection استفاده کنید.

آیا انتخاب Model داخل Claude Code روی Codex هم اعمال می‌شود؟

خیر.

هر CLI تنظیمات Model خودش را دارد.

انتخاب Model در UI یا Session Claude به‌صورت خودکار Model مورد استفاده Codex را تغییر نمی‌دهد.

اگر Model مشخصی می‌خواهید بهتر است آن را برای Role مربوطه صریحاً تعیین کنید.

آیا Claudex Loop واقعاً Bugs را حذف می‌کند؟

خیر.

Independent Review می‌تواند احتمال شناسایی بعضی مشکلات را بیشتر کند، اما هیچ تضمینی وجود ندارد که:

• تمام Bugها پیدا شوند
• Security Issue باقی نماند
• Plan کاملاً درست باشد
• Test Coverage کافی باشد

حتی دو مدل مختلف ممکن است یک فرض اشتباه مشترک داشته باشند.

بنابراین Claudex Loop جای:

• Automated Tests
• Integration Tests
• Static Analysis
• Security Testing
• Human Code Review

را نمی‌گیرد.

پس مزیت واقعی آن چیست؟

مزیت اصلی Separation of Responsibilities است.

به‌جای Workflow زیر:

AI:
Plan
↓
Code
↓
Review its own code
↓
Looks good!

یک Workflow شبیه این داریم:

Model A
Plan
      ↓
Model B
Challenge Plan
      ↓
Model A or B
Build
      ↓
Other Model
Independent Inspection

این ساختار می‌تواند Bias و Blind Spot ناشی از Self-review را کاهش دهد.

Adversarial Review یعنی چه؟

Reviewer صرفاً قرار نیست مؤدبانه Plan را تأیید کند.

هدف این است که فعالانه دنبال:

• فرضیات ضعیف
• Failure Mode
• Security Risk
• Missing Requirement
• Edge Case
• Compatibility Problem

بگردد.

این همان چیزی است که پروژه آن را:

Adversarial Review

می‌نامد.

آیا Claudex Loop سرعت را ۱۰ برابر می‌کند؟

در بعضی معرفی‌های شبکه‌های اجتماعی درباره افزایش سرعت بسیار زیاد یا حتی ۱۰ برابر صحبت شده است.

اما در README فعلی پروژه Benchmark معتبری که افزایش سرعت 10x را به‌صورت عمومی اثبات کند وجود ندارد.

بنابراین بهتر است چنین عددی را یک ادعای تجربی یا تبلیغاتی بدانیم، نه نتیجه تضمین‌شده.

حتی در بعضی پروژه‌ها Workflow دو مدلی می‌تواند زمان بیشتری هم بگیرد، چون:

• Plan باید Review شود
• Findings باید بررسی شوند
• Code باید Inspection شود
• ممکن است Fix Round لازم باشد

پس چرا ممکن است در مجموع سریع‌تر شود؟

صرفه‌جویی بالقوه بیشتر از کاهش Rework می‌آید.

مثلاً:

بدون Review مستقل:

3 ساعت Coding
+
4 ساعت Debugging
+
2 ساعت Refactor
=
9 ساعت

در حالی که یک Workflow فرضی دیگر ممکن است:

1 ساعت Planning + Review
+
3 ساعت Coding
+
1 ساعت Fix
=
5 ساعت

طول بکشد.

این اعداد فقط مثال هستند؛ نتیجه واقعی به پروژه بستگی دارد.

هزینه هم بیشتر می‌شود

استفاده از دو مدل به معنی اجرای Inference بیشتر است.

بنابراین Claudex Loop ممکن است:

• Token بیشتری مصرف کند
• Usage هر دو سرویس را درگیر کند
• زمان Review اضافه ایجاد کند

به همین دلیل برای تغییر بسیار ساده مثل:

Rename this button.

استفاده از Full Loop احتمالاً منطقی نیست.

Claudex Loop برای چه Taskهایی مناسب‌تر است؟

مثلاً:

• Featureهای چندفایلی
• Database Migration
• Authentication
• Payment System
• Architecture Change
• Large Refactor
• Security-sensitive Changes
• API Migration

می‌توانند از Independent Review بیشتری سود ببرند.

برای چه کارهایی احتمالاً اضافه است؟

برای Taskهایی مثل:

• تغییر یک Text
• اصلاح CSS ساده
• Rename یک Variable
• Fix یک Typo

استفاده از Workflow کامل احتمالاً Overkill است.

Permissionها همچنان مهم هستند

Claudex Loop به‌خودی‌خود Permissionهای Claude Code یا Codex را حذف نمی‌کند.

هر CLI همچنان Sandbox و Permission Model خودش را دارد.

برای مثال Plan Reviewهای Codex در حالت Read-only اجرا می‌شوند تا Reviewer نتواند هنگام بررسی Plan کد پروژه را تغییر دهد.

API Key جدید لازم نیست

Runner پروژه مستقیماً به Hosted API مدل‌ها متصل نمی‌شود.

در عوض Claude CLI و Codex CLI موجود روی سیستم را اجرا می‌کند.

بنابراین Authentication همان چیزی است که قبلاً برای هر CLI تنظیم کرده‌اید.

Python برای چه استفاده می‌شود؟

Claudex Loop یک Runner مشترک دارد که با Python اجرا می‌شود.

نسخه فعلی نیازمند:

Python 3.10+

است.

Runtime اصلی Dependency خارجی pip لازم ندارد.

آیا پروژه متن‌باز است؟

بله.

Claudex Loop در GitHub منتشر شده و از مجوز:

MIT License

استفاده می‌کند.

لینک پروژه در GitHub

برای مشاهده Source Code، Documentation و روش نصب:

مشاهده Claudex Loop در GitHub →

Workflow پیشنهادی برای استفاده واقعی

برای یک Feature مهم می‌توانید این ترتیب را امتحان کنید:

Requirement
      ↓
Claude Code
Recon + Plan
      ↓
Codex
Independent Plan Review
      ↓
Claude
Revise Plan
      ↓
Codex
Approve
      ↓
Codex
Build
      ↓
Claude
Independent Inspection
      ↓
Automated Tests
      ↓
Human Review
      ↓
Merge

یا Builder را برعکس کنید.

یک نکته مهم؛ AI Review جای Test را نمی‌گیرد

حتی اگر Claude و Codex هر دو بگویند:

APPROVED

باز هم باید تست‌های واقعی اجرا شوند.

مثلاً:

npm test
npm run lint
npm run build

یا در پروژه Laravel:

php artisan test

و در Python:

pytest

Review زبانی نمی‌تواند Execution واقعی نرم‌افزار را جایگزین کند.

Claudex Loop چه مشکلی را واقعاً حل می‌کند؟

هدف پروژه حل این مسئله است:

مدل نباید تنها منبع طراحی، اجرا و تأیید صحت کار خودش باشد.

با جدا کردن Roleها بین دو Provider، احتمال اینکه یک مدل اشتباه خودش را بدون Challenge تأیید کند کمتر می‌شود.

این ایده شباهت زیادی به Development Team انسانی دارد:

Developer
   ↓
Pull Request
   ↓
Different Reviewer
   ↓
Requested Changes
   ↓
Tests
   ↓
Merge

جمع‌بندی

Claudex Loop یک پروژه متن‌باز است که Claude Code و Codex را داخل یک Workflow مشترک قرار می‌دهد تا Plan و Implementation توسط بیش از یک مدل بررسی شوند.

مدل Host Requirementها و Plan را مدیریت می‌کند، Provider دیگر Plan را به‌صورت Adversarial بررسی می‌کند و سپس Claude یا Codex می‌تواند Builder باشد.

قانون اصلی این است که مدلی که کد را نوشته، Final Inspector نباشد.

این ساختار می‌تواند بعضی Blind Spotهای Self-review را کمتر کند، اما به معنی حذف کامل Bugها نیست و همچنان Tests، Security Checks و Human Review اهمیت دارند.

همچنین ادعاهایی مثل افزایش ۱۰ برابری سرعت را نباید نتیجه تضمین‌شده دانست؛ مزیت اصلی پروژه بیشتر در کاهش اشتباهات طراحی، Review مستقل و کاهش Rework است.

ایده جذاب Claudex Loop این نیست که دو AI با هم کد بزنند؛ بلکه این است که هیچ مدل هوش مصنوعی اجازه نداشته باشد بدون یک نگاه مستقل، کار خودش را تأیید کند.

آموزش AI Coding در معین گیفت

در معین گیفت جدیدترین Workflowهای Claude Code، Codex، Cursor و Coding Agentهای هوش مصنوعی را بررسی می‌کنیم تا بتوانید از AI برای توسعه نرم‌افزار با ساختار دقیق‌تر و خطای کمتر استفاده کنید.