كيف يحدد فريق تقنية المعلومات مسؤولية الكود المكتوب بمساعدة الذكاء الاصطناعي، ويراجعه قبل دمجه، وينظم تسليم النماذج التفاعلية من المصممين إلى المطورين.
أصبح الذكاء الاصطناعي جزءًا من عملنا اليومي. تستطيع الفرق اليوم أن تحوّل الفكرة إلى عمل قابل للمراجعة في وقت أقصر، ويظهر ذلك بوضوح في التطوير بمساعدة الذكاء الاصطناعي: يصل الكود أسرع، وتجهز النماذج الأولية للتجربة مبكرًا، ويتقدم العمل.
لكن هناك سؤالًا لا تظهر إجابته بالسرعة نفسها: هل سنتمكن من صيانة ما سلّمناه وتعديله لاحقًا؟
قد تبدو الميزة مكتملة اليوم، ثم يصعب تعديلها بعد ستة أشهر. وإذا لم يستطع الفريق شرح طريقة عملها، فسيحتاج شخص آخر إلى الوقت الذي اختصرناه في البداية كي يفهمها. وهذا الفرق بين إنجاز العمل وتحمّل مسؤوليته يشغلني كثيرًا بحكم عملي رئيسًا لتقنية المعلومات.
وقد واجهنا موقفين أوضحا المشكلة: مطوّر يسلّم كودًا لم يفهمه بالكامل، ومصمم يسلّم صفحة تفاعلية تعمل بالفعل. وفي الحالتين احتجنا إلى تحديد المسؤول عن تحويل هذا الناتج إلى جزء من المنتج يمكن الاعتماد عليه وتطويره لاحقًا.
التطوير بمساعدة الذكاء الاصطناعي يحتاج إلى وضوح في ملكية الكود
نشجّع المطورين وفرق التشغيل والتطوير على استخدام الذكاء الاصطناعي. لا نطلب من أحد أن يكتب كل سطر بنفسه، بل أن يفهم الكود الذي يسلّمه.
تبدأ المشكلة حين يعرض المطوّر ميزة تعمل، لكنه لا يستطيع شرح القرارات التي بُني عليها تنفيذها. فالعرض الناجح يترك أسئلة مهمة مفتوحة: كيف يتصرف الكود إذا فشل الطلب؟ ولماذا احتجنا إلى مكتبة خارجية جديدة؟ وماذا يحدث إذا تغيرت الافتراضات؟
هذه أسئلة طبيعية لأي فريق يتولى صيانة المنتج، والكود الذي كتبه الذكاء الاصطناعي ليس استثناءً منها.
وقاعدتنا واضحة: المطوّر الذي يقدّم كودًا إلى بيئة التشغيل مسؤول عن فهمه ودعم صيانته. ولا يعني ذلك أن يبقى المسؤول الوحيد عنه طوال عمر المنتج، بل أن نعرف من يتحمل مسؤولية التغيير، وأن يكون الشرح كافيًا ليتسلّمه مطوّر آخر.
وهنا يجب التمييز بين صاحب التغيير ومن يراجعه. فموافقة المراجع تعني أنه قيّم التغيير وفق معايير الفريق، ولا تعني أن مسؤولية كل سطر انتقلت إليه. وفي المقابل، لا يستطيع صاحب التغيير أن ينقل مسؤوليته إلى الأداة التي كتبت الكود.
الأدوات تدعم المراجعة، وصاحب الكود يظل مسؤولًا عن فهمه وصيانته.
أربع مراحل قبل قبول طلب الدمج
نعتمد أربع مراحل لتوضيح المسؤولية أثناء المراجعة:
نربط كل طلب دمج بمهمة محددة. فقبل قراءة الكود يحتاج قائد الفريق إلى معرفة المشكلة المطلوب حلها، وأي عمل إضافي يحتاج إلى مبرر واضح، حتى لو أنتجه الذكاء الاصطناعي في ثوانٍ.
نفحص شروط الجودة المحددة بأداة للتحليل الثابت للكود، ونستخدم لذلك SonarQube. ويتولى التحليل الثابت جزءًا من الفحوصات المتكررة، واجتياز بوابة الجودة يعني استيفاء الشروط المحددة فيها، لكنه لا يثبت أن الميزة صحيحة من كل الجوانب. توثيق بوابات الجودة
نضيف مراجعة آلية للكود بالذكاء الاصطناعي، ونستخدم لذلك Greptile. نبحث بها عن أخطاء محتملة وعن ملاحظات تتعلق بالتزام الكود بقواعدنا، وتتيح القواعد المخصصة تحديد متطلبات خاصة بكل مشروع، وتبقى مسؤولية تقييم الملاحظات على الفريق. توثيق إعدادات المراجعة
يتخذ قائد الفريق القرار النهائي في المراجعة: هل يتوافق التغيير مع المهمة؟ وهل يستطيع صاحبه شرحه؟ وهل بقيت أسئلة لم تحسمها الفحوصات الآلية؟ فظهور النتائج باللون الأخضر لا يغني عن هذا النقاش.
وإذا لم يستطع صاحب التغيير شرح الكود، نعيد إليه طلب الدمج. فالمشكلة هنا أن الفريق غير مستعد لصيانة الميزة، حتى لو كان العرض مقنعًا.
ولهذه المراحل تكلفة بالطبع، فهي تطيل وقت المراجعة، وقد اعترض عليها بعض المطورين في البداية. تقبّلنا ذلك مقابل اكتشاف سوء الفهم مبكرًا، قبل أن يُبنى عليه عمل آخر. وبالنسبة لي، مناقشة قرار غير واضح الآن أفضل من مطالبة شخص آخر بفهمه بعد أشهر.
وتعتمد قيمة وقت المراجعة على الأسئلة التي نركز عليها. فتكرار التنبيه الذي أصدرته الأداة لا يضيف الكثير، أما مناقشة افتراض لم ينتبه إليه صاحب الكود فقد تكون أهم جزء في المراجعة.
حين يسلّم المصمم نموذجًا تفاعليًا يعمل في المتصفح
يستخدم المصممون في فرقنا الآن الذكاء الاصطناعي لإنتاج صفحات تفاعلية تعمل في المتصفح، أحيانًا إلى جانب الشاشات الثابتة وأحيانًا بدلًا منها. والسبب مفهوم: بعض التفاعلات يصعب شرحها في مستند، بينما توضّح تجربتها في المتصفح الفكرة بسرعة.
والسؤال المهم: ماذا يتوقع الفريق من العمل الذي تسلّمه؟
يمكن للنموذج الأولي أن يوضّح السلوك المقصود دون أن يكون جاهزًا لبيئة التشغيل. وقيمته أنه يتيح للمطوّر تجربة التفاعل وطرح أسئلة أدق، ومن المفيد الإبقاء على هذه المساحة للتجربة بدل حصر النقاش في شاشات ثابتة.
وفي الوقت نفسه، وجود نموذج أولي يعمل لا يعني أن تنفيذه اجتاز المراجعة.
لذلك حددنا المسؤولية عند التسليم. يتولى المصمم مسؤولية التجربة المقصودة وطريقة عرضها، ويتولى المطوّر المسؤول عن التنفيذ تقييم الصفحة التفاعلية وتحديد ما يمكن إعادة استخدامه منها وما يحتاج إلى إعادة هيكلة أو كتابة من جديد. ثم يمر الكود النهائي بالمراجعة نفسها المطلوبة لأي تغيير آخر.
ويتحمّل المطوّر مسؤولية التنفيذ قبل الدمج، وهو قرار يختلف عن مجرد الضغط على زر الموافقة في طلب دمج قدّمه شخص آخر.
وهذه بالنسبة لي زاوية عملية لفهم دور الذكاء الاصطناعي في تصميم تجربة المستخدم: النموذج الأولي يسهّل النقاش حول التفاعل، ويبقى الفريق مسؤولًا عن طريقة تطبيقه في المنتج. فالشاشة المقنعة لا تحسم أسئلة التنفيذ.
وخطوتنا التالية أن نتيح مكوّنات نظام التصميم للمصممين مباشرة، ونتوقع أن يقرّب ذلك النماذج الأولية من الأنماط الموجودة في المنتج. لكنها خطوة لم تتحقق بعد، ولا تلغي حاجة المطوّر إلى تقييم التنفيذ.
ماذا نقيس إلى جانب عدد المهام المنجزة؟
يوضح عدد المهام المكتملة حجم العمل المنجز، لكن تقييم نجاح طريقتنا يحتاج إلى متابعة ما يحدث بعد الإطلاق: كم مرة نعيد العمل على التغيير؟ وهل يستطيع مطوّر آخر أن يتسلّمه؟ وأي القرارات غير الواضحة تعطّل الصيانة؟
هذه مقاييس أقترح متابعتها، وليست نتائج أدّعي أننا قسناها بالفعل. وهي تقرّب تقييم النضج الرقمي من واقع الفريق أكثر من الاكتفاء بعدّ من يستخدمون أدوات الذكاء الاصطناعي.
وأقترح بداية بسيطة: نختار تغييرًا حديثًا استعان فيه الفريق بالذكاء الاصطناعي، ونجمع صاحبه مع الشخص المتوقع أن يتولى صيانته لاحقًا. وخلال الشرح ستتضح الأجزاء المفهومة والافتراضات التي لم نناقشها.
زيادة المخرجات مفيدة حين تستطيع المؤسسة التعامل معها. وفي الفرق التي أقودها يتطلب ذلك نطاق عمل واضحًا، ومراجعة فعلية، وشخصًا يتحمل مسؤولية التغيير الذي سيصل إلى بيئة التشغيل. وقبل الدمج أريد أن نجيب عن سؤال بسيط: حين يحتاج هذا العمل إلى تعديل، هل سنعرف من أين نبدأ؟
للاستزادة
وجد تحليل جيت كلير لنحو 153 مليون سطر برمجي عُدّلت بين عامي 2020 و2023 أن الكود المنسوخ والمكرر ازداد مع انتشار مساعدات البرمجة، وتوقّع أن يتضاعف في عام 2024 معدل الكود الذي يُعاد تعديله أو يُتراجع عنه بعد وقت قصير من كتابته، مقارنة بعام 2021.
وفي تقرير دورا لعام 2024 عن حالة التشغيل والتطوير الصادر عن جوجل، ارتبطت زيادة الاعتماد على الذكاء الاصطناعي بتراجع تقديري في استقرار التسليم بنسبة 7.2% وفي سرعته بنسبة 1.5%.
