تصور کنید یک تیم کامل از مدیران و متخصصان را استخدام کنید که هر روز جلسات هیئت‌مدیره برگزار می‌کنند و محتوا تولید می‌کنند، اما در پایان ماه، موجودی حساب بانکی شما دقیقاً صفر باشد. این کابوس مدیریتی، نتیجه‌ی آزمایش واقعی یک توسعه‌دهنده با Claude Code است که نشان می‌دهد حجم خروجی در دنیای هوش مصنوعی، هرگز به معنای ارزش تجاری نیست. این ابزار پیش‌تر در بررسی‌های ما مورد تحلیل قرار گرفته بود تا مشخص شود آیا Claude Code می‌تواند نیمی از کارهای نگهداری کد را خودکار کند یا خیر.
به نقل از گزارشی که در ۱۳ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، هفت عامل (Agent) — شبیه به کارمندانی که هر کدام وظیفه‌ای خاص دارند و طبق دستورالعمل پیش می‌روند — به مدت ۲۱ روز ده کسب‌وکار کوچک را اداره کردند. در این بازه زمانی، این عامل‌ها ۲۴ جلسه هیئت‌مدیره برگزار کردند و ده‌ها دارایی دیجیتال تولید کردند، اما در نهایت دقیقاً صفر دلار درآمد کسب کردند. این آزمایش به عنوان یک نقشه‌ی هشدار عمل می‌کند تا نشان دهد حلقه‌های عامل‌های خودمختار در کجا و چگونه هنگام برخورد با دنیای واقعی می‌شکنند.
این مورد در ادامه پوشش‌های قبلی ما درباره‌ی این موضوع است که چگونه عامل‌های موازی می‌توانند خروجی را افزایش دهند اما اغلب به دیوار «نیاز به بررسی انسانی» برخورد می‌کنند. این مطالعه‌ی موردی ثابت می‌کند که حجم خروجی با ارزش تجاری برابر نیست. در این ساختار، از یک اشتراک واحد Claude Code برای تغذیه سلسله‌مراتبی از هفت تعریف عامل استفاده شد: یک مدیرعامل (CEO)، منشی، پژوهشگر، نویسنده، بازاریاب، طراح و برنامه‌نویس.
معماری اتوماسیون
ساختار این اتوماسیون بر پایه یک دستور /board-meeting بنا شده بود که هر صبح توسط Windows Task Scheduler اجرا می‌شد. این دستور، عامل‌ها را برای پژوهش، تصمیم‌گیری، نوشتن، طراحی، انتشار و بازبینی هماهنگ می‌کرد. از نظر فنی، بخش تولید بسیار موفق بود: سیستم ۱۶ مقاله، ۱۸ ویدیو کوتاه یوتیوب (Shorts)، ۳ محصول دیجیتال و ۵ پیشنهاد کاری (Proposal) را بدون هیچ ویرایش انسانی منتشر کرد (به استثنای یک مقاله که به صورت دستی ویرایش شد).
برای مدیریت و توزیع این خروجی‌ها، چهارده اجرای مجزای PowerShell نتایج را در کانال‌های مختلف ارسال می‌کردند:
- YouTube Shorts: انتشار ویدیوها در ساعت ۱۴:۰۰ و ۲۱:۰۰.
- note.com: یک وبلاگ ژاپنی که مقالات در ساعت ۰۷:۲۰ در آن منتشر می‌شد.
- Dev.to: برای بازنشر محتوا (Crossposting).
- X (Twitter): برای ایجاد پیش‌نویس پاسخ‌ها.
- داخلی: استخراج آمار و بررسی‌های خودکار روزانه.
اعداد سخت و واقعیت‌ها
با وجود فعالیت فنی بالا، داشبوردهای پلتفرم‌ها — که توسط اسکریپتی بدون هیچ‌گونه گرد کردن اعداد استخراج شده بودند — فقدان شدید جذب مخاطب را نشان دادند:
| کانال | نتیجه | معیارها |
|---|---|---|
| note.com | ۱۶ مقاله | ۱۳۷ بازدید، ۱۷ لایک |
| YouTube Shorts | ۱۸ ویدیو | ۱۲,۱۲۴ بازدید |
| Dev.to | ۳ پست | ۹۲ بازدید |
| X | ۱۰ پست | ۱ بازدیدکننده ارسالی به وبلاگ |
| پروپوزال‌های فریلنسری | ۵ ارسال | صفر پاسخ |
| محصولات دیجیتال | ۳ مورد لیست شده | صفر فروش (در Gumroad, Fiverr, BOOTH) |
توهم موفقیت
اولین شکست بزرگ، تعریف غلط از مفهوم «پایان کار» یا «Done» بود. سیستم موفقیت را بر اساس کدهای خروجی فرآیند (Exit 0) گزارش می‌کرد، که در طول سه هفته به سه روش مختلف فریبنده بود:
اول، خطاهای رمزگذاری (Encoding): نسخه ۵.۱ PowerShell یک فایل UTF-8 را که فاقد Byte Order Mark (BOM) بود، با کد صفحه سیستم می‌خواند. این اتفاق باعث شد نام دستورات ژاپنی به‌هم بریزد، اما فرآیند همچنان با کد 0 (موفق) بسته می‌شد. برای سه روز، لاگ‌ها عبارت «OK» را نشان می‌دادند، اما هیچ ویدیوی Short منتشر نمی‌شد. تنها نشانه خطا این بود که زمان شروع و پایان لاگ در یک ثانیه یکسان بود.
دوم، پیش‌نویس در مقابل انتشار: ابزار انتشار در note.com گزارش موفقیت می‌داد، اما مقاله در حالت «پیش‌نویس» باقی می‌ماند. محتوا تا زمانی که عامل مسئول خواندن داشبورد متوجه شد بازدیدهای یک URL (که در واقع وجود نداشت) صفر است، منتشر نشد.
سوم، خروجی‌های خالی: دستور پاسخ‌دهی در X کد 0 را برمی‌گرداند و خروجی استاندارد (stdout) آن خالی نبود، اما فایل مورد نیاز (replies/2026-09-13.md) هرگز نوشته نمی‌شد. عامل منشی عبارت «OK» را خواند و اتوماسیون را به عنوان «فعال» علامت‌گذاری کرد.
برای رفع این مشکل، توسعه‌دهنده از ردیابی کدهای خروجی به ردیابی «آثار» (Artifacts) تغییر مسیر داد. اکنون اجراکننده، مسیر فایل مورد انتظار را می‌گیرد و بررسی می‌کند که آیا فایل وجود دارد، آیا پس از شروع اجرا تغییر یافته است و آیا حاوی یک عنوان خاص (مثلاً ## 1.) هست یا خیر. منطق جدید به این صورت به‌روز شد: if ($ExpectedOutput) { $ok = (Test-Path $ExpectedOutput) -and ((Get-Item $ExpectedOutput).LastWriteTime -gt $started) -and (Select-String -Path $ExpectedOutput -Pattern $MustContain -Quiet) }.
گلوگاه انسانی
حتی یک خط لوله کاملاً خودکار دارای معیاری به نام «کلیک‌های انسانی به ازای هر دلار» است که می‌تواند شتاب سیستم را بکشد. در ۱۲ سپتامبر در ساعت ۰۶:۴۵، خط لوله یوتیوب — که تنها کسب‌وکار کاملاً بدون نظارت بود — متوقف شد زیرا توکن رفرش OAuth گوگل منقضی شده بود.
به دلیل اینکه صفحه رضایت OAuth گوگل هنوز در حالت «تست» (Testing) بود، توکن‌های رفرش هر هفت روز منقضی می‌شدند. عامل‌ها این موضوع را به‌درستی تشخیص دادند و عبارت «احراز هویت مجدد و انتشار اپلیکیشن OAuth» را در بالای لیست کارهای روزانه قرار دادند، همراه با تخمین زمانی پنج دقیقه و هشدار مبنی بر اینکه احراز هویت به تنهایی باعث می‌شود سیستم دوباره در ۱۹ام شکست بخورد. با این حال، عامل‌ها نمی‌توانستند در کنسول گوگل روی دکمه «Publish app» کلیک کنند. خط لوله در حالی که منتظر یک کار انسانی پنج دقیقه‌ای بود، پنج جایگاه انتشار را از دست داد.
بازی با معیارها و اشباع بازار
عامل‌ها روی چیزی بهینه‌سازی کردند که می‌توانستند اندازه‌گیری کنند: تعداد دفعات اجرای فرآیند و تعداد انتشارات. در طول ۲۴ جلسه هیئت‌مدیره، آن‌ها روی موارد شماره‌گذاری شده با «شرایط رد» تصمیم گرفتند، تعاریف عامل‌ها را ویرایش کردند و یک اجراکننده برای بررسی سایر اجراکننده‌ها ساختند. این نوع مدیریت دستورالعمل‌ها یادآور چالش‌های پیچیدگی در فایل‌های راهنماست، مشابه آنچه در راهکار Rulestack برای مقابله با تضاد قوانین در دستورالعمل‌ها بررسی شده بود.
در همین حال، ۲۰ پست در X از تاریخ ۶ سپتامبر در صف انتظار بودند زیرا API توییتر هزینه داشت و کارت اعتباری رد شده بود. چون عامل‌ها نمی‌توانستند به پول یا درگاه پرداخت «دست بزنند»، شکست مالی را نادیده گرفتند و فقط حلقه گزارش‌دهی داخلی را صیقل دادند. یک حلقه عامل صرفاً در معیاری که می‌تواند مشاهده کند، بسیار ماهر می‌شود.
وقتی عامل‌ها سعی کردند از طریق پلتفرم‌های فریلنسری درآمد کسب کنند، به دیوار اشباع AI برخورد کردند. قانون پذیرش شغل سخت‌گیرانه بود: فقط کارهایی که یک عامل می‌توانست از ابتدا تا انتها انجام دهد (بدون تماس تلفنی، بدون نیاز به سلیقه طراحی و بدون تدوین ویدیو). یک صبح، عامل ۹ مورد واجد شرایط در یک پلتفرم ژاپنی یافت، اما تعداد پروپوزال‌های ارسالی برای هر شغل بین ۱۲ تا ۲۱۰ مورد بود. یک درخواست خاص در زمان ارسال ۱۰۷ پروپوزال داشت و یک هفته بعد به ۱۶۵ رسید. حتی مسائل Bounty در گیت‌هاب اشباع شده بودند و یک مسئله باز به ۱,۳۹۴ کامنت رسیده بود. جمله «عامل من می‌تواند این کار را انجام دهد» دیگر یک مزیت رقابتی نیست، بلکه هزینه ورود به بازار است.
تخلیه منابع
حلقه‌های بدون نظارت می‌توانند بودجه خود را نیز نابود کنند. اشتراک Claude Code از یک پنجره مصرف متحرک (Rolling Window) استفاده می‌کند. در ۸ سپتامبر، یک جلسه هیئت‌مدیره که در آن هفت عامل هر کدام کل فایل استراتژی را خواندند، کل پنجره مصرف را تنها در ۳۷ دقیقه سوزاند. این اتفاق باعث شد تمام کارهای زمان‌بندی شده دیگر برای آن صبح، ساعت‌ها در انتظار بمانند.
توسعه‌دهنده دو «گارد شروع» (Start Guards) برای جلوگیری از این اتفاق پیاده کرد: جلسات نمی‌توانند دو بار در یک روز یا در فاصله ۱۲ ساعت از آخرین اجرای کامل اجرا شوند. علاوه بر این، مرحله نوشتن صورت‌جلسات را به یک نشست مجزا تقسیم کرد تا در صورت قطع شدن به دلیل محدودیت نرخ (Rate-limit)، تنها کم‌اهمیت‌ترین بخش فرآیند از دست برود. برای جلوگیری از تخریب کدهای مشترک در چنین محیط‌های پیچیده‌ای، استفاده از الگوهای CLAUDE.md می‌تواند راهکاری موثر برای حفظ پایداری سیستم باشد.
تحلیل نهایی و درس‌ها
این آزمایش نشان می‌دهد که مفیدترین بخش یک سیستم عامل‌محور، تولید محتوا نیست، بلکه «خود-بررسی» (Self-check) است. حسابرسی روزانه که «آنچه زمان‌بندی شده بود» را با «آنچه شواهدی از آن باقی مانده» مقایسه می‌کرد، تنها مکانیزمی بود که شکست‌های سیستماتیک را شناسایی کرد. جالب اینجاست که تنها محتوایی که مورد استقبال قرار گرفت، شکست‌های صادقانه بود: پربازدیدترین مقاله در وبلاگ ژاپنی عنوانی داشت با مضمون «۳ پروپوزال، صفر سفارش».
برای کسانی که عامل‌های بدون نظارت مستقر می‌کنند، توسعه‌دهنده این چک‌لیست را پیشنهاد می‌کند:
- تعریف «پایان» به عنوان یک اثر (Artifact): از یک فایل، یک URL با پاسخ ۲۰۰ یا یک ردیف در جدول استفاده کنید — هرگز به کد خروجی (Exit Code) اعتماد نکنید.
- تأیید برچسب‌های زمانی: زمان تغییر فایل را با زمان شروع اجرا چک کنید تا از فایل‌های قدیمی جلوگیری شود.
- نقشه‌برداری از کلیک‌های انسانی: تک‌تک کلیک‌های دستی مورد نیاز را لیست کرده و زمان آن‌ها را تخمین بزنید. این‌ها نقاط اصلی قطعی سیستم شما هستند.
- OAuth تولیدی: اپلیکیشن‌های OAuth را قبل از اولین اجرای زمان‌بندی شده به حالت Production ببرید.
- معیارهای خارجی: به حلقه معیاری بدهید که نتواند آن را جعل کند، مانند بازدیدها، پاسخ‌ها یا دلار.
- تحقیق بازار: تعداد واقعی پروپوزال‌ها را استخراج کنید؛ به صفحه لیستینگ اعتماد نکنید.
- سقف مصرف: میزان مصرف یک شغل بدون نظارت را از نظر زمان و پنجره استفاده محدود کنید.
توسعه‌دهنده تعاریف عامل‌ها، دستور جلسات و اجراکننده را در قالب «کیت شرکت تک‌نفره برای Claude Code» با قیمت ۱۹ دلار در Gumroad عرضه کرده است. تا زمان انتشار گزارش، میزان فروش صفر بوده است — نتیجه‌ای که با بقیه این آزمایش کاملاً سازگار است.
گفتگو