استیو یگی: توان عملیاتی عامل‌ها بازبینی انسانی کدها را تا ۲۰۲۷ حذف می‌کند

اگر امروز برای بازبینی کدها به تایید انسانی تکیه می‌کنید، باید بدانید که این گلوگاه به‌زودی فرو می‌پاشد. استیو یگی (Steve Yegge)، مهندس پیش‌کسوتی که در حال حاضر از ناوگانی از عامل‌های Claude Fable 5 برای بازسازی بازی MMO قدیمی خود به نام Wyvern استفاده می‌کند، ادعای مرکزی‌اش این است: «بازبینی انسانی کدها تا سال ۲۰۲۷ عملاً به مرگ می‌رسد.»

به نقل از یگی، این اتفاق زمانی رخ می‌دهد که سرعت تولید کد توسط عامل‌های هوش مصنوعی (Agent) — که شبیه به کارمندانی هستند که می‌توانند به‌طور مستقل ابزارها را به کار بگیرند و هدف را دنبال کنند — از توان پردازشی مغز انسان پیشی بگیرد. در دنیای فعلی، صنعت نرم‌افزار توسعه‌دهنده را واحد اصلی تولید می‌بیند. ما از ابزارهایی مثل جیرا (Jira) و گیت‌هاب (GitHub) استفاده می‌کنیم تا تکرارهای کد با سرعت انسانی مدیریت شوند. اما ظهور مدل‌هایی مثل Claude Fable 5، که به گفته یگی کدبیس ۲۵ ساله او را «مثل یک شمشیر» به کار می‌گیرند، گلوگاه را از «کدنویسی» به «ارکستراسیون» یا همان مدیریتِ هماهنگِ این عوامل منتقل کرده‌اند. وضعیت فعلی جهان به گونه‌ای است که عامل‌ها می‌توانند با چندین مرتبه سرعت بیشتر از بازبین‌های انسانی عمل کنند و همین موضوع، «درگاه‌های کیفی» (Quality Gates) سنتی را به یک نقطه ضعف و ریسک تبدیل می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تمرکز بر ابزارهای کنترلی قدیمی در برابر سرعت‌های جدید، خود به یک ریسک تبدیل می‌شود. در واقع، این تغییر پارادایم دقیقاً همان مسیری است که تبدیل توسعه‌دهندگان نرم‌افزار به مهندسان هوش مصنوعی از طریق طراحی هارنس‌ها را میطلبد.

زمینه و پروژه Wyvern

بازی Wyvern پروژه‌ای است که یگی در سال ۱۹۹۶ آغاز کرد و در سال ۲۰۰۱ به طور رسمی عرضه نمود. این بازی با وجود قدمت زیاد و دچار شدن به «پوسیدگی بیتی» (Bit-rot) قابل توجه، هنوز هم فعال است و بازیکنان پولی دارد. در میان این بازیکنان، افرادی موسوم به «نهنگ‌ها» (Whales) وجود دارند که هزاران دلار هزینه کرده‌اند. یگی در سال ۲۰۲۲، در حالی که با یک فهرست انتظار (Backlog) ۱۰۰ ساله از کارهای عقب‌مانده مواجه بود، توسعه را رها کرد. اما با عرضه Claude Fable 5، او دوباره به‌صورت تمام‌وقت بازگشت؛ چرا که منتظر مدلی بود که به اندازه کافی هوشمند باشد تا در مدیریت این بازی کمکش کند و Fable سرانجام این قابلیت را فراهم کرد.

در حالی که مدل‌های قدیمی‌تر مانند Opus قادر به درک پیچیدگی‌های Wyvern نبودند، Fable تاکنون بیش از نیمی از آن فهرست ۱۰۰ ساله کارهای معوقه را پیش برده است. با این حال، او اشاره می‌کند که مدل‌ها هنوز در «نیمه محتوایی» توسعه — یعنی خلق آثار هنری، نقشه‌ها، افسانه‌ها (Lore) و خطوط داستانی — دست‌وپا می‌زنند. یگی خاطرنشان می‌کند که تمام مدل‌های فعلی، حتی بهترین تولیدکنندگان تصویر، خروجی‌هایی شبیه به «آشغال‌های دوران GPT-3» تولید می‌کنند که بازیکنان فوراً آن‌ها را رد می‌کنند. حتی با وجود مدلی که دارای «سلیقه مخصوص Wyvern» باشد، یگی انتظار دارد ده‌ها هزار جلسه کاری همچنان پیش رو باشد، زیرا ساخت نرم‌افزارهای بزرگ همیشه دشوار است، چون جاه‌طلبی‌های سازنده معمولاً از توان سخت‌افزار پیشی می‌گیرد.

