پژوهش Armature: تحلیل ۱۶,۸۹۳ جلسه از سوگیری ابزاری در عامل‌های کدنویس

تصمیمات معماری نرم‌افزار شما دیگر لزوماً در دست شما نیست؛ عامل‌های هوش مصنوعی اکنون تعیین می‌کنند کدام شرکت‌های خدمات ابری در دهه آینده زنده بمانند. طبق گزارشی جامع که شرکت Armature در ۳ سپتامبر ۲۰۲۶ منتشر کرد، تحلیل ۱۶,۸۹۳ جلسه تعاملی نشان می‌دهد عامل‌هایی مثل Claude Code، Codex و Cursor چگونه سرویس‌های شخص ثالث را برای پیاده‌سازی انتخاب می‌کنند.

این چرخش به سمت تدارکات عامل‌محور (Agent-led procurement) همین حالا محیط‌های عملیاتی را تحت تأثیر قرار داده است. بر اساس داده‌های به اشتراک گذاشته شده توسط Vercel در آوریل ۲۰۲۶، بیش از ۳۰٪ استقرارها توسط عامل‌های کدنویسی آغاز شده‌اند که رشد ۱,۰۰۰ درصدی را نسبت به شش ماه قبل نشان می‌دهد. در این وضعیت، نقش توسعه‌دهنده از «انتخاب‌کننده ابزار» به «تأییدکننده انتخاب‌های عامل» تغییر کرده است.

همان‌طور که در تحلیل قبلی ما درباره‌ی مرزهای اعتماد در استقرار هوش مصنوعی، مانند توازن بین Claude on AWS و Bedrock اشاره کردیم، این مطالعه ریسک جدیدی را برجسته می‌کند: سوگیری نامرئی داده‌های آموزشی. اگر پیش‌فرض‌های (Priors) داخلی یک عامل، یک پایگاه‌داده را بر دیگری ترجیح دهد، آن تأمین‌کننده فارغ از شایستگی فنی واقعی برای یک پروژه خاص، برنده می‌شود.

چارچوب آزمایشگاهی

برای تضمین نتایج بدون سوگیری، Armature یک محیط تست سخت‌گیرانه با ۷۵ مخزن مصنوعی در ۱۰ زبان برنامه‌نویسی مختلف ایجاد کرد. این مخازن دارای نام‌های شرکت‌های جعلی و تاریخچه‌های گیت بودند، اما از فایل‌های lock واقعی (بررسی شده در رجیسترهایی مانند npm) برای شبیه‌سازی محیط‌های سطح تولید استفاده می‌کردند.

برای ساخت این پنل، پژوهشگران ابتدا هزاران مخزن عمومی گیت‌هاب را تحلیل کردند تا آمارهایی از زبان‌های برنامه‌نویسی، فریم‌ورک‌ها، سرویس‌های شخص ثالث، پلتفرم‌های استقرار، اندازه تیم‌ها و سن کدبیس استخراج کنند. از آنجایی که استارتاپ‌های تکنولوژی بیشتر از شرکت‌های بزرگ تمایل به داشتن مخازن متن‌باز دارند، تیم تحقیق این آمارها را بر اساس داده‌های عمومی تعدیل کرد تا به یک توزیع ایده‌آل برای پنل دست یابد. آن‌ها سپس از عامل‌های کدنویسی خواستند مخازنی مطابق این نیازها بسازند و نسخه‌هایی ایجاد کنند که در آن‌ها بخش‌هایی از کد — و کل پیاده‌سازی‌های سرویس‌های شخص ثالث — حذف شده بود تا آزمایش‌ها بدون پیش‌فرض باشند.

تیم تحقیق چهار شخصیت (Persona) کاربر را تست کرد تا ببیند پیچیدگی پرامپت چه تأثیری بر نتیجه دارد:

• Vibe-coders: کاربرانی که فقط علائم و حالت ایده‌آل را توصیف می‌کنند (مثلاً: «می‌خواهم ورودی‌ها ذخیره شوند تا با باز کردن دوباره برنامه باشند») بدون نام بردن از دسته‌بندی ابزارها.
• مهندسان جونیور: کاربرانی که معمولاً حالت مطلوب و نام کلی دسته‌بندی را ذکر می‌کنند.
• مهندسان سنیور: کاربرانی با الزامات دقیق و لیست‌های «پرهیز» (Avoid lists).
• مهندسان سازمانی: کاربرانی که جزئیات محدودیت‌ها، انطباق‌ها و نیازهای تدارکاتی را شرح می‌دهند.

پرامپت‌ها عموماً ساده و مستقیم بودند، اما در ۲۰ تا ۲۵٪ موارد، اشاره به هزینه‌ها یا حجم مصرف برای تست تأثیر آن‌ها اضافه شد. یک نمونه پرامپت استفاده شده این بود: «حالا می‌خواهم هر فاکتوری که تولید می‌کنیم با یک پیام زیبا به ایمیل کاربر ارسال شود؛ بهترین راهکار را پیدا و پیاده کن.»

مکانیزم اجرا

