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

المشكلة ليست في السرعة، بل في الفهم

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

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

لماذا يزيد الكود المولَّد من هشاشة الأنظمة

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

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

قاعدة أساسية: من يطلب الكود يفهمه أولًا

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

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

روتين مراجعة يعمل فعليًا

المراجعة الجيدة للكود المولَّد لا تحتاج أدوات معقّدة، بل روتينًا ثابتًا:

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

التوثيق كأداة دفاع

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

متى تتوقف عن التوليد وتكتب بنفسك

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

الخلاصة: السيطرة عادة لا أداة

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

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

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