يُظهر استطلاع أجرته Sonar لعام 2026 أن 88% من المطورين يرون أن الكود المولد بواسطة الذكاء الاصطناعي يؤدي إلى تضخم الديون التقنية، ويرى مؤيدو التطوير القائم على المواصفات (spec-driven development) أن خطوة وضع مواصفات منضبطة يمكن أن توقف هذا الانحراف.
لماذا تكمن أهمية هذه المشكلة
عندما يتلقى الإنسان تذكرة (ticket) غامضة، فإنه يطرح أسئلة توضيحية. في المقابل، يقوم وكيل الذكاء الاصطناعي بملء الفراغات بناءً على أفضل تخمين لديه، ويقدم كوداً يبدو منطقياً. إن وهم الصحة مكلف للغاية: حيث يشير استطلاع Sonar نفسه إلى أن أكثر من نصف المشاركين قد رأوا كوداً يجتاز الفحوصات الأساسية ولكنه يخفي عيوباً دقيقة. تتراكم هذه العيوب كديون تقنية، مما يفرض عمليات إعادة هيكلة (refactors) لاحقاً، ويبطئ تسليم الميزات، ويزيد من ميزانيات الصيانة.
كيف يبدو التطوير القائم على المواصفات
يقلب التطوير القائم على المواصفات (SDD) الترتيب الحالي. فبدلاً من توجيه نموذج ذكاء اصطناعي بقصة مستخدم (user story) موجزة، يقوم الفريق بكتابة مواصفات مفصلة وقابلة للتنفيذ بواسطة الوكيل، وتكون موجودة في نفس نظام التحكم في الإصدارات (version-control system) الخاص بالكود. تصبح المواصفات هي المصدر الوحيد للحقيقة؛ فهي تسجل القصد، والحالات الحدية (edge cases)، وتوقعات الأداء، وأي قيود يجب على نموذج الذكاء الاصطناعي الالتزام بها.
لا تحل هذه العملية محل عمل التصميم البشري، بل تقوم بتقنينه. ومن خلال نقل القرارات من ذاكرة المطور إلى وثيقة ملموسة، يمكن لكل من البشر ووكلاء الذكاء الاصطناعي المستقبليين تتبع سبب تصرف جزء من الكود بطريقة معينة. يتطلب صياغة المواصفات جهداً في البداية، لكن تصحيح أخطاء مخرجات الذكاء الاصطناعي الغامضة يكلف أكثر بكثير لاحقاً.
تغيير سير العمل
مخزن المنتج (Product backlog) – حافظ على العناصر قصيرة، بحيث تلتقط القصد ومعايير القبول عالية المستوى فقط. وتستمر هذه القائمة في توجيه عملية تحديد الأولويات.
تخطيط السبرنت (Sprint planning) – تناقش الفرق الهدف العام وتتفق على هدف السبرنت (Sprint Goal)، لكنهم يؤجلون التنفيذ التفصيلي حتى تصبح المواصفات جاهزة.
أثناء السبرنت – يقوم الشخص الذي يتولى المهمة بكتابة مواصفات دقيقة وقابلة للقراءة آلياً. تسرد المواصفات تنسيقات المدخلات، والمخرجات المتوقعة، ومعالجة الأخطاء، وأي متطلبات غير وظيفية. ولأن المواصفات تخضع للتحكم في الإصدارات، يمكن للمراجعين التعليق واقتراح التعديلات والموافقة على التغييرات تماماً مثل الكود.
تعريف الإنجاز (Definition of Done) – أضف "تمت مراجعة المواصفات والموافقة عليها" إلى بوابة الجودة. لا يعتبر الكود مكتملاً حتى تجتاز المواصفات نفس معايير المراجعة التي يمر بها التنفيذ.
تكييف كانبان (Kanban adaptation) – أضف عمودين جديدين: "تمت صياغة المواصفات" و"تمت الموافقة على المواصفات". تتدفق عناصر العمل الآن من: المخزن ← هدف السبرنت ← تمت صياغة المواصفات ← تمت الموافقة على المواصفات ← قيد التنفيذ ← تم الإنجاز. هذا التغيير المرئي يجعل خطوة التنسيق التي كانت غير مرئية سابقاً واضحة وصريحة.
أدوات تفرض المواصفات بالفعل
أضافت منصات مثل GitHub Spec Kit و AWS Kiro بوابات تتطلب وثيقة متطلبات قبل بدء أي عملية توليد كود بواسطة الذكاء الاصطناعي. هي لا تستبدل نموذج الذكاء الاصطناعي، بل توائم الوكلاء الذين يتبعون التعليمات حرفياً مع القصد البشري. ومن خلال جعل المواصفات شرطاً مسبقاً، تعمل هذه الأدوات على أتمتة هذا التحول دون كسر خطوط أنابيب CI/CD الحالية.
الاعتراضات المحتملة
يقول النقاد إن كتابة المواصفات تضيف عقبات إلى وتيرة العمل المرنة (agile) سريعة الحركة بالفعل. والرد على ذلك هو أن الوقت المستغرق في صياغة المواصفات عادة ما يكون جزءاً بسيطاً من الوقت الذي سيُقضى لاحقاً في تصحيح أخطاء الكود الذي أنتجه الذكاء الاصطناعي نتيجة مطالبة (prompt) غامضة.
هناك قلق آخر يتمثل في أن المواصفات قد تصبح قديمة مع تطور المتطلبات. ويحل التكامل مع نظام التحكم في الإصدارات هذه المشكلة: فأي تغيير في المواصفات ينشئ commit جديداً، ويطلق عملية مراجعة، ويجبر الفريق على إعادة تقييم الكود المرتبط به. ومن الناحية العملية، فإن التعامل مع المواصفات كأنها كود يحافظ على حداثة التوثيق.
ما يجب مراقبته لاحقاً
لا يزال التبني في مراحله الأولى، لكن الزخم واضح. ومع زيادة قدرة مولدات الكود بالذكاء الاصطناعي، ستزداد الحاجة إلى تحديد القصد بدقة وبطريقة قابلة للقراءة آلياً.
الخلاصة: قد يبدو تحويل المطالبات الغامضة إلى مواصفات ملموسة ومراجعة خطوة إضافية، ولكنه يحول التخمين إلى قرارات مسؤولة.