رائد DevOps يحذّر: تبني وكلاء الذكاء الاصطناعي يتطلب تغييرات على مستوى النظام، وليس فقط أدوات

لا تصلح الكود الذي ينتجه العميل، بل صلّح النظام الذي ينتج هذا الكود.

كاتب المقال، المصدر: InfoQ

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

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

لكن باتريك ديبوا، الذي اقترح مصطلح DevOps، يرى: "يحتاج المطورون إلى إجراء تحول فكري مهم: عندما لا يُنجز العامل المهمة كما توقعت، لا تقم بتعديل الكود الذي أنشأه، بل قم بتحسين النظام بأكمله، وليس فقط الـ Prompt."

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

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

النقاط الأساسية هي كالتالي:

• لا تصلح الكود الذي ينتجه العميل، بل صلّح النظام الذي ينتج هذا الكود.
• إذا كان لا يزال هناك أحد في فريقك يستخدم نهج "YOLO" العشوائي في تطوير الكود، فيجب عليك إيقافه فورًا. الممارسات الهندسية ليست فقط حاسمة لصيانتك للنظام، بل أيضًا حاسمة لتحسين Agent باستمرار.
• قد لا تكون المصنع المظلم مظلمًا بالكامل، بل قد يحتفظ ببعض الضوء الخافت (dim factory)، مما يعني أنك يجب أن تقرر مدى المخاطرة التي تتحملها لكل ميزة، فليس كل الميزات مناسبة للحكم الذاتي الكامل.
• الشخص الذي تبحث عنه هو من يجمع بين استخدام الذكاء الاصطناعي بدرجة قصوى، وقاعدة هندسية قوية، ورغبة في المشاركة والتعاون.
• حاجزك التنافسي هو التقاط المعرفة المترسبة، تلك التي تُدخلها الآن في skill وContext وحتى قيود Harness.

في عام 2009، أخبرني كثيرون أن فكرة التسليم المستمر كانت مجنونة.

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

واليوم، واجهت Dark Factory نفس العقبة تمامًا.

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

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

الكثير من الناس يتحدثون الآن عن كيفية تحسين العامل باستخدام الحلقات، وكيفية إنشاء Harness، وكل ذلك رائع. لكنني أريد أن أقول إننا في النهاية سنصل جميعًا إلى ذلك المستوى التقني، وستصبح يومًا ما نوعًا من السلع القياسية، بل وقد تُقدَّم كخدمة مُعبأة من قبل مختبر رائد. وفي ذلك اليوم، لن يكون هناك حواجز تقنية. الاختلاف الحقيقي يكمن في كيفية إعادة هيكلة منظمتك لأسلوب التعاون حول هذا الشيء.

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

أعتقد أن معظم الحاضرين يعملون في فريق ما، وليس وحدهم، والعمل الجماعي يختلف تمامًا عن التفاعل مع Claude Code بمفردك.

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

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

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

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

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

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

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

أبدأ في رؤية طقوس جديدة في بعض الفرق المتقدمة، حيث لا تزال تُعقد اجتماعات التخطيط والمراجعة، لكن محتوى المناقشات تغير تمامًا. لم تعد اجتماعات المراجعة تتحدث عن "ما الذي خرج خطأ في الكود"، بل تسأل "ما الذي خرج خطأ في النظام؟"

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

عادةً ما يمر المطورون بدورة تعلم: يبدأون بتعلم Prompt، ثم ينتقلون إلى SPEC أفضل، ثم إلى Context وHarness والدورات، وتصعد الصناعة بأكملها خلال هذه الدورة. لكن ما يمكن لقائد الفريق فعله هو تحديد الإيقاع والقيود لهذه العملية، مثل أن يقول لهم: "لا تواصلوا تعديل Prompt، ركزوا على جعل Context قابلاً لإعادة الاستخدام." أو: "جيد، لقد أكملتم هذه الخطوة، دعونا ننتقل إلى الخطوة التالية." إن قيمة قائد الفريق تكمن في تحديد هذا الإيقاع؛ فإذا تركتم الفريق يقول فقط "اكتشفوا ذلك بأنفسكم"، فلن ينجح ذلك.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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