وصفت مهندسة برمجيات أولى في شركة خدمات مالية ضمن Fortune 500 لحظة أوقفتها تماماً. كانت تراجع طلب سحب من زميل مبتدئ — ثلاثمائة سطر من كود Go المُحكم وظيفياً يعالج تسوية المدفوعات. المنطق كان نظيفاً، والاختبارات نجحت، والتوثيق كان شاملاً. لكن الكود لم يكن له تاريخ. لا إيداعات متكررة تُظهر كيف عمل المطور على حالات الحدود. لا تجارب مُعلّقة. لا علامات على صراع بشري. كان المهندس المبتدئ قد ولّد الوحدة بأكملها باستخدام [مساعد برمجة ذكي](ai-coding-assistants-ar)، واختبرها وقدمها. عندما سألته عن شرح خوارزمية التسوية، استطاع وصف ما تفعله لكن ليس لماذا صُمّمت بهذه الطريقة.
يتكرر هذا المشهد عبر آلاف المؤسسات الهندسية. مع أن الكود المُولَّد بالذكاء الاصطناعي يمثل الآن 30-41% من الكود الجديد في شركات التكنولوجيا الكبرى، لم يعد السؤال عما إذا كان الذكاء الاصطناعي سيكتب برمجياتنا. السؤال هو ماذا سيحدث لحرفة صيانتها — وهل الصيانة نفسها أصبحت في طريقها للاندثار.
الدين التقني يحصل على تعريف جديد
لعقود، كان الدين التقني الاستعارة المهيمنة في القطاع لتكلفة الاختصارات. صاغ Ward Cunningham المصطلح عام 1992 لوصف ما يحدث عندما تشحن الفرق كوداً يعلمون أنه غير مثالي، بنية تنظيفه لاحقاً. يتراكم الدين: الإصلاحات السريعة تصبح مشاكل هيكلية، والتوثيق يتخلف، وفي النهاية تقضي الفرق وقتاً أكبر في إدارة الكود القديم من بناء ميزات جديدة. قدّرت McKinsey في 2020 أن الدين التقني يستهلك 20-40% من إجمالي قيمة الأصول التقنية في المؤسسات الكبيرة.
الكود المُولَّد بالذكاء الاصطناعي يقلب هذه المعادلة. عندما يمكن إعادة توليد وحدة من مواصفات بلغة طبيعية في دقائق بدلاً من إعادة هيكلتها عبر أسابيع، تتغير حسابات الدين جوهرياً. بدلاً من سداد الدين من خلال إعادة هيكلة دقيقة، يمكن للفرق إعلان الإفلاس — التخلص من التنفيذ القديم وتوليد تنفيذ جديد.
مفهوم “قواعد الكود التجددية” — حيث تُعاد توليد مكونات غير حرجة معينة دورياً من المواصفات بدلاً من صيانتها عبر تصحيحات تدريجية — يبرز في النقاش الصناعي. يعامل هذا النهج المواصفات باعتبارها القطعة الدائمة والكود كمخرج عابر. إذا كانت المواصفات صحيحة والاختبارات شاملة، يصبح التنفيذ قابلاً للتبادل.
لكن هذا يخلق شكلاً جديداً من الدين ليس له اسم راسخ. لنسمّه دين المواصفات: الفجوة بين ما تصفه مواصفات اللغة الطبيعية وما يحتاج النظام فعلاً لفعله. عندما يكتب إنسان كوداً بشكل تكراري، تظهر حالات الحدود من خلال عملية التنفيذ. عندما يولّد الذكاء الاصطناعي كوداً من مواصفات، تختبئ حالات الحدود غير المكتشفة خلف مخرجات تبدو واثقة.
مراجعة الكود في عصر التوليد
تفترض مراجعة الكود التقليدية نموذجاً ذهنياً مشتركاً. يقرأ المراجع كود زميله ويُقيّم ليس فقط الصحة بل أيضاً النية وقابلية الصيانة والتوافق مع معمارية النظام. يمكن للمراجع أن يسأل: لماذا اخترت بنية البيانات هذه؟ ماذا يحدث على نطاق واسع؟ كيف يتفاعل هذا مع وحدة الفوترة؟
عندما يكون الكود مُولَّداً بالذكاء الاصطناعي، تصطدم هذه الأسئلة بجدار. المطور الذي قدّم الكود قد يفهم المتطلب التجاري لكن ليس خيارات التنفيذ التي اتخذها النموذج. يواجه المراجع تحدياً جديداً: تقييم كود لا يوجد مبرره في أي مكان إلا في أوزان شبكة عصبية.
بعض المؤسسات تتكيف. بنى فريق الهندسة في Stripe أنظمة مثل وكلاء “minions” الذكية والمخططات الداخلية التي تُقنّن المعايير الهندسية، محوّلاً تركيز المراجعة من المخرجات المُولَّدة إلى المواصفات والقيود التي توجّه التوليد. إذا كان المخطط سليماً ومجموعة الاختبارات شاملة، تهم تفاصيل التنفيذ أقل. يتحول التركيز من “هل هذا الكود مكتوب جيداً؟” إلى “هل تلتقط هذه المواصفات كل المتطلبات؟”
فرق أخرى تضاعف الاعتماد على التحقق الآلي. استثمرت شركات مثل Anthropic وOpenAI بكثافة في أطر اختبار مدعومة بالذكاء الاصطناعي تولّد حالات اختبار إلى جانب الكود، مما يخلق طبقة تحقق لا تعتمد على المراجعة البشرية لكل تفصيل تنفيذي. النمط الناشئ واضح: عندما يصبح الكود رخيصاً، تصبح الاختبارات هي المنتج الحقيقي.
إعلان
استراتيجيات الاختبار للكود المؤقت
هرم الاختبار — اختبارات الوحدات في القاعدة، واختبارات التكامل في الوسط، والاختبارات الشاملة في القمة — صُمم لعالم يدوم فيه الكود. كنت تكتب اختبارات لالتقاط الانحدارات في كود تتوقع صيانته لسنوات. عندما يكون الكود مؤقتاً، ينقلب الهرم.
تصبح اختبارات السلوك الشاملة هي الأهم. إذا كانت الوحدة ستُعاد توليدها دورياً، فإن اختبارات الوحدات المرتبطة بتفاصيل تنفيذ محددة تنكسر مع كل عملية إعادة توليد. العقود السلوكية — اختبارات تتحقق من ما يفعله النظام بدلاً من كيف يفعله — تبقى صالحة عبر التنفيذات المختلفة. يصبح الاختبار المبني على الخصائص (Property-based testing)، الذي يتحقق من الثوابت بدلاً من أزواج مدخلات-مخرجات محددة، ضرورياً وليس اختيارياً.
يكتسب اختبار العقود بين الخدمات إلحاحاً أيضاً. عندما يمكن إعادة توليد المكونات الفردية بشكل مستقل، يجب أن تكون الواجهات بينها صلبة. شهدت أطر اختبار العقود مثل Pact تبنياً متزايداً في المؤسسات التي تكثر فيها عمليات توليد الكود بالذكاء الاصطناعي، مع إدراك الفرق أن استقرار الواجهات أهم من استقرار التنفيذ عندما تُعاد توليد المكونات بانتظام.
للتحول تبعات على التكامل المستمر. خطوط الأنابيب المصممة لتشغيل آلاف اختبارات الوحدات في دقائق يجب إعادة تصميمها حول اختبارات تكامل وعقود أبطأ لكنها أكثر معنى. تُفيد المؤسسات التي أجرت هذا الانتقال بأوقات بناء أطول لكن حوادث إنتاج أقل — مقايضة يقبلها معظم قادة الهندسة عن طيب خاطر.
الحوكمة عندما لا يملك أحد الكود
تعتمد حوكمة البرمجيات تقليدياً على الملكية. فريق يملك خدمة، يصون تبعياتها، يستجيب عندما تتعطل، ويقرر متى تحتاج إعادة كتابة. الملكية تخلق المساءلة.
الكود المؤقت يتحدى هذا النموذج. إذا كانت وحدة وُلّدت بالذكاء الاصطناعي، وأُعيد توليدها ثلاث مرات في الربع الماضي، ويمكن إعادة توليدها غداً، فمن يملكها؟ المطور الذي كتب المواصفات؟ الفريق الذي يصون مجموعة الاختبارات؟ فريق المنصة الذي يدير بنية البرمجة الذكية التحتية؟
تجرّب شركات التكنولوجيا الكبرى إجابات. بعض الفرق تبنت مفهوم “مالكي المواصفات” — مهندسون مسؤولون ليس عن الكود بل عن المواصفات السلوكية وعقود الاختبار التي تحدد مسؤوليات المكون. بدأت فرق أخرى في تجريب “سياسات التوليد” التي تحدد أي نماذج ذكاء اصطناعي يمكن استخدامها لأي أنواع من الكود، مع حوكمة أشد للمكونات الحرجة أمنياً.
البُعد التنظيمي قادم أيضاً. قانون الذكاء الاصطناعي الأوروبي (EU AI Act)، الذي بدأ التطبيق التدريجي في فبراير 2025 مع دخول حظر ممارسات ذكاء اصطناعي معينة حيز التنفيذ أولاً، يتطلب من المؤسسات الحفاظ على توثيق حول المخرجات المُولَّدة بالذكاء الاصطناعي في التطبيقات عالية المخاطر. شركات الخدمات المالية الخاضعة لقانون المرونة التشغيلية الرقمية (DORA) يجب أن تُثبت قابلية التدقيق لأنظمتها التقنية — متطلب يصبح معقداً عندما يتغير الكود الأساسي مع كل دورة إعادة توليد.
حدود التخلص
ليس كل كود يمكن معاملته كمؤقت. الأنظمة التي تدير الحالة (State) — قواعد البيانات وطوابير الرسائل وجلسات المستخدمين — تقاوم إعادة التوليد لأن سلوكها لا ينفصل عن البيانات التي تحتويها. أنظمة الوقت الفعلي ذات متطلبات التأخير الصارمة تتطلب تحسينات تنبع من قياس الأداء الدقيق وليس من مواصفات اللغة الطبيعية. الكود الحرج أمنياً يتطلب تحققاً رسمياً ومسارات تدقيق لا تستوعبها أنماط التخلص.
الإجماع الناشئ بين قادة الهندسة هو معمارية من مستويين. المنطق التجاري عديم الحالة ومعالجات API وتحويلات البيانات ووحدات التقارير مرشحة لإعادة التوليد. البنية التحتية ذات الحالة وحدود الأمان والمسارات الحرجة من حيث الأداء تبقى تُصان تقليدياً. الحدود بين هذين المستويين تصبح بحد ذاتها قرار تصميم حاسم — قرار يتطلب نوعاً من التفكير المنظومي الذي لم يستنسخه الذكاء الاصطناعي بعد.
الواضح أن الأدوات تتحرك بسرعة تفوق أطر الحوكمة. المؤسسات التي تعامل الكود المُولَّد بالذكاء الاصطناعي ببساطة كـ”كود يُكتب بسرعة أكبر” تفوتها التحول الهيكلي. البرمجيات تتغير. السؤال هو ما إذا كانت الممارسات والسياسات والنماذج التنظيمية ستتغير معها — أم ستتخلف حتى يفرض العطل التالي هذا الحوار.
الأسئلة الشائعة
ما المقصود بـ Disposable Software؟
يتناول هذا المقال الجوانب الأساسية لهذا الموضوع، ويستعرض الاتجاهات الحالية والجهات الفاعلة الرئيسية والتداعيات العملية على المهنيين والمؤسسات في عام 2026.
لماذا يُعد هذا الموضوع مهمًا؟
يكتسب هذا الموضوع أهمية كبيرة لأنه يؤثر بشكل مباشر على كيفية تخطيط المؤسسات لاستراتيجيتها التقنية وتخصيص مواردها وتموضعها في مشهد سريع التطور.
ما أبرز النقاط المستخلصة من هذا المقال؟
يحلل المقال الآليات الرئيسية والأطر المرجعية والأمثلة الواقعية التي تشرح كيفية عمل هذا المجال، مستندًا إلى بيانات حديثة ودراسات حالة عملية.
