هل ما زلت بحاجة إلى كتابة الكود في عصر وكلاء الذكاء الاصطناعي؟

السؤال الذي يطرحه كل مسؤول تقني هذه الأيام

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

ما يفعله وكيل الذكاء الاصطناعي فعلاً

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

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

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

من يفهم النظام بعد ستة أشهر؟

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

الحل ليس في منع الأدوات، بل في فرض انضباط هندسي حولها:

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

ما يجب طلبه قبل الموافقة على أي مشروع

إذا كنت تتعاقد مع مطوّر أو فريق، سواء كان مستقلاً أو شركة، فهذه أسئلة عملية تكشف مستوى الجدية:

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

هذه الأسئلة لا تحتاج خلفية تقنية عميقة لطرحها، لكنها تفصل بين مشروع يُبنى ليعيش، ومشروع يُبنى ليُعرض.

أين تبقى الحاجة إلى المطوّر؟

تبقى الحاجة إلى المطوّر في كل ما لا تستطيع الأداة رؤيته:

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

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

خلاصة عملية

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

لنناقش مشروعك

إذا كنت تفكر في بناء نظام يعتمد على الذكاء الاصطناعي، أو ترغب في مراجعة مشروع قائم للتأكد من أن أساسه التقني متين، يمكنك التواصل عبر contact@hamzabelgacem.com. نبدأ عادة بجلسة قصيرة لفهم الحاجة قبل الحديث عن التقنية، لأن القرار الجيد يبدأ من السؤال الصحيح.