من كتابة الأكواد إلى هندسة المنطق والأنظمة
مشهد البداية: السهولة التي تخفي جبلاً من المنطق
تفتح هاتفك، تطلب عشاءك من تطبيق اعتدت عليه. في دقائق قليلة، تظهر لك قائمة بالمطاعم القريبة، وصور الأطباق، وتقييمات الزبائن، وتكلفة التوصيل، وزمن وصول تقديري يبدو دقيقًا حدّ السحر. تضغط زرّ الطلب، وقبل أن تغلق الشاشة تكون قد تلقيت إشعارًا بأن المطعم بدأ التحضير، وتتحرك أيقونة صغيرة على الخريطة تتبع مسار ساعي التوصيل في الشوارع المزدحمة.
خلف هذه السهولة الناعمة التي لا تكلفك أكثر من لمسات قليلة، يقف جبل جليدي هائل من المنطق المترابط:
- نظام إدارة قوائم الطعام
- بوابة دفع إلكتروني مشفّرة
- خوارزمية توزيع ديناميكية تقرر أي ساعي يذهب لأي مطعم ليلتقط أي طلب في أقل زمن ممكن
- نظام تتبع حيّ بالمواقع الجغرافية
- قواعد عمل تحدد متى يصبح الطلب مؤكدًا ومتى يمكن إلغاؤه
- آلية إشعارات فورية تصل إلى هاتفك، وهاتف الساعي، ولوحة المطعم في آن واحد
كل هذا يحدث بصمت، في ثوانٍ، دون أن تشعر أنك تتعامل مع «برنامج».
نحن نعيش في عالم أصبح التفاعل فيه مع البرمجيات سلسًا إلى درجة التلاشي. لكن هذه الشفافية تخفي وراءها مفارقة كبرى: كلما صارت البرمجيات أكثر نعومة في حياتنا اليومية، صار فهمنا للبرمجة أكثر سطحية. وفي اللحظة التي دخل فيها الذكاء الاصطناعي إلى مشهد بناء البرمجيات، اكتمل الارتباك. صرنا نسمع أن الذكاء الاصطناعي صار يكتب الكود، وأن المبرمجين سيختفون، وأن تعلم لغة برمجة ربما أصبح استثمارًا خاسرًا.
لكن السؤال الحقيقي ليس «هل ستختفي البرمجة؟» بل سؤال أكثر عمقًا:
هل كنا نعرف أصلًا ما البرمجة، حتى نحكم أنها في خطر؟
1. لماذا أصبحت صورة البرمجة مشوشة؟
ليس من الصعب أن نرى لماذا اختلطت الأمور على كثيرين. افتح أي منصة تقنية خلال العامين الماضيين، وستجد طوفانًا من العناوين: «ChatGPT يكتب تطبيقًا كاملًا في دقائق»، «نهاية المبرمجين»، «الذكاء الاصطناعي يجتاز مقابلات غوغل». تضافرت ثلاثة عوامل على الأقل لتشويه صورتنا عن البرمجة.
العامل الأول: توليد الكود بضغطة زر
المساعدات الذكية داخل المحررات البرمجية أصبحت تقترح أسطرًا، بل دوالًا كاملة، بدقة متزايدة. مبرمج مبتدئ يستطيع الآن أن يطلب من نموذج لغوي كبير أن يبني له صفحة تسجيل دخول، فيحصل على كود HTML و CSS و JavaScript جاهز، وربما لا يفهم تمامًا كيف يعمل، لكنه يعمل.
العامل الثاني: اختزال البرمجة في كتابة الكود
لعقود، كانت صورة المبرمج في المخيلة الجمعية هي شخص يجلس أمام شاشة سوداء يكتب تعويذات نصية غامضة. هذه الصورة راسخة لدرجة أن أي أداة تنتج نصوصًا مشابهة، يبدو وكأنها تفعل الشيء نفسه. وحين تفعل ذلك بسرعة أكبر، يخيّل إلينا أنها «تبرمج».
العامل الثالث: وهم الاختفاء
إذا كانت الآلة قادرة على إنتاج الكود الذي كان يكتبه الإنسان، فهذا يعني - في منطق السطح - أن الحاجة إلى الإنسان تلاشت. لكن هذا الاستنتاج يتجاهل حقيقة مركزية: الكود لم يكن يومًا سوى الأثر الأخير لعملية أطول وأعمق بكثير.
2. هل كانت البرمجة يومًا مجرد كتابة أكواد؟
حتى قبل ظهور المساعدات الذكية، كان هناك فارق كبير بين من يتقن لغة برمجة وبين من يفهم البرمجة. اللغة مجرد وسيلة تعبير؛ إنها أداة لصياغة المنطق، تمامًا كما أن اللغة العربية وسيلة للتعبير عن فكرة، لكن إتقان الإملاء والنحو لا يجعلك روائيًا.
تخيل مهندسًا مدنيًا يصمم جسرًا. قبل أن تُسكب الخرسانة، هناك شهور من العمل: دراسة التربة، حساب الأحمال، نمذجة الإجهادات، تقييم خيارات المواد، تحديد هوامش الأمان. المخططات الهندسية ليست الجسر، بل تمثيل رمزي له. في البرمجة، الكود هو المخططات والخرسانة معًا؛ لكن عملية التفكير التي تسبقه، هي الجوهر.
الكود وعاء مؤقت للمنطق
لاحظ أن منطق حساب الخصم لعملاء فئة معينة لا يتغير في روحه إن كتبته بلغة Python أو Java أو حتى بلغة لم تخترع بعد. ما يتغير هو طريقة التعبير عنه، لا جوهره. اللغات والأطر البرمجية أدوات فانية، أما القدرة على تحليل المشكلة وصياغة حلها في صورة نموذج ذهني، فتلك هي المهارة التي تنتقل معك من مشروع لآخر ومن عقد لآخر.
لحظة ما قبل الكود: التفكيك والنمذجة
خذ مثالاً عمليًا: تريد بناء تطبيق لإدارة مكتبة. أنت لا تبدأ بكتابة class Book. أنت تبدأ بأسئلة:
- ما الكيانات التي نتعامل معها؟ أعضاء، كتب، إعارات.
- ما العلاقات بينها؟ العضو يستعير نسخة من كتاب.
- ما القواعد؟ لا يستطيع العضو استعارة أكثر من 3 كتب في آن واحد، مدة الإعارة أسبوعان قابلة للتجديد إن لم يحجزها غيرُه.
- ما السيناريوهات الخاصة؟ ماذا لو أعاد كتابًا تالفًا؟ ماذا لو تأخر؟
هذا النموذج المفاهيمي - بقواعده وعلاقاته - هو قلب النظام. تستطيع فيما بعد أن تطلب من مساعد ذكي أن يترجم هذا كله إلى أكواد SQL و REST API، لكن التصميم نفسه ليس كودًا. إنه منطق صافٍ، يعيش خارج شاشة المحرر.
3. كيف تتحول المشكلات إلى أنظمة؟
كل نظام برمجي، مهما بدا معقدًا، هو في الأصل إجابة عن مجموعة من الأسئلة الصحيحة. المبرمج الفعلي هو من يعرف كيف يطرح هذه الأسئلة، وكيف يحول الإجابات إلى بنية متماسكة. هذه العملية تتبع نمطًا يمكن ملاحظته في أي مشروع ناجح:
- تفكيك المشكلة إلى أجزاء يمكن التفكير فيها بشكل مستقل.
- تقسيمها إلى مكونات ذات مسؤوليات واضحة.
- تصميم العلاقات والعقود بين هذه المكونات.
تطبيق عملي: تفكيك تطبيق طلب الطعام
ظاهريًا، هو واجهة بسيطة: تختار طعامًا، تدفع، يصلك. لكن كي يحدث هذا، كان على من صمموا النظام أن يفككوا رحلة المستخدم إلى طبقات من المسؤوليات:
- نظام إدارة المستخدمين: حسابات، عناوين، وسائل دفع.
- نظام إدارة المطاعم: قوائم طعام، ساعات عمل، مناطق تغطية.
- نظام الطلبات: حالات الطلب (قيد المراجعة، قيد التحضير، قيد التوصيل، مكتمل).
- محرك التوصيل: خوارزمية توفيق بين السائقين المتاحين والطلبات الجاهزة، تأخذ في الحسبان المسافة، وزمن التوصيل المتوقع، وعدد الطلبات المعلقة.
كل جزء من هذه الأجزاء يمثل مجالًا مستقلًا بذاته، له قواعده الخاصة، ويتواصل مع غيره عبر عقود واضحة: «عندما يصبح الطلب في حالة جاهز للتوصيل، أرسِل إشعارًا إلى نظام التوصيل مع الموقع الحالي للمطعم وموقع العميل». هذا التقسيم ليس رفاهية أكاديمية؛ إنه شرط البقاء لأي نظام سيتطور مع الزمن. بدونه، يتحول الكود إلى كتلة هشة، أي تغيير فيها يكسر شيئًا آخر لا علاقة له ظاهريًا.
مثال آخر: تطبيق خرائط
خلف واجهة بسيطة تظهر لك أفضل مسار بين نقطتين، توجد طبقات:
- بيانات الخرائط (شبكة الطرق، إشارات المرور، الشوارع المغلقة)
- محرك حساب المسارات (خوارزمية ديكسترا أو متغيراتها)
- بيانات الزحام الحيّ (تتدفق من هواتف ملايين المستخدمين)
- طبقة العرض
كل طبقة تُحل مشكلة محددة، وتتعاون مع غيرها لإنتاج التجربة النهائية. المبرمج الذي صمم هذه العمارة لم يكن مشغولًا بصياغة for loop، بل كان مشغولًا بتقسيم العالم إلى قطع يمكن التفكير فيها واحدةً واحدة.
4. ماذا غيّر الذكاء الاصطناعي فعليًا؟
التغيير الذي أحدثته النماذج اللغوية الكبيرة ليس أنها بدأت «تبرمج»، بل أنها نقلت نقطة الجهد في دورة حياة البرمجيات. لقد قلّصت المسافة بين الفكرة والكود، وجعلت توليد الشيفرات المصدرية أسرع وأرخص، ولكنها لم تلغِ المراحل التي تسبق الكود وتليه. بمعنى آخر: سهّلت التعبير، ولم تحل محل الفهم.
ما الذي تغير؟
تغيرت طبيعة العمل اليومي للمبرمج. أجزاء كبيرة من كتابة الكود النمطي - كتابة دوال تحقق من صحة البيانات، بناء واجهات برمجة تطبيقات متكررة، إنشاء هيكل ملفات أولي لمشروع جديد - صارت تتم في ثوانٍ. هذا يحرر وقت المبرمج ليقضيه في المكان الأهم:
- تصميم النظام ككل
- مراجعة التوليدات التي ينتجها الذكاء الاصطناعي
- فهم العواقب البعيدة للقرارات التقنية
ما الذي لم يتغير؟
الحاجة إلى إنسان يفهم السياق، ويستطيع التمييز بين الحل الصحيح والحل المناسب. الذكاء الاصطناعي يقترح حلولاً مبنية على أنماط رآها في بيانات التدريب، لكنه لا يعرف أن:
- عميلك لديه نظام قديم يجب التكامل معه
- أداء قاعدة البيانات في بيئتك الإنتاجية مختلف عن المثالي النظري
- قرارًا تقنيًا قد يحمل تداعيات أمنية أو قانونية
هو لا يشعر بالمسؤولية إن فشل الدفع، ولا يقلق من تداعيات خلل أمني.
الأسطورة: الذكاء الاصطناعي سيكتب الكود بدلاً مني، إذن أنا لم أعد ضروريًا.
الواقع: الذكاء الاصطناعي يكتب الكود بناءً على توجيهي، ومراجعتي، وفهمي للسياق. تبقى المسؤولية النهائية على عاتقي.
أين يساعد الذكاء الاصطناعي؟
يساعد بشكل هائل في:
- تسريع التنفيذ وتقليل العمل اليدوي المتكرر
- توليد نماذج أولية سريعة
- اقتراح اختبارات وحالات تغطية
- شرح كود غامض كتبه غيرك
إنه مسرّع إنتاجية، مثلما كانت المجمعات (Compilers) حين ظهرت نقلت المبرمج من كتابة لغة الآلة إلى لغات أعلى مستوى، فلم تختف البرمجة بل تحررت طاقتها لتصميم أنظمة أعقد.
أين لا يزال الإنسان ضروريًا؟
في اللحظة التي يتحول فيها السؤال من «كيف نكتب هذا؟» إلى:
- ماذا يجب أن نبني؟
- ولماذا؟
- وما القيود؟
- وكيف سنعرف أننا بنيناه بشكل صحيح؟
هذه أسئلة تتعلق بالحكم، والتقدير، وفهم العالم الحقيقي. لا يمكن اختزالها إلى تنبؤ بالكلمة التالية في سلسلة نصية.
5. إذا لم تكن البرمجة كتابة كود، فما هي إذًا؟
البرمجة، في جوهرها الذي لا تبليه الأدوات، هي طريقة تفكير قبل أن تكون طريقة كتابة. هي ثلاثة أركان متداخلة، لا يقوم أي منها على لغة بعينها أو محرر نصوص.
الركن الأول: البرمجة كطريقة تفكير
إنها القدرة على رؤية المشكلة من زوايا متعددة، وتفكيكها إلى خطوات قابلة للتنفيذ. حين يطلب منك مدير مشروع أن «تضيف ميزة تقييم المطاعم»، فأنت لا تترجم الجملة إلى كود مباشرة. أنت تسأل:
- من يستطيع التقييم؟ هل فقط من أكمل طلبًا؟
- هل التقييم العلني يؤثر في ترتيب المطعم؟
- ماذا لو حاول صاحب مطعم التلاعب؟
هذا التفكير هو البرمجة، حتى قبل أن تفتح المحرر.
الركن الثاني: البرمجة كبناء نماذج
كل برنامج هو محاكاة لجزء صغير من العالم. نموذج يعكس كيانات العالم الحقيقي (مستخدم، طلب، منتج) وقواعد التفاعل بينها. بناء النموذج يتطلب اختيار:
- أي التفاصيل نضمّنها وأيها نهمله
- أي العلاقات نصنعها صريحة
هذا الاختيار ليس تقنيًا بحتًا، بل ينبع من فهم عميق للمجال. نموذج مكتبة يختلف عن نموذج متجر كتب، مع أن كليهما فيه «كتاب»؛ لأن سياق الاستخدام مختلف.
الركن الثالث: البرمجة كتصميم أنظمة
عندما تنمو البرمجيات، لا تعود المسألة مجرد نموذج واحد، بل شبكة من النماذج تتفاعل عبر الزمن. تصميم النظام هو تحديد:
- من يتحدث إلى من؟
- من يملك البيانات؟
- كيف تتدفق الأحداث؟
إنه هندسة التدفق. هذا الركن يستدعي مهارات من هندسة النظم، وإدارة التعقيد، وفهم المقايضات:
- الأمان مقابل سهولة الاستخدام
- الأداء مقابل المرونة
- السرعة في البناء مقابل سهولة الصيانة مستقبلًا
6. هل تتغير هوية المبرمج؟
إذا كانت البرمجة هي بناء المنطق وتصميم الأنظمة، فإن المبرمج في عصر الذكاء الاصطناعي لا يختفي، بل تتبدل أولوياته. هناك مهارات ستتراجع أهميتها النسبية، وأخرى ستصعد، ويبرز دور جديد يمكن أن نسميه «مهندس المعرفة والمنطق».
مهارات قد تتراجع
- الحفظ الصرف لتراكيب اللغة
- التباهي بكتابة خوارزميات يدويًا دون الاستعانة بأدوات
- كتابة كود نمطي متكرر
هذه المهام كانت تشغل حيزًا كبيرًا من وقت المبرمجين، واليوم صار بالإمكان أتمتة قدر كبير منها.
مهارات ستزداد قيمة
- صياغة المشكلة بدقة قبل طلب الحل
- القدرة على مراجعة الكود المُولّد والتحقق من صحته وأمانه وكفاءته
- تصميم العمارة الشاملة للنظام
- فهم التفاعلات بين المكونات
- التواصل مع أصحاب المصلحة غير التقنيين لاستخراج المتطلبات الحقيقية
- اتخاذ قرارات المقايضة الصعبة
دور الإنسان داخل الحلقة
في كل نظام برمجي حقيقي، هناك حلقة تغذية راجعة مستمرة: نلاحظ سلوك النظام في بيئة الإنتاج، نكتشف مشكلات لم نتوقعها، نفهم احتياجات المستخدمين الجديدة، نعيد تصميم أجزاء من النموذج. الذكاء الاصطناعي لا يستطيع إدارة هذه الحلقة بمفرده، لأنه:
- لا يملك فضولًا
- لا يشعر بألم المستخدم
- لا يستطيع قراءة تعابير وجه مدير المنتج حين يسمع عن خطأ تسبب في خسارة مالية
المبرمج الجديد يشبه قائد الأوركسترا أكثر مما يشبه عامل البناء. إنه يوجه مجموعة من الأدوات الذكية، ويعرف متى يثق في اقتراحاتها ومتى يتدخل، ويحتفظ في ذهنه بصورة عن العمل الكامل. المسمى الوظيفي قد لا يتغير، لكن الروح مختلفة: أنت لم تعد تنفق طاقتك على هجاء الكلمات، بل على صياغة المعنى.
الخاتمة: العودة إلى المشهد الأول
حان وقت العودة إلى المشهد الذي افتتحنا به. تخيل المطور الذي كان يحدق في محرر الأكواد، وقد ملأته الحيرة وهو يرى المساعد الذكي يقترح كودًا كاملًا لدالة حساب الخصم. هذا المطور نفسه، بعد أن رفع بصره من التفاصيل الصغيرة، صار يرى ما هو أبعد. لم يعد يسأل: «ماذا أفعل هنا؟»، بل صار يسأل:
- هل شروط الخصم هذه تعكس سياسة الشركة الجديدة؟
- هل تتعامل الدالة مع الحالات النادرة؟
- هل موقعها في هيكل المشروع صحيح؟
تحرر من عبء التهجئة، لينشغل بالمعنى والتصميم والعواقب. وهذا هو جوهر التحول. لم تلغِ الآلةُ المبرمجَ، بل جردته من طبقة كان يظنها جوهره، ليكتشف أن جوهره الحقيقي كان دائمًا في مكان آخر: في القدرة على فهم الفوضى وترجمتها إلى نظام، وفي تحويل المتطلبات الغامضة إلى نماذج صارمة، وفي بناء عوالم رقمية لا تنهار عند أول ريح.
قد تتغير الأدوات التي نكتب بها البرمجيات، وقد تصبح كتابة الكود الفعلية مهمة هامشية في سير العمل اليومي. لكن الحاجة إلى من يفهم المشكلات ويبني المنطق الذي يحلها تبدو أكثر رسوخًا من أي وقت مضى.
لأن المشكلات التي تواجه البشر لن تتوقف عن التعقد، ولأن ترجمة هذا التعقيد إلى أنظمة قابلة للعمل ستظل تحتاج إلى ذلك الشيء الذي لا تملكه الآلة: وعي بالسياق، وإحساس بالمسؤولية، وقدرة على تخيل ما لم يُبنَ بعد.