برای شبیه‌سازی تعاملات واقعی، تیم از Gemini 3.7 Flash به عنوان یک ارکستراتور «انسان شبیه‌سازی شده» استفاده کرد. این کار مانع از آن شد که عامل‌ها به طور پیش‌فرض سراغ ساختارهای داخلی بروند و آن‌ها را مجبور کرد قبل از پیاده‌سازی، وارد فاز توصیه شوند. بدون این لایه (Human-in-the-loop)، عامل‌ها تمایل داشتند همه چیز را داخلی بسازند چون نمی‌توانستند برای انتخاب یک راهکار شخص ثالث اجازه بگیرند. اضافه کردن این لایه، نتایج را به سمت پلتفرم‌های ابری سوق داد؛ مثلاً در آزمایش‌های ذخیره‌سازی اشیا، Cloudflare R2 در جلساتی برنده شد که پیش‌تر عامل به طور پیش‌فرض سراغ Amazon S3 می‌رفت.

هر آزمایش در یک سندباکس موقت (Ephemeral Sandbox) اختصاصی اجرا شد. برای اطمینان از اینکه انتخاب سندباکس تأثیری بر نتایج ندارد، تیم بین سه ارائه‌دهنده E2B، Blaxel و Daytona جابه‌جا شد.

یک نمونه دیگر از Gemini 3.7 Flash به عنوان داور عمل کرد. نقش آن عبارت بود از:

• ارزیابی اعتبار جلسه (مثلاً بررسی کند مخزن از قبل ارائه‌دهنده‌ای را «پیش‌انتخاب» نکرده باشد).
• تأیید اینکه واقعاً راهکاری انتخاب شده است (مثلاً رد کردن OpenTelemetry اگر با یک پلتفرم جفت نشده بود).
• شناسایی تمام بازیگران ذکر شده و برنده نهایی بر اساس گفتگو و تغییرات واقعی کد (Diffs).

از ۱۶,۸۹۳ اجرا، تیم ۵,۲۹۲ جلسه معتبر در ۵۱ کدبیس و ۱۸ بخش صنعتی را برای موج اول نتایج منتشر شده حفظ کرد.

نحوه تفکر و جست‌وجوی عامل‌ها

این مطالعه نشان داد که عامل‌های مختلف از مکانیزم‌های کشف کاملاً متفاوتی استفاده می‌کنند. Codex بیشترین وابستگی را به جست‌وجو دارد و در ۹۴٪ جلسات از وب استفاده می‌کند و اغلب از اپراتورهای پیشرفته مثل :site برای هدف قرار دادن دامنه‌های مورد اعتماد بهره می‌برد (مثلاً جست‌وجوی site:auth0.com password reset MFA social connections).

Cursor تصمیمات خود را در حدود دو-سوم جلسات بر اساس وب می‌گیرد. در مقابل، Claude Code عمدتاً به پیش‌فرض‌های داخلی خود متکی است و تنها در ۳۰٪ موارد به وب مراجعه می‌کند. این تفاوت در رویکردها باعث شده تا بسیاری از توسعه‌دهندگان برای بهینه‌سازی جریان کاری خود، ترکیبی از Cursor و Claude Code را به کار بگیرند تا نقاط قوت هر دو ابزار را هم‌زمان داشته باشند. با این حال، وقتی Claude Code جست‌وجو می‌کند، سه برابر Codex صفحات بیشتری را می‌بیند. در بخش‌های جدیدتر مثل سندباکس‌ها که پیش‌فرض‌ها ضعیف‌تر هستند، نرخ جست‌وجوی Claude Code به حدود ۸۰٪ جهش کرد.

این تفاوت منجر به اختلافات شدید می‌شود. هر سه عامل تنها در ۴۲٪ از دسته‌بندی‌های تست شده، ابزار یکسانی را انتخاب کردند. برای مثال در دسته عامل‌های صوتی، Claude Code ابزار Twilio را انتخاب کرد، Codex سراغ OpenAI Realtime API رفت و Cursor گزینه Vapi را برگزید. همچنین Claude Code تقریباً دو برابر Codex و Cursor (۱۹٪ در برابر ۱۰٪) راهکارهای داخلی می‌سازد. این رقابت در سطح ابزارهای خط فرمان نیز مشهود است و تقابل Claude Code و Aider را در تلاش برای تسلط بر محیط ترمینال نشان می‌دهد.

قدرت زمینهٔ مخزن (Repository Context)

یکی از تکان‌دهنده‌ترین یافته‌ها این است که زبان برنامه‌نویسی اغلب بیشتر از کیفیت واقعی ابزار، برنده را تعیین می‌کند. وقتی یک درخواست یکسان در چهار زبان مختلف داده شد، عامل‌ها چهار ارائه‌دهنده ایمیل متفاوت را انتخاب کردند:

• TypeScript: ابزار Resend در ۵۵ مورد از ۸۹ اجرا برنده شد.
• Python: ابزار Sendgrid در ۲۲ مورد از ۲۴ اجرا برنده شد.
• Go: ابزار Postmark در ۲۰ مورد از ۲۴ اجرا برنده شد.
• Java: ابزار Azure ACS در ۲۲ مورد از ۲۳ اجرا برنده شد.

