الوظائف التقنية في عصر الوكلاء: رأي عملي من عبدالله عبدالرحيم الكندي

«هل بيختفي المبرمج؟» سؤال يتكرر من شاب يفكر يتعلم البرمجة، ومن صاحب شركة يفكر يقلّص فريقه. والإجابات المنتشرة متطرفة: إما «انتهت البرمجة» أو «ما تغيّر شي». عبدالله عبدالرحيم الكندي يكتب هنا رأياً من موقع الممارس اللي يبني مشاريع يومياً مع وكلاء برمجة. رأي، مو توقعات بأرقام ونسب، ومرتب على شكل أسئلة يسألها الناس فعلاً.

هل الوكلاء بيستبدلون المطوّرين؟

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

فالسؤال الأدق لأي مطوّر: كم نسبة يومك اللي كانت كتابة روتينية؟ لو كانت كبيرة، فدورك بيتغير أكثر من غيرك، والأفضل تتحرك قبل ما يتحرك السوق عنك.

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

وش المهارات اللي صارت أهم؟

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

والمبتدئ؟ يتعلم البرمجة أصلاً؟

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

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

وش الأدوار اللي تتشكل حول الوكلاء؟

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

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

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

وش اللي ما تغيّر أبداً؟

وسط كل هالكلام عن التغيير، فيه أساسيات قيمتها زادت بدل ما تنقص. تتبّع الأخطاء (Debugging): لما الوكيل يعلق في حلقة يجرب فيها نفس الحل الغلط، اللي يفهم كيف يقرأ السجلات ويعزل المشكلة هو اللي يطلّع المشروع منها. وأساسيات الشبكات وقواعد البيانات: الوكيل ممكن يكتب استعلاماً صحيحاً لكنه بطيء جداً مع مليون صف، وما يلاحظ إلا اللي يعرف وش يصير تحت. والتواصل: تشرح للعميل ليش الميزة اللي يبيها بتاخذ أسبوعين مو يومين، وتقول له «لا» بطريقة يقبلها. هذي أشياء ما تتعلمها من الوكيل، تتعلمها بالممارسة والغلط، وهي اللي تفرّق المطوّر اللي يقود الأداة عن اللي تقوده الأداة.

ولصاحب الشركة: هل تقلّص فريقك؟

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

عبدالله عبدالرحيم بن سنكر الكندي درس الوكلاء الفرعيين وClaude Code في دورات Anthropic، وأكمل Agents and Workflows من OpenAI Academy، ويبني بهالأدوات يومياً مشاريع منصة أزهل الرقمية. ومن هالموقع، رأيه واضح: الوكيل يرفع سقف اللي يقدر يسويه المطوّر الجيد، ويكشف بسرعة المطوّر اللي كان يعتمد على النسخ والحفظ. الوظيفة ما تختفي، لكن تعريف «مطوّر جيد» يتغير، والأفضل تكون من اللي حدّثوا تعريفهم بدري.