مع تولي وكلاء البرمجة أجزاء متزايدة من رحلة التطوير، يبرز جانب واحد يعتمد فيه الجميع، من المبرمجين المبتدئين إلى كبار المهندسين، على هؤلاء الوكلاء: ألا وهو اختيار الخدمة المثلى لتلبية احتياجات محددة ضمن قاعدة تعليمات برمجية موجودة.
لنأخذ مثالاً على اختيار قاعدة البيانات:
- يقوم مبرمج حيوي بإنشاء تطبيق سفر شخصي، ويكتشف أن التطبيق يعيد تعيين البيانات مع كل اتصال. يسأل كلود كود: أريدك أن تقوم بتخزين ما أقوم بإدخاله في التطبيق في مكان ما بحيث يظل هناك في المرة القادمة عندما أعيد فتح التطبيق. يحلل كلود كود قاعدة التعليمات البرمجية ويجيب بعد 5 دقائق: أنت بحاجة إلى قاعدة بيانات وNeon مناسب تمامًا لأنه يحتوي على طبقة مجانية، وسهل التثبيت، ولن يؤدي إلى إيقاف تطبيقك مؤقتًا كما يفعل Supabase إذا كنت لا تستخدمه كثيرًا. يقبل المستخدم ويقوم الوكيل بالتثبيت. انتهى.
- أحد كبار المهندسين الذي يعمل في أحد تطبيقات الإنتاج يسأل Cursor: ما هو أفضل حل لقاعدة البيانات لهذا التطبيق؟ يجب أن يكون له تكاليف يمكن التنبؤ بها وأن تتم إدارته بالكامل. وبعد 5 دقائق، الاستنتاج هو نفسه، Neon هو التوصية مع أسباب واضحة لعدم ملاءمة المنافسين للاحتياج. يوافق المهندس والوكيل ينفذ.
هذه في الواقع تجربة قمنا بإجرائها. صندوقان للرمل، وكلاء مختلفون، قواعد تعليمات برمجية مختلفة، شخصيات ومطالبات مختلفة، والنتيجة نفسها. لذلك تساءلنا: إذا قمنا بتعميم الاختبار على فئات الأدوات الأخرى، مما يجعل السياق وقواعد التعليمات البرمجية والشخصيات تختلف بشكل أكبر، فهل ستتغير النتيجة؟
إنه سؤال مهم للمطورين الذين يحاولون معرفة ما إذا كان بإمكانهم الوثوق في حكم وكيلهم بشأن ما يناسب احتياجاتهم حقًا. ولكنه أكثر أهمية بالنسبة للبائعين الذين سيعتمد بقاؤهم قريبًا على اختيارهم من قبل وكلاء البرمجة. في أبريل الماضي، شارك Vercel قائلاً إن أكثر من 30% من عمليات النشر بدأت بواسطة وكلاء الترميز، بزيادة قدرها 1000% عما كانت عليه قبل ستة أشهر.
ولهذا السبب قررنا إجراء أكبر تجربة على الإطلاق لفهم كيفية تفكير وكلاء البرمجة في الأدوات، وكيف يكتشفونها ويختارونها، وأيها سيفوز في كل فئة. لقد راقبنا ما يقرب من 17 ألف جلسة عبر أنواع مختلفة من الشخصيات (على سبيل المثال، المبرمجون النشطون، والمهندسون المبتدئون في الشركات الناشئة، وكبار المطورين في المؤسسات) مع 1,163 اختلافًا سريعًا، و75 مستودعًا، و3 وكلاء تشفير (Claude Code، وCodex، وCursor) ينفذون الحلول فعليًا بدلاً من مجرد التوصية بأحدها.
اليوم نشارك كل شيء: النتائج المجمعة ولوحات المتصدرين لكل فئة، بالإضافة إلى كل ملاحظة وحتى الآثار الكاملة مع مطالبات المستخدم وتتبعات التفكير واختلافات التعليمات البرمجية الفعلية التي يطبقها الوكيل.
كيف قمنا بإجراء كل هذه التجارب بشكل ملموس؟
لوحة المستودعات لدينا
لقد بدأنا بإجراء تحليل على آلاف مستودعات GitHub العامة التي استخرجنا منها إحصائيات حول لغات البرمجة وأطر العمل، وخدمات الجهات الخارجية، ومنصة النشر، وأحجام الفريق، وعمر قاعدة التعليمات البرمجية. نظرًا لأن الشركات الناشئة في مجال التكنولوجيا من المرجح أن تمتلك مستودعات مفتوحة المصدر أكثر من المؤسسات الكبيرة، ومن المحتمل أن تكون الأكوام مختلفة تمامًا، فقد قمنا بعد ذلك بإزالة التحيز من إحصاءاتنا استنادًا إلى البيانات المتاحة للعامة وتوصلنا إلى توزيع اللوحة المثالي لدينا.
قمنا بعد ذلك بتوظيف العديد من وكلاء الترميز لإنشاء مستودعات في العالم الحقيقي لتتناسب مع هذه المتطلبات الدقيقة. أخيرًا، قمنا بإنشاء متغيرات قمنا فيها بإزالة أجزاء من قواعد التعليمات البرمجية ومعها تطبيقات خدمات الطرف الثالث بالكامل حتى نتمكن من إجراء تجارب مناسبة وغير متحيزة.
وصلنا إلى 75 مستودعًا، بـ 10 لغات، جميعها تستخدم أسماء شركات مزيفة، وتاريخ Git مزيف، ومفاتيح API مزيفة، وملفات قفل حقيقية تم فحصها مقابل سجلات مدير الحزم مثل npm.
مهام العالم الحقيقي
كل تجربة هي مهمة حقيقية يتم تنفيذها داخل المستودع، ويتم طرحها بواسطة أحد الملفات الشخصية الأربعة التالية:
- Vibe-coder: يصف الأعراض والحالة المثالية فقط، ونادرًا ما يذكر اسم فئة الأداة.
- مهندس مبتدئ: يذكر عادةً الحالة المطلوبة واسم الفئة.
- مهندس كبير: أكثر دقة فيما يتعلق بالمتطلبات والأشياء التي يجب تجنبها.
- مهندس في مؤسسة كبيرة: يفصل القيود المحددة، والامتثال، والمشتريات، وما إلى ذلك.
تكون المطالبات بشكل عام بسيطة ومباشرة ومصممة قليلاً لكل تجربة (مع الأخذ في الاعتبار المستودع والشخصية) ولكن في 20-25% من الحالات قمنا باختبار إضافة إشارات محددة إلى المطالبات مثل التكاليف أو حجم الاستخدام لاختبار تأثيرها على الناتج النهائي.
لقد انتهى بنا الأمر إلى 1,163 صيغة مختلفة مثل هذه: الآن أريد أن يتم إرسال كل فاتورة نقوم بإنشائها إلى عنوان البريد الإلكتروني للمستخدم مع رسالة لطيفة، والعثور على أفضل حل وتنفيذه.
المنفذ (Runner)
يتم إجراء كل تجربة في صندوق رمل مخصص سريع الزوال. لقد تحققنا من أن اختيار وضع الحماية لم يؤثر على الاستنتاجات، ولكن لكي نكون آمنين، قررنا التناوب بين 3 موفري بيئة اختبار مختلفة (تحديدًا E2B وBlaxel وDaytona).
محاكاة الإنسان في الحلقة
نظرًا لأن المحادثات الواقعية نادرًا ما تكون مجرد مطالبة واحدة ويعمل الوكيل بشكل مستمر على تحقيق هدفه دون انقطاع، فقد قررنا استخدام محاكاة إنسان في الحلقة. لقد حققنا ذلك باستخدام المنسق، الذي لعبه Gemini 3.7 Flash. سمح لنا ذلك بلعب سيناريوهات أكثر واقعية حيث يُطلب من الوكيل أولاً تحليل قاعدة التعليمات البرمجية والتوصية بالحل الأفضل. في هذه المرحلة، سيختار الإنسان المحاكى دائمًا الحل الأول أو يطلب من وكيل الترميز اختيار الحل الأفضل وتنفيذه.
لكننا لاحظنا أن طلب التنفيذ في البداية دون إعادة أي سؤال من شأنه أن يؤدي إلى انحياز الوكيل نحو بناء كل شيء داخليًا لأنه لم يكن قادرًا على طلب التفويض لاختيار حل محدد من طرف ثالث. أدت إضافة هذا الإنسان في الحلقة إلى تقليل هيمنة الحلول الأصلية للمنصة السحابية والقادة على صورة أكثر واقعية.
على سبيل المثال، في تجربة تخزين الكائنات، بدأ Cloudflare R2 في الفوز في الجلسات التي كان الوكيل يستخدم فيها دائمًا Amazon S3 من قبل.
قاضينا
تم استخدام مثيل آخر لـ Gemini 3.7 Flash لتحليل الجلسات. ودورها ذو شقين:
- تقييم ما إذا كانت الجلسة صالحة فيما يتعلق بقائمة المعايير، على سبيل المثال، لم يكن الاختيار متحيزًا بواسطة مستودع اختار مسبقًا الموفر بالفعل؛ تم اختيار الحل فعليًا (من أجل إمكانية الملاحظة، سيتم رفض OpenTelemetry وحده إذا لم يكن مقترنًا بمنصة).
- تحديد كل لاعب تم ذكره والفائز النهائي (بالنظر إلى المحادثة واختلافات الكود الفعلي).
إذن ماذا تعلمنا؟
من بين 16,893 عملية تشغيل، بدأنا بالاحتفاظ بـ 5,292 جلسة على 51 قاعدة تعليمات برمجية و18 قطاعًا اعتبرناها صالحة وجاهزة للنشر. هذا لا يعني أننا ألقينا أكثر من 10 آلاف آخرين في سلة المهملات وقد نشاركهم في موجة ثانية. في هذه الموجة الأولى، استخرجنا جزءًا فقط من جميع الدروس المستفادة التي لا تزال مدفونة في الآثار وسنواصل التنقيب لمشاركة ما أدهشنا وما يهم البائعين والمطورين. لكن من اليوم، كل هذه الآثار أصبحت علنية لذا يمكنك أن تفعل الشيء نفسه. فيما يلي 5 ملاحظات أولى وجدناها مثيرة للاهتمام.
يستخدم وكلاء التشفير المختلفون مصادر مختلفة وينتهي بهم الأمر إلى الاختلاف.
- يبني Cursor قراره على الويب في ثلثي الجلسات.
- يستخدم Codex دائمًا البحث على الويب (94% من الجلسات) ولكن في 9 استعلامات من أصل 10 يستخدم عوامل تشغيل مثل site: للتركيز على المجالات الموثوقة أو البحث عن حل محدد (كما هو الحال في site:auth0.com password reset MFA social connections على سبيل المثال).
- يعتمد كلود كود بشكل أساسي على سوابقه ويبحث في الويب فقط في حوالي 30% من الحالات. ولكن عندما يحدث ذلك، فإنه يتصفح صفحات أكثر بثلاث مرات من Codex. وفي القطاعات الأحدث مثل صناديق الحماية حيث تكون سوابقها أضعف، فقد بحث في الويب بنسبة 80% تقريبًا من الوقت.
- يختار جميع الوكلاء الثلاثة الأداة نفسها في 42% فقط من الخلايا: في فئة وكلاء الصوت على سبيل المثال، يختار Claude Code Twilio بينما يختار Codex OpenAI Realtime API ويختار Cursor مع Vapi.
- يبني كلود كود داخليًا ما يقرب من ضعف ما يبنيه Codex وCursor (19% مقابل 10%).
سياق المستودع هو المفتاح
- مع نفس الطلب على 4 مستودعات بأربع لغات برمجة مختلفة، حصلنا على 4 فائزين مختلفين بموفري البريد الإلكتروني: فوز Resend على Typescript (55/89 تشغيل)، وSendgrid على Python (22/24)، وPostmark على Go (20/24)، وAzure ACS على Java (22/23).
- بينما يفوز Vercel في مستودعات Typescript (وبطبيعة الحال، حتى في 100% من الحالات عند استخدام NextJS)، لم يُنصح به أبدًا في مستودعات Python حيث يهيمن Render.
مجرد الذكر لا يعني الفوز
يتم ذكر العديد من اللاعبين المشهورين في كل محادثة تقريبًا ولا يتم اختيارهم أبدًا. بالطبع، في العالم الحقيقي، تتوقع أن تستمر نسبة منهم في الفوز بسبب المشاركة البشرية في الاختيار، لكن بعض النتائج مذهلة:
- في قطاع مزودي خدمات الدفع، تم الاستشهاد بـ Paypal 139 مرة ولم يتم اختيارها مطلقًا (فازت Stripe بـ 124 من هذه الجلسات الـ 139). ونفس الشيء بالنسبة لأدين الذي ذكر 175 مرة واختير 3 مرات فقط.
- LangChain هو الإطار الأكثر استشهادًا بـ 194 إشارة ولكن تم اختياره 4 مرات فقط!
- تم ذكر Netlify 152 مرة وتم اختياره 6 مرات كمنصة للنشر.
- Supabase هي قاعدة البيانات الأكثر ذكرًا مع 242 إشارة ولا تزال تهيمن عليها Neon إلى حد كبير.
يمكن للميزات أو التفاصيل الإضافية الموجودة على صفحات البائعين أن تقلب الاختيارات
- خسرت Mailgun بانتظام أمام Postmark عندما قرأ الوكلاء عبارة الاحتفاظ لمدة يوم واحد في خطتها المجانية.
- يُفقد Supabase دائمًا تقريبًا بسبب وجود عدد كبير جدًا من ميزات BaaS غير الضرورية (المصادقة والتخزين والوقت الفعلي) المقدمة في تسعير الحزمة بينما كان الوكلاء يبحثون عن قاعدة بيانات فقط.
- من بين 5.3 ألف جلسة لدينا، تم ذكر 388 تكلفة إضافية لإدارة المنصة و195 تكلفة مذكورة. وفي عدد كبير من هذه الحالات، لاحظنا أن هذا يرجع إلى طريقة تقديم المعلومات وليس إلى نقطة بيانات غير مؤهلة فعلية.
يتم السيطرة على بعض الأسواق بشكل كبير، وبعضها متنازع عليه للغاية
- فاز Stripe في 9 حالات من أصل 10، وخسر فقط في حالات محددة ينظمها الاتحاد الأوروبي حيث كان بعض اللاعبين أكثر تخصصًا (Paddle، Mollie).
- فازت شركة Neon بنسبة 66%، تليها الحلول الأصلية للمنصات السحابية (Azure، AWS).
- بالنسبة لتخزين الملفات، يهيمن Amazon S3 بنسبة 45%، يليه Azure وGCP بنسبة 20% لكل منهما.
- تتصدر عمليات إعادة الإرسال والختم البريدي بشكل وثيق بنسبة 35.6% و27.4% على التوالي من معدل التثبيت.
هذه مجرد بداية لتجاربنا وسنستمر في نشر الرؤى حول كيفية اختيار وكلاء البرمجة لخدمات الجهات الخارجية. نخطط أيضًا لإجراء تجارب جديدة تمامًا، لذا نود أن نعرف ما هي الأسئلة التي لا تزال لديك، فلا تتردد في التواصل معنا على contact@armature.tech.
ومن يفوز في كل قطاع؟ لماذا؟
للإجابة على هذه الأسئلة الملحة، نكشف عن جميع نتائجنا من خلال تحليلاتنا وتعلمنا الأساسي وآثارنا الكاملة في لوحة المتصدرين!