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

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

حيث يخفق العامل

الحالة الأكثر كشفاً هي تدقيق نظام Java قديم يضم 17 وحدة بدون توثيق محدّث. جمع العامل خريطة معمارية مقنعة: التبعيات والواجهات وأوصاف المكونات والعلاقات بين الخدمات. بدا كل شيء دقيقاً تقريباً حتى وصل إلى طبقة وكيل قديمة بقيت بعد الهجرة إلى قائمة الانتظار.

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

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

"الفرق بين المبرمج والعامل ليس السرعة."

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

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

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

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

تكلفة الأتمتة السريعة

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

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

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

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

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

ماذا يعني هذا

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