اگر امروز برای مدیریت پروژههای کدنویسی خود تنها از یک دستیار هوش مصنوعی استفاده میکنید، احتمالاً تصور میکنید افزودن سه دستیار دیگر، سرعت شما را چهار برابر میکند. اما واقعیت این است که در دنیای واقعی، سرعت شما نه توسط قدرت پردازش مدل، بلکه توسط توانایی شما در بررسی تغییرات محدود میشود.
به گزارش وبسایت dev.to، یک توسعهدهنده در آزمونی یکهفتهای دریافت که اجرای موازی چهار عامل (Agent) — شبیه به داشتن چهار کارآموز سریع که هر کدام در اتاقی جداگانه کار میکنند — توان عملیاتی را افزایش میدهد، اما نه به اندازه تعداد عاملها. در این آزمایش مشخص شد که در حالی که حجم وظایف انجام شده افزایش یافته است، گلوگاه صرفاً از سرعت کدنویسی هوش مصنوعی به توانایی انسان در بررسی تفاوتهای کد (Diffs) منتقل شده است.
این یافته در حالی منتشر میشود که برنامهنویسان تلاش میکنند جریانهای کاری عاملمحور (Agentic) را از دستیارهای تکوظیفهای به اعضای مستقل تیم تبدیل کنند. همانطور که در تحلیل قبلی ما دربارهی استفادهی APT29 از مدلهای Claude برای بازنویسی بدافزارها اشاره کردیم، قدرت این ابزارها در استقلال آنهاست، اما همین استقلال وقتی چندین عامل بدون هماهنگی روی یک کدبیس کار کنند، به هرجومرج منجر میشود.
تصور کنید چهار برنامهنویس تازهکار دارید که با سرعت برق کد میزنند اما نمیتوانند با هم حرف بزنند. آنها بر سر منطق برنامه نمیجنگند، بلکه بر سر ابزارها، پورتها و پایگاهداده درگیر میشوند و اغلب بدون اینکه بفهمند، کار یکدیگر را پاک میکنند.
زیرساخت و چیدمان آزمایش
این آزمایش روی یک پروژه SaaS کوچک با معماری monorepo انجام شد. پشتهی فنی شامل فرانتاند Next.js، بکاند FastAPI، پایگاهداده Postgres با مهاجرتهای Alembic و Redis برای کشینگ بود.
توسعهدهنده برای جداسازی فایلها، چهار نشست مستقل Claude Code را با استفاده از git worktrees ایجاد کرد. این ساختار اجازه میداد هر عامل در محیطی ایزوله کار کند. استفاده از این قابلیت در Claude Code به طور موثری مانع از تخریب فایلها در جلسات موازی شد و محیط توسعه را پایدارتر کرد. برای این کار، دستوراتی مانند git worktree add ../app-wt1 -b feat/billing-export اجرا شد. به همین ترتیب، محیطهایی برای ویژگیهای feat/team-invites (دعوت تیم)، fix/search-pagination (اصلاح صفحهبندی جستجو) و feat/audit-log (گزارش بازرسی) ایجاد گردید.
اگرچه این worktreeها برای جلوگیری از کلون کردن مجدد پروژه، از یک ذخیرهساز اشیاء .git مشترک استفاده میکردند، اما هر کدام به فایلهای استخراجشده (checked-out)، شاخه (branch) و پوشه node_modules مخصوص به خود نیاز داشتند. قانون عملیاتی سختگیرانه بود: هر وظیفه باید در یک شاخه باشد، هر شاخه باید از تستهای CI عبور کند و تنها توسعهدهنده انسانی اجازه ادغام (Merge) در شاخه اصلی را داشت. این رویکرد در واقع مدیریتی بدون تداخل در کدنویسی AI است که در مقایسه با روشهای سنتی گیت برتری چشمگیری دارد.
شکاف توان عملیاتی
بر اساس مستندات این گزارش، در طول پنج روز کاری ۲۳ وظیفه در صف قرار گرفت. نتایج نشاندهنده بازده نزولی در موازیسازی بود:
- ۱۲ وظیفه: بدون مشکل ادغام و منتشر شدند.
- ۵ وظیفه: تداخل داشتند اما سریعاً حل و منتشر شدند.
- ۴ وظیفه: نیاز به بازنویسی گسترده (بیش از ۳۰٪ کد) داشتند.
- ۲ وظیفه: بهطور کامل دور ریخته شدند.
برای مقایسه، در هفتهی قبل با استفاده از یک عامل بهصورت متوالی، ۱۱ وظیفه منتشر شده بود. جهش به ۱۷ وظیفه، افزایشی ۱.۵ برابری در بهرهوری است که با رشد تئوریک ۴ برابری فاصله زیادی دارد.
دو وظیفه دور ریخته شده به این دلیل بود که عاملها مشکلاتی را به گونهای حل کردند که کار عاملهای دیگر را بیمعنی کرد. برای مثال، عامل ۳ در حالی که مشغول کار بود، یک «سازنده کوئری جستجو» (search query builder) را بازنویسی کرد. این اقدام باعث شد رویکردی که عامل ۱ برای فیلترهای خروجی صورتحساب به کار میبرد، کاملاً بیفایده شود. هیچیک از این دو عامل از وجود دیگری خبر نداشتند.
ماتریس تداخلات
عاملهای موازی به این دلیل برخورد میکنند که git worktrees فایلها را جدا میکند، اما منابع مشترک یا «قصد» (Intent) را جدا نمیکند. در این آزمایش ۹ تداخل اصلی ثبت شد:
- تداخل فایلهای Lock (۴ مورد): سه عامل وابستگیهای npm را اضافه کردند و یکی از بستههای پایتون را بهروزرسانی کرد. تداخلات در
package-lock.jsonاز نظر متنی بسیار حجیم اما از نظر معنایی خستهکننده بودند و هر بار حدود ۱۰ دقیقه زمان میگرفت تا با اجرای مجددnpm installدر آن شاخه حل شوند. - مهاجرتهای پایگاهداده (۲ مورد): عامل ۲ (دعوت تیم) و عامل ۴ (گزارش بازرسی) هر دو دستور
alembric revision --autogenerateرا از یک والد مشترک اجرا کردند. چون شناسههای بازبینی (revision IDs) تصادفی و متفاوتی داشتند، گیت تداخلی تشخیص نداد، اما CI در شاخه اصلی با خطای «وجود چندین نسخه head» متوقف شد. این مشکل استقرار را تا زمان اجرایalembic merge headsمسدود کرد. - اندیسگذاری مسیرها (۱ مورد): تداخل کلاسیک در خطوط مجاور هنگام افزودن روترهای API جدید به فایل
routers/__init__.pyتوسط دو عامل رخ داد. - شکستهای منطقی نامرئی (۲ مورد): خطرناکترین تداخلات که از CI عبور کردند:
- تغییر نام: عامل ۱ نام تابع
formatPrice()را بهformatCurrency()تغییر داد و ۱۴ جای فراخوانی را بهروز کرد. همزمان، عامل ۴ سه فراخوانی جدید به نام قدیمیformatPrice()اضافه کرد. گیت این را بهسادگی ادغام کرد اما برنامه برای ۲۵ دقیقه در حالت خطا باقی ماند تا TypeScript متوجه شد. - کلید کش: عامل ۲ عضویت تیم را تحت کلید
user:{id}کش کرد، در حالی که عامل ۴ خلاصههای گزارش بازرسی را تحت همان کلیدuser:{id}ذخیره کرد. این خطا به محیط Staging رسید و باعث شد صفحه دعوت، یک خلاصه گزارش را به جای لیست عضویت تحلیل کند و خطای ۵۰۰ بدهد.
- تغییر نام: عامل ۱ نام تابع
مالیات محیطی
عاملها حتی بر سر محیط محلی نیز جنگیدند. در یک روز چهارشنبه ساعت ۱۱:۴۰ صبح، چهار نشست در چهار تب ترمینال برای ۲۰ دقیقه بر سر پورت ۳۰۰۰ درگیر شدند. عامل ۲ سرور Next.js را اجرا میکرد و عامل ۴ با تصور اینکه پروسه قدیمی است، آن را میکشت. سپس عامل ۲ خطای «connection refused» گزارش میکرد و محیط را «ناپایدار» مینامید.
برای حل این مشکل، توسعهدهنده اسکریپت wt-init.sh را نوشت تا پورتها و پایگاهدادههای منحصربهفردی به هر worktree اختصاص دهد:
- پورتها: متغیرهای
PORT=$((3000 + n))وAPI_PORT=$((8000 + n))به فایل.env.localاختصاص یافتند. - پایگاهدادهها: دیتابیسهای منحصربهفردی (مانند
app_wt1) ایجاد شدند تا مثلاً عامل ۳ در حالی که عامل ۲ در حال تست دعوتهاست، جدول کاربران را خالی نکند.
فضای دیسک نیز به یک عامل تبدیل شد. هر worktree حدود ۱.۱ گیگابایت فضای دیسک برای node_modules اشغال کرد که در مجموع با کشهای بیلد، به ۶ گیگابایت رسید.
گلوگاه انسانی
بحرانیترین محدودیت، توجه انسان و سقف API بود. چهار نشست همزمان در روز سوم ساعت ۲:۴۰ بعدازظهر باعث رسیدن به سقف مصرف شد و کل بعدازظهر توسعهدهنده را از بین برد. کاهش تعداد به سه عامل در روزهای چهارم و پنجم مانع از تکرار این اتفاق شد.
توسعهدهنده ۶.۵ ساعت زمان صرف بررسی تغییرات (Diffs) برای ۲۳ وظیفه موازی کرد (میانگین اندازه هر Diff حدود ۲۱۴ خط بود). در هفتهی متوالی، بررسی ۱۱ وظیفه تنها ۳ ساعت زمان برد.
وقتی چهار شاخه در یک ساعت ادغام میشوند، بار شناختی برای جابجایی بین چهار ویژگی نامرتبط افزایش مییابد. این فشار ذهنی منجر به اشتباهاتی شد، از جمله باگ کلید کش که از بررسی انسانی گریخت و به محیط Staging رسید.
چارچوب بهینهشده
برای رفع این مشکلات در هفته دوم، توسعهدهنده یک سیستم «لاین» (Lane) سختگیرانه را اجرا کرد:
- سقف ۳ عامل: برای ماندن در محدوده سقف مصرف API و ظرفیت بررسی انسانی.
- لاین تکمهاجرتی: تنها یک worktree اجازه ایجاد نسخه Alembic دارد. سایر دستورات اکنون شامل این جمله هستند: «مهاجرت ایجاد نکن. اگر به تغییر طرح نیاز داری، متوقف شو و به من خبر بده.»
- مالکیت فایل: در دستورات (Prompts) صراحتاً دایرکتوریهای مجاز لیست شدهاند (مثلاً: «تو فقط مجاز به تغییر
app/billing/وweb/app/billing/هستی. برای هر چیز دیگر، ابتدا بپرس.»). - ممنوعیت بازنویسیهای فرصتطلبانه: قانونی در فایل
CLAUDE.mdتعریف شد که تغییر نام ابزارهای مشترک را مگر در درخواست صریح، ممنوع میکند. - ریبیس (Rebase) توسط عامل: عاملها باید قبل از ارسال کد، دستور
git fetch && git rebase origin/mainرا اجرا کرده و تستها را مجدداً اجرا کنند. این کار باعث میشود عاملی که با متن کد آشناست تداخل را حل کند، نه انسان. - فایل کنوانسیونها: یک سند مشترک برای نامگذاری فضای نام کلیدهای کش (مثلاً
teams:user:{id})، ثبت مسیرها و نامگذاری متغیرهای محیطی ایجاد شد.
این رویکرد ساختاریافته تداخلات را در سه روز به تنها یک مورد (تداخل lockfile) کاهش داد و هیچ بیلد قرمز رنگی در شاخه اصلی ثبت نشد.
این تغییر نشان میدهد که آینده کدنویسی با هوش مصنوعی، نه در افزودن عاملهای بیشتر، بلکه در ایجاد «نردههای حفاظتی» (Guardrails) بهتر و تقسیم کدبیس به دامنههای مستقل است. بهرهوری واقعی وجود دارد، اما سقف آن توسط سرعت صف ادغام انسانی تعیین میشود.
برنامهنویسانی که به دنبال مقیاسبندی جریانهای کاری AI هستند، باید پیش از استقرار چندین عامل، ابتدا منابع مشترک خود — پورتها، پایگاهدادهها و کلیدهای کش — را بازبینی و تفکیک کنند.
گام بعدی شما
- پیش از استقرار چندین عامل، منابع مشترک مانند پورتها، کلیدهای کش و پایگاهداده را تفکیک کنید.
- برای جلوگیری از تداخلات منطقی، هر عامل را به دایرکتوریهای خاصی محدود کنید (File Ownership).
- قانونی برای ممنوعیت بازنویسیهای فرصتطلبانه (Opportunistic Refactors) در فایلهای مشترک تعریف کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو