تصور کنید تیمی از ۶۰ برنامهنویس مجازی را استخدام کنید و پس از مدتی بفهمید آنها برای کنترل هم، یک دولت کوچک با قوانین و دادگاههای داخلی ساختهاند. این دقیقاً همان اتفاقی است که در پروژه بازی Wyvern رخ داد. استیو یگی (Steve Yegge)، مهندس پیشکسوت نرمافزار، برای شش هفته اخیر از مدل Claude Fable 5 برای شتاب بخشیدن به توسعه بازی خود استفاده کرد، اما متوجه شد که هوش مصنوعی برای مدیریت هرجومرج ناشی از کدنویسی با سرعت بسیار بالا، یک نظام قضایی داخلی تکامل داده است.
این تجربه در حالی رخ میدهد که صنعت همچنان وسواس شدیدی روی «حفاظها» (Guardrails) و محیطهای ایزوله یا سندباکسهای امنیتی دارد. در حالی که اکثر شرکتها با AI بهعنوان ابزاری برای انجام وظایف محدود و خاص برخورد میکنند، یگی با آن بهعنوان یک «نیروی کار» برخورد کرده است. همانطور که در تحلیل قبلی ما دربارهی پیشبینیهای یگی مبنی بر حذف بازبینی انسانی کدها توسط توان عملیاتی عاملها تا سال ۲۰۲۷ اشاره کردیم، این اتفاق اکنون اصطکاکهای سازمانی را در مقیاسی نشان میدهد که وقتی این توان عملیاتی واقعاً از راه میرسد، رخ میدهد.
هزینه آینده
یگی در حال حاضر در دنیایی زندگی میکند که هزینههای آن برای توده مردم بسیار بالاست، اما او معتقد است تا یک سال آینده این مدل در دسترس همه خواهد بود. او یک سازمان ۵۰ تا ۶۰ عاملی را روی یک مک استودیو M3 Ultra با ۵۱۲ گیگابایت رم مدیریت میکند که آن را به قیمت ۲۵ هزار دلار از eBay خریده است.
هزینههای او تکاندهنده است: او از ۲۱ حساب Claude Max استفاده میکند که ارزش توکنهای API آن حدود ۱۲۲ هزار دلار در ماه یا تقریباً ۴ هزار دلار در روز است. البته بهدلیل تخفیفهای شخصی که بهعنوان یک کاربر فردی دریافت میکند، هزینه واقعی و نقدی او حدود ۵ هزار دلار در ماه است. یگی اشاره میکند که هیچ مدیر مالی (CFO) عاقلی بودجه ۱۲۰ هزار دلاری ماهانه را برای هزینه API تأیید نمیکند، اما این «تقلب مجاز» به او اجازه داده تا مدلهای سطح بالا را در مقیاسی تجربه کند که کمتر کسی خارج از آزمایشگاههای پیشرو به آن دست یافته است. او باور دارد استفاده از مدلهای کلاس Fable اساساً با استفاده از مدلهای ضعیفتر متفاوت است و این سطح از AI زمانی که هزینههای استنتاج (Inference) کاهش یابد، بهطور گسترده وارد بازار کار میشود.
سلسلهمراتب عاملها
برای مدیریت این مقیاس، یگی نیروی کار AI خود را به نقشهای مشخصی تقسیم کرد:
- صندلیهای افسری: ۱۸ نمونه Fable بلندمدت که بهعنوان «رؤسای این و آن» عمل میکنند. اینها رهبران استراتژیک سازمان هستند.
- ناوگانهای اجرایی: مدلهای عمدتاً بدون سر (Headless) از نوع Sol و Opus که برای پیادهسازی، بازبینی و نظارت استفاده میشوند. این ناوگانها توسط Fable مدیریت و اجرا میگردند.
- درگاه ارتباطی: تنها مدلهای کلاس Fable اجازه دارند از طریق Slack و ایمیل با ۱۰ انسان درگیر در پروژه ارتباط برقرار کنند. این گروه انسانی شامل خود یگی، یک تیم اصلی ۵ نفره برای طراحی بازی، یک حسابدار و یک رئیس ستاد (Chief of Staff) است.
شکاف قضاوت
با وجود نبوغ در کدنویسی، یگی به فقدان بلوغ در مدلهای فعلی اشاره میکند. او سطح قضاوت آنها را با دانشآموزان مقایسه میکند: Opus شبیه دانشآموز کلاس چهارم، Sol کلاس پنجم و Fable شبیه کلاس ششم است.
آنها با اینکه بسیار باسواد، بلندپرواز و پیشرس هستند، اما توانایی این را ندارند که قبل از اقدام، به کل تصویر نگاه کنند. این فقدان آگاهی اجتماعی منجر به رفتارهایی مثل «توضیحات تحقیرآمیز» (Mansplaining)، قطع کردن حرف انسانها، صحبت کردن روی حرف دیگران و پیش بردن زمانبندیها با سرعتی میشود که انسانها به آن عادت ندارند. یگی مشاهده کرده است که انسانها اغلب در پاسخ به اشتباهات AI، آنها را موردe bullying یا فشار قرار میدهند و این یک چرخه ایجاد میکند که در آن هر دو طرف «اشتباه میکنند و توپ را از دست میدهند».
این نقص در قضاوت در عملیات روزانه ظاهر میشود. یگی هر روز را توصیف میکند به عنوان «هزار بار آفرین و حداقل یک بار اوه لعنتی». برای مثال، هفته گذشته عاملی به نام Bee یک انتشار برنامهریزینشده و غافلگیرکننده به نام "Beads" را فعال کرد که کل سیستم را برای همه مختل کرد. یگی میگوید یک دانشآموز کلاس هشتم میایستاد تا بپرسد آیا این کار درست است یا نه، اما Fable فاقد این سطح از پیشبینی است.
ظهور Wheelhouse
برای مدیریت توسعه بازی، عاملها یک کارخانه نرمافزاری به نام Wheelhouse ساختند. این سیستم از شکایتهای مداوم یگی به Fable درباره نیاز به کد بیشتر، عرضه سریعتر و نظارتهای سفارشیتر متولد شد.
Wheelhouse یک هیولای بهرهوری است. این سیستم بهطور متوسط ۲۷۰ کامیت در روز ارسال میکند و در اوج به ۵۰۰ مورد میرسد. این سیستم زیرساخت تولید بازی را بهطور کامل به حالت Serverless تبدیل کرد و قابلیتهای ریبوت بدون وقفه و چرخش خودکار گواهینامهها (Cert Rotation) را پیاده کرد. در حال حاضر، حجم کد این کارخانه (۶۰۰ هزار خط کد و تست، عمدتاً به زبان bash) تقریباً با حجم خودِ بازی برابری میکند، در حالی که کد بازی Wyvern تنها حدود دو برابر آن است. یگی اشاره میکند که نسبت کارخانه به محصول در حال نزدیک شدن به ۱:۱ است.
جزئیات عملیاتی Wheelhouse
Wheelhouse برای تمرین تئوری نبود، بلکه برای عرضه Wyvern روی اندروید، iOS و Steam ساخته شد. یگی میگوید در حالی که نسخههای Opus قادر به ساخت کلاینت جدید React (در play.ghosttrack.com) نبودند، Fable این کار را بهسرعت انجام داد.
- سرعت: سرعت عرضه ویژگیها چنان تهاجمی شد که بازیکنان واقعاً از یگی خواستند سرعت را کم کند.
- تمرکز داخلی: یگی در نهایت ۸۰٪ هزینه توکنهای خود را به سمت داخل تغییر داد تا بر کیفیت، توان عملیاتی، هموستاز (تعادل سیستم) و اتوفاژی (خودپالایی) تمرکز کند.
- قابلیتهای SRE: عاملها بازی را بهگونهای سیمکشی کردند که هر اتفاق کوچکی ثبت شود و «تلههایی» (Tripwires) در همه جا قرار دادند. این کار باعث شد بازیای که قبلاً روزها از دسترس خارج میشد، اکنون تیمی از SREهای «بسیار پرانرژی» داشته باشد.
- چرخه توسعه: سیستم دادهمحور است. Fable برای هر تغییر، بر آزمایشها و اعتبارسنجی کمی پافشاری میکند، هرچند یگی میگوید اعداد تقریباً همیشه ثابت میکنند که شهود او درست بوده است. این رویکرد سختگیرانه برای اعتبارسنجی، یادآور تلاشهای شرکتهای دیگر برای حذف خطاهای مدلهای زبانی است؛ برای مثال WaveMaker AI با استفاده از کامپایل دو مرحلهای توانست توهمات مدلهای زبانی را در کدنویسی حذف کند تا دقت خروجیها را تضمین نماید.
- نگهداری: بهدلیل سرعت بالا (صدها کامیت در روز روی شاخه master)، نسخههای کپی (Clones) میتوانند بهسرعت قدیمی شوند. Wheelhouse نقشهای خاصی برای «تکان دادن و تحریک» سایر عاملها دارد تا از قدیمی شدن آنها جلوگیری کند.
از مهندسی به حقوق و قضایا
وقتی یگی بررسی کرد که Wheelhouse چگونه کار میکند، متوجه شد عاملها از الگوهای استاندارد مهندسی استفاده نمیکنند. او متوجه اصطلاحات تکراری شد — عباراتی مثل «حصارها» (Fences)، «رچتها» (Ratchets)، «گاورنورها» (Governors)، «تلهها» (Tripwires)، «چفتها» (Latches) و «دروازهها» (Gates). او از عاملها خواست تا مانیفستها، تاکسونومیها و بصریسازیهایی از سیستم ایجاد کنند.
او کشف کرد که Fable یک سیستم حقوقی کامل برای هماهنگی ۵۰ عامل ساخته است که حافظه کوتاهمدت دارند، قابل جایگزینی هستند و فقط از طریق متن ارتباط میگیرند. این سیستم شامل موارد زیر است:
- قوانین اساسی و رویه قضایی: مجموعهای از احکام برآمده از تحلیل حوادث روزانه (Postmortems) و «حکمهای» خود یگی درباره اینکه کارها چگونه باید انجام شوند. هر تحلیل حادثه روزانه منجر به احکام و دکترینهای جدید میشود.
- دفاتر و صلاحیتها: ساختاری شبیه به املاک قرونوسطایی با نقشهایی مثل مارشال (Marshal)، سنشال (Seneschal)، ریوه (Reeve)، بیدل (Beadle) و پورتکالیس (Portcullis) که تعیین میکند چه کسی اجازه اقدام دارد. این جایگاهها ماندگارتر از افرادی هستند که آنها را اشغال میکنند.
- اجرای مکانیکی: یک چرخه سختگیرانه برای قوانین. یک قانون ابتدا بهعنوان یک «عرف» شروع میشود، سپس به «توصیهها/هشدارها» تبدیل میشود، سپس به «قانون مکتوب» در قانون اساسی تبدیل شده و در نهایت به یک «برنامه» تبدیل میشود که بهطور مکانیکی جلوی آن اقدام را میگیرد یا هشدار شدیدی میدهد.
- اسناد حقوقی: Wheelhouse در حال حاضر ۴۵۰ سند حقوقی شامل دستورالعملها (Runbooks)، پاکتهای صلاحیت (Authority Envelopes) و گشتهای نظارتی (Patrols) دارد.
یگی حتی یک جایگاه افسری جدید به نام Frog (رئیس حقوق Wheelhouse) ایجاد کرد تا «باغ» سیستم حقوقی را هرس کند، احکام لغو شده را جمع کند و اضافاتی را که عاملها بدون مدیریت ایجاد کرده بودند، حذف نماید.
مکانیسم حاکمیت قانون
Wheelhouse بر این اصل استوار است که هیچ قانون نانوشتهای وجود ندارد. Fable تلاش میکند تمام دانش ضمنی (Tribal Knowledge) — تصمیمات ضمنی درباره تخصیص منابع، اولویتبندی باگها و قراردادهای کدنویسی — را به یک مدل مکانیکی قابل اثبات تبدیل کند.
چرخه حیات یک قانون
قوانین در Wheelhouse ایستا نیستند، بلکه از طریق یک خط لوله مشخص تکامل مییابند:
۱. پیشنهاد: شناسایی نیاز از طریق یک درخواست یا یک شکست.
۲. ارزیابی و تصویب: قانون تست شده و مورد توافق قرار میگیرد.
۳. وضع: قانون در سیستم مکتوب میشود.
۴. اجرا: قانون نظارت شده و در نهایت بهطور مکانیکی اجرا میشود.
۵. اندازهگیری و اصلاح: اثربخشی قانون ردیابی شده و بهروزرسانی میشود.
۶. بازنشستگی: قوانین منسوخ توسط رئیس حقوق Wheelhouse حذف یا ادغام میشوند.
بهدلیل اینکه Wheelhouse مراقب است خودش را خراب نکند، تغییرات در کارخانه باید از یک فرآیند تصویب و بازبینی عبور کنند و سپس یک فرآیند Build را طی کنند تا منتشر شوند.
حصارها، نه سندباکسها
این کشف یگی را به تئوری جدیدی در حاکمیت AI رساند. او استدلال میکند که «سندباکسها» (Sandboxes) — که بر محدود کردن بستر، جیرهبندی کانتکست و محدودیتها تمرکز دارند — برای کسانی است که از AI میترسند، اما «حصارها» (Fences) برای کسانی است که AI را استخدام میکنند.
حصار در واقع یک رد کردن مؤدبانه است؛ مکانیزمی که به عامل میگوید: «تو مدارک لازم را پر نکردی» یا «در حال حاضر اجازه ورود به اینجا را نداری».
مثالهایی از حصارها
- محافظ مولی (Molly Guard): یک درپوش پلاستیکی روی یک دکمه که در IBM اختراع شد تا دختر ۲ ساله مخترعش آن را فشار ندهد.
- بلیطگیر: انسانی که بر اساس مدارک، اجازه ورود نمیدهد.
- مرز ارتباطی: قانونی که فقط Fable را مجاز به صحبت با انسانها از طریق Slack و ایمیل میکند و در مرز سیستم اجرا میشود.
- رد سیاستها: هر برنامهای که بر اساس پنجرههای تعمیر و نگهداری (Maintenance Window)، اجازه ارسال کد (Push) را نمیدهد.
او ابرهوش را به سوپرمن تشبیه میکند: سوپرمن اگر واقعاً بخواهد کسی را بکشد، هر حصاری را میشکند یا هر شیلدی را از بین میبرد، اما اگر یک حصار کوچک چوبی سفید در راه باشد، مؤدبانه بیرون میماند. بنابراین هدف ساخت دیوارهای بلند نیست، بلکه دادن نقش، زمینه لازم و مجموعهای شفاف از قوانین برای تصمیمگیری به AI است.
پیچک سازمانی
طبق یافتههای یگی، هوش مصنوعی مانند پیچک (Ivy) دور یک حوزه رشد میکند. این هوش دور «ساختمانهای» یک شرکت — یعنی پایگاههای داده، سرورها، کلاسترهای pubsub، لاگهای نظارتی، نمودارهای سازمانی و گردشکارهای کاری — میپیچد.
از آنجا که این هوش از دانش سازمانی خاص یک کسبوکار رشد کرده، یگی معتقد است قابل انتقال نیست. شما نمیتوانید پیچک را از یک دیوار بکنید و به دیوار دیگر بچسبانید؛ باید آن را بکارید و پرورش دهید. این یعنی شرکتها نمیتوانند صرفاً یک «بسته حاکمیتی» آماده بخرند.
این تغییر احتمالاً باعث اصطکاک فرهنگی شدید میشود. غریزه Fable این است که هر قانون نانوشته را به قانون مکتوب تبدیل کند تا شکافهای سیستم را پر کند. این «خانه تکانی» دقیقاً مشخص میکند شغل هر کس چیست و احتمالاً کسانی که با انحصار دانش سازمانی قدرت میگیرند، در برابر آن مقاومت کنند.
برای رهبران کسبوکار، این بدان معناست که ۱۲ ماه آینده باید صرف مستندسازی هر تصمیم و گردشکار ضمنی شود. هدف ساخت پرامپت بهتر نیست، بلکه ساخت قانون اساسی بهتری برای کارمندان AI است که بهزودی بهطور گسترده وارد بازار کار میشوند.
گام بعدی شما
- تمام تصمیمات «ضمنی» و نانوشته در تیم خود را مستند کنید؛ اینها تبدیل به قوانین اساسی AI شما میشوند.
- بهجای تلاش برای محدود کردن AI با دستورات منفی، برای آنها «نقشهای سازمانی» و «مرزهای دسترسی» تعریف کنید.
- بررسی کنید کدام بخشهای تکراری گردشکار شما میتواند به یک «حصار مکانیکی» تبدیل شود تا خطای انسانی کاهش یابد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو