چطور با Codex هم‌زمان ۱۵ پروژه را بازبینی می‌کنم و کنترل نهایی را از دست نمی‌دهم

چند سال پیش اگر می‌گفتم ۱۵ پروژه نرم‌افزاری را در یک زمان به‌صورت جدی بازبینی می‌کنم، برای خودم هم غیرواقعی به نظر می‌رسید. منظورم باز کردن ۱۵ repository و نگاه سطحی نیست. منظورم بررسی مداوم پروژه‌های واقعی برای باگ، فرض اشتباه، مشکل SEO، خطای ترجمه، ناسازگاری localization، تست‌های گمشده، regression و کد قدیمی‌ای است که دیگر با بخش‌های دیگر سیستم هماهنگ نیست.

محدودیت هیچ‌وقت سرعت تایپ نبود. محدودیت توجه بود. هر پروژه تاریخچه، convention، edge case و کدی دارد که ممکن است اشتباه به نظر برسد اما عمداً همان‌طور نوشته شده باشد. Review دقیق یعنی خواندن، جست‌وجو، مقایسه، اجرای check و فقط بعد از آن تصمیم‌گیری درباره چیزی که واقعاً باید تغییر کند.

Codex هزینه این کار تکراری را برای من تغییر داد. می‌تواند first pass روی repository انجام دهد، referenceها را دنبال کند، فایل‌های مرتبط را ببیند، patternهای مشکوک را نشان دهد، برای تست ایده بدهد و در بررسی بخش‌هایی کمک کند که قبلاً مجبور بودم یکی‌یکی باز کنم. این تصمیم نهایی را خودکار نمی‌کند. بخش پرهزینه قبل از تصمیم را خیلی سریع‌تر می‌کند.

مهم‌ترین قانونی که برای خودم دارم ساده است: از Codex استفاده نمی‌کنم تا خودم را از review loop حذف کنم؛ از آن استفاده می‌کنم تا دامنه review خودم را بزرگ‌تر کنم.

گلوگاه واقعی تکرار است، نه نوشتن کد

وقتی فقط یک پروژه دارید، می‌توانید حجم زیادی از context را در ذهن نگه دارید. با پروژه‌های متعدد این روش دیگر scale نمی‌شود. همان نوع کارها بارها تکرار می‌شوند:

• پیدا کردن bugهای مشابه در componentهای مختلف؛
• بررسی اینکه refactor یک call site قدیمی جا نگذاشته باشد؛
• Review تست‌ها بعد از تغییر رفتار؛
• پیدا کردن ناسازگاری در metadata، منطق زبان، heading یا internal link؛
• مقایسه localization key و محتوای ترجمه‌شده؛
• جست‌وجوی error handling ناقص و edge case؛
• بررسی اینکه یک تغییر «کوچک» بیشتر از حد انتظار فایل‌ها را لمس نکرده باشد؛
• خواندن diffهایی که جداگانه ساده‌اند ولی مجموعاً زمان زیادی می‌گیرند.

هیچ‌کدام جذاب نیستند، اما همه مهم‌اند. وقتی همان review در چند codebase تکرار شود، هزینه خیلی بزرگ می‌شود.

اینجاست که AI coding agent برای من بیشترین ارزش را دارد. بخش تکراری فضای جست‌وجو را می‌گیرد تا توجه من برای judgment باقی بماند.

از inspection شروع می‌کنم، نه اجازه بازنویسی همه‌چیز

یکی از ساده‌ترین راه‌ها برای نتیجه بد این است که بگوییم «کل پروژه را review کن و همه چیز را درست کن». این درخواست ظاهراً کارآمد است، اما discovery، اولویت‌بندی، architecture، implementation و validation را در یک task کنترل‌نشده مخلوط می‌کند.

وقتی مراحل را جدا می‌کنم نتیجه خیلی بهتر است.

inspect → explain findings → prioritize → change → validate → review diff

اول می‌خواهم agent بخش مرتبط را بفهمد و توضیح دهد چه چیزی پیدا کرده. مسیر دقیق فایل، کد درگیر، دلیل مشکوک بودن و impact احتمالی لازم است. تغییر بعد از آن می‌آید.

این مهم است چون AI می‌تواند با اعتمادبه‌نفس زیاد اشتباه کند. کدی که redundant به نظر می‌رسد ممکن است برای مرورگر قدیمی، payment edge case، مسیر migration یا business ruleای باشد که از یک فایل قابل فهم نیست. Inspection به من فرصت می‌دهد فرض اشتباه را قبل از تبدیل شدن به diff بزرگ متوقف کنم.

Finding را سرنخ می‌دانم، نه حکم

Review خوب Codex با «۱۷ مشکل پیدا کردم» تمام نمی‌شود. عدد به‌تنهایی تقریباً بی‌معنی است. من evidence می‌خواهم.

برای finding قابل اقدام می‌خواهم بدانم:

