Senar: لماذا لا تحل وكلاء الذكاء الاصطناعي محل المبرمجين بل تغيّر عملية التطوير

في الجزء الثاني من سلسلة SENAR لا يتناول الكاتب جودة النماذج، بل عملية التطوير نفسها مع وكلاء الذكاء الاصطناعي. الفكرة الرئيسية بسيطة: قد يكتب الوكيل الكود أسرع من الإنسان، لكنه لا يتصرف كمهندس حين يواجه فجوة في المعرفة.

أين يخطئ الوكيل

أوضح الحالات دلالةً تدقيقٌ لنظام Java قديم يضم 17 وحدة ولا يملك توثيقًا محدّثًا. بنى الوكيل خريطة معمارية مقنعة: التبعيات والواجهات ووصف المكوّنات والروابط بين الخدمات. بدا كل شيء تقريبًا دقيقًا، حتى وصل إلى طبقة وكيل (proxy) قديمة بقيت بعد الانتقال إلى طابور الرسائل. في الكود بدت هذه الطبقة كاستدعاء HTTP عادي، فوصفها الوكيل بثقة على أنها جزء اعتيادي من البنية المعمارية، مع أنها بالنسبة إلى من عملوا على المشروع سابقًا حلّ مؤقت ترقيعي وأثر لقرار قديم.

هنا يظهر الفرق الجوهري بين الوكيل والمطوّر. الإنسان يلاحظ عادةً البنية الغريبة، ويسجّل المخاطرة، ثم يسأل الفريق أو كاتب الكود عن تاريخ القرار. أما الوكيل فغالبًا ما يُكمل التفسير الناقص بنفسه: يصوغ سببًا منطقيًا، ويخترع غرضًا، ولا يفصل بين الحقيقة الموجودة في المستودع وبين إعادة البناء التي أجراها بنفسه. وكلما بدت النتيجة أكثر إتقانًا، زاد احتمال أن يفوت الخطأ على المراجعة ويُؤخذ الافتراض على أنه حقيقة معمارية.

«الفرق بين المبرمج والوكيل ليس في السرعة».

خمسة استنتاجات رئيسية

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

• ليست لدى الوكيل ذاكرة للمشروع: إذا لم يُنقل إليه تاريخ القرارات صراحةً، فهو غير موجود بالنسبة إليه.
• ينفّذ المهمة حرفيًا، ولا يستكمل السياق التجاري كما يفعل المطوّر المتمرّس.
• افتراض خاطئ واحد يتكاثر سريعًا عبر سلسلة من الملفات والأدوات المساعدة المتشابهة.
• لا يرى الوكيل البنية المعمارية خارج حدود الأمر (prompt) الحالي، ويختار المسار الأنسب محليًا.
• لا يعيش مع عواقب قراراته، ولذلك تبقى المسؤولية عن الإصدار والبيانات على عاتق الإنسان.

الاستنتاج العملي من هذه الملاحظات صارم: يجب ألا تتضمن المهمة الهدف ومعايير القبول فحسب، بل أيضًا السيناريوهات السلبية والقيود والمحظورات والأطر المعمارية. فإذا تُركت فراغات، سيملؤها الوكيل بنفسه. لذلك تشترط بوابة الجودة عند المدخل في SENAR أن تُجمع المواصفات والسياق أولًا، ثم يبدأ التوليد. والسرعة مفيدة هنا فقط عندما يضيّق الإنسان مسبقًا مساحة التخمين.

ثمن الأتمتة السريعة

الكود السريع من الوكيل ينتج نوعًا مختلفًا من الدَّين — الدَّين المعرفي. قد تعمل الوحدة، وتنجح الاختبارات، ويصمت أداة الفحص (linter)، لكن الفريق لا يفهم لماذا بُنيت على هذا النحو وأي قرارات مضمَّنة فيها. يسوق الكاتب مثالًا لوحدة تخزين مؤقت (cache) بنحو 500 سطر: بعد أسبوعين تقريبًا احتاج الفريق إلى تغيير استراتيجية إزالة البيانات القديمة، فبدل ساعة واحدة للتعديل استغرق الأمر نصف يوم لاستعادة منطق لم يتخذه أي إنسان صراحةً ولم يوثّقه.

ولكي لا تُحجب الأعطال المنهجية خلف التعديلات اليدوية، يقترح الكاتب قياس MIR — نسبة المهام التي اضطر فيها الإنسان إلى التدخل في الكود يدويًا بعد عمل الوكيل. في المشاريع الناضجة ظل هذا المؤشر لديه في نطاق 5–15%، وعند بداية مشروع جديد نحو 20%. والغاية ليست تقريرًا جميلًا، بل تغذية راجعة: إذا تكررت التعديلات اليدوية، فالمشكلة ليست في ملف واحد، بل في السياق أو المواصفات أو الحدود المعمارية أو النموذج المختار.

الدور الجديد للمهندس

لهذا يتغير أيضًا دور الإنسان في الفريق. بتقدير الكاتب، يذهب الآن ما يصل إلى 60% من الوقت إلى صياغة المهام وجمع السياق واتخاذ القرارات المعمارية، ونحو 30% إلى فحص النتائج، و10% أخرى إلى ضبط الأدوات والمقاييس والعملية نفسها. لم تعد كتابة الكود محور العمل: صار المهندس أقرب إلى من يحدد هوامش التسامح، ويفكك النظام المعقد إلى أجزاء، ويتحقق من أن المخرجات الأنيقة للوكيل لم تتحول إلى خطأ مكلف.

ويرد استنتاج منفصل بنبرة حاسمة: كل ما لم يُدوَّن غير موجود بالنسبة إلى الوكيل. فإذا كانت حدود الوحدات وأعراف واجهات API وأسباب القرارات السابقة والتبعيات المحظورة موجودة في رأس قائد الفريق التقني فقط، فالوكيل سينتهكها على الأرجح، لأن الاستيراد قد يعمل تقنيًا والاختبارات قد تنجح. لذلك لا تهدف الوثائق في نموذج SENAR إلى إعداد التقارير، بل تعمل كواجهة تشغيلية بين الإنسان والوكيل والمطوّرين المستقبليين الذين سيتولون صيانة هذا الكود.

ماذا يعني ذلك

بالنسبة إلى الفرق التي تدمج وكلاء الذكاء الاصطناعي في التطوير بجدية، ليس الخبر الأهم أنهم يسرّعون التطوير. الأهم أن السرعة، من دون مواصفات صارمة وتوثيق للقرارات وتحقق مستمر، تتحول سريعًا إلى دَين معرفي، ويصبح المهندس من كاتب للكود إلى محرر ومعماري ومراقب للجودة.