"بحلول عام 2030، لن تحتاج إلى معرفة كيفية كتابة الأكواد لتكون مبرمجاً ناجحاً. ستحتاج فقط إلى معرفة كيف تطلب من الذكاء الاصطناعي القيام بذلك."
إنه ادعاء جريء يتردد صداه في أروقة صناعة التكنولوجيا: البرمجة تتحول بسرعة إلى هندسة أوامر (prompting). فبدلاً من كتابة كل سطر برمجي بأنفسنا، سنستخدم ببساطة اللغة الطبيعية لتوجيه الذكاء الاصطناعي لإنشاء الأكواد، وإعادة هيكلتها (refactor)، واختبارها نيابة عنا.
إذن، هل تعتبر هندسة الأوامر (prompt engineering) هي مستقبل البرمجة؟
نعم ولا. وهذا الاختلاف يحمل أهمية أكبر بكثير مما يعتقده البعض.
بالعودة إلى عام 2020، كان مصطلح "prompting" يعني استخدام علامات واجهة سطر الأوامر (CLI flags) أو طلب إدخال بيانات من المستخدم. أما الآن، فقد أصبح يعني توجيه GPT لإنشاء تطبيق ويب متكامل من الصفر. هذا أمر مفيد حقاً. الخطأ لا يكمن في استخدام الذكاء الاصطناعي، بل في تفويض التفكير إليه. عندما تستبدل الدوال (functions) بالأوامر النصية (prompts) دون فهم ما يجري في الكواليس، فأنت لا تهندس أي شيء. أنت مجرد شخص يلقي بتخميناته داخل صندوق أسود ويأمل أن تعمل المخرجات بنجاح.
وإليك الحقيقة التي لا يرغب أحد في البوح بها: حتى في المستقبل حيث تصبح البرمجة معتمدة بنسبة 100% على الأوامر النصية (وهو تحول قد يستغرق سنوات أو عقوداً)، ستظل بحاجة إلى معرفة كيفية توجيه الآلة. يجب أن يكون هناك شخص يوجه الأوامر، ويتحقق من المخرجات، ويتحمل مسؤولية النتيجة النهائية. هذا الشخص يجب أن يفهم المنطق البرمجي، وإلا سينهار النظام بأكمله في أول مرة يخطئ فيها الذكاء الاصطناعي في تفصيلة صغيرة.
في هذا المقال، سنلقي نظرة على أسباب حدوث هذا التحول، ولماذا أصبحت وظيفتك الحقيقية هي أن تكون الشخص الذي يفهم المنطق البرمجي فعلياً.

