نهاية مهندس التطبيقات: لماذا العقد القادم ملك لبناة وكلاء الذكاء الاصطناعي

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

تخيل أواخر التسعينيات. إذا كنت تعرف كيف "تصارع" أكواد HTML والقليل من Perl أو PHP لتحويلها إلى موقع ويب يعمل، فقد كنت تُعتبر ساحراً. كنت "مهندس ويب" (Web Engineer)، وكان العالم كله بين يديك. كنت تبني واجهات المحلات التجارية لعالم الإنترنت.

لننتقل سريعاً إلى عام 2009. كان الآيفون (iPhone) قد فتح أبواب العالم للتو. فجأة، لم يعد أحد يهتم كثيراً بموقعك الثابت (static website). انتقلت الطاقة والزخم إلى Objective-C و Java. إذا كنت "مهندس تطبيقات جوال" (Mobile App Engineer)، فأنت كنت تكتب المستقبل. كنت تبني الأدوات التي يحملها الناس في جيوبهم.

الآن، انظر إلى عام 2024. الجو يبدو راكداً وثقيلاً مرة أخرى. متاجر التطبيقات مشبعة؛ والويب مزدحم للغاية. ولكن تحت السطح، هناك تحول تكتوني يحدث. نحن نغادر عصر "الواجهة" (Interface) وندخل عصر "الوكيل" (Agent).

في العقد القادم، اللقب الأكثر قيمة لن يكون "مطور الويب الشامل" (Full Stack Developer) أو "مهندس iOS". بل سيكون مهندس وكلاء الذكاء الاصطناعي (AI Agent Engineer).

التحول التكتوني الجديد

هذه ليست مجرد حرب أخرى بين أطر العمل (frameworks) أو لغة برمجة جديدة يجب تعلمها. هذا تغيير جوهري في من يقوم بالعمل.

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

هذه الديناميكية تنقلب الآن رأساً على عقب.

في عصر الوكلاء (Agentic Era)، البرمجيات هي التي توفر العقل. وظيفتك لم تعد بناء الزر لينقر عليه الإنسان. وظيفتك هي بناء "الموظف الرقمي" الذي يقرر متى ينقر على الزر، أو الأفضل من ذلك، يكتشف أن الزر غير مطلوب أصلاً.

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

ولكن إليك الحقيقة القاسية: إذا رفضت تعلم هذا، وإذا تمسكت بالبرمجة الحتمية التقليدية فقط، فأنت تخاطر بأن تصبح المعادل الرقمي لـ "مصفف الحروف اليدوي" في عصر النشر المكتبي.

إزالة الغموض عن السحر: الأدوات والسياق

عندما يسمع الناس مصطلح "وكيل ذكاء اصطناعي" (AI Agent)، يتخيلون نظام "سكاي نت" (Skynet) أو بنية شبكة عصبية معقدة بشكل مستحيل. دعونا نتجاوز هذا الضجيج.

بناء وكيل ليس سحراً. إنه هندسة. ويتلخص الأمر في شيئين: الأدوات (Tools) و السياق (Context).

لقد وجدت أن معظم المطورين يبالغون في تعقيد هذا الأمر. يعتقدون أنهم بحاجة لتدريب نماذج خاصة. أنت لست بحاجة لذلك. النماذج الموجودة—مثل Claude و GPT-4 و Llama—ذكية بما فيه الكفاية. وظيفتك هي منحها "أيادٍ" و "ذاكرة".

1. الأدوات (منح النموذج أيادٍ)

النموذج اللغوي الكبير (LLM) هو مجرد دماغ في وعاء. يمكنه التفكير، لكنه لا يستطيع لمس العالم. "الوكيل" هو ببساطة نموذج لغوي (LLM) تم منحه حق الوصول إلى نقاط نهاية API أو أوامر الطرفية (CLI).

أنت تخبر النموذج: "هنا أداة تسمى list_files. هنا أداة تسمى read_file. وهنا أداة تسمى send_email."

2. السياق (منح النموذج توجيهاً)

ثم تحدد الدور. "أنت مهندس ضمان جودة (QA) خبير. هدفك هو إصلاح أخطاء الكتابة (type errors) في هذا المستودع البرمجي."

هذا كل شيء. هذه هي الحلقة الأساسية.

إذا استخدمت Cursor أو Claude Code، فقد رأيت هذا عملياً. أنت لا تدير التعديلات بشكل تفصيلي ممل. أنت تقول فقط: "أصلح أخطاء الكتابة في utils.ts."

يفكر الوكيل: حسناً، أحتاج لرؤية الملف أولاً. يقرر استخدام أداة ls. ثم يقرر استخدام grep أو read. يكتشف الخطأ. يقرر كتابة الإصلاح. ثم يشغل المترجم (compiler) للتحقق من عمله.

