فريق يراجع كل pull request بنموذج 27B على خوادمه، والمكسب في الكود المحيط بالنموذج

نشر Galo Navarro في مدوّنته يوم 3 نوفمبر 2026 وصفًا لنظام بناه فريقه، يراجع كل pull request في المشروع الأساسي بنموذج حجمه 27B يعمل على خوادم الفريق نفسه. وفي الشهر الأول، تلقت 75% من الـ PRs ملاحظات في أقل من 8 دقائق. والنموذج محلي، مع fallback واضح إلى مزوّد خارجي عند الحاجة.

لكن أهم ما في المقال ليس الرقم، بل المبدأ الذي بُني عليه النظام: determinism حين يكون ممكنًا، وinference حين يكون ضروريًا. فكل خطوة متوقعة، مثل نداءات الـ API واستعلامات قاعدة البيانات والتنقل بين الأنظمة، كُتبت كودًا عاديًا يعمل على CPU. ولا يتولى النموذج إلا الجزء الذي يحتاج فهمًا فعليًا، وهو قراءة الـ diff في سياق codebase كبير.

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

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

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