أخيرًا، اندلع الجدل حول ما إذا كان ينبغي أن يوجد بناء برمجيات مؤتمت بالكامل بالذكاء الاصطناعي. وكان الشرارة هي
@yetone الذي يتولى صيانة magpie، وهو ما انتقده أقرانه ووصفوه بأنه "خدمة وجبات سريعة" و"محفوف بالمخاطر للغاية للاستخدام".
يتفق معظم الناس على أن بناء البرمجيات المؤتمت بالذكاء الاصطناعي هو الاتجاه السائد. فكيف يطبق magpie هذا عمليًا؟ قمت بسحب مستودع magpie، وحللت 2,862 commit خلال الأيام العشرة الماضية، واستخدمت OpenClaw للمقارنة.
https://x.com/wquguru/status/2109458639501271530
1204 إصدارات في 19 يومًا
magpie هو بوابة LLM محلية تربط وكلاء البرمجة (coding agents) مثل Claude Code و Codex و Gemini CLI بأي نموذج أو اشتراك. منذ أول commit في 22 سبتمبر وحتى اليوم، حصد المشروع 9,474 نجمة في 19 يومًا فقط. ومن بين 2,862 commit، استحوذ حساب yetone على 85% منها، مع دمج 383 طلب سحب (PR) من المجتمع.
وصل عدد الـ tags (أي الإصدارات) إلى 1,204 في 19 يومًا، بمتوسط يتجاوز 60 إصدارًا يوميًا — وهو معدل يستحيل على البشر الحفاظ عليه يدويًا. وفي المقابل، سجل OpenClaw 1,423 commit في أول 19 يومًا له، قدم Peter Steinberger نفسه 99% منها، مع حوالي 10 tags فقط.
يمتلك magpie ضعف عدد الـ commits، لكن بإصدارات تفوقه بأكثر من مئة مرة.
ما أردت اكتشافه كان أمرًا واحدًا: كيف يُغلق الذكاء الاصطناعي الدائرة في هذا المشروع بالضبط؟
جدول توجيه ودفتر أخطاء
لا يشير ملف CLAUDE.md الخاص بـ magpie سوى إلى ملفين: AGENTS.md و LESSONS.md.
ملف AGENTS.md هو جدول توجيه. لا يكتب القواعد بنفسه؛ بل يخبر الوكلاء فقط بالوثائق التي يجب الرجوع إليها قبل تنفيذ أي عمل: راجع docs/subsystems/ قبل تعديل الأنظمة الفرعية، واتبع docs/code-standards.md عند كتابة الكود أو مراجعته، واطلع على docs/contributors.md لمراجعة طلبات السحب المجتمعية.
وتجيب الجملة الأولى في LESSONS.md على السؤال الأول:
كود magpie تتم كتابته ومراجعته ودمجه وإصداره بواسطة الوكلاء. (يُكتب كود magpie ويُراجع ويُدمج ويُصدر بواسطة الوكلاء)
الكتابة، المراجعة، الدمج، الإصدار — كل ذلك يقوم به الوكلاء. وبدون إشراف بشري، لماذا لا ينهار النظام؟ تكمن الإجابة في هذا الملف. فبطول يبلغ 479 سطرًا، هو في جوهره دفتر أخطاء، يكتبه الوكيل كل ليلة.
كل ليلة، يراجع الوكيل جميع الـ commits الخاصة بذلك اليوم، مركزًا على ثلاثة سيناريوهات:
- ما هي الإصلاحات التي تطلبت إعادة العمل عليها؟
- ما الذي لم يكن ينبغي دمجه من الأساس؟
- ما هي عمليات التحقق التي تمت بتساهل شديد؟
وبالنسبة لكل مشكلة يتم اكتشافها، يسجل قاعدة وسببًا، ويرفق أرقام الـ commits والـ issues كأدلة. على سبيل المثال:
أعد إنتاج الحالة الدقيقة التي أبلغ عنها المستخدم، وعلى الواجهة التي يستخدمها فعلًا، قبل أن تعتبر المشكلة محلولة.
المشكلة 834 عادت 4 مرات (v0.1.920 → .925 → .931 → .938). في كل جولة، تم إصلاح الوكيل الظاهر في لقطة الشاشة فقط. شوهدت 1× (2026-10-05).
المشكلة 834 تطلبت إعادة العمل أربع مرات، وفي كل مرة تم إصلاح الوكيل الظاهر في لقطة الشاشة فقط. لذا القاعدة هي: قبل اعتبار المشكلة محلولة، أعد إنتاجها بدقة على الواجهة التي يستخدمها المُبلّغ.
والسر يكمن في السطر الأخير: شوهدت 1×. إذا ظهر نفس الدرس في المراجعات خلال ثلاثة أيام مختلفة، ينتقل من LESSONS.md إلى code-standards.md، ليصبح قاعدة صارمة مستمدة من التجربة. ويجب بعد ذلك التحقق من كل مراجعة لطلبات السحب مقابل هذه القواعد بندًا بندًا.
وقد تمت ترقية ثماني قواعد بهذه الطريقة بالفعل. من الأمثلة على ذلك: إصلاح الأخطاء المتشابهة معًا (حيث تم رصد الخطأ مرة واحدة في 5 و6 و7 أكتوبر)؛ الاختبارات التي تفشل في الفرع main تُعتبر أخطاءً يجب إصلاحها فورًا؛ وتحديد ما تم اختباره وعلى أي commit بوضوح قبل الدمج.
وبالطبع، يسجل دفتر الأخطاء أيضًا الأشياء التي تمت بشكل صحيح، وتُوسم بعبارة Done right، حتى لا يقرأ الوكلاء "لا تفعل هذا" فحسب، بل "افعل هذا بدلًا منه" أيضًا.
تم إدخال دفتر الأخطاء في فجر السادس من أكتوبر
هل صُمم هذا النظام منذ البداية؟ بالتحقق من سجل الـ commits لملف LESSONS.md، نجد أن النسخة الأولى كانت commit رقم 303819c5، وأُنشئت في الساعة 3:10 فجرًا يوم 6 أكتوبر.
وقبل ذلك بيوم واحد، في 5 أكتوبر، أصدر magpie 168 نسخة.
سجلت النسخة الأولى من LESSONS.md أحداث ذلك اليوم. فمع 220 commit وحوالي 170 إصدارًا، كان نحو 40 منها إصدارات لإصلاح مشاكل ظهرت في نفس اليوم أو اليوم السابق. وكانت عمليات CI تُلغى دائمًا تقريبًا بمجرد الدفع التالي. واختبار فشل على Linux فقط ظل أحمر اللون من v0.1.877 إلى v0.1.892 دون أن يلاحظه أحد.
294 tag في 51 ساعة لم تترك أي عملية تكتمل. (294 tag في 51 ساعة تعني أنه لم تتمكن أي عملية CI من الاكتمال)
لذا أضافت النسخة الأولى قاعدة: قبل إنشاء tag، يجب أن تكتمل عملية CI الخاصة بهذا commit وتكون خضراء (ناجحة). العمليات الملغاة بسبب دفعات جديدة لا تُحتسب.
168 إصدارًا في اليوم الأول، 42 في الثاني، 15 في الثالث، ثم استقر العدد بين 15 و26.
لم تُعقد أي اجتماعات، ولم تُرسل أي إشعارات. اكتشفت المراجعات الليلية المشكلات، وأضافت قاعدة إلى دفتر الأخطاء، وقام الوكلاء العاملون بقراءتها، مما أدى إلى إبطاء وتيرة الإصدارات.
وبالتالي، فإن الإصدارات العشرون اليومية التي اعتُبرت مؤخرًا مشكلة، كانت في الواقع السرعة بعد الضغط على المكابح.
معايير قبول طلبات السحب (PR)
بعد ذلك، لنلقِ نظرة على طلبات السحب الحقيقية:
يسرد ملف code-standards.md ستة معايير للقبول. ويجب اجتيازها جميعًا قبل الدمج أو الإصدار. وبصرف النظر عن الفحوصات المعتادة مثل الترجمة على ثلاث منصات والاختبار في بيئة معزولة (sandbox)، هناك ثلاثة معايير نادرة في المشاريع التقليدية:
- اختبار التراجع (Regression Test): أعد الكود القديم؛ يجب أن تفشل الاختبارات الجديدة بشكل صريح، موضحةً أي سلوك خاطئ. أخطاء الترجمة أو الاختبارات المتخطاة لا تُحتسب.
- الاستخدام الفعلي: إذا كنت تغير تكاملًا مع مزود خارجي، فتحقق باستخدام حسابات وإعدادات واستجابات API حقيقية. الميزات غير المختبرة لا يمكن البناء عليها أو ادعاء جاهزيتها للمستخدمين.
- يجب إدراج الفحوصات التي لم تُجرَ:
الفحص الذي لم يُجرَ يُدرج كـ "لم يُجرَ"، ولا يُحذف أبدًا. (يجب إدراج الفحوصات التي لم تُنفذ بصفتها "لم تُجرَ"، ولا يجوز حذفها مطلقًا)
اخترت عشوائيًا #1339 لأرى التعليق المتروك قبل الدمج:
Red check تعني اختبار التراجع، و Break check تعني تعمد إتلاف الكود لمعرفة ما إذا كانت الاختبارات ستكتشف ذلك، والسطر الأخير يقول Not run — أي أنه لم يُختبر على أجهزة حقيقية.
ويتضمن أمر الدمج --match-head-commit <reviewed sha>. فإذا قام شخص بدفع كود أثناء المراجعة، يفشل الدمج، مما يضمن عدم دخول كود غير مُراجع.
العنصر البشري في الحلقة
بالطبع، لا يزال البشر يشاركون في بعض الأعمال، على الأقل في هذه المجالات:
- قرارات المنتج: "لا تعكس القرارات المتعمدة." أشياء مثل سلوك التمرير أو مؤشرات الأزرار لا يمكن تغييرها عبر طلبات السحب.
- بوابات الأمان: إذا تم تفعيل فحوصات المخاطر، انتظر موافقة المشرف.
- اقتراحات المجتمع: 474 عنوان commit يذكر مُبلّغين من X أو Discord، مثل JonahFu على X، و Jeremy.Zhou على Discord.
باختصار، البشر يديرون التوجه ويحرسون البوابات؛ أما الكتابة والمراجعة والدمج والإصدار فيتولاها الوكلاء.
هل يخفي yetone شيئًا؟
عند هذه النقطة، قد يتساءل البعض: هل يخفي yetone شيئًا؟ راودني الفضول أيضًا، فبحثت أعمق.
وبالفعل، هناك عدة أمور غير موجودة في المستودع:
- كيفية تشغيل المراجعات الليلية غير موثقة. فلا توجد أي من مسارات العمل (workflows) الأربعة مجدولة زمنيًا.
- استخرجت أوقات تحديثات LESSONS.md السبعة: 03:10، 03:49، 00:23، 23:46، 03:48، 14:24، 05:26. إنها متفرقة، ولا تبدو كمهام cron jobs، بل أشبه بتشغيلات يدوية محلية أو سكربتات مخصصة.
- الأوامر (prompts) المستخدمة في المراجعات الليلية غير موجودة أيضًا. أي وكيل، وكم جلسة موازية — لا شيء من ذلك موثق.
وأثناء البحث، وجدت نقطتين إضافيتين:
أولًا، تعتمد المنهجية على مساهمات المجتمع. تم إدخال وثائق الأنظمة الفرعية ومراجعات التغييرات الدلالية عبر طلب السحب #889 من عضو المجتمع Junjie Zhou. والجداول الموجودة في بداية ملف code-standards.md تُنسب صراحةً في commit رقم 926bcaa3 إلى ست قواعد مراجعة اقترحها Junjie Zhou على Discord.
ثانيًا، تفاعلات yetone مع الوكلاء محفوظة في الـ commits. تحتوي 52 عنوان commit على اقتباسات yetone الأصلية بين أقواس:
1(المالك: هذا قبيح جدًا)2(المالك: لماذا هذا محدد أصلي بدلاً من ComboBox المجرد الخاص بنا؟)3(المالك: لماذا عاد هذا مجددًا؟ ألم نقل إنه يجب أن يظهر عند التمرير فوقه فقط؟ الظهور الدائم قبيح جدًا)4(المالك: أثناء pr-preview، أحيانًا لا توجد بيانات للاختبار. هل يمكنك المساعدة في إنشاء بعض البيانات الوهمية؟)
هذه في الغالب شكاوى من سطر واحد؛ بينما يكمل الوكيل الباقي، مما يؤدي غالبًا إلى مئات الكلمات في نص الـ commit. وطلب البيانات الوهمية تحول لاحقًا إلى مجموعة البيانات التجريبية (mock data) المستخدمة في تسجيلات CI.
يشير البشر إلى ما هو خاطئ؛ ويحول الوكلاء ذلك إلى تغييرات قابلة للتحقق. وعناوين الـ commits هذه تشرح المنهجية أفضل من أي وثيقة.
إذا أردت بناء نسختك الخاصة
يمكن لأي شخص كتابة جدول توجيه. القيمة الحقيقية التي تستحق الاقتباس هي نظام دفتر الأخطاء. يبدو مدخل LESSONS هكذا:
1**<قاعدة من جملة واحدة>**2- <أي commit/issue تسبب في المشكلة، وما كانت النتيجة>3- <commit الإصلاح>4- تم بشكل صحيح: <مثال على التنفيذ الصحيح>5- شوهد N× (YYYY-MM-DD, YYYY-MM-DD).
اجعل وكيلًا يراجع الـ commits يوميًا كل ليلة، باحثًا فقط عن إعادة العمل، والدمجات السيئة، والتحقق الضعيف. وإذا ظهرت نفس المشكلة في ثلاثة أيام مختلفة، انقلها إلى معايير الكود. وأثناء القبول، ادرج اختبارات التراجع، والاستخدام الفعلي، والعناصر التي لم تُفحص في نصوص الـ commits وتعليقات طلبات السحب.
بعد مراجعة المستودع بأكمله، أكثر ما أثار إعجابي هو حد "شوهد 3 مرات". تُدوَّن الأخطاء، ويقرأها الوكلاء عند التشغيل، وتكرار نفس الخطأ ثلاث مرات يرقّيها إلى قاعدة صارمة، مجسدًا تمامًا المقولة "الثالثة ثابتة" (أو بالأحرى، الضربة الثالثة القاضية).
أفكار أخيرة...
قبل عام، أو حتى قبل ستة أشهر، نادرًا ما كانت قدرات النماذج تصل إلى مستوى الأتمتة الإنتاجية. لكن الآن، وخاصة منذ ظهور Opus 5.5، يمكننا أن نرى — المستقبل هنا.
هذا يذكرني بمشروع Yoyo الخاص بـ @yuanhao، وهو وكيل (Agent) طوّر نفسه ذاتيًا لأكثر من 200 يوم: https://yoyo-gasp.yolog.dev/، ويستحق الاطلاع عليه أيضًا.