• مشکل کجاست؛
• چرا مشکل است؛
• چه رفتاری ممکن است خراب شود؛
• چقدر می‌توان به نتیجه اعتماد کرد؛
• چه checkی می‌تواند آن را تأیید یا رد کند؛
• کوچک‌ترین fix امن چیست.

این برای security، SEO و business logic خیلی مهم است. Agent می‌تواند نقطه‌ای برای تحقیق نشان دهد، اما توضیحی که شبیه گزارش امنیتی است هنوز vulnerability تأییدشده نیست. هشدار SEO لزوماً مشکل ranking نیست. شرط عجیب هم خودکار dead code نیست.

AI هزینه یافتن candidate را کم می‌کند. Verification هنوز تعیین می‌کند چه چیزی واقعی است.

Validation loop است که workflow را قابل اعتماد می‌کند

Code generation بخش دیده‌شده AI-assisted development است، اما validation چیزی است که آن را برای production مفید می‌کند.

بعد از تغییر می‌خواهم codebase پاسخ بدهد. بسته به پروژه می‌تواند شامل این موارد باشد:

• TypeScript یا compiler/type checker دیگر؛
• lint؛
• unit وintegration test؛
• build check؛
• search هدفمند برای اسم یا call site قدیمی؛
• review دستی diff نهایی؛
• تأیید دستی رفتار قابل مشاهده برای کاربر.

Command دقیق کمتر از loop مهم است. Agent فرضی می‌سازد، repository evidence می‌دهد و تصمیم بعدی از همان evidence استفاده می‌کند.

برای همین پروژه‌های strongly typed را برای AI-assisted work دوست دارم. جداگانه درباره اینکه چرا TypeScript با Codex در نرم‌افزار واقعی خوب کار می‌کند نوشته‌ام: typeها بسیاری از فرض‌های اشتباه را فوراً به feedback ماشین‌خوان تبدیل می‌کنند.

بعضی reviewها مخصوصاً برای AI مناسب‌اند

Bug و regression

Agent می‌تواند value را میان فایل‌ها دنبال کند، callerها را ببیند، implementationهای مشابه را مقایسه کند و branchهای ناسازگار را پیدا کند. برای محدود کردن منبع symptom مفید است. قبل از قبول نتیجه، رفتار را بازتولید یا به شکل دیگری verify می‌کنم.

Test

AI برای پیدا کردن رفتاری که تغییر کرده اما test coverage مناسب ندارد، پیشنهاد edge case و توضیح اینکه test موجود واقعاً چه چیزی را محافظت می‌کند مفید است. همچنین می‌تواند testهایی را نشان دهد که فقط implementation detail را چک می‌کنند.

SEO

Technical SEO پر از consistency work است: metadata، language alternate، indexability، internal link، template، sitemap generation، redirect و ruleهای page-level. Agent می‌تواند این قوانین را در codebase بزرگ سریع‌تر از باز کردن دستی هر route مقایسه کند. اما correctness فنی را از سؤال سخت‌ترِ «آیا خود محتوا ارزش ranking دارد؟» جدا می‌کنم.

Localization و ترجمه

در محصول چندزبانه یکی از تکراری‌ترین بخش‌هاست. AI می‌تواند keyها را مقایسه کند، value گمشده پیدا کند، زبان اشتباه را تشخیص دهد، placeholder را بررسی کند و localeهایی را که از نظر ساختار منحرف شده‌اند نشان دهد. خیلی سریع‌تر از خواندن translation object بزرگ به‌صورت دستی است، هرچند copy مهم هنوز judgment انسانی می‌خواهد.

Consistency بعد از refactoring

Refactor بزرگ اغلب به دلیل‌های خسته‌کننده خراب می‌شود: یک import قدیمی باقی می‌ماند، یک route هنوز field name قبلی را استفاده می‌کند، یک test fixture shape قدیمی دارد. Repository-wide search همراه agentی که هدف تغییر را می‌فهمد اینجا خیلی مفید است.

Parallel work فقط وقتی کمک می‌کند که taskها مستقل باشند

وسوسه‌انگیز است چند agent را روشن کنیم و همه هم‌زمان همه‌چیز را تغییر دهند. Throughput بالا می‌رود، اما conflict و فرض‌های ناسازگار هم می‌توانند چند برابر شوند.

Parallelism را مسئله coordination می‌بینم. Auditهای مستقل گزینه خوبی هستند: یک پروژه localization را بررسی کند، پروژه دیگر test review شود، یا repositoryهای جدا هم‌زمان inspect شوند. دو agent که بدون plan مشترک یک architecture را بازنویسی کنند داستان دیگری است.

هرچه کار parallelتر باشد، boundary مهم‌تر می‌شود: project روشن، task روشن، definition of done روشن و resultی که جداگانه review شود.

