لماذا تعمل وكلاء البرمجة ولماذا تنهار

نفس النموذج. ذلك النموذج الذي كان يُهلوس في الدردشة عبر الويب، يُنجز في Claude Code ميزة من 200 سطر دفعة واحدة. أمر /goal في Codex يحلّ issue كاملة. النموذج لم يصبح أذكى فجأة. ما تغيّر هو البنية.

لماذا تعمل

حلقة الذكاء الاصطناعي الحواري تبدو هكذا:

LLM → إنسان → LLM → إنسان

التغذية الراجعة كلها لغة طبيعية. توليد احتمالي يتبعه تقييم احتمالي. الدقة تتدهور بالضرب.

حلقة وكيل البرمجة مختلفة:

LLM → توليد كود → حفظ ملف → تشغيل اختبار → pass/fail → LLM
LLM → تعديل كود → بناء → نجاح/فشل → LLM
LLM → فحص أنواع → رسالة خطأ → LLM

داخل الحلقة توجد بوابات حتمية. نظام الملفات يحفظ ما يُكتب كما هو. الاختبار إما pass أو fail. المُترجم يقول خطأ حين يكون هناك خطأ. هذه تلعب — دون قصد — دور السقاطة (ratchet).

LLM مكوّن غير موثوق (unreliable component). لكن بناء بروتوكول موثوق فوق مكوّن غير موثوق هو أساس الهندسة. TCP يصنع تسليماً موثوقاً فوق شبكة غير موثوقة. RAID يصنع تخزيناً موثوقاً فوق أقراص غير موثوقة. ECC يصنع حوسبة موثوقة فوق ذاكرة غير موثوقة.

وكيل البرمجة يعمل للسبب ذاته. لأنه يضع فوق LLM غير موثوق محققات حتمية (deterministic verifier): اختبارات، بناء، linter، فاحص أنواع. السبب في النجاح ليس أداء النموذج، بل topology.

لكن لماذا تنهار

قلنا إنها تعمل. لكنها أحياناً تنهار. لماذا؟

لأن هناك فرقاً بين سقاطة وُجدت بالصدفة وسقاطة صُممت بوعي.

توجد مناطق بلا سقاطة

حين يعدّل الوكيل كوداً بلا اختبارات — يمرّ البناء، يمرّ lint، لكن الوظيفة معطوبة. في المناطق الخالية من البوابات الحتمية، يحكم LLM احتمالياً، والحكم الاحتمالي يتدهور بالضرب.

من أصل 200 endpoint، لـ180 منها اختبارات ولـ20 لا. الوكيل يعالج الـ180 بإتقان، ويزرع أخطاء صامتة في الـ20. هذا سبب عبارة “تقريباً انتهى لكن شيئاً ما خاطئ”.

كمية المعلومات في التغذية الراجعة غير كافية

في تجربة فرز 1000 كلمة: المعالج أنجزها في 0.08ms بدقة 100%. LLM احتاج 438 ثانية بدقة 97.7%. هذا بحد ذاته مذهل — 97.7% بالتفكير المحض. لكن الاكتشاف الحقيقي كان في مكان آخر.

غيّرنا مستوى التغذية الراجعة لنفس النتيجة:

التغذية الراجعة	النتيجة
بدون	6 أخطاء (99.4%)
“يوجد أخطاء”	10 أخطاء (99.0%) — تدهور
“يوجد 23 خطأ”	خطأ واحد (99.9%)
“6 أخطاء، هنا مواقعها”	0 أخطاء (100%)

إخباره فقط بأنه “مخطئ” يؤدي إلى تصحيح مفرط يزيد الأمر سوءاً. إخباره بعدد الأخطاء يمنحه هدفاً فيبحث بإصرار. إخباره بالمواقع يجعله يصلح بشكل مثالي.

معظم الوكلاء اليوم عالقون في المستوى الثاني. حين يفشل الاختبار يعلمون أن “شيئاً ما خطأ”، لكنهم لا ينقلون السبب البنيوي. رسالة الخطأ موجودة، لكنها عَرَض لا سبب.

توجد نقاط عمياء، والتكرار لا يحلّها

في تجربة الفرز، ترك LLM 6 أخطاء في R2. في R3 أبلغ “لا أخطاء”. في R4b أيضاً أبلغ “لا أخطاء”. فاته نفس الستة بنفس الطريقة.

بدون تلميح، مهما تكرّر، استقرّ عند 99.4%. حين أُخبر “بقي 6”، حقق أخيراً 100%.

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

عند التوسّع يعمل الضرب

دقة 97.7% في خطوة واحدة. سلسلة من خطوتين: 0.977² = 95.4%. ثلاث خطوات: 93.2%. عشر خطوات: 79.2%.

الوكيل يُجيد تعديل ملف واحد. لكن حين تطلب إعادة هيكلة تمتد على 100 ملف؟ حتى لو كانت كل خطوة 97%، بعد 100 خطوة: 0.97¹⁰⁰ = 4.8%. الفشل مضمون عملياً.

هذا هو التفسير الرياضي لـ"vibe coding ينهار عند 200 endpoint". في المشاريع الصغيرة عدد حلقات السلسلة قليل فتصمد الاحتمالات. في المشاريع الكبيرة يعمل الضرب بشكل كارثي.

ما الذي نحتاجه

سبب النجاح وسبب الانهيار يشيران إلى نفس النقطة: وجود أو غياب بوابات التحقق الحتمية.

الوكلاء اليوم تعتمد على سقاطات وُجدت بالصدفة (اختبارات، بناء، linter). لو صُممت بوعي لأصبحت أقوى.

تصميم السقاطة بوعي يعني:

أولاً، تحديد المناطق الخالية من السقاطة. كود بلا اختبارات، API بلا schema، بيانات بلا أنواع. كل مكان يحكم فيه الوكيل احتمالياً هو نقطة ضعف.

ثانياً، رفع كمية المعلومات في التغذية الراجعة. إعادة pass/fail فقط تسبب تصحيحاً مفرطاً. يجب نقل “أين، ولماذا، وما الذي يختلف عن المتوقع” بشكل منظّم.

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

LLM مولّد مذهل. يفرز 1000 كلمة بالتفكير المحض بدقة 97.7%. شيء لا يستطيعه الإنسان. لكن كل ما هو أقل من 100% ينهار بالتكرار. 0.977 مرفوعة للقوة الثانية تساوي 0.954.

وكيل البرمجة يعمل ليس لأن النموذج ذكي. بل لأن داخل الحلقة بوابات حتمية. وينهار حين تغيب تلك البوابات.

التوليد يمكن أن يكون احتمالياً. التحقق يجب أن يكون حتمياً.