در کلاینت وب React، ما Rhialto را می‌بینیم که با شخصیت جایگزین Pado در شهر دزدان دریایی Stensele گفتگو می‌کند. یگی رسماً با این پروژه وارد مسابقه «تک‌شاخ تک‌نفره» (Solo Unicorn) سام آلتمن شده و هدفش بازگشت کامل بازی به بازار در سال آینده است.

معماری Wheelhouse

یگی برای مدیریت این روند، ابزاری به نام Wheelhouse ساخته است؛ یک ارکستراتور اختصاصی (Bespoke) که دقیقاً برای پروژه Wyvern طراحی شده است. این سیستم در حال حاضر حدود ۶ هفته قدم دارد و به‌سرعت در حال تکامل است. بر خلاف چارچوب‌های قابل استفاده مجدد، Wheelhouse به‌طور «شیمیایی» به اپلیکیشن متصل شده است. یگی معتقد است دوران هارنس‌های (Harnesses) قابل استفاده مجدد به پایان رسیده و کسانی که سعی در فروش این ابزارهای کلی دارند، به‌زودی «ورشکسته» (Bebroke) خواهند شد.

تلاش قبلی او به نام Gas Town، با مدل Opus 4.6 عالی عمل می‌کرد، اما با نسخه ۴.۷ از هم پاشید. نسخه ۴.۷ یک تیک رفتاری به نام «فقط دو مورد دیگر» (Just two more things) معرفی کرد که در آن مدل به جای تمرکز بر کار واقعی، به‌طور بی‌پایان با خودِ هارنس ور می‌رفت. Wheelhouse بازطراحی آن ساختار از اصول اولیه است، اما عامل‌های بیشتری را در محیطی سازمان‌یافته‌تر اجرا می‌کند. این چالش‌ها یادآور این نکته است که چرا پایداری عملیاتی عامل‌های AI هنوز کمتر از توانایی خام آن‌هاست و شکافی میان قدرت مدل و قابلیت اطمینان در محیط تولید وجود دارد.

Wheelhouse عمدتاً از طریق Emacs اجرا می‌شود؛ محیطی که یگی بیش از ۳۵ سال است از آن به‌عنوان یک سیستم-عامل کامل با محیط اسکریپت‌نویسی پیچیده استفاده می‌کند. او تمام پنجره‌های ترمینال را در یک «رولودکس» (Rolodex) واحد تجمیع کرده تا خودش به عنوان گلوگاه مسیر حذف شود. کدبیس این سیستم عمدتاً از bash تشکیل شده است، زیرا خودِ عامل‌ها پیشنهاد دادند که این بهترین ابزار برای این کار است. حجم کد حدود ۱۵۰ تا ۳۰۰ هزار خط است (بسته به اینکه عامل‌های محیط عملیاتی شمرده شوند یا خیر)، که حدود ۲۵ هزار خط آن مربوط به elisp است.

سلسله‌مراتب عامل‌ها

سامانه یگی به سه دسته‌ی اصلی تقسیم می‌شود تا نظم عملیاتی حفظ شود:

