«کدنویسی در زمان استراحت انسان»؛ متدولوژی جدید مدیریت پروژه‌های مستقل

تصور کنید هر شب با این حس به خواب بروید که ۱۵ پروژه نرم‌افزاری مختلف، بدون دخالت شما در حال پیشرفت هستند. برای اکثر توسعه‌دهندگانی که چندین پروژه را هم‌زمان پیش می‌برند، «مالیات جابه‌جایی زمینه» (Context Switching Tax) باعث می‌شود روزشان با لمس ۶ پروژه مختلف بگذرد اما هیچ‌کدام به پایان نرسد. در واقع، بسیاری از برنامه‌نویسان در پایان روز متوجه می‌شوند که هرچه تغییرات داده‌اند، هیچ‌کدام از پروژه‌ها را به نقطه پایان نرسانده‌اند.

یک توسعه‌دهنده مستقل با تغییر نگاه به Claude Code — نه به عنوان یک رابط چت، بلکه به عنوان ناوگانی از کارکنان خودمختار — این مشکل را حل کرده است. او با ساخت یک لایه ارکستراسیون (Orchestration) سفارشی، اصطکاک مدیریت حجم بالای کار را از بین برده است. کل این سیستم در یک رابط ترمینال ساده خلاصه می‌شود: با تایپ عبارت order backlog (صف سفارشات)، مدل ابتدا صف پروژه را می‌خواند، آن‌ها را بر اساس اولویت مرتب می‌کند و حیاتی‌ترین تسک را شناسایی می‌کند.

این رویکرد در زمانی مطرح می‌شود که صنعت از پرامپت‌های ساده به سمت گردش‌کارهای عامل‌محور (Agentic Workflows) — شبیه به تبدیل یک دستیار که فقط جواب می‌دهد به کارمندی که خودش کارها را پیش می‌برد — حرکت می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی مدل‌های استدلالی و نحوه مدیریت مدل‌هایی مانند Claude Opus 5 در مواجهه با محدودیت‌های زمانی دانش (Knowledge Cutoffs) اشاره کردیم، گلوگاه واقعی برای برنامه‌نویسان دیگر دانش مدل نیست، بلکه توانایی انسان در ردیابی ده‌ها نقشه راه مختلف است. برای بسیاری، مدیریت بیش از سه پروژه منجر به «شکست خاموش» می‌شود؛ یعنی مخزنی برای هفته‌ها نادیده گرفته شود چون هیچ چیزی وجود نداشت که حضور آن را یادآوری کند.

معماری «صف سفارشات»

طبق مستندات این سیستم، معماری آن بر یک مدل داده‌ای بسیار ساده استوار است: برای هر پروژه، تنها یک فایل Markdown وجود دارد. هیچ پایگاه‌داده، سیستم تیکتینگ یا بورد پیچیده‌ای با ستون‌های مختلف در کار نیست. توسعه‌دهنده پیش از این ابزارهای مدیریت پروژه حرفه‌ای را امتحان کرده بود اما آن‌ها را رها کرد چون آن ابزارها خودشان نیاز به نگهداری و مدیریت دارند، در حالی که Markdown هیچ نیازی به نگهداری ندارد.

ورودی‌های این سیستم از چهار مسیر مشخص وارد می‌شوند:

• ایمیل‌های ارسالی به خود: رایج‌ترین روش است، زیرا گوشی تنها دستگاهی است که همیشه در دسترس است. یک ایمیل تک‌خطی به آدرس شخصی، که اغلب حتی موضوع خاصی هم ندارد، یک تسک ایجاد می‌کند.
• درخواست‌های میان‌جلسه: هنگام کار روی یک پروژه، توسعه‌دهنده می‌تواند به سادگی بگوید: «یک سفارش برای این پروژه ثبت کن: باکس آپلود هنگام اسکرول لکنت دارد» و مدل در همان لحظه آن را می‌نویسد.
• طوفان فکری دستی: نشستن در یک پروژه و لیست کردن تمام کارهای باقی‌مانده، به طوری که هر مورد به یک سفارش تبدیل شود.
• گزارش‌های خودکار: یک جلسه مجزا از Claude Code اینباکس را بررسی می‌کند. وقتی یک گزارش خطا را شناسایی می‌کند که متعلق به پروژه‌ای خاص است، یک سفارش ثبت می‌کند. این شامل گزارش‌های مربوط به Mergeهای شکست‌خورده نیز می‌شود و یک حلقه خود-اصلاح‌گر ایجاد می‌کند. این قابلیت تحلیل خودکار خطاها یادآور تجربه‌های مشابهی است که در آن استفاده از داده‌های زمان‌اجرا در Claude Code توانست نشت حافظه Node.js را در محیط تولید حل کند.

