الكود الأفضل لم يفز: ماذا يكشف نهائي هاكاثون Dev-to-Dev عن هندسة الوكلاء؟

في نهائي Dev-to-Dev: Agentic Engineering Challenge جاء المشروع صاحب أفضل كود في المركز الثاني. 65 اختبار وحدة (unit tests)، وتحديد أنواع كامل، وحماية من path traversal، وحاوية Docker بمستخدم non-root: هي بنية تنمّ عن مهندس جادّ. وهذا بالتحديد هو سبب عدم فوزه.

عندما لا تنقذ جودة الكود صاحبها

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

لكن الهاكاثون قاس شيئًا آخر. فقد قيّم المنظّمون agentive engineering، وهو بالضبط ما كان ينقص هذا المشروع الرفيع الجودة. أما الحل الفائز فكان الأدق فهمًا لما يبحثون عنه.

هندسة الوكلاء لغة مختلفة

مصطلح Agentive engineering حديث العهد (بالكاد مضى عليه عامان)، وكل فريق يضع فيه معنى خاصًا به. لكن نهائي هذا العام أظهر بوضوح أن أنظمة الوكلاء تتطلب أولويات مختلفة. فبدلًا من نظافة الكود، القدرة على التكيّف أثناء العمل. وبدلًا من التغطية الكاملة بالاختبارات، الاستعداد للعمل بمعلومات ناقصة. وبدلًا من البنية المثالية، التكرار والتعلّم من الأخطاء.

وتبيّن أن:

• التفاعلية وسرعة الاستجابة أهم من البنية الداخلية
• القدرة على التكيّف أهم من تحديد الأنواع لكل شيء
• التكرار السريع أهم من التغطية الكاملة بالاختبارات
• التعامل مع عدم اليقين أهم من الضمانات التي توفرها الأنواع

انقسام في الهندسة

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

الأمر لا يقتصر على الكود. إنه يتعلق برؤيتين مختلفتين لمعنى البرمجيات الجيدة.

ماذا يعني ذلك

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