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

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

المسودة الأولى ليست هندسة

أراقب عدداً متزايداً من المطورين المبتدئين وهم يعاملون ChatGPT أو Claude كأنهم المهندس الخبير الجالس في المقعد المجاور. يقومون بلصق وصف التذكرة، ونسخ الرد، وتشغيل الاختبارات، ثم عمل commit. إذا تم تجميع الكود (compiles)، تُغلق المهمة. هذه الحلقة سريعة، وسلسة، وخطيرة.

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

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

تتعلم من خلال الصعوبات

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

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

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

الحكم يتفوق على التوليد

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

أفضل المهندسين الذين أعمل معهم لا يكتبون أكبر عدد من الأوامر، بل يطرحون أصعب الأسئلة. يعرفون متى تؤدي إعادة هيكلة الكود (refactor) إلى إدخال تبعية مخفية. يدركون متى يغطي الاختبار المولد "المسار السعيد" (happy path) ويتجاهل "الحالة الاستثنائية" (edge case) التي ستؤدي إلى تلف بيانات العملاء. يمكنهم النظر إلى كود صحيح تماماً والقول: "هذا الكود صحيح، لكن البنية التحتية خاطئة".

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

العمل الذي لا يزال ينتمي للبشر

AI can accelerate almost every part of the development lifecycle, yet there are core practices that should remain firmly human. System design requires holding competing constraints in balance: cost, latency, reliability, and future maintainability. Architecture reviews depend on institutional memory and the ability to project second-order effects. Mentorship requires someone who has actually suffered through the failure modes they are warning you about. Deep product understanding comes from talking to users and watching behavior in the wild, not from reading training data.

Engineering judgment is the sum of those experiences. It is the quiet voice that tells you a migration is too risky to ship on a Friday afternoon, even if the code review passed. It is the intuition that a performance optimization now might create a security hole later. An LLM has no intuition. It has patterns. Patterns are useful, but they are not judgment.

Companies hiring right now need to stop optimizing for people who are merely good at using AI tools. Hire people who can challenge AI. Look for candidates who will pause, read the generated output carefully, and explain why they disagree with it. Those are the engineers who will keep your systems healthy when the generated code meets the messy reality of production.

Acceleration Without a Compass

Think of AI as an accelerator pedal. In a car with a