در هفته گذشته بحثی سالم درباره فلسفه و روانشناسیای که پشت دیدگاه بخش قابلتوجهی از جامعه هوش مصنوعی — بهویژه آنهایی که وسواس سناریوهای آخرالزمانی دارند — شکل گرفته است. در نهایت، استدلال کردن با فلسفهای دشوار است که وزن اخلاقی برابری برای همه موجودات قائل میشود؛ نه فقط انسانها و موجودات غیرانسانی امروز، بلکه هر موجودی که ممکن است در آینده پدید بیاید. چنین نگاهی ترازو را به شکلی پوچ به سمت «ایمنیگرایی» میچرخاند، جایی که نوآوری غیرممکن و آزادی تحملناپذیر میشود.
بدتر اینکه این نگاه به روانشناسی دین گره میخورد؛ جایی که مخالفت تحمل نمیشود و زیر سؤال بردن پیشفرض، ارتداد است. پس من هم یک مرتد هستم: پیشفرض را رد میکنم و به جایش بر تردید درباره تواناییمان در پیشبینی آینده و ایمان به این که بشر مسیر را در ادامه پیدا میکند تکیه میکنم. اگر همین نگاه به هولناکترین سناریوی آخرالزمانی برسد، حرف ایالت نیوهمپشایر بهترین پاسخ است: یا آزاد زندگی کن، یا بمیر.
موضوع این است: «نوعدوستی اثربخش» (Effective Altruism) و میزان درهمآمیختگیاش با آنتروپیک و پافشاری داریو آمودئی، مدیرعامل آن، بر اینکه «ما باید مرز را همگام کنیم». من جزئیات مخالفتهای فلسفیام را در دو قسمت آخر پادکست Sharp Tech باز کردهام، اما استراتچری سایتی درباره استراتژی و فناوری است و این زاویه هم دقیقاً به همان اندازه بررسیشدنی است.
سه ماه پیش در یادداشت «ابرقدرت ایمنی آنتروپیک» توضیح دادم که باور صادقانه این شرکت به لفاظیهای ایمنیاش، بهشکلی راحت به آن مجوز میداد اهداف فوقالعادهای را دنبال کند که با منافع تجاریاش همسو بود: تلاشهای تهاجمی برای واسطهزدایی از نرمافزار، جمعآوری دادههای مقدس مشتریان و خرابکاری پنهانی در حق رقبایی که میتوانستند رقیب شوند. تحلیل امروز در همان مسیر است، اما از جهت مخالف: «همگام کردن مرز» با نگرانی درباره ایمنی چارچوببندی میشود — و من باور دارم که همین انگیزه پشتش است — اما تصادفاً چند مشکل جداگانه آزمایشگاههای پیشرو را هم حل میکند. این مشکلات شکل «سرریزهایی» را دارند که بهخاطر سرعت بالای بهبود مدلها شکل گرفتهاند؛ کند کردن بهبود مدل، این سرریزها را کاهش میدهد.
سرریز توانمندی
شش ماه پیش در یادداشت «عاملها به جای حبابها» استدلال کردم که پارادایم عاملمحور — که با انتشار Opus 4.5 در اواخر نوامبر ۲۰۲۵ شروع شد — آنقدر توانمند و آنقدر «تشنگی توکن» دارد که ما در یک حباب زیرساختی نیستیم: واقعاً به تمام آن محاسباتی که ساخته میشود نیاز داریم.
من به اقتضای شغلم درباره چیزهایی مینویسم که لزوماً شخصاً تجربهشان نمیکنم؛ نمونه کلاسیکش سالها تحلیل و طرفداری از تبلیغات بهعنوان مدل کسبوکار است، درحالیکه خودم کسبوکار مبتنی بر اشتراک دارم. این را میگویم چون این دیدگاه درباره هوش مصنوعی عاملمحور را قبل از آن ساختم که خودم غرق کدنویسی عاملی شوم؛ و چه خوب شد: آنقدر مسحور امکان ساخت نرمافزار برای خودم شدم که در چند ماه گذشته چند پروژه جدید شروع کردم و حتی چندتایشان را به پایان رساندم. هیجانانگیز است و امکانات بیپایان بهنظر میرسد. لازم نیست بگویم که بیش از همیشه به این باور دارم.
همزمان، یک بخش از آن یادداشت است که دربارهاش تردید کردهام: اهمیت «مهار» (harness) شرکتهای مدل. در آنجا نوشتم چیزی که Opus 4.5 را متقاعدکننده کرد نه خود رویداد انتشار مدل بود، بلکه تغییرات در مهار Claude Code بود که آن را ناگهان بسیار کاربردیتر کرد. معنایش این است که عملکرد مدل تنها چیز مهم نیست: تلفیق مدل و مهار جایی است که تفاوت واقعی میان عاملها پیدا میشود.
این موضوع برای فهم ساختار آینده صنعت هوش مصنوعی و جریان سود بسیار پراهمیت است، چون سود از بخشهای ماژولار زنجیره ارزش — که کالایی میشوند — بیرون میرود و به بخشهای تلفیقشده زنجیره ارزش میرسد که متمایزند. نتیجه منطقی این است که اگر عاملها نیازمند تلفیق مدل و مهار باشند، شرکتهایی که همین تلفیق را میسازند — مشخصاً آنتروپیک و OpenAI — واقعاً میتوانند بهشکلی معنادار سودآورتر از آن چیزی باشند که حتی اواخر سال گذشته بهنظر میرسید. به همین ترتیب، شرکتهایی که روی کالایی شدن مدل شرط بستهاند ممکن است در ارائه محصولات رقابتی به مشکل بخورند.
یکی از پروژههایی که در یک ماه گذشته شروع کردم — دستکم در یکی از حالتهایش — ساختن مهار خودم بود، و شدنی است! البته بسیار هم دشوار است، دستکم با سطح توانمندی من. با این حال، مثال همیشگی من در آن یادداشت درباره میزان اهمیت تلفیق مدل و مهار، مایکروسافت بود که محصول سازمانی جدیدش E7 را حول Claude Cowork ساخت، اما ساتیا نادلا، مدیرعامل مایکروسافت، در مصاحبهای با استراتچری خبر داد که این وضعیت موقتی است: «ما همان مهار GitHub را در بخش امنیت هم استفاده میکنیم. یعنی یک مهار چندمدلی داریم که بین مدلها میچرخیم — بدیهی است MAI بهصورت پیشفرض با مهار ما آموزش میبیند، اما GPT و Anthropic و هر مدل وزنباز را هم در آن خواهیم داشت. اجازه میدهیم هر کسی هر مدلی را که خودش فاینتیون کرده یا ساخته بیاورد. در واقع میتواند یک مدل وزنباز از Fireworks را بردارد، فاینتیون کند و در Copilot بگذارد؛ بی هیچ مشکلی.»
کمی طول کشید تا ادعاهای نادلا در محصول عرضهشده دیده شود، اما مطمئناً امروز میتوانید برای Copilot Cowork مدل انتخاب کنید؛ اینکه مهار مایکروسافت چقدر با مهار کلاد رقابتی است را کاربران نهایی تعیین میکنند، اما روشن است که مهار و مدل میتوانند دو چیز متفاوت باشند.
این اتفاق مهمتر از آن است که بهنظر میرسد و به نظریه تلفیق و ماژولاریتی زندهیاد کلیتون کریستنسن در کتاب The Innovator's Solution برمیگردد. او میگوید وقتی شکاف عملکردی وجود دارد — یعنی کارکرد و قابلیت اطمینان محصول هنوز برای نیازهای مشتریان یک لایه از بازار کافی نیست — شرکتها باید با ساخت بهترین محصول ممکن رقابت کنند. در این مسابقه، شرکتهایی که محصولاتشان را حول معماریهای اختصاصی و درهمتنیده میسازند مزیت رقابتی مهمی نسبت به رقبای دارای معماری ماژولار دارند، چون استانداردسازی ذاتی در ماژولاریتی درجه آزادی طراحی را از مهندسان میگیرد و آنها نمیتوانند عملکرد را بهینه کنند. اما وقتی نیازهای کارکردی و قابلیت اطمینان برآورده شد، مشتریان تعریف «بهاندازه کافی خوب نبودن» را بازتعریف میکنند: چیزی که دیگر کافی نیست این است که آنچه میخواهند را دقیقاً در زمان نیاز و به راحتی به دست نیاورند. در این نقطه مشتریان حاضرند برای عملکرد بهتر در مسیر جدید نوآوری — سرعت، راحتی و سفارشیسازی — پول بیشتری بدهند و پایه رقابت در آن لایه از بازار تغییر میکند.
فشار رقابت در این مسیر جدید، تحول تدریجی معماری محصول را تحمیل میکند: حرکت از معماریهای اختصاصی و درهمتنیده که در دوره «بهاندازه کافی خوب نبودن» برنده بودند، به سمت طراحیهای ماژولار در دوره «مازاد عملکرد». معماری ماژولار به شرکتها کمک میکند در ابعادی رقابت کنند که در بخشهای پایینراست نمودار اختلال اهمیت دارند. شرکتها میتوانند محصول جدید را سریعتر عرضه کنند چون میتوانند زیرسیستمهای جداگانه را بدون بازطراحی همهچیز ارتقا دهند. هرچند رابطهای استاندارد ناگزیر عملکرد سیستم را کمی فدا میکنند، شرکتها در برابر این گروه از مشتریان فضای مانور دارند که بخشی از عملکرد را معامله کنند، چون کارکرد محصول بیشتر از کافی است.
یکی از مثالهای همیشگی من در یادداشت «ابرقدرت ایمنی آنتروپیک» تصمیم این شرکت برای وابسته کردن استفاده از Fable به همین بود که آنتروپیک دادههای مشتریان را دستکم یک ماه نگه میدارد. آن تصمیم مهم بود و من همان موقع استدلال کردم آنتروپیک دارد شرط میبندد که مدلهایش آنقدر خوباند که سازمانها را قانع کنند از «نگهداری صفر داده» دست بکشند. همانجا نوشتم: «تصمیم آنتروپیک به این معناست که نگهنداشتن داده دیگر یک گزینه نیست، دستکم اگر خواهان دسترسی به بهترین مدلهایشان باشید. بله، امروز این نگهداری فقط برای اهداف ایمنی است نه آموزش؛ اما باورپذیر است که برتری آنتروپیک آنقدر بزرگ شود که بیسروصدا اعلام کنند داده را برای آموزش هم به کار میبرند و شرکتها حس کنند چارهای ندارند. آن داده آموزشی اضافه، بهطبع فاصله آنتروپیک را بیشتر میکند و همهاش با این توجیه موجه میشود که آنتروپیک پیشاپیش تصمیم گرفته تنها نهادی است که میتوان به آن اعتماد کرد.»
واقعیت این است که Fable بهاندازه کافی خوب نبود: مشتریان فشار آوردند، استفاده از Fable نسبتاً پایین ماند و وقتی Fable 5.1 منتشر شد، شرط «آنتروپیک دادههایت را نگه میدارد» حذف شده بود. این شاهدِ عملی نظریه کریستنسن است: مشتریان ثابت کردند حاضرند تصمیم انتخاب مدل را بر چیزی جز عملکرد محض بنا کنند؛ یعنی بر سیاستهای نگهداری داده.
این بهخودیخود نشان نمیدهد قابلیتهای جدید مدلها مطلوب نیستند؛ اما نشان میدهد قابلیتهای فعلی مدلها برای مشتریان «بهاندازه کافی خوب» است و به همین دلیل حاضر نیستند هر کاری برای دسترسی به لبه پیشرو انجام دهند. همین، ارزش آن لبه را برای صاحبانش کم میکند و به استراتژی مایکروسافت و دیگرانی که روی جدا کردن مهار از مدل تمرکز کردهاند اعتبار میدهد. توانمندی محض دیگر مستقیم به یک خندق رقابتی تبدیل نمیشود.
سرریز محصول
ماژولار شدن مدل و مهار توضیح میدهد چرا آزمایشگاههای پیشرو آن چیزی را دارند که من «ضرورت اقتصادی مالکیت نقاط تماس کاربر نهایی» نامیدم. در یادداشت «ابرقدرت ایمنی آنتروپیک» نوشتم: «مدتها برای من روشن بوده که آزمایشگاههای پیشرو ضرورت اقتصادی دارند به کاربر نزدیکتر شوند. اگر صاحب نقطه تماس کاربر باشید، قفلشدگی معناداری دارید و بهترین راه مالکیت آن نقطه تماس این است که بومِ همه کارهای لازم کاربر باشید. به همین دلیل، آزمایشگاههای پیشرو در مسیر تصادم با شرکتهای نرمافزاریاند: این نرمافزار است که نقطه تماس کاربر را در اختیار دارد و منافع بلندمدت آزمایشگاهها این است که نه صرفاً یک ورودی کالایی در نرمافزار، بلکه جایگزین خود نرمافزار شوند.»
کلید ماجرا برای آزمایشگاههای پیشرو این است که این نقاط تماس را در زمانی بسازند که توانمندی برتری دارند. اینجاست که عرضه اخیر Muse از سوی متا یک سیگنال نزولی است. Muse با فاصله معنادار بهترین و قابلمراجعهترین محصول «عامل شخصی» است که من امتحان کردهام. متا برای کار محصولی که انجام داده اعتبار زیادی میطلبد، همانطور که برای تعهد عظیم زیرساختیاش در اختیار گذاشتن یک ماشین مجازی بسیار توانمند بهصورت رایگان. و البته اعتبار برای مدل Muse Spark که زیربنای Muse است.
با این حال، Muse Spark 1.3 بهعنوان پیشرفتهترین مدل متا هنوز در سطح SOTA نیست و دقیقاً همین سیگنال نزولی است: این مدل برای یک محصول عامل شخصی بسیار خوب «بهاندازه کافی خوب» است و نکته کلیدی این است که یک عامل شخصی بسیار چسبندهتر از یک چتبات است. وقتی همه اطلاعاتت را در یک عامل شخصی ریختهای و عملاً آن را وارد زندگی روزمرهات کردهای، تغییر دادنش به چیز دیگری بهمراتب دشوارتر است. این درست برعکس Codex/ChatGPT و Claude Code است: بله، ممکن است مجموعهای از مهارتها و درکی از نحوه کار هر مهار ساخته باشی، اما در نهایت artifactهای مهم — یعنی کد تو — روی GitHub هستند و اگر جایگزین بهتر یا ارزانتری باشد (یا نخواهد دادههایت را نگه دارد)، اشاره دادن یک عامل و مهار دیگر به همان artifactها زحمت چندانی ندارد.