التطوير الموجَّه بالمواصفات: الممارسة التي تقاربت عليها الفئة كلها
أطلقت كل أداة شفرة جدية بالذكاء الاصطناعي الخصيصة نفسها في نحو عام، وهذا لا يحدث بالمصادفة تقريباً أبداً.
في 2025 كان السؤال المثير: كم ستتحسن النماذج. وفي 2026 السؤال المثير: ماذا تعطيها.
أطلقت GitHub منتج Spec Kit. وأطلقت AWS منتج Kiro، وهو بيئة تطوير مبنية حول هذه الفكرة. وقدّم كل من BMAD-METHOD و OpenSpec و Tessl محاولة. ووصل Cursor إلى هناك عبر ملفات القواعد. ونشر Martin Fowler مقارنة لهذه التنفيذات. وحين تتقارب ستة فرق مستقلة على الجواب نفسه في اثني عشر شهراً، فهي لا تنسخ بعضها. كلها تصطدم بالحائط نفسه.
وللحائط اسم الآن. وللحل أيضاً.
ما هو التطوير الموجَّه بالمواصفات فعلاً
اكتب المتطلبات والقيود ومعايير النجاح قبل توليد أي شفرة. وتعامل مع تلك الوثيقة كمصدر الصحة. ودع الوكيل يبني مقابلها.
هذا كل شيء. وهي ليست فكرة جديدة: إنها تحليل المتطلبات الذي أخطأ القطاع في أدائه ثلاثين عاماً ثم تخلى عنه في معظمه لبطئه. والذي تغيّر ليس المفهوم. الذي تغيّر هو الاقتصاد.
كانت المواصفات مكلفة الكتابة ومكلفة الصيانة، ما يعني أن معظم الفرق كتبت خطوطاً عريضة واكتشفت كل ما عداها في مراجعة الشفرة. وكانت هذه مبادلة معقولة طالما احتاج المهندس ثلاثة أسابيع لخصيصة على أي حال. وكفّت عن كونها معقولة حين صار التوليد سريعاً، لأن المواصفة هي الجزء البطيء الآن، وكل الحكم يسكن في الجزء البطيء.
شكل العطل الذي اختُرِع في مواجهته
الأدوات التي تبدأ من التوجيه تتجاوز المواصفة تماماً. تصف نتيجة، فتنتج الأداة شيئاً يشبهها، ويتخذ المُولِّد بصمت كل قرار لم يغطّه الوصف.
أي قرارات؟ التي تبيّن أنها مهمة. هل عنوان البريد فريد، وفريد داخل ماذا. وما يستطيع حساب ملغى رؤيته بعد. وما يحدث حين يعدّل شخصان السجل نفسه. وهل تحتاج تلك القائمة تقسيماً إلى صفحات قبل أن تبلغ عشرة آلاف صف.
لم يطرح أحد هذه الأسئلة فلم يجب أحد، لكن التطبيق يملك جواباً لكل منها، مُختاراً باستنباط من سياق لم يتضمن شركتك قط.
والحركية نفسها تظهر في كل أداة تتجاوز خطوة التعريف. وهذه هي الآلية خلف مشكلة السبعين بالمئة: يتوقف التقدم لا لأن العمل الباقي صعب، بل لأنه محجوز بقرار بنيوي اتُّخذ بصمت قبل مئات الأجيال ولم يعد قابلاً للتغيير دون تفكيك النظام.
البيانات عن ما يحدث بدونه
تقرير DORA لعام 2025 عن حال تطوير البرمجيات المدعوم بالذكاء الاصطناعي هو أنقى قراءة متاحة. فتسعون بالمئة من العاملين في التقنية يستخدمون الذكاء الاصطناعي في العمل الآن، وأكثر من ثمانين بالمئة يعتقدون أنه رفع إنتاجيتهم. وارتفاع استخدام الذكاء الاصطناعي يسير جنباً إلى جنب مع ارتفاع معدل التسليم وارتفاع عدم استقرار التسليم، في الوقت نفسه.
أسرع في الإطلاق. وأسوأ في إبقاء الأمور تعمل. الاثنان معاً.
وتحليل GitClear لعام 2026 على 623 مليون تغيير في الشفرة يُظهر شكل الضرر. فمقابل خط أساس 2023: كتل الشفرة المكرَّرة أعلى 81 بالمئة، والنسخ واللصق داخل الدفعة نفسها ارتفع من 9.4 بالمئة في 2022 إلى 15.7 بالمئة في النصف الأول من 2026، والبنى التي تحجب الأخطاء أعلى 47 بالمئة. وفي الوقت نفسه، استدعاءات الدوال بين الملفات، وهي أفضل مؤشر متاح لإعادة استخدام الشفرة، أدنى 35 بالمئة، وعمل تنظيم الشفرة انهار من 21 بالمئة من التغييرات في 2022 إلى 3.8 بالمئة في 2026.
فالمهندسون الآن أكثر احتمالاً بنحو خمس مرات لنسخ الشفرة ولصقها من تنظيمها. وفي 2022 كانت هذه النسبة تعمل في الاتجاه الآخر.
ولا شيء من هذا مسألة جودة نموذج. إنه النتيجة حين يكون التوليد رخيصاً والبنية ليست عمل أحد صراحةً.
درجات الالتزام الثلاث
لا يفهم الجميع هذه العبارة بالطريقة نفسها، والفروق مهمة عملياً. وصياغة Martin Fowler أنقى ما رأيت.
المواصفة أولاً. تكتب مواصفة، وتولّد منها، ثم تصون الشفرة يدوياً. فالمواصفة تدفع البناء الأول ثم تصبح تدريجياً تاريخية. الأسهل تطبيقاً والأضعف ضماناً: فبعد ستة أشهر تصف الوثيقة نظاماً لم يعد موجوداً.
المواصفة كمرساة. تتطور المواصفة والشفرة معاً. تعدّل المواصفة، وتعيد توليد الأجزاء المتأثرة، وتُبقي الاثنين محدَّثين. انضباط أكثر، والمكافأة أن الوثيقة تبقى جديرة بالثقة.
المواصفة كمصدر. المواصفة هي الناتج الوحيد الذي تعدّله. والشفرة ناتج، كما أن الملف المُصرَّف ناتج: لا تُرقَّع يدوياً. أقوى الضمانات وأكبر قفزة في طريقة عمل الفريق.
ومعظم الفرق التي تسمّي نفسها موجَّهة بالمواصفات تمارس صيغة «المواصفة أولاً». وهي تحسّن حقيقي على التوجيه العشوائي، وهي في الوقت نفسه الصيغة التي تتعفّن بصمت.
ما ينتمي إلى المواصفة
اختبار مفيد: إذا كان على المُولِّد أن يحدس، فهو ينتمي إلى الوثيقة.
- نموذج البيانات. الكيانات والعلاقات والتعدد وما يجعل سجلاً فريداً وما يحدث عند الحذف. الجزء الأكثر قيمة والأكثر تجاوزاً.
- أنواع المستخدمين والصلاحيات. من يوجد، وما يستطيع كل منهم رؤيته وفعله، وما يحدث عند الحدود.
- الثوابت. القواعد التي لا يجوز خرقها أبداً، معلنة صراحةً. لا «عالج الأخطاء بلطف»، فذلك أمنية لا قيد.
- معايير النجاح. كيف تعرف أن الشيء يعمل، بكلمات دقيقة بما يكفي لحسم الجدال حول ما إذا كان يعمل.
وما لا ينتمي إليها: تفاصيل التنفيذ التي يختارها المُولِّد أفضل منك. فالمواصفة التي تسمّي المتغيّرات ليست مواصفة، بل شفرة مكتوبة بأداة أسوأ.
الجزء الذي يخطئ فيه الجميع
المواصفة تساعد فقط إذا كان بالإمكان فرضها في مكان خارج النص.
فإذا كان القيد يسكن في الوثيقة فقط، فهو اقتراح. قرأه المُولِّد مرة، وقد يحترمه في الملف الرابع عشر المتأثر وقد لا يفعل. وعلى القيود أن تذهب إلى حيث يتحقق النظام: «غير فارغ» و«فريد» في قاعدة البيانات لا في معالج النموذج، والأنواع عند الحدود لا في تعليق، والتخويل كسياسة يقيّمها النظام لا كشرط تذكّر أحدهم كتابته.
وهذا هو الفرق بين التطوير الموجَّه بالمواصفات كممارسة والتطوير الموجَّه بالمواصفات كنوع من الوثائق. فالوثيقة هي كيف تقرر. والفرض هو كيف تحافظ على القرار.
كيف تعرف إن كنت تمارسه فعلاً
أربعة أسئلة، مزعجة بقصد.
- حين ينكسر شيء، هل تصلح الشفرة أم المواصفة؟ إذا كان الجواب دائماً الشفرة، فأنت في أفضل الأحوال تمارس «المواصفة أولاً»، والوثيقة عتيقة أصلاً.
- هل يستطيع شخص جديد قراءة المواصفة والتوقع كيف سيتصرف النظام؟ إذا كان عليه قراءة الشفرة لذلك، فالمواصفة ملخّص لا مصدر.
- هل في المواصفة شيء لا يستطيع النظام خرقه؟ إذا كانت كل قاعدة نصاً، فلا شيء مضمون.
- هل تراجع المواصفة أم فرق الشفرة؟ مراجعة آلاف الأسطر من الشفرة المُولَّدة مسرح. تجادل في الوثيقة والجدال ما زال رخيصاً.
أين يترك هذا الأدوات
معظم تنفيذات اليوم موجَّهة بالمواصفات لأجل توليد الشفرة تحديداً. تنتج مواصفة وتولّد التنفيذ مقابلها، والناتج الذي تعمل عليه هو قاعدة الشفرة.
والصيغة الأصعب تمدّ المنطق نفسه إلى التطبيق كله (نموذج البيانات، وسطح واجهة البرمجة، وحدّ المصادقة، والواجهة)، بحيث تغطي المواصفة لا ما تفعله الشفرة فقط بل ما هو النظام. ومرحلة المخطط في Archie هي ذلك بالضبط، ولهذا أصفها بأنها تطوير موجَّه بالمواصفات مطبَّق على الحزمة كلها لا على مستودع. نطاق مختلف، والمبدأ نفسه: عرّف قبل أن تولّد.
والعقلاء يختلفون في مدى المضي بهذا. ولا أحد جدي يدعو إلى العودة.
ما تكلفة هذا
نقل الحكم إلى البداية أبطأ في الأسبوع الأول من مشروع وأسرع في كل أسبوع بعده. وهذه تكلفة حقيقية تُدفَع مقدماً، في اللحظة التي يبدو فيها الزخم أثمن ما يكون وينشر فيها منافس شيئاً مرئياً. وستكون هناك دورات عمل يبدو فيها الفريق الذي تجاوز كل هذا متقدّماً.
والانضباط يتعفّن أيضاً. فكتابة القيود أقل متعة من مشاهدة واجهة تظهر، ومراجعة مواصفة أقل إشباعاً من مراجعة شفرة. وهذه العادات تتآكل تحت ضغط المواعيد، وهو الضغط نفسه الذي يجعلها مهمة.
وبعضه لا ينطبق فعلاً. فإذا كنت تختبر فكرة نهاية هذا الأسبوع وتنوي التخلص من النتيجة، فتخلّص منها: لا شيء من هذا يستحق العناء لبرمجية عمرها يومان.
سبب رسوخ هذا
كل محاولة سابقة لدفع الفرق إلى كتابة المواصفات أولاً فشلت، وفشلت لسبب وجيه: كانت المواصفة عبئاً إضافياً فوق العمل الحقيقي. تكتب الوثيقة، ثم عليك بناء الشيء على أي حال.
ولم تبقَ تلك هي المبادلة. فالوثيقة الآن هي معظم العمل، والبناء هو الجزء الرخيص. ولاحظت ستة فرق مستقلة هذا في عام واحد، لأنه كان النتيجة البديهية لتحسّن النموذج.
هذه الممارسة لم تكسب الجدال. الاقتصاد تحرّك من تحتها.
قراءات ذات صلة
التشخيص الأول: vibe coding أخلف وعده. وإلى أين مضت الفئة: ما يأتي بعد vibe coding. والحجة نفسها مطبَّقة على أنظمة كاملة: تصميم البرمجيات بالذكاء الاصطناعي أولاً من المبادئ الأولية. وصياغة أقدم للفكرة نفسها: لا تكتب البرمجيات مرتين.
الأسئلة الشائعة
ما هو التطوير الموجَّه بالمواصفات؟ كتابة المتطلبات والقيود ومعايير النجاح قبل توليد أي شفرة، والتعامل مع تلك المواصفة كمصدر الصحة الذي يبني وكيل الذكاء الاصطناعي مقابله. وقد ظهر في 2025 و2026 كرد مباشر على طرق العمل التي تبدأ من التوجيه وتتجاوز خطوة التعريف.
كيف يختلف عن وثائق المتطلبات الكلاسيكية؟ المفهوم نفسه؛ والاقتصاد ليس كذلك. فالمواصفات الكلاسيكية كانت مكلفة إلى حد بعيد، فكتبت الفرق خطوطاً عريضة واكتشفت الباقي في أثناء التنفيذ. وحين يستغرق إعداد واحدة ساعات لا أشهراً وتكون رخيصة التصحيح، فإتمامها يستحق وإبقاؤها محدَّثة يستحق.
أي الأدوات تدعم التطوير الموجَّه بالمواصفات؟ GitHub Spec Kit و AWS Kiro و BMAD-METHOD و OpenSpec و Tessl تنفيذات مسمّاة، ويدعم Cursor صيغة أخف عبر ملفات القواعد. وتختلف جوهرياً في مدى إحكام ربط المواصفة بالشفرة: هل تدفع التوليد مرة واحدة، أم تتطور بجانبها، أم هي الناتج الوحيد الذي تعدّله؟
ما درجات التطوير الموجَّه بالمواصفات الثلاث؟ المواصفة أولاً: تدفع المواصفة البناء الأول وتصون الشفرة يدوياً بعده. والمواصفة كمرساة: تتطور المواصفة والشفرة معاً. والمواصفة كمصدر: المواصفة هي الشيء الوحيد الذي تعدّله والشفرة تُعامَل كناتج. ومعظم الفرق التي تمارس هذا تفعل «المواصفة أولاً».
هل يبطّئ التطوير الموجَّه بالمواصفات الفرق؟ ينقل العمل بدل إضافته. فالقرارات في المواصفة تُتخذ إما بوعي مقدماً وإما بصمت بواسطة مُولِّد يحدس لاحقاً، والطريق الثاني مصدر التصحيحات. إنه أبطأ في الأسبوع الأول وأسرع بعده.
ما ينبغي أن يدخل المواصفة؟ كل ما كان على المُولِّد حدسه لولا ذلك: نموذج البيانات بعلاقاته وقواعد التفرد، وأنواع المستخدمين والصلاحيات، والثوابت التي لا يجوز خرقها، ومعايير نجاح دقيقة بما يكفي لحسم جدال. وتجاوز تفاصيل التنفيذ التي يختارها المُولِّد أفضل منك.
هل التطوير الموجَّه بالمواصفات هو نفسه التصميم بالذكاء الاصطناعي أولاً؟ التطوير الموجَّه بالمواصفات هو ممارسة التعريف قبل التوليد. أما التصميم بالذكاء الاصطناعي أولاً فهو مجموعة أوسع من النتائج البنيوية، تشمل أيضاً أين تُفرَض القيود، وبأي ترتيب تُتخذ القرارات، وكيف تُصمِّم لمستخدمين وكلاء إلى جانب مستخدمين بشر.