هدف زیاد کردن تعداد agentهای در حال اجرا نیست. هدف افزایش progress مفید و قابل verify است.

چیزهایی که کورکورانه واگذار نمی‌کنم

• Architecture decision: مدل می‌تواند option بدهد، اما trade-off بلندمدت ممکن است به context بیرون repository وابسته باشد.
• Security conclusion: finding به verification، threat context و اغلب ابزار تخصصی نیاز دارد.
• Business rule: کد می‌تواند درون خودش consistent باشد اما رفتار محصول اشتباه را پیاده کند.
• Refactor بزرگ و مخرب: diff عظیم سخت‌تر فهمیده می‌شود و راحت‌تر بی‌دقت approve می‌شود.
• Production deployment: pass شدن test operational risk را حذف نمی‌کند.
• Final review: قبل از اینکه اسمم را روی تغییر بگذارم می‌خواهم بدانم چه شده.

نه چون AI در این حوزه‌ها بی‌فایده است، بلکه چون جواب غلطِ قانع‌کننده می‌تواند خیلی گران تمام شود.

AI review جای static analysis را نمی‌گیرد

Codex را جای compiler، linter، test، scanner یا monitoring نمی‌بینم. این ابزارها مزیتی دارند که AI ندارد: محدود، deterministic و repeatable هستند.

قوی‌ترین workflow همه را ترکیب می‌کند. Codex روی context reasoning می‌کند و می‌گوید کجا را ببینیم. Static tool rule دقیق را enforce می‌کند. Test behavior را verify می‌کند. Log و monitoring واقعیت را نشان می‌دهند. Human review این signalها را به product intent وصل می‌کند.

بدون این feedback systemها به AI کمتر اعتماد می‌کنم، نه بیشتر.

بزرگ‌ترین افزایش بهره‌وری، توزیع بهتر توجه است

گفتن «Codex زمان ذخیره می‌کند» ساده است، اما برای من اصل تغییر بزرگ‌تر است.

Resource کمیاب در software development keystroke نیست؛ high-quality attention است. قبل از AI coding agent مقدار زیادی از آن صرف discovery تکراری می‌شد: پیدا کردن patternهای یکسان، خواندن فایل‌های شبیه، دنبال کردن reference، بررسی انتشار تغییر و تکرار همان audit در repository بعدی.

حالا first-pass work بیشتری را واگذار می‌کنم و attention خودم را برای تصمیم‌هایی نگه می‌دارم که سخت‌تر automate می‌شوند: آیا finding مهم است؟ fix با architecture سازگار است؟ UX بهتر می‌شود؟ risk قابل قبول است؟ واقعاً می‌خواهم این تغییر ship شود؟

برای همین نگهداری و review چند پروژه امروز حس دیگری دارد. کمتر review نمی‌کنم. در بسیاری از موارد بیشتر review می‌کنم، چون بخش مکانیکی همه budget را مصرف نمی‌کند.

Workflow مورد اعتماد من

1. هدف review محدود تعریف کن. Bug، test، SEO، localization، refactor یا concern مشخص.
2. Agent قبل از edit inspect کند. اول evidence و محل‌های درگیر را می‌خواهم.
3. Findingها را اولویت‌بندی کن. هر مسئله نظری نیاز به تغییر کد ندارد.
4. تغییر را bounded نگه دار. diff کوچک و coherent ساده‌تر validate می‌شود.
5. Machine check اجرا کن. Typecheck، lint، test، build، search یا validation اختصاصی پروژه.
6. Diff را دستی بخوان. Rewrite اضافه، فرض غلط، edge case گمشده و تغییر خارج scope را پیدا کن.
7. Behavior مهم را verify کن. مخصوصاً users، money، security، SEO و production infrastructure.
8. بعد به پروژه بعدی برو. Parallelism مفید است، اما uncertainty حل‌نشده نباید پخش شود.

۱۵ پروژه دیگر مثل ۱۵ برابر کار review احساس نمی‌شود

Codex ۱۵ پروژه را ساده نکرد و مسئولیت را از من نگرفت. رابطه بین scale و repetitive effort را تغییر داد.

می‌توانم first pass عمیق‌تر، consistency check گسترده‌تر، test idea بیشتر و audit سیستماتیک‌تر بخواهم بدون اینکه خودم هر دقیقه در هر فایل جست‌وجو کنم. بعد attention ذخیره‌شده را برای تصمیم‌هایی استفاده می‌کنم که هنوز developer می‌خواهند.

AI-assisted development ارزشمند برای من این است: نه autopilot، نه blind trust و نه «کد تولید کن تا چیزی pass شود». Loop فشرده‌تر بین inspection در مقیاس ماشین و judgment در مقیاس انسان.

این برای من leverage واقعی Codex است. Review را حذف نمی‌کند؛ serious review را در scaleای ممکن می‌کند که قبلاً نگه داشتنش خیلی سخت‌تر بود.