Habr AI: لماذا يتحول الكود الذي يكتبه AI إلى دين خطير على الفرق

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

من أين تأتي الديون

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

"تُغلق المهام والمقاييس تصبح خضراء". في هذه المرحلة، كل شيء يبدو جيداً

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

لماذا من المخيف لمسه

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

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

كيفية تقليل المخاطر

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

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

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

ما معنى هذا

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