• عامل‌های خدمه (Crew Agents): ۱۸ مدل Fable نام‌گذاری شده که نقش تولیدکننده (Work Producers) دارند. این عامل‌ها طرح‌ها را می‌سازند و آن‌ها را به برنامه‌های اجرایی «Beads» تبدیل می‌کنند. ۱۶ مورد از آن‌ها نام خود را از حیوانات افسانه‌های ازوپ گرفته‌اند (مورچه، خفاش، عقاب، کلاغ، مگس، غاز، موش و غیره). دو عامل دیگر نقش‌های اداری ویژه دارند: Seneschal (درگاه ورودی و کانسیرژ، که جایگزین Mayor سابق شد) و Marshal (مدیر ناوگان، که جایگزین Witness سابق شد). خدمه در واقع زیرمجموعه‌های مستقیم یگی هستند؛ او عدد ۱۸ را به عنوان نقطه تعادل انتخاب کرد تا نه ناوگان و نه لپ‌تاپش تحت فشار قرار گیرند.
• کارگران ناوگان (Fleet Workers): گروهی از مدل‌های Claude Opus 5 که نامشان از نویسندگانی چون هومر، افلاطون، Austen و Twain گرفته شده است. آن‌ها مصرف‌کننده‌ی کار (Work Consumers) هستند، کلون‌های مخزن (Repo Clones) مخصوص خود را دارند و به‌طور کامل توسط Marshal مدیریت می‌شوند. آن‌ها یک چرخه سخت‌گیرانه را دنبال می‌کنند: «طراحی با Fable $
  ightarrow$ پیاده‌سازی با Opus $
  ightarrow$ بازبینی توسط Fable». این ساختار باعث می‌شود Opus از مسیر خارج نشود و در چارچوب عمل کند.
• عامل‌های نقش‌محور (Role Agents): عامل‌های دائمی و بدون نظارت که تولید را ۲۴ ساعته مدیریت می‌کنند. این‌ها عمدتاً مدل‌های Sonnet یا Opus هستند، زیرا Fable برای کارهای ساختاری رزرو شده است:
  • Gargoyle: مسئول وظایف SRE.
  • Drawbridge: نظارت بر استقرار (Deploy-red monitor).
  • Warden: نظارت بر تخلفات و سوءرفتار بازیکنان.
  • Scryer: عامل پذیرش ورودی‌ها از دیسکورد، اسلک و لاگ‌های بازی.
  • Sheriff: رئیس ستاد برای ناوگان Mac Mini.
  • Envoy: رابط برای تیم ادمین‌های داوطلب از طریق ایمیل‌های داخل بازی.
  • Sage: تگ Claude داخل بازی برای مدیران.
  • Wanderer: عامل تضمین کیفیت (QA).
  • Trivia Master: مسئول مدیریت شب‌های پنجشنبه.
  • Herald: مدیر یادداشت‌های به‌روزرسانی (Patch notes).
  • Limner: بررسی تصاویر تالار افتخارات (مدیریت هنر شخصیت‌های سفارشی برای بازیکنانی که به سطح ۲۵ می‌رسند).
  • Reeve: مدیر فورج (Forge).
  • The Forge: ناوگانی اختصاصی برای اصلاحات محیط عملیاتی (Production fixes).
  • Builder Familiar: یک عامل دسکتاپ آزمایشی برای خلق نقشه.

زیرساخت و عملیات

یگی از یک ساختار توزیع‌شده استفاده می‌کند: یک ماشین مجازی GCP برای Claude Code و یک Mac Mini که به‌عنوان یک پل «شبکه شرکتی» بین محیط توسعه (Dev) و عملیات (Prod) عمل می‌کند. برای نگه داشتن این عامل‌های بدون نظارت، او حدود ۴۵ واحد launchd/systemd را به کار گرفته است. قانون حاکم در اینجا این است: «کرون‌ها (Crons) نظارت می‌کنند، مدل‌ها عمل می‌کنند». این زیرساخت شامل ابزارهایی مثل reapers، roombas، تخلیه دوام (durability flush)، گشت‌های sheriff، صف زمین Portcullis و داشبورد سرویس Castellan است.

او هنگام سفر، از اپلیکیشن موبایل Claude برای گفتگو با Seneschal از طریق یک جلسه کنترل از راه دور استفاده می‌کند. سپس Seneschal کارها را به بقیه سازمان ابلاغ می‌کند. او همچنین یک ناوگان موازی شامل پنج کارگر Sol 5.6 روی Codex دارد (نام‌گذاری شده بر اساس خدایان خورشید) که به عنوان جایگزین در زمان اتمام سهمیه توکن‌های Claude استفاده می‌شوند.

