أفكارٌ
أعود إليها

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

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

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

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

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

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

أما اليوم فهذا المعيار يتغيّر. التركيز ينتقل من عدد الساعات المبذولة إلى جودة القرار ودقّة النتيجة.

لم يعد السؤال: «كم استغرق ذلك من وقت؟»

صار السؤال: «هل اتخذت القرار الصحيح، وهل حققت النتيجة الصحيحة؟»

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

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

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

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

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

هذه خوارزمية جشعة. تعمل جيداً إلى أن تتوقف عن ذلك.

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

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

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

الخوارزمية المجرية تحلّها بدقة، بتعقيد O(n³). فبدلاً من المرور على الطلبات واحداً تلو الآخر، تبني مصفوفة كل متخصص مقابل كل مقعد مفتوح، وتجد أفضل إسناد عبرها جميعاً معاً.

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

هي أبطأ، بنحو ثمانية أضعاف. عند 150 متخصصاً تستغرق 160 ميلي ثانية. أما العمل الذي تحلّ محلّه فيأخذ من الإنسان ثلاثة أيام.

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

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

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

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

أتفق مع الفكرة، لكن هناك نقطة مهمة تستحق التوضيح.

المشكلة ليست أن Git «لا يسمح» لنا برفع ملفات .env. تقنياً نستطيع ذلك. السبب الذي يجعلنا عادةً لا نفعله هو أن ملف .env قد يحتوي معلومات حساسة: مفاتيح واجهات برمجية، وكلمات مرور، وبيانات اعتماد قواعد البيانات.

لذلك فالسؤال الأفضل برأيي ليس: لماذا لا نضع .env في Git؟ بل: هل نفعل ذلك لأنه الصواب فعلاً، أم لأننا هكذا اعتدنا دائماً؟

والحل ليس بالضرورة رفع ملف .env الحقيقي.

يمكننا مثلاً رفع ملف .env.example يضم كل المتغيرات التي يحتاجها المشروع دون القيم السرية الفعلية، مع إدارة الأسرار نفسها عبر مدير أسرار أو نظام مركزي لإدارتها.

وأعتقد أن هذا هو أهم ما يمكن الخروج به من النقاش كله.

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

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