قبل أشهر قليلة، كنتُ أجلس أمام المحرر ساعات. أكتب، أراجع، أمسح، وأعيد. اليوم؟ أكتب جملة واحدة واضحة... وأراقب وكيلاً ذكياً يُنجز ما كان يأخذ مني يوماً كاملاً. هذه ليست مبالغة، هذه قصتي.
بدأتُ مع Cursor، النسخة المبنية التي اكتسبت شعبية هائلة مع إطلاق نموذج Sonnet 3.5. في تلك المرحلة، كنت أتفحّص كل تغيير يقترحه النموذج، حرفياً، سطراً بسطر. لم أكن أثق، ولم أكن أترك شيئاً يمر دون مراجعة شبه كاملة.
ثم بدأت أتعلّم: المشكلة ليست في الأداة، بل في السياق (Context) الذي أعطيه لها. أضفت قواعد (Rules) تضبط سلوك النموذج، واستخدمت Gemini في Google AI Studio لتوليد فهم شامل لمشاريعي — هيكلة الملفات، العلاقات بين المكونات، وخريطة المشروع بأكملها. كل ذلك لغرض واحد: أن أمنح النموذج سياقاً غنياً بما يكفي ليعمل بكفاءة حقيقية. كان الأمر يشبه تحضير ملف تعريفي مفصّل لموظف جديد قبل أن يبدأ أول يوم عمل.
ثم ظهر Claude Opus 4.5. الفرق كان صادماً؛ نجاعة يصعب تصديقها، حيث أصبح من النادر جداً أن أحتاج لتعديل يدوي. لكنني بقيتُ متعلقاً بالمحرر — عادة قديمة يصعب كسرها.
جرّبته على Cursor، تحمّست، واشتركت بالخطة المتقدمة (200 دولار). انتهى الرصيد في خمسة أيام فقط! ليس لأنني أسرفت، بل لأن الجودة كانت مُدمنة؛ فكل مهمة تنجح من المحاولة الأولى تجعلك تريد إرسال المزيد والمزيد.
بحثت عن أرخص وأكفأ طريقة لاستخدام هذا النموذج بكثافة، فوجدتُ أن اشتراك Claude Code (بـ 200 دولار) هو الخيار الأذكى، خاصة إذا كنت تعمل على مشاريع حقيقية يومياً. وهنا بدأ كل شيء يتغير.
الفرق لم يكن تقنياً فقط، كان في طريقة تفكيري. لم أعد أسأل: "هل هذا السطر صحيح؟" بل أصبحتُ أسأل: "هل الوكيل فهم المهمة؟ هل مساره منطقي؟ هل النتيجة تطابق النية؟".
لقد انتقلتُ من كوني مبرمجاً إلى كوني مدير فريق من المبرمجين. هذا لا يعني أنني خرجت من الحلقة، بل على العكس؛ تركيزي تحوّل إلى ما هو أهم: وضوح المهمة، التخطيط الصحيح، نجاعة الأداء، التحقق الآلي، وجودة التعاون بيني وبين الوكلاء.
ثلاثة أشياء جعلت تجربتي مختلفة تماماً، بالإضافة لجعله التركيز ينصب على إدارة الوكلاء أكثر من مجرد كتابة الكود:
المهارات (Skills): الوكلاء لا يبدأون من الصفر. المهارات تبدأ بسيطة، ثم تتطور وتكتسب نضجاً مع كل استخدام — تماماً كموظف يتعلم من تجاربه. المثير هنا أن الكثير من المطورين يشاركون مهارات جاهزة على GitHub يمكنك استخدامها والتعديل عليها آلياً كلما واجهت مشكلة.
التواصل الخارجي (MCPs): الوكلاء ليسوا معزولين. يمكنهم التواصل مع خدمات خارجية، مما يجعلهم جزءاً حقيقياً ومؤثراً من بيئة العمل.
الأوامر (Commands): مهام معقدة تُختصر في أمر واحد؛ قد يستدعي أكثر من وكيل، وينسّق بينهم تلقائياً. ومع التحديث الجديد، تمت إضافة ميزة "الفرق" (Teams) لتشغيل عدة وكلاء معاً (رغم أنني لم أجربها بعد).
الاتجاه واضح: المبرمجون في المستقبل لن يحتاجوا المحرر إلا لكتابة المواصفات، تحديد شروط النجاح، وصقل مهارات الوكلاء. هذا التوجه هو ما ظهر بوضوح في Codex Applications التي جاءت بتجربة مختلفة تركز على هذه الزاوية أكثر من مجرد كتابة السطور البرمجية.
لكن هناك فخ يجب أن نعيه: كل مرة تُسهّل فيها المهمة على نفسك، تُسهّلها على شركات الذكاء الاصطناعي أيضاً. أنت تُعلّمهم، تُغذّي نماذجهم، وتبني لهم المهارات التي سيستخدمونها ليحلّوا محلك غداً. للأسف، ليس هناك خيارات أخرى غير ذلك.
كمبرمجين، ليس لدينا خيار إلا التركيز على المهارات اللينة (Soft Skills): التواصل، فهم المتطلبات، والقدرة على ترويض الوكلاء وتوجيههم. هذا التطور سيُقلّص عروض العمل التقليدية. الوظائف ستتجه نحو الخبراء في مجالاتهم الذين يفهمون المشكلة قبل الحل، والذين يمتلكون القدرة على إدارة أسراب من الوكلاء بكفاءة. أما سقف توقعات العملاء؟ سيرتفع بشدة، حيث سيتوقعون رؤية ما لا تستطيع الوكلاء إنجازه بمفردها!
على المدى القصير: الاستثمار بكثافة في أدوات الذكاء الاصطناعي. من يتقنها اليوم يسبق من سيتعلمها غداً.
على المدى البعيد: التفكير في مجالات لا تحتاج مهارات تقنية بحتة؛ الزراعة، النقل، الترفيه. هذه مجالات كانت موجودة قبل الثورة الصناعية، وستبقى بعد ثورة الذكاء الاصطناعي، لأن البشر سيظلون بحاجة لمن يزرع لهم، ينقلهم، ويُسلّيهم — بغض النظر عن مدى ذكاء الآلة.
العالم يتغير بسرعة مخيفة. السؤال الوحيد: هل تتغير معه؟