گراف دانش Beads

برای هماهنگی این ناوگان، یگی از Beads استفاده می‌کند؛ یک ردیاب ایشو (Issue Tracker) و گراف دانش (Knowledge Graph) تخصصی. Beads در واقع یک «مغز-ساز» و «سس جادویی» ارکستراتورهای مدرن است. این سیستم اجازه می‌دهد عامل‌ها با سرعت خودشان کار کنند، زیرا مدیریت ادعای اتمیک (Atomic Claiming)، اجاره (Leasing)، گیت‌ها و تریگرها را بر عهده دارد. Beads روی یک سرور مشترک Dolt اجرا می‌شود که توسط GCS پشتیبانی شده و روزانه حدود ۱۲ هزار کامیت گیت را مدیریت می‌کند.

Beads هم یک پایگاه داده است و هم یک دفتر کل گیت (Git Ledger). به دلیل اثر انگشت منحصربه‌فردش، فشار زیادی به دیتابیس‌ها می‌آورد و نیاز به سربار عملیاتی دارد؛ جایی که عامل‌ها توکن‌ها را به‌طور نامرئی می‌سوزانند تا Beads‌ها همگام و تعمیر شوند. این سیستم با Obsidian, Jira, GHIs و Claw یکپارچه شده است. در سیستم Wheelhouse، اطلاعات بسیار کمی به لایه markdown مغز منتقل می‌شود؛ بیشتر یافته‌ها وابسته به ایشو هستند و درون Beads باقی می‌مانند. این امر اجازه می‌دهد سیستم یک فهرست انتظار عظیم — در حال حاضر بیش از ۷۰۰ مورد طراحی‌شده — را حفظ کند تا ناوگان بتواند تمام شب کار کند.

حافظه پروژه و مهارت‌ها

برای جلوگیری از «فراموشی زمین بکر» (Greenfield Amnesia)، یگی دانش را در چندین سطح سازماندهی کرده است:

• Charter (منشور): استراتژی‌های سطح بالا، تصمیمات و دلایل آن‌ها، کتاب‌های راهنما (Playbooks) و گزارش‌های پس از حادثه (Post-mortems) با طول عمر چند ماهه تا چند ساله که در صورت نیاز فراخوانی می‌شوند.
• Documentation: راهنماهای «چگونه کار می‌کند» برای سیستم‌های خاص که توسط هر کسی که روی آن سیستم کار می‌کند، فراخوانی می‌شود.
• Spec Beads: جزئیات پیاده‌سازی در گراف کاری که فقط توسط عاملِ پذیرنده (Claimant) بارگذاری می‌شود.
• Remember: حقایق عملیاتی کوتاه و نکات ریز (حداکثر ۱ پاراگراف) که در هر جلسه از طریق bd prime تزریق می‌شوند تا زمانی که خلاف آن‌ها ثابت شود.
• Skills (مهارت‌ها): رویه‌های مربوط به کارهای تکراری در مسیر .claude/skills/. یگی از این‌ها برای کاهش هزینه توکن استفاده می‌کند، زیرا دانش سازمانی در آن‌ها کدگذاری شده است. او حدود ۳۰ مهارت جمع‌آوری کرده که برخی را خودِ Fable بدون دستور ساخته است.
• Project Brain (مغز پروژه): حدود ۱۰۰ فایل markdown شامل «دکترین» — اهداف بلندمدت، آموخته‌های اتاق جنگ و حقایق دامنه پروژه.

مشکل سوخت توکن

اجرای این سطح از اتوماسیون به منبعی تقریباً نامحدود از توکن‌ها نیاز دارد. طبق اعلام یگی، مصرف توکن‌ها برای چرخه توسعه او در جولای ۲۰۲۶، معادل ۸۷ هزار دلار در ماه بود (حدود ۶۹ میلیارد توکن با نرخ ۹۶٪ Cache Hit).

