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

هذا الأمر مهم لأن سير عمل البرمجة باستخدام الذكاء الاصطناعي الحديث لم يعد يعتمد على مطالبات أحادية (single-shot prompts). بل أصبحت أنظمة وحدات (modular systems) مبنية من مهارات صغيرة متعددة مترابطة معاً. وعندما تفتقر كل مهارة إلى هوية واضحة، يتضرر مسار العمل (pipeline) بأكمله.

لماذا يؤدي غياب الشخصيات إلى إفساد مسار عملك

عندما تغفل عن تحديد الدور، فإنك تجبر النموذج على ارتجال سلطته الخاصة. في لحظة ما، يكتب كوداً مثل متدرب حذر يحاول ألا يتسبب في تعطل البناء (build). وفي اللحظة التالية، يصمم نظاماً موزعاً مثل مهندس رئيسي (principal engineer) مرّ بكل الحالات الاستثنائية (edge cases). هذا التضارب ليس مجرد أمر مزعج، بل يجعل مسار عملك غير موثوق.

تتراكم المشكلات بسرعة. يختار الذكاء الاصطناعي صوتاً عشوائياً، لذا تبدأ قاعدة الكود (codebase) الخاصة بك وكأنها كُتبت بواسطة لجنة لم تجتمع قط. تتغير المخرجات في كل مرة تقوم فيها بتشغيل المهارة، مما يعني أنه لا يمكنك الوثوق بالاختبارات الآلية أو مراجعات الفروقات (diff reviews). يصبح التدقيق مستحيلاً لأنك لا تعرف المنظور الذي أنتج النتيجة. هل تم إنشاء هذا بواسطة مهندس يركز على الأمن أم متخصص عام في المنتج؟ إذا كانت الإجابة "بما يمليه النموذج"، فليس لديك وسيلة للتحقق من المنطق.

يزيد تسلسل المهارات (skill chaining) الأمر سوءاً. تخيل مهارة تولد عقود واجهة برمجة التطبيقات (API contracts) ومهارة أخرى تكتب التنفيذ (implementation). إذا تصرفت الأولى كمهندس معماري أول دقيق يفرض تحققات صارمة، بينما تصرفت الثانية كمطور مبتدئ يتجاهل معالجة الأخطاء، فإن تكامل النظام سينهار. لا يتماسك التسلسل إلا عندما تعرف كل حلقة هويتها الخاصة. وبدون ذلك، تختفي المساءلة. عندما ينكسر شيء ما، لا يمكنك تحديد العدسة التي فشلت لأنه لم يتم تحديد أي عدسة من الأساس.

كيفية إصلاح ذلك

الحل بسيط ولكنه محدد. أضف تحديداً للدور كأول تعليمات في ملف المهارة الخاص بك. لا تدفنه تحت قواعد التنسيق أو مخططات المخرجات (output schemas). ابدأ بالهوية.

استخدم هيكلاً واضحاً: "أنت [الدور] ولديك خبرة في [المجال]". اتبع ذلك بجملة أو جملتين حول ما يفعله هذا الدور فعلياً في سياق المهمة. على سبيل المثال: "أنت مهندس خلفية (backend engineer) أول ولديك خبرة في الأنظمة الموزعة. مهمتك هي مراجعة طلبات السحب (pull requests) بحثاً عن مخاطر التزامن ومشكلات اتساق البيانات. أنت تشكك في الافتراضات المتعلقة بإدارة الحالة وترفض الموافقة على الكود الذي يفتقر إلى معالجة الأخطاء المناسبة".

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

التزم بالأدوار المهنية الحقيقية. مهندس برمجيات رفيع المستوى (staff software engineer) أو كاتب وثائق تقنية يمنح النموذج إطاراً مألوفاً من المسؤوليات. قد يبدو طلب التصرف مثل شرلوك هولمز أو ساحر من العصور الوسطى أمراً إبداعياً، لكنه يقدم ارتباطات غير متوقعة لا علاقة لها بمسار مراجعة الكود الخاص بك. الأدوار الحقيقية تحمل قيوداً حقيقية.

ما الذي يتغير عندما تنجح في ذلك

بمجرد أن تحمل كل مهارة شخصيتها الخاصة، يستقر مسار العمل بأكمله.

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

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

يعمل تسلسل المهارات أخيراً كما هو مخطط له. كل