دمج Devin في Pylon: الأعطال تصل إلى PR خلال 15–20 دقيقة والإصلاحات أسرع بنسبة 30%

حصل Devin على تكامل أصلي مع Pylon، منصة دعم العملاء. عندما تنتقل التذكرة إلى قائمة الهندسة، يبدأ Devin العمل من تلقاء نفسه: يحلل السجلات، ويعيد إنتاج العطل، ويحدد السبب الجذري، ثم يفتح pull request يتضمن الإصلاح. وبحسب المطورين، أصبحت الإصلاحات على تدفق البلاغات الخاص بهم تصدر أسرع بنحو 30%، وفي الحالات الناجحة تستغرق السلسلة من الشكوى إلى PR ما بين 15 و20 دقيقة. ويحصل عملاء Devin الجدد الذين يعملون في Pylon على اعتمادات بقيمة $15 000.

أي فجوة يسدّها التكامل

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

ويصف المقال في المدونة أيضًا حلًا محليًا ابتكره بعض العملاء. فقد ضبط بعضهم وكيلًا محليًا يعمل وفق جدول زمني: يفحص تذاكر Pylon الجديدة والمحدَّثة، ويكتب السياق في Slack، ويستدعي Devin. وكان خلف هذا الوكيل ملف تعليمات من 1 500 سطر يصف قاعدة الشيفرة وإجراءات الدعم. وحتى مع ذلك، كان التحليل يستغرق غالبًا أكثر من ساعة. أما فريق Devin نفسه فكان يفرز التذاكر يدويًا ليقرر ما يُسند إلى الوكيل، وينسخ إلى الجلسة كل رسالة جديدة من العميل. وكان سير العمل يمر عبر أربع أدوات.

كيف يعمل

يشغّل Pylon وكيل Devin عبر مشغِّل (trigger) ويمرر إليه شكوى العميل. يقيّم Devin الأولوية بنفسه ويبدأ التحقيق دون انتظار أمر. وقبل ذلك يبحث في Linear وGitHub وجلسات Devin الأخيرة الأخرى عن مشكلة مشابهة أو إصلاح قيد التنفيذ. وتصل رسائل العميل الجديدة إلى الجلسة نفسها. ينضم المهندس إلى هذه الجلسة ويرى ما تم العثور عليه، بدلًا من أن يبدأ من الصفر مع وكيل جديد.

• المشغِّل: تذكرة في Pylon موسومة للهندسة.
• عمل Devin: السجلات، وإعادة إنتاج العطل، وتحليل السبب الجذري، وPR يتضمن الإصلاح.
• التحقق من التكرار: Linear وGitHub وجلسات Devin السابقة.
• المزامنة: ثنائية الاتجاه بين Pylon والجلسة، ويعمل المهندسون في Slack أو Linear.
• السرعة وفق بيانات الفريق: الإصلاحات أسرع بنحو 30%، وفي أفضل الحالات 15–20 دقيقة بدلًا من ساعات.
• المكافأة: اعتمادات Devin بقيمة $15 000 للعملاء الجدد على Pylon.

وإلى جانب الأعطال، يمكن لفريق الدعم عبر Devin البحث عن إجابات لأسئلة المنتج المتعلقة بقاعدة الشيفرة، والتقاط لقطات الشاشة وإنتاج عروض فيديو توضيحية، وتقدير حجم طلبات الميزات الصغيرة. ويبقى كل ذلك داخل Pylon.

مثال: الخطأ 500 بدلًا من 429

في المثال المعروض، يبلّغ عميل بأن طلبات API التي بلغت الحد المسموح تعيد خطأ الخادم 500 بدلًا من الاستجابة 429. في العملية اليدوية، يطلب فريق الدعم من وكيل محلي إعادة صياغة المشكلة، وينشئ تذكرة في Linear، ثم يبحث في Slack عن مهندس. يفتح المهندس جلسته الخاصة ويجمع أمثلة العميل، وبعد الإصلاح يربط أحدهم PR بالتذاكر ويبلغ فريق الدعم.

مع التكامل، يتلقى Devin الشكوى، ويبحث عن عمل جارٍ بالفعل، ويكتشف خطأ تسلسل (serialization) أدى إلى إصدار حالة خاطئة. بعد ذلك يحدّث التذكرة في Linear ويشير إلى المهندس في سلسلة محادثة Slack. ولا يكتفي بتصحيح من سطر واحد يخفي العَرَض، بل يعالج الخطأ نفسه، ويضيف أربعة اختبارات انحدار (regression tests)، ويفتح PR. يراجع المهندس التغييرات ونتائج الاختبارات في Slack ثم يدمج الشيفرة. تعود التحديثات إلى Pylon، وتُرسل ردود العميل مجددًا إلى الجلسة التي يتابعها المهندسون.

ما الذي ينبغي التحقق منه قبل الاعتماد

الأرقام هنا صادرة عن الشركة المطورة: فنسبة 30% مستمدة من تدفق التذاكر الداخلي للفريق نفسه، أما 15–20 دقيقة فوُصفت بأنها تحدث «أحيانًا». وهذا مؤشر استرشادي لا ضمانة، وتتوقف النتيجة على جودة التذاكر وتغطية الاختبارات وتوفر السجلات. لذلك يُستحسن قبل الإطلاق قياس مؤشر أساسي: الزمن الوسيط من التصعيد إلى PR ومن التصعيد إلى الإصدار على بياناتكم، ثم المقارنة بعد شهر.

وثمة مسألة منفصلة تتعلق بالصلاحيات. يقرأ الوكيل السجلات والمستودعات، لذا حدّدوا الأنظمة التي يصل إليها وأي بيانات للعملاء تدخل الجلسة. وتبقى المراجعة البشرية لـ PR إلزامية، وهذا ما ينص عليه السيناريو الموصوف. ويمكن البدء بفئة من التذاكر يكون سببها محليًا عادةً، مثل رموز الاستجابة الخاطئة أو أخطاء التصدير. وللاتصال بالخدمة يلزم التواصل مع فريق حسابات Pylon، وهو من يمنح الاعتمادات ويساعد في الإعداد. كما يتوفر ندوة عبر الويب (webinar) ووثائق للتكامل.