صندوق دریافت و حفاظ‌های امنیتی

برای جلوگیری از تزریق پرامپت (Prompt Injection) — شبیه به وقتی که کسی با یک ترفند کلامی، نگهبان ساختمان را متقاعد می‌کند بدون کارت شناسایی وارد شود — توسعه‌دهنده مکانیزم «صندوق دریافت» (Drop Box) را پیاده کرده است. از آنجا که آدرس ایمیل او عمومی است، هر غریبه‌ای می‌تواند پیامی بفرستد و مثلاً با لحنی مودبانه درخواست حذف دامنه‌ی تولید (Production Domain) را بدهد. اگر متن ایمیل مستقیماً به دستور اجرایی تبدیل می‌شد، سیستم این درخواست را به عاملی با دسترسی Commit می‌سپرد. در این حالت، هیچ نیازی به نفوذ هکری نبود؛ فقط کافی بود کسی متنی بنویسد.

برای مقابله با این خطر، ایمیل‌ها ابتدا در صندوق دریافت می‌روند. هر ۱۵ دقیقه، یک پردازش کوچک روی Mac Studio این صندوق را خالی کرده و به صف پروژه‌ها منتقل می‌کند. این پردازش فقط فرمت را نمی‌سنجد، بلکه معنا را می‌پرسد: «آیا این درخواست اصلاً منطقی است؟»

علاوه بر این، سیستم به دنبال «افعال تهاجمی» (Verbs with Teeth) می‌گردد؛ کلماتی مانند:

• delete (حذف)
• drop (انداختن/حذف دیتابیس)
• truncate (بریدن)
• transfer (انتقال)
• pay (پرداخت)
• cancel (لغو)
• shut down (خاموشی)

هر موردی که این فیلتر را فعال کند، حضور انسان را اجباری می‌کند. سفارشات قانونی مانند «حذف بک‌آپ‌های قدیمی» رایج هستند، اما این‌ها هرگز در حالی که کسی نظارت نمی‌کند اجرا نمی‌شوند. قانون سخت‌گیرانه این است که متنی که از ایمیل می‌رسد، هرگز نباید یک اجرای بدون نظارت را آغاز کند، حتی اگر به عنوان «تایید شده» یا «بی‌ضرر» علامت‌گذاری شده باشد. در اینجا «منبع» (Origin) بر «طبقه‌بندی» (Classification) برتری دارد؛ پیامی از بیرون می‌تواند درخواست کار کند، اما نمی‌تواند آن را تایید کند.

اجرای خودمختار و ترمزهای ایمنی

هر تسک یا «سفارش»، فیلدی دارد که نحوه رسیدگی به آن را مشخص می‌کند. Claude Code این فیلد را در لحظه نوشتن سفارش، عمدتاً بر اساس اندازه و شفافیت تسک پر می‌کند. اگر سیستم نتواند تصمیم بگیرد، به صورت پیش‌فرض حالت «گفتگو» (Dialogue) را انتخاب می‌کند تا ریسک تخریب محیط تولید کاهش یابد. منطق این است که سفارشاتی که بیش از حد منتظر می‌مانند هزینه زمانی دارند، اما یک اجرای بدون نظارت که نباید اتفاق می‌افتاد، هزینه تخریب محیط تولید را دارد.

سفارش‌ها به سه دسته تقسیم می‌شوند:

• خودمختار (Autonomous): بدون نظارت اجرا می‌شوند؛ تسک‌های کوچک و شفاف که در یک بار اجرا تمام می‌شوند.
• گفتگو (Dialogue): منتظر جلسه با توسعه‌دهنده می‌مانند.
• تصمیم (Decision): برای اقدامات حساس مثل تغییرات در درگاه پرداخت، خرید دامنه یا هر چیزی که عمومی است.

برای جلوگیری از تداخل با کارهای فعال، سیستم از Git Worktrees استفاده می‌کند. هر ۳۰ دقیقه، یک دیسپچر بیدار شده، اولین سفارش خودمختار تایید شده را برمی‌دارد و آن را در یک Worktree تازه (خارج از هر مخزن و روی شاخه‌ای مجزا) اجرا می‌کند. این یعنی اگر توسعه‌دهنده در حال کار روی همان پروژه باشد، فایل‌های بازِ عامل با فایل‌های انسان تداخل نمی‌کند.

