مع صعود وكلاء الذكاء الاصطناعي: مهمة المهندس تصبح تصميم الحدود التي لا يمكن كسرها

لم تعد كتابة أول نسخة من الكود هي الجزء الأصعب دائماً، خصوصاً في مهام مثل تكاملات الـ API أو بناء أجزاء من data pipelines. فمع أدوات مثل Cursor وClaude Code، يمكن للوكيل أن يقرأ Repository، يقترح تعديلاً، يشغّل الاختبارات، ثم يحاول إصلاح ما فشل.

لكن مقالاً منشوراً في VentureBeat يلفت إلى أن هذه القدرة لا تجعل مهندس البرمجيات مجرد مراجع لـ Pull Requests. بل تنقل مركز العمل إلى مستوى أعلى: تصميم الحدود التي تجعل مخرجات الوكيل قابلة للثقة. (venturebeat.com)

المشكلة ليست في أن الوكيل لا يستطيع توليد الكود، بل في أنه قد يواصل العمل انطلاقاً من افتراض قديم، أو يخلط بين سياقات متعارضة، أو يعالج عرضاً بدلاً من السبب الحقيقي. ويصف المقال هذا التراكم من الافتراضات القديمة والاعتماديات غير المحسومة داخل دورة العمل بأنه نوع من «الإنتروبيا التشغيلية». هنا تصبح الاختبارات الفاشلة، وdata contracts الدقيقة، والأدوات الحتمية، والتقييمات الواضحة إشارات تصحيح تعيد الوكيل إلى المسار الصحيح. (venturebeat.com)

تظهر أهمية ذلك أكثر داخل أنظمة المؤسسات. قد ينجح تغيير ما في اختبارات الأنواع وقابلية القيم الفارغة، لكنه يظل خاطئاً من ناحية business logic. ويضرب المقال مثالاً افتراضياً لحقل customer_tier: قد يعثر الوكيل على حقل status ويستخدمه في نموذج الإيرادات، فيمر الـ pipeline تقنياً، رغم أن تعريف الحقل الصحيح يجب أن يستند إلى إنفاق العميل خلال آخر 12 شهراً لا إلى حالته في قاعدة التشغيل.

في هذا المثال، لا تكون مساهمة المهندس في كتابة transformation نفسها، بل في وضع semantic data contract يحدد مصدر الحقل ومعناه ومالكه التجاري والقواعد التي تمنع استخدام مصدر خاطئ. بهذه الطريقة يصبح الخطأ قابلاً للاكتشاف والتفسير والإصلاح قبل وصوله إلى Dashboard. (venturebeat.com)

ويقترح المقال أن بناء «التوازن» في بيئات العمل المعتمدة على الوكلاء يعتمد على ممارسات معروفة في هندسة المنصات، منها:

• طبقات semantic واضحة وصارمة.
• immutable event logs.
• data contracts محددة.
• APIs idempotent.
• deterministic state machines.

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

الخلاصة: مع انخفاض كلفة توليد الكود، لا تختفي هندسة البرمجيات. ما يزداد أهمية هو تصميم النظام الذي يحدد ما الذي يستطيع الوكيل فعله، وكيف نتحقق من صحته، ومتى يجب إيقافه أو تصحيح مساره. (venturebeat.com)