من كتابة الكود إلى إدارة الوكلاء: المهندس AI-Native

المسمى الوظيفي لا يزال يقول "مهندس برمجيات". لكن الوظيفة نفسها؟ تتغير أسرع مما يدركه معظم المهندسين.

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

هذا التحول ليس افتراضياً. إنه يحدث في قواعد الأكواد الإنتاجية الآن. والمهندسون الذين يتكيفون سيحددون العقد القادم من صناعة البرمجيات.

المهندس AI-Native: جيل جديد

يصف إيريك جيلاً جديداً يدخل سوق العمل: المهندس AI-native. هؤلاء ليسوا مطورين يستخدمون Copilot أحياناً للإكمال التلقائي. إنهم مهندسون يفكرون بتدفقات العمل الوكيلية منذ اليوم الأول.

لكن ما يجعل رؤية إيريك منعشة هو أنه لا يقول أن المهارات التقليدية لم تعد مهمة. العكس تماماً. المهندسون AI-native يحتاجون أساساً متيناً في البرمجة وتصميم الأنظمة والتفكير الخوارزمي. بدونه، لا يمكنك تقييم ما ينتجه الوكيل. لا يمكنك تصحيح أخطائه. لا يمكنك تصميم أنظمة يستطيع الوكلاء التنقل فيها فعلاً.

الفرق هو أنه فوق هذا الأساس، يتقن المهندسون AI-native لغة ثانية: تنسيق الوكلاء المستقلين لإنجاز العمل الذي كان يتطلب سابقاً كتابة كل سطر يدوياً.

فكّر في الأمر كالفرق بين موسيقي يعزف فقط وقائد أوركسترا يشكّل العمل بأكمله. لا تزال بحاجة لفهم الموسيقى. لكن الناتج يتضاعف بشكل كبير.

من مبرمج إلى مدير: تحول في العقلية

يقدم إيريك مقارنة مثيرة: إدارة وكلاء الذكاء الاصطناعي تشبه كثيراً إدارة المتدربين البشريين.

لن تعطي متدرباً قاعدة الأكواد بأكملها في يومه الأول وتقول "أعد هيكلة نظام المصادقة". ستبدأ بالصغير. تعطيه مهمة محددة. تراجع عمله. ثم توسّع نطاقه تدريجياً مع بناء الثقة.

نفس المبدأ ينطبق على الوكلاء. يوصي إيريك بنهج التفويض التكراري:

1. أتقن تدفقات الوكيل الواحد أولاً. اجعل وكيلاً واحداً يعمل بموثوقية على مهمة محددة جيداً قبل إضافة التعقيد.
2. ضع حدوداً واضحة. حدد ما يستطيع الوكيل لمسه وما لا يستطيع. قيّد وصوله لملفات أو وحدات أو عمليات محددة.
3. أضف وكلاء تدريجياً. لا تضف وكيلاً ثانياً أو ثالثاً إلا لمهام معزولة ومتوازية، بعد استقرار الأول.
4. راقب باستمرار. اعرف متى يكون الوكلاء عالقين. اعرف متى يهلوسون. اعرف متى تتدخل.

المهارة الأولى التي تفصل المهندسين AI-native العظماء عن البقية؟ وفقاً لإيريك، إنها تبديل السياق — القدرة على تتبع ما يفعله عدة وكلاء في وقت واحد، ورصد متى ينحرف أحدهم عن المسار، وتصحيح المسار في الوقت الحقيقي.

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

بناء قواعد أكواد متوافقة مع الوكلاء

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

الحل؟ ابنِ قاعدة أكوادك كأنك تدرّب أكثر متدرب حرفي في العالم.

الاختبارات عقود

الوكلاء لا يملكون حدساً. لا يستطيعون النظر للكود والتفكير "هذا يبدو خاطئاً". يحتاجون عقوداً صريحة — وهذا يعني اختبارات.

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

إذا أردت أن يساهم الوكلاء بكود ذي معنى، استثمر في الاختبارات أولاً.

الاتساق قبل الذكاء

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

يؤكد إيريك أن قواعد الأكواد يجب أن تكون متينة ومحكمة ومتسقة ذاتياً:

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

المبدأ بسيط: إذا كان سيربك موظفاً جديداً، سيربك الوكيل. لكن الوكيل لن يطلب توضيحاً — سيكتب كوداً سيئاً بثقة.

التوثيق كواجهة

هذا يمتد لما هو أبعد من ملفات README. كل وحدة، كل API، كل ملف تكوين هو جزء من الواجهة التي يستخدمها الوكلاء لفهم نظامك. فكّر في التوثيق ليس كشيء تكتبه لبشر المستقبل، بل كشيء تكتبه للوكلاء الذين يعملون بجانبك الآن.

