استخدم نموذجًا مخصصًا للذكاء الاصطناعي. قضيت أسابيع في اختبار نماذج برمجة بحجم 8B–30B على Azure A100s. النموذج الذي غيّر بنية نظامنا؟ نموذج بـ 137 مليون معلمة، تم تدريبه في 3 دقائق و35 ثانية على Mac mini M2 Pro. كشفت Microsoft’s FastContext عن العقدة: يمكن أن تستهلك استكشاف المستودعات حتى 46.5% من رموز وكيل البرمجة. وقد خفّضت تجاربهم المنشورة استخدام الوكيل الرئيسي بنسبة تصل إلى 60.3%. أنا أخذت الفكرة أبعد من ذلك في DeltaCode: → يُعدّ Go قائمة السياقات القانونية للمستودع → يتعامل مُصنّفنا المخصص بحجم 137M مع الاختيارات الروتينية → يتعامل FastContext 4B فقط مع استكشافات READ/GLOB/GREP الغامضة → يؤدي Qwen3 4B المخصص التحضير البرمجي المسبق → تتلقى النماذج باهظة التكلفة أدلة مضغوطة—وليس مستودعًا كاملًا → تحتفظ المُجمّعات والاختبارات بالسلطة النهائية حقق مُصنّفنا المخصص: • دقة استدعاء (Recall@5) مغلقة بنسبة 57.97% • زيادة قدرها +5.80 نقطة مقارنة بالنموذج القياسي • زيادة قدرها +14.49 نقطة في Recall@1 • دقة استدعاء (Recall@5) بنسبة 73.33% على الحالات الخارجية الموجهة • صلاحية تنفيذية صفرية الفرق في الكفاءة هائل: • 96.6% أقل من عدد المعلمات مقارنة بمُستكشف بحجم 4B • 99.5% أقل من نموذج بحجم 27B–30B • تم تدريب فقط 0.3225% من معلماته • وبالتالي بقيت 99.68% من النموذج الأساسي ثابتة • تم تجنب تكلفة A100 بالكامل لهذا المُكمّل • انخفاض مقدر بنسبة 35–55% في رموز السياق السحابية بمجرد أن يعالج التسلسل عمليات البحث الروتينية في المستودعات محليًا* لم تفشل النماذج الأكبر لأنها افتقرت إلى الذكاء. فشلت لأننا طلبنا من نموذج واحد أن يستكشف، ويستنتج، ويُنسق، ويُبرمج، ويُشغل الأدوات، ويفحص نفسه بنفسه. فازت النماذج الأصغر لأن كل منها كان لديه مهمة واحدة قابلة للقياس. لقد استخدمت تجارب A100 باهظة التكلفة لأتعلم كيف لا أحتاج إلى حوسبة باهظة في الإنتاج. مستقبل وكلاء البرمجة قد لا يكون نموذج LLM ضخمًا واحدًا. قد يكون فريقًا من المتخصصين الصغار—كل منهم مدرب على مهمة واحدة، وكل منهم يُقاس بشكل مستقل، ولا يُوثق به لأي سلطة نهائية.