كتب Claude Code محرك البحث في 3 أيام، لكن فريق Jmix احتاج إلى 3 أسابيع لقبول الكود

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

مؤقّتان بدل مؤقّت واحد

يبحث المساعد، قبل أن يجيب، عن مقاطع من الوثائق في قاعدة بيانات متجهية. أضاف الفريق إلى هذه القاعدة بطاقات الفئات المستخرجة من Javadoc، وقسّم الوثائق إلى أمثلة قصيرة مكتملة. وتتولى حلقة التقييم فحص الجودة: 74 سؤالًا اختباريًا تقيّم نموذج-حَكَم إجاباتها.

كتب Claude Fable 5 النسخة الأولى من الكود، وأعاد GPT-5.6 Sol التحقق من بعض الأجزاء بصورة مستقلة. وكانت النتيجة diff من 122 ملفًا وقرابة 15 ألف سطر. وقد توقّع المؤلفون مسبقًا أن تستغرق المراجعة يومين إلى ثلاثة أيام. فقد رأوا كل تغيير، وكان بوسعهم أن يسألوا الوكيل عن أي قرار. لكن تصفّح الـ diff شيء، وفهمه إلى درجة تسمح بتحمل المسؤولية عنه دون الوكيل شيء آخر.

يصف الفريق ذلك بأنه مؤقّتان. الأول يعمل حتى يظهر كود يعمل، وقد توقف بعد ثلاثة أيام. والثاني يعمل حتى يظهر في الفريق شخص قادر على إصلاح النظام من الذاكرة. ويسمي المؤلفون هذه اللحظة «اعتماد الكود» (code adoption)، وهي في المعنى تملّك الكود والمسؤولية عنه (ownership). وعلاماتها: يستطيع الشخص أن يتتبع مسار البيانات من المدخل إلى النتيجة، وأن يشرح الثوابت (invariants)، وأن يتوقع ما سيتأثر بأي تعديل، وأن يغيّر العقد (contract) وهو يدرك ما سيلزم إعادة فحصه. ولا يضمن نجاحُ البناء (البناء «الأخضر») ذلك، لأنه يجيب فقط عن أسئلة مطروحة مسبقًا. فمثلًا: هل تحقق أحد من أن المقاطع القديمة ستبقى في مكانها إذا حدث عطل في منتصف إعادة الفهرسة؟

أين ذهبت الأسابيع الثلاثة

لا تفسّر سرعة القراءة إلا جزءًا من الفارق. فبحسب بيانات SmartBear وCisco، ينبغي في الجلسة الواحدة مراجعة 200–400 سطر خلال 60–90 دقيقة. ومن أصل 15 ألف سطر، يشغل نحو ثلاثة آلاف سطر ملفات HTML ثابتة (fixtures) لا حاجة إلى قراءتها. يتبقى نحو 12 ألف سطر، أي 30 جلسة و30–45 ساعة من القراءة. وهذا يعادل تقريبًا أسبوع عمل، علمًا بأن الاختبارات تُقرأ أسرع. ويقرّ المؤلفون بأن التقدير تقريبي، وبأن الدراسة التي يستندون إليها يقارب عمرها عشرين عامًا.

والتهم الباقيَ ثلاثةُ أمور. أولًا، كان الوكيل يغيّر الكود «بالمناسبة». ففي اليوم الثالث من المراجعة اختفى من الكود دعم عدة إصدارات من Jmix.

وكان الوكيل قد غيّر في اليوم الأول صيغة الرد في /api/search، فاضطر الفريق إلى إعادة العقد القديم، وانتقلت الصيغة الجديدة إلى /api/v2/search. كما أُزيلت من المستودع لقطات شاشة وملفات تصدير بحجم 3,5 ميغابايت وسجلات Playwright. واستمرت سلسلة commits بعنوان «Restore …

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

وكل ما كان الفريق قد فهمه عن معنى الدرجة اضطر إلى إعادة التحقق منه.

وبحسب سجل commits: 44 commit في الأيام الثلاثة الأولى، ثم 53 خلال أسبوع ونصف من الفحص، ثم 47 أخرى في الأيام التسعة الأخيرة.

أما السياق من بيانات القطاع فهو التالي. وفق DORA 2024، ارتبط نمو استخدام الذكاء الاصطناعي بنسبة 25% بتحسّن الوثائق وتسريع المراجعة، لكن الإنتاجية في التسليم تراجعت بنحو 1,5%، والاستقرار بنسبة 7,2%. وهذه علاقة ارتباط مستمدة من استبيان، وليست تجربة. وفي DORA 2025 صارت العلاقة مع الإنتاجية إيجابية، وبقيت مع الاستقرار سلبية. وفي تجربة METR أمضى مطورون ذوو خبرة وقتًا أطول بنسبة 19% في إنجاز المهام عند استخدام الذكاء الاصطناعي، لكنهم ظنوا أنهم أسرع بنسبة 20%. وكانت الأدوات المستخدمة هناك من بداية 2025، وجاء القياس المتكرر في فبراير 2026 غير موثوق إحصائيًا.

ما يفعله الفريق الآن

الفكرة الرئيسية هي التمييز بين ثلاثة حدود. حد التسليم يحدد ما سيدخل main كاملًا. وحد التكرار الوكيلي (agentic iteration) يوصل العمل إلى حالة مستقرة يمكن تشغيلها وفحصها. ونقطة اعتماد الكود تبيّن أي جزء صار الإنسان يتولى صيانته بنفسه. وكان الفريق قد جمعها سابقًا في pull request واحد كبير، فلم يبدأ المؤقت الثاني إلا بعد انتهاء الأول.

الآن يُقسَّم العمل إلى ثلاث شرائح: دورة حياة المدونة (corpus)، والبحث مع API، وحلقة التقييم. يفحص الإنسان كل شريحة ويقبلها قبل الانتقال إلى التالية. وتُبنى الشرائح على شكل مكدّس من الفروع (stack of branches)، ويدخل إلى main طلب دمج (pull request) نهائي واحد لا تُفحص فيه إلا نقاط الالتقاء. مثلًا: أن يظل البحث، بعد إعادة فهرسة فاشلة، يُرجع الجيل القديم من البيانات.

وهناك ست ممارسات: وصف عقد النظام كله قبل الجلسة الأولى، وتقسيم العمل إلى حالات مستقرة مع ترك مذكرة بين الجلسات، وطلب إثبات من الوكيل بدل تقرير، وإسناد الفحص إلى وكيل منفصل بسياق جديد، وإشراك الإنسان بعد كل شريحة، وإنهاء العمل بقبول تكاملي (integration) كامل. وتوجد أفكار مشابهة في تجارب Anthropic مع المهام الطويلة للوكلاء، وفي توصيات Claude Code بشأن فحص الـ diff بواسطة وكيل فرعي (subagent).

القيود

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