ماذا يعني الـ AI Prompting في البرمجة فعلياً؟
في أبسط صوره، يعني الـ AI prompting في مجال التطوير إعطاء نموذج لغوي كبير (LLM) تعليمات باللغة الطبيعية لإنتاج مخرجات تقنية. وفي سياق البرمجة، يظهر هذا عادةً في ثلاثة أشكال:
-
الإكمال التلقائي (Autocompletion). تقوم أدوات مثل GitHub Copilot أو Cursor بقراءة الكود الحالي الخاص بك واقتراح الأسطر القليلة التالية. إنها عملية مطابقة للأنماط بسرعة فائقة.
-
الأوامر التوجيهية (Instructional prompting). أن تعطي روبوت المحادثة مهمة محددة، مثل "اكتب سكربت Python لاستخراج العناوين الرئيسية من موقع إخباري وحفظها في ملف CSV." يقوم الذكاء الاصطناعي بالاستعانة ببيانات التدريب الخاصة به لتقديم الحل.
-
حقن السياق (Context injection). هذه هي الطبقة المتقدمة. حيث تقوم بتزويد الذكاء الاصطناعي بالوثائق الحالية، أو مخططات الـ API، أو القيود المنطقية الخاصة بك حتى يفهم نظامك الفريد قبل أن يكتب قوساً واحداً.
في جوهر هذه الأشكال الثلاثة، يقوم الذكاء الاصطناعي ببساطة بتوقع الرمز (token) التالي الأكثر احتمالاً بناءً على مليارات الأمثلة التي تدرب عليها. المترجم (compiler) يعطيك إجابة ثنائية قاطعة "صح أو خطأ". أما الأمر النصي (prompt) فيعطيك تخميناً احتمالياً. في بعض الأحيان يكون هذا اختصاراً عبقرياً، وفي أحيان أخرى يكون مجرد "هلوسة" واثقة. إذا كنت لا تفهم البنية البرمجية (syntax) الأساسية، فلن تتمكن من التمييز بينهما.
هذه هي اللعبة بأكملها. وكل ما يأتي بعد ذلك يتمحور حول البقاء على الجانب الصحيح من هذا الخط الفاصل.
كيف تتغير البرمجة، وماذا ستصبح وظيفتك؟
إذا كان الذكاء الاصطناعي سيتولى المزيد من مهام الكتابة، فما هو دور العنصر البشري إذن؟ الإجابة ليست "دوراً أقل"، بل دوراً مختلفاً. هناك أربعة تحولات تعيد تشكيل طبيعة العمل في الوقت الحالي.
1. من مُبرمج (Builder) إلى مهندس أنظمة (System Architect)
الأقواس والفواصل المنقوطة أصبحت أقل أهمية الآن. ما يهم أكثر هو النية، والهيكلة، وما يحاول الكود تحقيقه. قيمتك الحقيقية تكمن في التخطيط المعماري والتحقق من الصحة. يجب أن تكون أنت الشخص الذي يفهم كيف تتكامل أجزاء النظام بأكمله معاً، لأن هذه هي الطريقة الوحيدة لاكتشاف الأخطاء عندما تفشل مخرجات الذكاء الاصطناعي في ذلك.
2. إتقان السياق، وليس الأوامر فقط
نماذج LLMs هي نماذج غير حتمية (non-deterministic). نفس الاستعلام قد ينتج إجابات مختلفة في كل مرة يتم تشغيله فيها. لذا، فإن إدارة السياق الذي تقدمه للنموذج هي المهارة التقنية الحقيقية.
إذا قدمت له مشكلة غامضة مع القليل من المواد المرجعية المتاحة عبر الإنترنت، فسيقوم بكل سرور باختراع دوال (functions) لا وجود لها أو إنشاء spaghetti code بطيء أو غير آمن. سياق جيد يعني كوداً مفيداً. سياق غامض يعني هراءً يبدو منطقياً في ظاهره.
3. التحقق من المنطق
لقد خلق الذكاء الاصطناعي فجوة منطقية خطيرة: فالأكواد يتم إنتاجها بسرعة تفوق قدرة أي شخص على مراجعتها. كما أن أخطاء الذكاء الاصطناعي (bugs) يصعب اكتشافها بشكل استثنائي، لأنها تبدو صحيحة للوهلة الأولى.
تخيل أن الذكاء الاصطناعي قام بإنشاء دالة تقوم بتصفية قائمة المستخدمين بناءً على is_active. الكود يعمل. الاختبارات تمر بنجاح. مراجعة الكود تبدو جيدة. بعد ستة أسابيع، تبدو أرقام تسرب العملاء (churn numbers) نظيفة بشكل غريب ولا أحد يستطيع معرفة السبب. يتضح لاحقاً أن الدالة قامت بصمت بإسقاط المستخدمين الذين كانت حالتهم null بدلاً من false. عادةً ما يكون خطأ المطور المبتدئ واضحاً. أما أخطاء الذكاء الاصطناعي فتختبئ داخل كود يبدو صحيحاً. قيمتك هنا تكمن في اكتشاف هذه الأخطاء قبل إطلاق المنتج.
4. أتمتة الأكواد النمطية (Boilerplate)
صفحات تسجيل الدخول، مسارات الدفع الأساسية، وعمليات CRUD البسيطة. يتعامل الذكاء الاصطناعي مع هذه الأمور بشكل جيد، وهذا أمر إيجابي. فهو يحررك لقضاء وقتك في حل المشكلات الأكثر إثارة للاهتمام: القرارات المعمارية، والحالات الطرفية (edge cases) الغريبة، والأجزاء التي تجعل مشروعك مميزاً.
هنا تصبح الصورة مربكة للكثيرين، لذا دعونا نكون صريحين: تسليم الأكواد النمطية (boilerplate) للذكاء الاصطناعي أمر لا بأس به. لكن تسليمه قدرتك على الحكم واتخاذ القرار ليس كذلك. هما قراران مختلفان تماماً، والخلط بينهما هو ما يحول المطورين إلى مجرد مخمنين للأوامر.
| التحول | من: المُبرمج (The builder) | إلى: مهندس الأنظمة (The architect) |
|---|---|---|
| التركيز الأساسي | البنية البرمجية (Syntax)، الأقواس، والفواصل المنقوطة | النية، معمارية النظام، والمنطق |
| "الكود المصدري" | أسطر المنطق المكتوبة يدوياً | السياق، القيود، والتوثيق |
| سير العمل | كتابة الأكواد النمطية وعمليات CRUD | تفويض العمل المتكرر وحل الحالات الطرفية (edge cases) المعقدة |
| مراقبة الجودة | التنقيح اليدوي (debugging) سطراً بسطر | تدقيق مخرجات الذكاء الاصطناعي وضمان السلامة المعمارية |
| النظرة للذكاء الاصطناعي | تهديد، أو "غش" | أداة قوية تحتاج إلى مشغل ماهر |
هل ستصبح ديناصوراً في عالم البرمجة؟
قبل سنوات، كان بعض المطورين ينظرون بدونية إلى الأدوات "السهلة". كانت أطر العمل (Frameworks) مثل React أو Django تُعتبر "غشاً". فالمطورون الحقيقيون يكتبون كل سطر من JavaScript أو CSS من الصفر. أما اليوم، أصبحت هذه "الاختصارات" هي... المعيار الأساسي. لا أحد يبني تطبيقاً احترافياً بإعادة اختراع العجلة.
الذكاء الاصطناعي هو الفصل التالي من نفس القصة، ونفس الانقسام يتشكل الآن:
-
الديناصورات: لا يتجنبون الذكاء الاصطناعي فحسب، بل يرفضون التكيف معه. يرونه تهديداً لـ "البرمجة الحقيقية" ويقضون ساعات في إعادة حل مشكلات سبق للصناعة أن حلتها. ينسون أن البرمجة تتمحور حول حل المشكلات، وليس حول الكتابة على لوحة المفاتيح.
-
المهندسون (The Architects): يستخدمون الذكاء الاصطناعي لإنجاز الأجزاء المملة ويحافظون على قوة أساسياتهم لكل شيء آخر. لا يتوقفون عن التعلم، لأن الفهم العميق هو الطريقة الوحيدة للتحقق من عمل الذكاء الاصطناعي والحفاظ على أمان الأنظمة. لن يتم استبدالهم بالذكاء الاصطناعي، بل هم من سيديرونه.
الخلاصة: اختيارك لعدم استخدام الذكاء الاصطناعي لا يجعلك مطوراً سيئاً. بصراحة، حل المشكلات بشكل فردي لا يزال هو المكان الذي يحدث فيه التعلم الأعمق. الهدف هو أن تظل قابلاً للتكيف. سواء قام الذكاء الاصطناعي بإنشاء سطر واحد أو دالة كاملة، فإن اسمك هو الذي سيُكتب على المشروع. أن تكون مهندساً يعني أن تمتلك دائماً العمق الكافي لفهم المنطق، والتحقق منه، وتحمل مسؤوليته بنفسك.
كيف تظل أنت الشخص المسؤول؟
عندما يتم إنشاء التطبيقات بواسطة نفس النماذج القليلة، فإنها تبدأ جميعاً في الظهور بشكل متشابه إلى حد ما. الخيارات البشرية الذكية وغير التقليدية هي ما يجعل البرمجيات العظيمة لا تُنسى، وهذه الخيارات لا تخرج من صندوق الأوامر النصية بمفردها.
هناك بعض العادات التي تبقيك على جانب "المهندس":
-
استخدم الذكاء الاصطناعي لبناء الهيكل الأساسي (scaffolding)، وليس لللمسات النهائية. إنه رائع للأجزاء الهيكلية. أما التفاصيل المخصصة، والحالات الطرفية، والأشياء التي تجعل منتجك يحمل بصمتك، فهذه لا تزال وظيفتك.
-
لا تدع أساسياتك تصدأ. حتى خمس دقائق من البرمجة العملية يومياً تحافظ على حدة تفكيرك المنطقي. الابتعاد عن الذكاء الاصطناعي في بعض الأحيان هو الطريقة التي تضمن بها أنك لا تزال تفهم المحرك الذي يُفترض بك توجيهه.
-
عامل الذكاء الاصطناعي كمطور مبتدئ (junior developer). أعطه توجيهات واضحة، وتحقق من عمله، واتخذ القرار النهائي. القاعدة بسيطة: كن دائماً أكثر دراية ومعرفة من الأداة التي تستخدمها.
البرمجة لن تختفي. القواعد فقط هي التي تتغير.
إذن، هل ستصبح البرمجة مجرد كتابة أوامر نصية بحلول عام 2030؟
بصراحة؟ لا أحد يعرف حقاً. قبل عامين، كان التفكير في أن الأكواد التي ينشئها الذكاء الاصطناعي ستصل إلى مرحلة الإنتاج (production) بمثابة مزحة. اليوم، يستخدمها معظم المبرمجين يومياً. من الصعب التنبؤ بوتيرة هذا التطور.
لكن الإجابة بـ "نعم، ستصبح كلها أوامر نصية" هي فقط للأشخاص الذين لا يهتمون بالجودة. إلى أن يتمكن الذكاء الاصطناعي من أخذ وصف لنظام معقد وتقديم برمجيات خالية من العيوب وآمنة بشكل موثوق (ونحن لسنا قريبين من ذلك على الإطلاق)، ستستمر الصناعة في الحاجة إلى مبرمجين قادرين على تنقيح المنطق (debug) واكتشاف الأخطاء التي يتجاهلها الذكاء الاصطناعي بصمت. هذا ليس دوراً احتياطياً. بل هو الدور الأكثر قيمة.
المهندسون يواصلون التعلم. وهذا بالضبط نوع الممارسة الذي بُنيت من أجله منصة Coddy: دروس تفاعلية وعملية تبني عمقاً لا يمكن لأي أمر نصي أن يزيفه.
Share this article
About the Author
Jana Simeonovska
Content Strategist & Writer
Frequently Asked Questions
كيف يتم استخدام الذكاء الاصطناعي في البرمجة؟
يعتمد إنشاء الأكواد البرمجية بالذكاء الاصطناعي على التعلم الآلي ومعالجة اللغات الطبيعية لإنشاء الكود المصدري تلقائياً. يتم تدريب نماذج التعلم الآلي على مجموعات بيانات ضخمة من الأكواد لفهم لغات البرمجة وأنماط البرمجة الشائعة.
ماذا يعني الـ prompting في البرمجة؟
الـ prompt هو نص باللغة الطبيعية يصف ويحدد المهمة التي يجب على الذكاء الاصطناعي أداؤها. يمكن أن يكون الـ prompt لنموذج لغوي من نص إلى نص عبارة عن استعلام أو أمر أو عبارة أطول تشير إلى السياق والتعليمات وسجل المحادثة.
هل البرمجة والـ prompting هما نفس الشيء؟
يعمل كل من الـ prompting والبرمجة بناءً على افتراضات مختلفة تماماً. التعامل معهما على أنهما نفس الشيء يؤدي إلى أنظمة هشة وسلوك غير متسق وإخفاقات غير متوقعة في بيئة الإنتاج. يعد فهم أين ينهار النموذج العقلي أمراً ضرورياً لاستخدام الـ LLMs بشكل موثوق.
هل تعتبر الـ prompts كوداً برمجياً؟
على عكس الكود التقليدي، تبدو الـ prompts قابلة للتعديل من قبل الجميع. فهي لغة طبيعية يمكن لأي شخص قراءتها وتعديلها. لكن هذه البساطة بالذات هي سلاح ذو حدين. نظراً لأن الـ prompts تُكتب بلغة بسيطة، فهي مفتوحة للتفسير.
هل لا تزال البرمجة ذات صلة في عام 2026؟
حتى في عام 2026، تظل البرمجة هي الأساس لأدوار مثل مهندس البرمجيات، ومهندس الذكاء الاصطناعي، وعالم البيانات، من بين أدوار أخرى.
هل سيحل الـ prompt engineering محل البرمجة؟
تحتاج التطبيقات عالية الأداء إلى أكواد برمجية مضبوطة بدقة لا يمكن أن يوفرها سوى المبرمجين المهرة. لا تزال الأنظمة المعقدة، مثل أنظمة التشغيل، بحاجة إلى البرمجة التقليدية ولا يمكن بناؤها باستخدام الـ prompts وحدها. قد تعزز من عملية التطوير، لكنها لا تحل محل الحاجة الأساسية للبرمجة.


