لماذا تخلّت Stripe عن localhost حين أطلقت أسطولها من العملاء الذكيين

كانت قاعدة الهاكاثون بسيطة: أضع المواصفات والبنية التحتية اللازمة بحلول الساعة الثامنة مساءً، ثم أبتعد عن لوحة المفاتيح حتى الثامنة صباحًا. اثنتا عشرة ساعة كاملة تعمل فيها العملاء الذكية وحدها لإنجاز المنتج.

خلال هذه التجربة أدركت بالملموس لماذا أعلنت Stripe عند إطلاق منصة Minions، وكذلك Ramp عند نشرها تجربة بناء عميلها الذكي Inspect، أن “عصر localhost قد انتهى” — وقد احتجت أقل من اثنتي عشرة ساعة لاستيعاب السبب كاملًا.

تشغيل عملاء متوازية على جهاز واحد يفتح باب الفوضى

حين يعمل أكثر من عميل ذكي على جهاز واحد، تتشابك الحالات لا محالة: تتصادم الأسرار، وتتعارض المنافذ، وحين يدخل الجهاز في وضع السكون تتبخر ساعات العمل دفعةً واحدة.

حين كشفت كل من Stripe وRamp عن بنيتيهما المعتمدتين على العملاء الذكية، كان القاسم المشترك واضحًا: كلتاهما منحت كل عميل بيئة VM مستقلة وحاوية تطوير خاصة به.

تعمل Minions من Stripe داخل بيئات عزل تُسمى “devbox”، مماثلة لأجهزة المهندسين من حيث النوع، لكنها معزولة تمامًا عن موارد الإنتاج والإنترنت. تُشغَّل خلال عشر ثوانٍ، وتدعم تنفيذ المهام المتوازية دون أي تكلفة إضافية مرتبطة بـ git worktrees.

أما Inspect من Ramp فمبنية على Modal Sandbox، إذ تمتلك كل جلسة بيئة تطوير متكاملة مستقلة تشمل Postgres وRedis وTemporal وRabbitMQ. لا تنافس بين الجلسات، وتبدأ كل واحدة في لحظات بفضل لقطات نظام الملفات.

العميل الذكي في المقدمة يحتاج إلى جهازك وتركيزك، أما عميل الخلفية فلا يحتاج إلى أي منهما. وقد رأيت بأم عيني خلال الليل كيف أوقف دخول الجهاز في وضع السكون حلقة عمل كاملة مرة واحدة. هذا لا يحدث على VM سحابي.

التنفيذ التسلسلي للمهام لا ينتج إلا أبسطها

كان هذا أكثر دروس الهاكاثون إيلامًا. التنفيذ المتسلسل يُنتج وظائف CRUD بسيطة لا أكثر. المشكلة تبدأ حين تنشأ تبعيات بين المكونات: مرات عديدة كان عميل لاحق يكتب فوق ما أنجزه سابقه أو يتعارض معه.

هنا يجب التمييز بين أسطول العملاء (fleet) وسرب العملاء (swarm).

أسطول العملاء هو نمط تطبيق تغيير موحد على مستودعات متعددة في آنٍ واحد. هذا ما يُمكّن Stripe من دمج أكثر من ألف pull request أسبوعيًا: تطبيق ذات الترحيل وذات التصحيح على مئات الخدمات دفعة واحدة.

سرب العملاء هو نمط تكليف عملاء مختلفة بأجزاء مختلفة تتقارب نحو نتيجة واحدة: عميل للواجهة الأمامية، وآخر للخلفية، وثالث للاختبارات، ثم تجميعها في وحدات pull request.

لا يمكن بناء منتج معقد دون نمط التوازي والدمج بوحدات pull request. التجربة المباشرة أثبتت الفارق الكبير في الجودة بين النهجين.

حدود الاستخدام والتواصل بين العملاء مشكلة بنية تحتية لا مشكلة prompt

في حلقة الاثنتي عشرة ساعة، كان الوصول إلى حدود الاستخدام (rate limits) أمرًا لا مفر منه. فوق ذلك، كنت بحاجة إلى عملاء تراجع commits عملاء أخرى، وتُعيد الحكم على الأجزاء الغامضة من المواصفات تلقائيًا.

ثمة عبارة دقيقة تُعبّر عن هذا تمامًا: “كتابة ‘لا تحذف الملفات’ في system prompt هو رجاء لا تحكم.” وهذا صحيح تمامًا.

Stripe حلّت هذه المشكلة على مستوى طبقة التنفيذ. Minions محجوبة بالكامل عن موارد الإنتاج والإنترنت، مما يتيح التنفيذ الآمن دون أي فحص إضافي للصلاحيات. أكثر من 400 أداة MCP مُستضافة على خادم داخلي يُسمى “Toolshed”، ومجموعة الأدوات المتاحة لكل عميل منتقاة بعناية.

Ramp من جهتها صممت النظام بحيث تُنشأ كل pull request عبر OAuth مرتبط بحساب مستخدم حقيقي، لا بمعرّف تطبيق. هذا يمنع هيكليًا دمج أي كود دون مراجعة بشرية.

تقييد نطاق الصلاحيات على مستوى التنفيذ، وحفظ سجلات التدقيق، وتحديد نطاق الفشل المحتمل — بدون هذه الضمانات لن يوافق فريق الأمان على تشغيل عملاء مستقلة.

سرعة الفرد لا تعني بالضرورة سرعة المنظمة

ثمة ظاهرة يمكن تسميتها “قمة زائفة”: حين تُدخل عملاء ذكية يتدفق تيار pull requests، لكن دورة التطوير تبقى كما هي. المراجعات تتراكم، وال CI ينكسر، وتنشأ تعارضات الدمج.

في الهاكاثون، لم تكن سرعة إنتاج الكود هي العائق. الوقت كله استُنفد في اختناق تجميع النتائج والتحقق منها.

Stripe تتجاوز هذا الاختناق بالأتمتة. تستخدم Minions تنسيقًا هجينًا يتناوب فيه حلقات العملاء مع عمليات الكود الحتمية: lint، وaختبارات، وعمليات git مضمونة الإتمام دائمًا، مع الحفاظ على إبداعية العميل. ولمنع الدوران اللانهائي، حدّت Minions تكرار اختبارات الـ CI بمرتين كحد أقصى.

Ramp تقيس النجاح بعدد pull requests المدموجة فعلًا. أكثر من 50% من pull requests التي تُنشئها Inspect تُدمج فعلًا، وأكثر من 80% من Inspect نفسها كُتبت بواسطة Inspect.

لكي تواكب سرعة المنظمة، يجب أن تعالج عملاء الخلفية مراجعات pull requests وتحليل فشل CI وحل تعارضات الدمج قبل المطور البشري. الجوهر هو الانتقال من “in the loop” — التدخل المباشر — إلى “on the loop” — مراجعة النتائج فحسب.

المعركة الحقيقية ليست في سرعة البناء بل في بنية الدمج

سرعة بناء العملاء الذكية مسألة محلولة بالفعل. Stripe تدمج أكثر من ألف pull request أسبوعيًا، وRamp تجعل العملاء تُنشئ أكثر من نصف pull requests المشروع.

التحدي الحقيقي هو تصميم نظام يدمج مخرجات العملاء بأمان. بيئات التنفيذ المعزولة، والهيكل الموازي المتقارب بوحدات pull request، والحوكمة على مستوى البنية التحتية، وأتمتة التحقق — بدون هذه الركائز الأربع، يبقى العميل الذكي مجرد لعبة سريعة.