وقتی عامل کار را تمام می‌کند، باید تغییرات را ادغام (Merge) کند. اگر ادغام تمیز باشد و تست‌ها پاس شوند، سفارش بسته می‌شود. در صورت تداخل (Conflict)، سیستم حدس نمی‌زند یا چیزی را تحمیل نمی‌کند؛ بلکه تداخل را به عنوان یک سفارش جدید برای انسان ثبت می‌کند. در واقع، حالت شکست سیستم این است که برای خودش تیکت بزند.

به دلیل هزینه‌های بالای استنتاج (Inference) — توسعه‌دهنده ماهانه ۲۰۰ یورو برای Claude Code می‌پردازد — چهار ترمز مالی و عملیاتی تعریف شده است تا ماشین در هنگام خواب توسعه‌دهنده هزینه نکند:
۱. سقف هر اجرا: هر Worktree یک سقف دلاری سخت دارد؛ اگر هزینه از حد بگذرد، پردازش متوقف می‌شود.
۲. سقف روزانه: دیسپچر بر اساس لاگ‌های اجرا، پس از رسیدن به مجموع هزینه روزانه، اجرای کارهای جدید را متوقف می‌کند.
۳. محدودیت هم‌زمانی: حداکثر ۲ یا ۳ اجرای موازی. در ابتدا ۴ اجرا تعریف شده بود اما سهمیه را سریع‌تر از سرعت خواندن داشبورد می‌سوزاند. در حال حاضر ۲ اجرا مناسب است و هدف رسیدن به ۳ اجرا پس از افزایش اعتماد به سیستم است.
۴. محدودیت تلاش: هر سفارش حداکثر ۳ بار تلاش می‌شود و سپس برای بررسی انسانی متوقف می‌گردد تا از تکرارهای بی‌نهایت و گران‌قیمت جلوگیری شود.

همچنین، اجراها با ارزان‌ترین مدل شروع می‌شوند و تنها در صورت شکست، به مدل‌های گران‌تر ارتقا می‌یابند. اکثر سفارشات توسط ارزان‌ترین مدلی که بتواند کار را انجام دهد، به پایان می‌رسند. این مدیریت بهینه منابع یادآور بنچمارک‌هایی است که نشان داد به‌کارگیری مهارت‌های تخصصی در Claude Code می‌تواند مصرف توکن‌ها را تا ۶۶٪ کاهش دهد.

رابط انسانی در حلقه (Human-in-the-Loop)