قيمة الذوق

يرسم إيريك خطاً بين البرمجيات الوظيفية والبرمجيات الاستثنائية. ما الفرق؟ ذوق المطور.

يستطيع وكلاء الذكاء الاصطناعي توليد كود يعمل. يمكنهم بناء هياكل الميزات وكتابة الاختبارات وربط الـ APIs. لكن آخر 10% — التلميع وحالات الحدود وتفاصيل تجربة المستخدم التي تجعل المستخدمين يحبون المنتج — لا تزال تأتي من الحكم البشري.

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

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

يجب على المطورين AI-native تبني نفس الموقف: جرّب، اختبر، كرّر. لا تتعلق بتدفق عمل معين. لا تفترض أن إعداد وكلائك الحالي هو الأمثل. استمر في التجريب. المطورون الذين سينجحون ليسوا من وجدوا الأداة الصحيحة — بل من لا يتوقفون أبداً عن البحث.

لماذا يملك المطورون المبتدئون ميزة فريدة

قد يكون هذا أكثر رؤية مفاجئة في حديث إيريك. في سوق عمل قاسٍ للمهندسين المبتدئين، يملك المطورون الجدد في الواقع ميزة خفية في عصر AI-native.

لماذا؟ لأن المطورين الكبار بخبرة 20 عاماً غالباً ما يكونون متجذرين في عاداتهم. طوّروا ذاكرة عضلية حول تدفقات عمل سبقت وكلاء الذكاء الاصطناعي. مطالبتهم بتغيير جذري في طريقة عملهم تواجه مقاومة نفسية حقيقية.

المطورون المبتدئون بالمقابل هم إسفنجات. يتميزون بـ:

• لا عادات موروثة للتخلص منها
• سذاجة صحية تجعلهم مستعدين لتجربة مناهج يرفضها الكبار
• مرونة لتبني أدوات وتدفقات عمل جديدة بسرعة
• شجاعة ريادية لمواجهة المشاكل الصعبة دون إفراط في التفكير

ساحة اللعب يُعاد ضبطها. الخبرة لا تزال مهمة — لكن القدرة على التكيف أهم. مطور مبتدئ يتقن تدفقات العمل الوكيلية في سنته الأولى قد يتفوق على كبير يرفض التغيير.

إذا كنت في بداية مسيرتك المهنية، هذه لحظتك. اغتنمها.

المستقبل: المنظمات AI-Native

في حديث إيريك، يأخذ ريم كونينغ — أستاذ في كلية هارفارد للأعمال — خطوة للوراء نحو المستوى التنظيمي. رؤيته تعيد تأطير المحادثة بأكملها.

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

المنظمات AI-native الحقيقية لن تستخدم الذكاء الاصطناعي فقط لمساعدة المطورين على كتابة الكود أسرع. ستقوم بتضمين الذكاء الاصطناعي مباشرة في المنتج — وكلاء يتفاعلون مع العملاء، يعالجون الطلبات، يديرون الدعم، ويتخذون القرارات بدون بشري في الحلقة.

ثم يأتي سؤال التريليون دولار: ماذا يحدث عندما يبدأ وكلاء الذكاء الاصطناعي بالتحدث مع بعضهم البعض؟

ليس إنسان-إلى-وكيل. وكيل-إلى-وكيل. أنظمة مستقلة تتفاوض وتتعاون وتتخذ قرارات بسرعة الآلة. هذا ليس خيالاً علمياً — إنه الخطوة المنطقية التالية عندما تملك وكلاء موثوقين يعملون في بيئات جيدة الهيكلة.

الشركات التي تحل هذا أولاً لن تملك مجرد ميزة تنافسية. ستعمل على مستوى مختلف تماماً.

ما يجب أن تفعله اليوم

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

لقاعدة أكوادك:

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

لتدفق عملك:

• ابدأ بوكيل واحد على مهمة محددة. أتقن ذلك قبل التوسع.
• ابنِ حلقات تغذية راجعة. راجع ناتج الوكيل كما تراجع PR مبتدئ.
• تتبع ما ينجح وما لا ينجح. احتفظ بسجل لنجاحات وإخفاقات الوكلاء.
• جرّب أسبوعياً أدوات ومناهج جديدة.

لمسيرتك المهنية:

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

الانتقال من كتابة الكود إلى إدارة الوكلاء ليس اختيارياً. إنه يحدث بالفعل. السؤال هو: هل ستقوده أم ستلحق به؟

هذا المقال مبني على محاضرة ميخائيل إيريك "From Writing Code to Managing Agents" على قناة EO، مع رؤى من أستاذ كلية هارفارد للأعمال ريم كونينغ.