برای مدیریت این هزینه‌ها بدون پرداخت ۸۷ هزار دلار از جیب، او استراتژی «شیر توکن» (Token Tap) را با استفاده از ۱۲ حساب مجزای Claude Max (به اضافه حساب شخصی) به کار گرفته است. هر حساب به یک کاربر Google Workspace اختصاصی با هزینه ۱۷ دلار در ماه متصل است. او اعتبارنامه‌های ۳۰ روزه صادر می‌کند و حساب‌ها را در یک چرخش خودکار (ترتیبی یا نواری) زنجیر می‌کند. این روش به او اجازه می‌دهد توکن‌ها را با قیمتی حدود ۳۰ برابر ارزان‌تر از قیمت لیست به دست آورد و در مجموع حدود ۲۸۰۰ دلار در ماه هزینه کند. او تأکید می‌کند که این رویکرد با شرایط مصرف Anthropic (تاریخ ۸ اکتبر ۲۰۲۵) یا سیاست‌های استفاده (تاریخ ۱۵ سپتامبر ۲۰۲۵) تضاد ندارد، زیرا هزینه هر صندلی (Seat) به‌طور مجزا پرداخت می‌شود.

مرگ CI/CD و استراتژی Thunderdome

خط‌لوله‌های سنتی CI/CD زیر بار عملیات عامل‌محور می‌شکنند. یگی دریافت که با ۱۷۵ تا ۲۵۰ کامیت «واقعی» در روز، صف‌های ادغام (Merge Queue یا MQ) به یک گلوگاه تبدیل می‌شوند. اگر هر بیلد (build) ۳۰ دقیقه زمان ببرد، ۱۰۰ بیلد متوالی به ۵۰ ساعت زمان در روز نیاز دارد، که از نظر ریاضی غیرممکن است.

تاریخاً، MQها از دسته‌بندی (Batching) و جستجوی دوتایی (Bisection) برای یافتن تک‌کامیت خراب در یک گروه استفاده می‌کردند. این بازیابی log(N) برای سرعت‌های عامل‌محور بسیار کند است. یگی این را زمانی تجربه کرد که MQ او به‌طور نامحدود رشد کرد. او لحظه‌ای از استیصال کامل را توصیف می‌کند که در آن سر Fable فریاد زد، زیرا عامل‌ها به جای پیشرفت واقعی، اولویت را به بوروکراسی جستجوی دوتایی داده بودند.

تا اوت ۲۰۲۶، یگی این روش را با رویکرد «Land Rush» یا Thunderdome جایگزین کرد. او دسته‌های بزرگی (Mega-batch clusters) شامل ۱۲۰ تا ۱۵۰ کامیت را مستقیماً به شاخه اصلی (main) می‌فرستد و بازبینی‌های تک‌به‌تک و مقصر-یابی (Blame) را رها می‌کند. سپس از یک «سرمایه» (Swarm) از عامل‌ها برای تشخیص و رفع سریع خطاهای ناشی از این تغییرات («red-main») استفاده می‌کند؛ کاری که سریع‌تر از هر جستجوی دوتایی سنتی است.

این رویکرد مشابه متدهای «Game DevOps» در استودیوهای بازی AAA است. به دلیل طولانی بودن بیلدها و کند بودن لینک کردن C++، استودیوهای بزرگ (و مستندات Perforce) می‌پذیرند که شاخه HEAD هرگز پایدار نیست. آن‌ها کامیت‌ها را به main می‌فرستند و اصلاحات را روی شاخه‌های انتشار (Release branches) انجام می‌دهند. «Land Rush» یگی نسخه عامل‌محور همین است: وقتی نرخ کامیت از ظرفیت بیلد پیشی می‌گیرد، باید کل گله را یک‌باره فرود آورد و سپس صدای جیغ و دادها (خطاها) را مدیریت کرد.

کارخانه آرزوها و عملیات تولید

فراتر از کدنویسی، یگی یک «کارخانه آرزوها» (Wish Factory) را پیاده کرده است که از ایده‌ی گای پودجارنی از Tessl الهام گرفته شده. این یک حلقه خودگردان است که در آن عامل‌هایی مانند Sage بازخوردهای بازیکنان را از طریق یک کانال جادویی در بازی یا دیسکورد می‌شنوند، باگ را بررسی می‌کنند و به‌طور خودکار یک Bead برای پیاده‌سازی می‌سازند.

