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

Image: AI generated

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

لماذا تعمل

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

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

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

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

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

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

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

سبب عمل وكلاء البرمجة هو نفسه. LLM غير موثوق يُعلوه مُحققات حتمية (اختبارات، بناء، linters، فاحصو أنواع). دراسة SWE-agent أظهرت أن حتى نفس النموذج يُظهر أداءً مختلفاً جذرياً بحسب تصميم Agent-Computer Interface‏ (Yang et al., NeurIPS 2024). الطوبولوجيا هي سبب النجاح، لا قدرة النموذج.

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

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

لأن السقاطات الموجودة صدفة والسقاطات المُصممة عن وعي شيئان مختلفان.

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

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

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

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

أجريت تجربة ترتيب لـ 1,000 كلمة. CPU: 0.08 مللي ثانية بنسبة 100%. LLM: 438 ثانية بنسبة 97.7%. هذا وحده مذهل — 97.7% بالإدراك المحض. لكن الاكتشاف الحقيقي كان في مكان آخر.

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

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

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

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

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

بدون تلميحات، مهما تكررت المحاولات، تقارب عند 99.4%. فقط حين أُخبر “بقي 6” وصل أخيراً إلى 100%.

نفس الشيء يحدث مع وكلاء البرمجة. الوكيل يصنع خطأ، يُراجع نفسه بـ “يبدو جيداً”، وحين يُطلب منه الإصلاح مرة أخرى، يُغفل نفس الموضع. أظهر Huang et al.‏ (2024) أنه بدون تغذية راجعة خارجية، تصحيح LLM لأخطائه في الاستدلال يُدهور الأداء فعلياً (Huang et al., ICLR 2024). لهذا إعادة المحاولة ليست الجواب. النقاط العمياء قيد بنيوي من الطبيعة الاحتمالية للنموذج، لا نقص في الجهد.

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

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

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

هذا التفسير الرياضي لـ “vibe coding ينهار عند 200 نقطة نهاية.” في المشاريع الصغيرة، عدد السلاسل منخفض بما يكفي لتصمد الاحتمالات. في المشاريع الكبيرة، الضرب يصبح كارثياً.

ما المطلوب

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

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

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

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

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

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

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

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

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

مقالات ذات صلة

• Ratchet Pattern — كيف تجعل الوكيل يُنهي المهمة — بنية ومبادئ نمط السقاطة
• طوبولوجيا التغذية الراجعة أهم من ذكاء النموذج — لماذا بنية التغذية الراجعة أهم من قدرة النموذج
• القيود عقود — كيف تُحرر القيود العقلانية الأنظمة
• filefunc — ملف واحد، مفهوم واحد — بنية كود أصلية لـ LLM
• تفكير AI: 5 خطوات لكسر المسلّمات بالمبادئ الأولى — كيف تفكر مع AI

المراجع

1. Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Shannon, C.E. & McCarthy, J. (Eds.), Automata Studies, Annals of Mathematical Studies, No. 34, Princeton University Press, pp. 43-98.
2. Saltzer, J.H., Reed, D.P., & Clark, D.D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems, 2(4), 277-288.
3. Patterson, D.A., Gibson, G., & Katz, R.H. (1988). “A Case for Redundant Arrays of Inexpensive Disks (RAID).” Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pp. 109-116.
4. Hamming, R.W. (1950). “Error Detecting and Error Correcting Codes.” The Bell System Technical Journal, 29(2), 147-160.
5. Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
6. Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
7. Jimenez, C.E. et al. (2024). “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
8. Yang, J. et al. (2024). “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024.
9. Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
10. Kamoi, R. et al. (2024). “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs.” TACL, 12, 1298-1318.
11. Cemri, M. et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657.
12. Arbuzov, M.L., Shvets, A.A., & Beir, S. (2025). “Beyond Exponential Decay: Rethinking Error Accumulation in Large Language Models.” arXiv:2505.24187.

سجل التغييرات

• 2026-05-16: الإصدار الأول