فريق يدمج وكيل ذكاء اصطناعي في عملية التطوير ويعتمد مرحلتين للمراجعة

كتب الوكيل الشيفرة بسرعة. والآن يجب أن يتحقق أحدهم مما إذا كان قد عدّل الخدمة الصحيحة، واستعلم من قاعدة البيانات الصحيحة، ولم يتسبب في تجميد الواجهة بعملية طويلة. في مقال على Habr، وصف فريق كيف عالج هذه المشكلات في وكيله الخاص لبيئة IntelliJ IDEA. وكانت إحدى الخطوات الرئيسية اعتماد المواصفات عبر طلب دمج مستقل قبل بدء التنفيذ. ويمكن تجربة هذا الترتيب مع وكيل مثبت بالفعل.

بدأت القصة في عام 2024 بإضافة لتوليد الاختبارات. ثم ظهرت واجهة محادثة داخل بيئة التطوير، وبعد التعرف على Windsurf في يناير 2025، شرع الفريق في بناء وكيل متكامل يستطيع البحث في المشروع وتعديل الملفات وتشغيل عمليات التحقق. ومع الاستخدام، اتضح أي جوانب العمل تحتاج إلى شرح متكرر، وأين ينبغي فرض قيود على الأداة.

سياق المشروع: العثور على الشيفرة واختيار قاعدة البيانات الصحيحة

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

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

وللمصادر الخارجية، أضاف الفريق MCP لربط خوادم توفر أدوات للوكيل. ومن خلالها، يمكن جلب المهام من GitHub، أو الاستعلام من قاعدة بيانات، أو فحص تطبيق ويب في المتصفح. وتعتمد الإجراءات المتاحة على الخادم المعني والأذونات الممنوحة.

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

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

مراجعة المهمة أولًا، ثم مراجعة التنفيذ

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

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

لمراجعة الشيفرة، استعان أصحاب المقال بملاحظاتهم السابقة على طلبات الدمج. وخلال تطوير الإضافة، تكررت العمليات الطويلة على خيط الواجهة EDT، واستدعاءات واجهة IntelliJ API من دون إجراء القراءة اللازم، أو read action. وحوّلوا هذه الحالات إلى تعليمات للوكيل المسؤول عن المراجعة.

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

ما الذي يمكن تطبيقه في فريقك؟

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

فصل الفريق أيضًا منطق الوكيل عن الواجهة وأصدر واجهة سطر أوامر CLI. وبحسب وصفه، تحتفظ نسخة الطرفية بإمكانات التعامل مع الملفات والمهارات والنماذج وMCP. لكن المقتطف المقدم ينقطع هنا، ولا يتضمن اسم المنتج أو شروط الوصول إليه أو صورة كاملة عن استخدامه الفعلي.

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