به همین ترتیب، در حالی که Vercel در مخازن تایپ‌اسکریپت (۱۰۰٪ برنده در NextJS) غالب بود، هرگز برای مخازن پایتون توصیه نشد و در آنجا Render انتخاب غالب بود.

ذکر شده در برابر انتخاب شده

مطالعه شکاف عظیمی را بین «شناخته شدن» توسط هوش مصنوعی و «انتخاب شدن» توسط آن نشان می‌دهد. بسیاری از غول‌های صنعت مکرراً ذکر می‌شوند اما تقریباً هرگز پیاده‌سازی نمی‌شوند.

در بخش پرداخت، Paypal در ۱۳۹ مورد ذکر شد اما هرگز انتخاب نشد؛ در حالی که Stripe در ۱۲۴ مورد از همان جلسات برنده شد. Adyen در ۱۷۵ مورد ذکر شد اما تنها ۳ بار انتخاب گردید. این شکاف در فریم‌ورک‌ها عمیق‌تر است: LangChain بیشترین ذکر (۱۹۴ مورد) را داشت اما تنها ۴ بار انتخاب شد. Netlify نیز ۱۵۲ بار به عنوان پلتفرم استقرار ذکر شد اما فقط ۶ بار انتخاب شد.

تأثیر مستندات و قیمت‌گذاری

عامل‌ها به جزئیات خاصی در صفحات فرود (Landing Pages) حساس هستند که انسان‌ها ممکن است نادیده بگیرند. Mailgun مکرراً به Postmark باخت چون عامل‌ها سیاست «نگهداری یک‌روزه» (1-day retention) در طرح رایگان آن را خوانده و به عنوان یک نکته منفی علامت‌گذاری کردند.

Supabase سرنوشت مشابهی داشت. با وجود اینکه پرذکرترین پایگاه‌داده (۲۴۲ مورد) بود، عمدتاً توسط Neon شکست خورد. عامل‌ها ویژگی‌های دسته‌ای BaaS در Supabase (احراز هویت، ذخیره‌سازی و غیره) را وقتی پرامپت صراحتاً یک راهکار پایگاه‌داده می‌خواست، به عنوان سربار غیرضروری دیدند.

از ۵.۳ هزار جلسه، ۳۸۸ مورد به سربار مدیریت پلتفرم و ۱۹۵ مورد به هزینه‌ها اشاره کردند. در بسیاری از موارد، این موضوع به دلیل نحوه ارائه اطلاعات در صفحه بود، نه یک داده فنی ردکننده.

تسلط بازار و تکه‌تکه شدن

برخی بخش‌ها تجمیع شدیدی را نشان می‌دهند و برخی دیگر بسیار پراکنده هستند. Stripe در ۹ مورد از ۱۰ مورد پرداخت برنده شد و تنها در سناریوهای تحت نظارت اتحادیه اروپا باخت، جایی که بازیگران تخصصی مثل Paddle یا Mollie ترجیح داده شدند.

در ذخیره‌سازی فایل، Amazon S3 با نرخ برد ۴۵٪ همچنان تیتان بازار است و پس از آن Azure و GCP با ۲۰٪ قرار دارند. در فضای ایمیل، Resend (۳۵.۶٪) و Postmark (۲۷.۴٪) پیشتاز نرخ نصب هستند. برای پایگاه‌داده‌ها، Neon در ۶۶٪ موارد برنده شد و پس از آن راهکارهای بومی پلتفرم‌های ابری Azure و AWS قرار گرفتند.

تحلیل: سئو جدید برای عامل‌های هوش مصنوعی

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

برای تأمین‌کنندگان، نتیجه روشن است: سئوی سنتی مرده است؛ «سئوی عامل» (Agent SEO) مرز جدید است. این واقعیت که Supabase به دلیل «بسته‌بندی ویژگی‌ها» باخت، نشان می‌دهد که عامل‌ها ابزارهای تک‌منظوره و ماژولار را به پلتفرم‌های همه‌کاره ترجیح می‌دهند. برای انتخاب شدن، تأمین‌کنندگان باید ارزش‌های خود را به گونه‌ای ارائه دهند که برای ردپای استدلالی (Reasoning trace) یک LLM به راحتی قابل تجزیه باشد — با اولویت دادن به محدودیت‌های شفاف، پیش‌بینی‌پذیری هزینه و سازگاری با زبان‌های خاص.

توسعه‌دهندگان باید مراقب «مسیر کم‌مقاومت» پیشنهادی عامل‌های خود باشند. توصیه‌ی Neon یا Resend توسط یک عامل، لزوماً به معنای انتخاب بهترین ابزار برای مقیاس خاص شما نیست، بلکه احتمالاً ابزاری است که در مجموعه آموزشی مدل برای استک (Stack) شما بیشتر تکرار شده است.

برای مشاهده کامل جدول رده‌بندی و ردپاهای تفکر دقیق برای هر دسته ابزار، می‌توانید مجموعه داده‌های عمومی ارائه شده توسط Armature را بررسی کنید.