عميلي البرمجي أنجز 3 طلبات سحب (PRs) في أمسية واحدة. 40% من رسائلي كانت تصحيحات.
قام عميلي البرمجي المدعوم بالذكاء الاصطناعي بإرسال ثلاثة طلبات سحب (pull requests) في أمسية واحدة، ولكن 40% من أصل 30 رسالة أرسلتُها كانت عبارة عن تصحيحات.
أنتجت الجلسة عميل MCP، وAzure AI Agent، وM365 Copilot Agent. اجتازت جميع طلبات السحب الثلاثة عمليات التحقق الآلية، ولم أقم بتعديل سطر برمجي واحد. ومع ذلك، تروي سجلات المحادثة قصة مختلفة: من بين إجمالي 710 رسائل، كتبتُ أنا 30 رسالة، و12 منها كانت لتوجيه العميل مرة أخرى إلى المسار الصحيح. ويبلغ "معدل التوجيه" (steering rate) – أي نسبة رسائلي التي كانت تصحيحات – 40%.
كيف تم بناء خط العمل (pipeline)
- قام Claude بصياغة خطة تنفيذ عالية المستوى.
- عمل DeepSeek V4-Flash كمنسق (orchestrator)، حيث قام بمراجعة الخطة.
- قام Codex بتوليد الكود الفعلي.
- قام المنسق بفحص الكود وفتح طلبات السحب.
كان الدور المنشود للمنسق ربطياً بحتًا – حيث ينبغي له حل النزاعات بين المكونات، وليس كتابة الكود بنفسه. ومن الناحية العملية، أنتج العميل 3,500 سطر من الكود عبر طلبات السحب الثلاثة في حوالي 40 دقيقة، لكنه تعثر أيضًا في فئتين متكررتين من الأخطاء.
فئتا الأخطاء
- انتهاكات سير العمل (Workflow violations) – كان المنسق يتولى أحيانًا خطوة البرمجة، متجاهلاً دوره كـ "رابط" (glue) وقام بكتابة تفاصيل التنفيذ بنفسه.
- فشل استرجاع السياق (Context-retrieval failures) – على الرغم من التعليمات الصريحة، اختار العميل الـ SDK أو الإصدار الخاطئ. كانت المعلومات الصحيحة موجودة في سياق الأمر (prompt context)، لكن النموذج فشل في إظهارها في الوقت المناسب.
هذه ليست فجوات في القدرة على الاستنتاج؛ بل هي أخطاء هندسية (engineering bugs) في كيفية تقييد سير العمل. فحتى لو كان النموذج اللغوي أكثر قدرة، فسيظل بحاجة إلى قاعدة صارمة لا يمكن إغفالها، تُلزم المنسق بمهامه غير البرمجية وتفرض اختيار الـ SDK الصحيح.
ما قمت بتغييره لترويض العميل
توقفت عن افتراض أن النظام سيستنتج دوره من قائمة الخطوات. أضفتُ عبارة مباشرة: "أنت منسق (orchestrator). أنت لا تقوم بالتنفيذ." استغرق الأمر خمس رسائل تصحيحية حتى تترسخ التعليمات، وبعد ذلك احترم العميل الحدود.
كما قمت بتشديد منطق استرجاع السياق. عندما ظهرت الأداة الخاطئة، تعاملت مع الأمر كخطأ في خط استرجاع البيانات (retrieval pipeline) بدلاً من كونه "هلوسة" (hallucination)، وأعدت كتابة الأمر (prompt) الذي يغذي تفاصيل الـ SDK لجعل من المستحيل إغفال الإصدار الصحيح.
دروس عملية للتطوير المعزز بالذكاء الاصطناعي
- احسب عدد رسائلك الخاصة. يمكن أن يحجب العدد الكبير من طلبات السحب المقبولة عملية معطلة. ويعد عدد تصحيحاتك مؤشرًا رئيسيًا لمكان الخلل في النظام.
- حدد الدور صراحةً. لا يستنبط العملاء هويتهم من قائمة مهام؛ بل يحتاجون إلى تعليمات واضحة ومثبتة حول هويتهم وما يمكنهم فعله.
- عامل أخطاء اختيار الأدوات كأخطاء هندسية. إذا تجاهل العميل SDK محددًا، فإن الخطأ يكمن في آلية تسليم السياق، وليس في "معرفة" النموذج.
- حوّل الأخطاء إلى مهارات قابلة لإعادة الاستخدام. جعلتُ العميل يولد روتين تحقق (validation routine) من أخطائه الخاصة، محولاً الفشل إلى وسيلة حماية مستقبلية.