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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


التعليق السابق

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

Seham_Sleem أضف ردا

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

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

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

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

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