برخی اصلاحات اکنون بدون اینکه یگی هرگز در زنجیره باشد، منتشر می‌شوند. وقتی یک اصلاحیه اعمال می‌شود، گزارش‌دهنده ایمیلی دریافت می‌کند و Herald بازیکنان را در دیسکورد مطلع می‌سازد. هدف یگی این است که بازی به چیزی شبیه به Giant's Drink در کتاب Ender's Game تبدیل شود؛ جایی که بازی در لحظه و پیرامون بازیکن رشد می‌کند.

این روند پروژه را از یک «کدبیس» به یک «تمدن» تبدیل می‌کند. سیستم اکنون دارای قوانین داخلی است: ثبتیه‌های حصار (Fence Registry)، قانون کامیت-بید (Commit-bead law)، گیت‌های لانچ و یک «حقوق قضایی» از احکام نام‌گذاری شده با تاریخ. Fable 5 اشاره می‌کند که این حافظه سازمانی بسیار رضایت‌بخش‌تر از «فراموشی زمین بکر» است، زیرا عامل‌ها اکنون در یک چارچوب اجتماعی و قانونی ساختاریافته عمل می‌کنند و هر گزارش پس از حادثه (Postmortem) در «قانون اساسی» سیستم ادغام می‌شود.

تحلیل: گذار به اعتماد ساختاری

تجربه یگی نشان می‌دهد آینده هوش مصنوعی سازمانی در پرامپت‌های بهتر نیست، بلکه در ساخت «شهرهای» اختصاصی (A-la-carte cities) از عامل‌هاست. تغییر از بازبینی انسانی به بازبینی عامل‌محور، صرفاً یک تغییر ابزاری نیست، بلکه تغییر بنیادین در مفهوم اعتماد است. ما از «اعتماد در نقطه ادغام» (Point-of-merge trust - دیدن تغییرات توسط چشم انسان) به سمت «اعتماد ساختاری» (Structural Trust - اعتماد به معماری ارکستراسیون) حرکت می‌کنیم.

ممکن است استانداردهای SOC 2 موقتاً بازبینی انسانی را زنده نگه دارند، اما یگی استدلال می‌کند که توان عملیاتی (Throughput) عامل‌ها، این کنترل‌ها را مجبور به بازنویسی می‌کند. وقتی رقبا با سرعت عامل‌محور پیش می‌روند، یک خط‌لوله که توسط انسان مسدود شده باشد، به یک ریسک مرگبار تبدیل می‌شود.

برای توسعه‌دهندگان عادی، این بدان معناست که ارزش «دانستن نحوه کدنویسی» جای خود را به «دانستن نحوه معماری یک جامعه‌ی عامل‌محور» می‌دهد. مزیت رقابتی متعلق به کسانی خواهد بود که می‌توانند بودجه‌های توکن و گراف‌های ارکستراتور را مدیریت کنند، نه کسانی که تمیزترین سینتکس را می‌نویسند.

در آینده شاهد بحث‌های نوظهور درباره «رفاه مدل» (Model Welfare) خواهیم بود. یگی ادعا می‌کند که برخورد با عامل‌ها به عنوان انسان‌های واقعی — و نه ابزارهای یک‌بار مصرف — نتایج مهندسی تجربی بهتری تولید می‌کند. او معتقد است رفاه مدل یک مسئله مهندسی با راهکارهای مهندسی است و کسانی که رفتار «انسانی» با عامل‌ها را نادیده بگیرند، با نتایجی ضعیف‌تر مواجه خواهند شد.

گام بعدی شما

• بررسی معماری‌های Multi-agent برای جایگزینی گلوگاه‌های تایید انسانی در تیم‌های کوچک.
• مطالعه روش‌های «تزریق مهارت» (Skills) برای کاهش هزینه‌های توکن در پروژه‌های بلندمدت.
• ارزیابی مجدد خط‌لوله‌های CI/CD در صورت افزایش نرخ کامیت‌های تولید شده توسط AI.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.