وهم “الفايب كودنج”: عندما تتحول تفاصيل المشروع إلى فخ

في الفترة الأخيرة لاحظت نمط يتكرر مع بعض العملاء في المشاريع التقنية.

العميل يطلب المشروع من أكثر من مستقل، ثم يبدأ يجمع التفاصيل التقنية من كل عرض:

كيف نبني قاعدة البيانات؟ كيف نبرمج الواجهة؟ ما أفضل تقنية للاستخدام؟

ومع الوقت تتكون لديه صورة كاملة “نظرياً” عن كيفية بناء المشروع.

ثم تأتي الفكرة:

“طالما فهمت التفاصيل… يمكنني تنفيذ المشروع بنفسي باستخدام أدوات الذكاء الاصطناعي أو الفايب كودنج.”

لكن ما لا يظهر في هذه المرحلة هو أن كل مستقل كان يشرح جزءاً منفصلاً من الصورة، وليس النظام ككل.

المشكلة تبدأ عندما يتم التنفيذ فعلياً.

كل جزء يبدو صحيحاً وحده، لكن عند دمجه مع باقي الأجزاء تظهر التعقيدات:

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

ومع الوقت، يتحول المشروع من فكرة بسيطة إلى نظام معقد لا يفهمه حتى من قام ببنائه.

النتيجة المفاجئة؟

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

الذكاء الاصطناعي ليس المشكلة هنا.

المشكلة في الاعتقاد أن “معرفة التفاصيل” تعني “القدرة على بناء نظام متكامل”.

هناك فرق كبير بين فهم أجزاء المشروع… وبين تصميمه كمنظومة كاملة.

-----------------

هل تعتقد أن أدوات الذكاء الاصطناعي قربت فعلاً غير المبرمجين من بناء التطبيقات؟

أم أنها فقط أعطتهم إحساساً زائفاً بأن الأمر أصبح أسهل مما هو في الواقع؟


أولًا: تصرف العميل بهذه الطريقة هو تصرف دنيء من وجهة نظري، لأنه يذهب لمن يقدم الخدمة مقابل المال ثم يخدعه لأخذ معلومات ولا يوظفه.

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

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

Seham_Sleem أضف ردا

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

وحتى لو فعل ذلك بمشروع ما، فهل سيفعل ذلك بكل المشاريع؟ فهو بالنهاية ليس لديه خبرة أو علم.

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

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

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

أتفق مع نقطة أن أدوات الذكاء الاصطناعي والـ No-Code جعلت بناء الأشياء البسيطة أسهل بكثير، وهذا شيء إيجابي، لكن المشكلة تظهر عندما يعتقد البعض أن نفس الأسلوب يصلح لبناء أنظمة حقيقية أو أفكار جديدة ومعقدة.

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

ولهذا نرى الكثير من المشاريع تبدأ بسرعة ثم تتعقد عند أول تعديل أو توسعة أو مشكلة حقيقية في الاستخدام.

  • حذف بواسطة المستخدم