هذا هو الاختراق الحقيقي. لم يعد الأمر مجرد "دردشة". إنها حلقة اتخاذ قرار. النموذج يختار الأدوات التي سيلتقطها لحل المشكلة التي أعطيتها له.

من روبوتات الدردشة إلى محركات القرار

على مدار العامين الماضيين، كنا عالقين في مرحلة "الدردشة" (Chat). كنا نعامل الذكاء الاصطناعي مثل أمين مكتبة ذكي—نسأل سؤالاً، فيعطينا إجابة.

تلك المرحلة تنتهي الآن.

مرحلة الوكلاء (Agentic phase) تدور حول التنفيذ. إنها تتعلق بالنظر إلى واجهة سطر الأوامر (CLI) ليس كمكان تكتب فيه أنت، بل كملعب للنموذج.

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

اليوم، يمكنني كتابة وكيل. أمنحه حق الوصول لـ Stripe API (أداة) وسجل بريدنا الإلكتروني (سياق). وأعطيه سياسة: "قم برد الأموال إذا كان المستخدم غير سعيد خلال 7 أيام." يقرأ الوكيل البريد الوارد، يقرر ما إذا كان يفي بالمعايير، يشغل أداة استرداد الأموال في Stripe، ويصيغ رداً.

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

"مرحلة المنتصف الفوضوية" في بناء الوكلاء

لا أريد أن أرسم صورة مثالية هنا. لقد قضيت الأشهر الستة الماضية غارقاً في خنادق بناء الوكلاء، ودعني أخبرك: الأمر فوضوي.

البرمجة التقليدية منطقية. If X then Y (إذا حدث س، افعل ص). إما أن تعمل أو تتعطل.

هندسة الوكلاء احتمالية (probabilistic). أنت تبني الوكيل، تعطيه الأدوات، وأحياناً يقرر استخدام مطرقة لفتح نافذة. وأحياناً يهلوس بوجود "باراميتر" (parameter) غير موجود أصلاً.

هنا تكمن مجموعة المهارات الجديدة.

أن تكون مهندس وكلاء (Agent Engineer) لا يعني مجرد كتابة نصوص Python. الأمر يتعلق بـ:

• هندسة الأوامر كبنية للنظام (Prompt Engineering as Architecture): تصميم أوامر النظام لتقييد وتوجيه سلوك النموذج.
• التطوير القائم على التقييم (Eval Driven Development): لا يمكنك كتابة اختبارات وحدة (unit tests) للإبداع، لذا تقوم ببناء خطوط أنابيب تقييم لقياس مدى تكرار نجاح الوكيل في مهمة ما.
• تصميم الأدوات (Tool Design): إنشاء واجهات API "نظيفة" بما يكفي ليفهمها النموذج دون أن يرتبك.

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

نصائح عملية: كيف تبدأ اليوم

إذا كنت سأبدأ من الصفر اليوم، أو أتطلع لتغيير مساري المهني، فهذا بالضبط ما سأفعله:

1. توقف عن بناء واجهات المستخدم الرسومية (GUIs): على الأقل لمشاريعك الجانبية. حاول حل مشكلة بدون واجهة أمامية (frontend). هل يمكنك حلها باستخدام واجهة سطر أوامر (CLI) ونموذج لغوي (LLM)؟
2. تعلم بروتوكول الواجهة: افهم كيف يعمل "استدعاء الدوال" (function calling) في OpenAI أو "استخدام الأدوات" (tool use) في Anthropic. هذا هو بمثابة بروتوكول TCP/IP لعصر الوكلاء.
3. ابنِ "فاعلاً" لا "متحدثاً": لا تبنِ روبوتاً يجيب عن أسئلة حول تقويمك. ابنِ روبوتاً يدير تقويمك. امنحه القدرة على حذف الأحداث. اشعر بالخوف من منح الذكاء الاصطناعي صلاحية الكتابة (write access). عندها ستبدأ التعلم حقاً.
4. أتقن إدارة السياق: تعلم كيف تحشو المعلومات الصحيحة في "نافذة السياق" (context window) دون أن تفيض. تقنية RAG (توليد الاستجابة المعزز بالاسترجاع) هي مجرد البداية.

الفرصة القادمة

نحن نتطلع إلى مستقبل حيث يمكن لمطور واحد، مسلح بأسطول من الوكلاء المتخصصين، أن يقوم بعمل شركة ناشئة مكونة من 20 شخصاً.

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

قبل عشر سنوات، كان يتم توظيفك لكتابة الكود. اليوم، يتم توظيفك لهندسة النظام الذي يكتب الكود.

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

لننطلق في البناء.