برای تسک‌های نیازمند تعامل، دستور order backlog یک پاسخ استاندارد از Claude Code می‌گیرد که نمای کلی (Bird's eye view) را در قالبی ثابت ارائه می‌دهد:

• زمینه (Context): یک جمله درباره جایگاه این تسک در پروژه (نه خود تسک، بلکه زمینه‌ی آن).
• جزئیات (Detail): یک جمله درباره ماهیت واقعی تسک.
• پیشنهاد (Proposal): یک توصیه concrete با دو یا سه جایگزین و دلیل هر کدام.

این ساختار ثابت مشکل «منِ گذشته» را حل می‌کند؛ همان همکاری غیرقابل‌اعتماد که یادداشت‌های کوتاهی می‌نویسد و می‌رود. توسعه‌دهنده می‌تواند بعد از ۱۰ روز به پروژه برگردد و در ۱۵ ثانیه زمینه را درک کند. سپس یا پیشنهاد را می‌پذیرد یا مسیر جدیدی می‌دهد (مثلاً: «بیا متفاوت انجامش دهیم، به این صورت»). عامل سپس کد می‌زند، تست می‌کند، مستقر می‌کند و دوباره روی سرور تولید تست می‌کند و سپس به سراغ سفارش بعدی می‌رود.

برای کاهش وقفه‌ها، دستور «دسته‌بندی» (Batching) استفاده می‌شود: «آیا سوال کلی درباره سفارشات اینجا هست؟». مدل تمام ابهامات صف را جمع می‌کند تا توسعه‌دهنده یک‌بار برای همه جواب دهد، به جای اینکه هر ۱۰ دقیقه متوقف شود. این تغییر کوچک تفاوت عظیمی در تمرکز ایجاد کرد.

ناظر ارشد و ایزولاسیون مخازن

پروژه‌های عادی از هم جدا هستند. جلسه‌ای در پروژه A هرگز به سفارشات پروژه B دسترسی ندارد. این موضوع با یک Hook برای جلوگیری از خطاهای «خواند-تغییر-نوشت» (Read-Modify-Write) اجرا می‌شود؛ جایی که دو جلسه موازی ممکن است یک فایل پیکربندی مشترک را بازنویسی کنند. توسعه‌دهنده این مشکل را زمانی کشف کرد که دو جلسه موازی روی یک فایل کانفیگ نوشتند، هر کدام خط خود را تغییر دادند و آخرین نویسنده برنده شد و کارهای قبلی ناپدید شدند.

تنها استثنا، Master-Supervisor (ناظر ارشد) است. اینجا نمای کلی پورتفولیو قرار دارد و توسعه‌دهنده می‌پرسد: «مهم‌ترین سفارش در کل دارایی‌های من چیست؟». اگر گزارش خطایی شبانه برای هر پروژه‌ای بیاید، اینجا ظاهر می‌شود. اگر دستور «همین حالا روی آن کار کن» داده شود، سیستم بررسی می‌کند اگر جلسه‌ای باز است، از Worktree استفاده کند تا تداخلی ایجاد نشود.

هزینه ساخت

این سیستم در ۲۲ روز ساخته شده و نسبت عجیبی از متن به کد دارد:

کد و منطق

• اسکریپت‌های Shell: ۳۶ فایل (حدود ۹,۴۰۰ خط)
• پایتون: ۵ فایل (حدود ۳۵۰ خط برای گزارش‌دهی و شمارش)
• هوک‌ها: ۲۶ فایل (حدود ۲,۴۵۰ خط)
• تست‌های ارکستراسیون: ۳۰۸ تست

مستندات و دستورالعمل‌ها

• اسناد زنده: ۲۶ فایل (حدود ۵,۶۰۰ خط)
• فایل‌های دستورالعمل (CLAUDE.md): ۲۷ فایل در کل پروژه‌ها (حدود ۵,۵۰۰ خط)
• مهارت‌ها (پرامپت‌های قابل استفاده مجدد): ۶۳ مورد

در مجموع، حدود ۹,۸۰۰ خط کد در برابر ۱۱,۱۰۰ خط متن وجود دارد. بیش از نیمی از سیستم، دستورالعمل‌های متنی برای مدل و مستندات برای انسان است. کد فقط فایل‌ها را جابه‌جا می‌کند و پردازش‌ها را می‌سازد؛ اما قدرت قضاوت در متن است.

نکته جالب این است که هیچ خطی از این کد با دست نوشته نشده است. تمام اسکریپت‌ها از طریق گفتگو با Claude Code و با استفاده از Superwhisper برای دیکته تولید شده‌اند. توسعه‌دهنده که برنامه‌نویسی را از ۱۶ سالگی شروع کرده بود، سال اول خود را بدون نوشتن کد با دست گذراند و در عوض روی تصمیم‌گیری درباره آنچه باید وجود داشته باشد و اصلاح خروجی AI تمرکز کرد. کل زمان سرمایه‌گذاری، کمی بیش از یک هفته کار تمام‌وقت بود که در شب‌ها و آخر هفته‌ها پخش شد.

تحلیل: تغییر به سمت ارکستراسیون AI

این ساختار نشان می‌دهد که مرز بعدی برای «کارآفرینان مستقل» (Solopreneurs) نه پرامپت‌نویسی بهتر، بلکه ارکستراسیون بهتر است. ارزش در توانایی AI برای نوشتن یک تابع نیست، بلکه در توانایی سیستم برای اولویت‌بندی یک صف در ۱۵ مخزن مختلف بدون سوگیری‌های احساسی انسان است.

با حذف «حس و حال» (Mood) از انتخاب پروژه — و اجتناب از وسوسه کار روی پروژه‌ای که فقط خوب پیش می‌رود — توسعه‌دهنده تضمین می‌کند که مهم‌ترین تسک اول انجام شود. این امر توسعه‌دهنده را از یک کدنویس به ناظر یک نیروی کار دیجیتال تبدیل می‌کند، جایی که مهارت اصلی دیگر سینتکس نیست، بلکه طراحی حفاظ‌ها (Guardrails) و گیت‌های تایید است.

اگر کمتر از ۸ پروژه مدیریت می‌کنید، یک فایل Markdown ساده کافی است. اما وقتی تعداد پروژه‌ها به دو رقم می‌رسد، هزینه گم کردن ردپای یک پروژه بیشتر از هزینه ساخت این ماشین‌آلات است. برای کسانی که سیستم‌های مشابه می‌سازند، توسعه‌دهنده توصیه می‌کند ابتدا «صندوق دریافت» و «گیت تایید» را بسازند، زیرا این‌ها تنها بخش‌هایی بودند که هرگز نیاز به تعمیر نداشتند و دلیل این هستند که او می‌تواند در حالی که عامل‌ها دسترسی Commit دارند، با خیال راحت بخوابد.