ماذا لو تم تخزين قاعدة الشيفرة فعليا في Postgres وقام الوكلاء بتعديل الملفات مباشرة عن طريق القراءة/الكتابة إلى قاعدة البيانات؟ سرعة الشيفرة زادت بمعدل 3-5 أضعاف. وهذا سيستمر بلا شك. لقد أصبحت مراجعة العلاقات العامة بالفعل عنق زجاجة للفرق ذات الإنتاج العالي. تم التحقق من قاعدة الشيفرة على نظام الملفات يبدو كبدائي سيء عندما يكون لديك 10-100-1000 وكيل يكتبون الكود. الكود الآن بيانات عالية السرعة ويجب نمذجته بهذه الطريقة. على الأقل، نحتاج إلى ذرية على مستوى الكتابة وتنسيق أفضل بين الوكلاء، وأساسيات مزامنة أفضل للاشتراك في تغييرات حالة قاعدة الكود، ومراجعة كود على مستوى ملف في الوقت الحقيقي. النموذج الحالي ~20 عاما لفحص git للخروج/الفرع/الدفع/العلاقات العامة/المراجعة/إعادة القاعدة انتهى في يناير 2026. نحتاج إلى نظام أساسي جديد تماما لكتابة الكود إذا أردنا حقا مواكبة قوانين الحجم.

🚨المعلوم: اختبرت علي بابا عوامل ترميز الذكاء الاصطناعي على 100 قاعدة شيفرة حقيقية، تمتد كل منها على مدار 233 يوما. فشل العملاء فشلا ذريعا. اتضح أن اجتياز الاختبارات مرة واحدة أمر سهل. الحفاظ على الكود لمدة 8 أشهر دون أن يكسر كل شيء هو ما ينهار فيه الذكاء الاصطناعي. SWE-CI هو أول معيار يقيس صيانة الشيفرة طويلة الأمد بدلا من إصلاحات الأخطاء السريعة مرة واحدة. تتبع كل مهمة 71 التزاما متتاليا من التطور الحقيقي. 75٪ من نماذج الذكاء الاصطناعي تكسر كود يعمل سابقا أثناء الصيانة. فقط Claude Opus 4 يبقى فوق معدل انحدار صفري 50٪. كل نموذج آخر يتراكم عليه الدين التقني الذي يتراكم مع التكرارات. إليك الجزء القاسي: - تقييم الإنسان ومشروع SWE-bench "هل يعمل الآن؟" - مقياس SWE-CI "هل لا يزال يعمل بعد 6 أشهر من التغييرات" الوكلاء المحسنون لاختبار اللقطات يكتبون كودا هشا يجتاز الاختبارات اليوم لكنه يصبح غير قابل للصيانة غدا. بنت علي بابا EvoScore لوزن الإصدارات اللاحقة بوزن أثقل من النسخ المبكرة. العملاء الذين يضحون بجودة الكود من أجل انتصارات سريعة يعاقبون عندما تتراكم العواقب. سرد البرمجة حول الذكاء الاصطناعي أصبح أكثر صدقا: معظم النماذج يمكنها كتابة الكود. نادرا ما يستطيع أحد الحفاظ عليه.