جدول المحتويات

في عصرٍ تكتب فيه الذكاء الاصطناعية الشيفرة، تنتقل المهارة الأعلى قيمة من «كتابة الشيفرة» إلى «كتابة المواصفات». والممارسة التي تجسّد هذا التحوّل هي التطوير المدفوع بالمواصفات (Spec-Driven Development، واختصارًا SDD). ففي عام 2026 تبنّت كبرى الأدوات — مثل Claude Code و GitHub و AWS وغيرها — هذا النهج، وصار يحظى باهتمام بوصفه «الخطوة التالية» بعد vibe coding.

يوضّح هذا المقال للمبتدئين ما هو التطوير المدفوع بالمواصفات، ولماذا صار ضروريًّا الآن، وما هي خطواته الأربع الأساسية، وأبرز أدواته، ومتى تستخدمه بدلًا من vibe coding.

SPEC-DRIVEN DEVELOPMENT · المواصفات تقود

"Specify → Plan → Tasks → Implement"

— كل خطوة تترك وثيقة، فلا يضطر الذكاء الاصطناعي إلى التخمين

STEP 1

Specify

حدِّد ما الذي تبنيه، بالكلمات.

STEP 2

Plan

أضِف التصميم والتقنية والقيود.

STEP 3

Tasks

قسِّمه إلى وحدات صغيرة قابلة للمراجعة.

STEP 4

Implement

يبنيه الذكاء الاصطناعي وفق المواصفات.

1. ما هو التطوير المدفوع بالمواصفات (Spec-Driven Development / SDD)؟

التطوير المدفوع بالمواصفات هو نهجٌ تكون فيه «المواصفات» (spec، أي وثيقة وصف ما سيُبنى) هي نجم المشروع (الوثيقة المركزية)، ويشتقّ منها الذكاء الاصطناعي التنفيذ. فبدلًا من أن يكتب الذكاء الاصطناعي الشيفرة فورًا، تقوم أولًا بتوثيق «ماذا تبني وكيف» في وثيقة منظَّمة، ثم يقرأ وكيل الذكاء الاصطناعي تلك المواصفات ليصمّم ويقسّم وينفّذ.

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

💡 في سطر واحد: SDD = «اكتب المواصفات قبل الشيفرة». المواصفات هي مصدر الحقيقة، والشيفرة مشتقّ يُولَّد منها. ومن منظور هندسة السياق، فإنّ المواصفات هي أيضًا أفضل «سياق» يمكنك تسليمه للذكاء الاصطناعي.

2. لماذا الآن؟ «جدار الأشهر الثلاثة» في vibe coding

يستطيع vibe coding (البناء عبر محادثة أفكارك خطوةً بخطوة) أن ينتج النماذج الأولية بسرعة خاطفة، لكنه يميل إلى الانهيار عند التوسّع. وكثيرًا ما تصف التقارير والممارسون الشيفرة المبنية على الاندفاع بأنها تصطدم بـ«جدار الدَّيْن التقني» بعد نحو ثلاثة أشهر، مع تضخّم تكاليف الصيانة. إذ تُترك الشيفرة المولَّدة بالذكاء الاصطناعي كما هي، فتتراكم في الإنتاج ويستحيل إصلاحها لاحقًا.

أما التطوير المدفوع بالمواصفات فيقضي على ذلك «الانجراف في المتطلبات» في مرحلة التصميم. صحيح أن تثبيت المواصفات أولًا يضيف جهدًا مسبقًا، لكنه يقلّص إعادة العمل لاحقًا بشدّة. وتفيد GitHub بأنّ عدد دورات «إعادة التوليد من الصفر» انخفض بمقدار رتبة عشرية تقريبًا باستخدام أدواتها الخاصة (رقمٌ أوردته الشركة).

VIBE CODING

سريع · مناسب للاستكشاف

  • النمذجة والتحقّق سريعان كالبرق
  • استكشف الاتجاه وأنت تحادث
  • لكنه يميل إلى الانهيار عند التوسّع
  • تنجرف المتطلبات ويتراكم الدَّيْن
SPEC-DRIVEN DEVELOPMENT

قابل للصيانة · مناسب للإطلاق

  • المواصفات هي مصدر الحقيقة، فيقلّ التشتّت
  • يمنع انجراف المتطلبات بحكم التصميم
  • جهد مسبق أكبر
  • إعادة عمل أقل بكثير وصيانة أسهل

بل يقول البعض إنّ «ميزة المهندس في 2026 هي القدرة على كتابة المواصفات أكثر من كتابة الشيفرة». فكلّما فوّضتَ أكثر إلى الذكاء الاصطناعي، تحوّلت مهمة الإنسان نحو «تحديد ما سيُبنى بدقّة».

3. التدفق الأساسي — أربع خطوات

تختلف الأسماء قليلًا بحسب الأداة، لكنّ التطوير المدفوع بالمواصفات يتّبع تقريبًا الخطوات الأربع نفسها. والأساس هو أنّ كل خطوة تترك وثيقة (غالبًا ملف Markdown) تقرؤها الخطوة التالية. والحيلة هي ألّا تبقى المعلومات في «رأس» الذكاء الاصطناعي وحده.

① Specify

صِف ماذا تبني — الميزات والغرض والمستخدمين ومعايير القبول — بالكلمات.

② Plan (التصميم)

أضِف كيف تبنيه: البنية المعمارية، والمكتبات التي ستستخدمها، والقيود.

③ Tasks (التقسيم)

قسِّم الخطة إلى وحدات صغيرة قابلة للمراجعة تتأكّد منها واحدةً تلو الأخرى.

④ Implement

يبني الذكاء الاصطناعي كل مهمّة وفق المواصفات. ويركّز البشر على المراجعة والموافقة.

⚠️ المراجعة البشرية إلزامية: حتى مع العمل المدفوع بالمواصفات، لا تتجاوز أبدًا فحص الشيفرة المولَّدة بالذكاء الاصطناعي. فـ SDD ليس أداة لـ«أطلقها وانسَها» — بل آلية تسهّل على الإنسان توجيه الدفّة.

4. الأدوات الرئيسية (Spec Kit و Kiro وغيرها)

اعتبارًا من عام 2026، تدعم معظم وكلاء البرمجة الكبرى نهج SDD. وإليك أبرز الأمثلة.

GitHub Spec Kit

أداة سطر أوامر (CLI) مفتوحة المصدر (أكثر من 90,000 نجمة على GitHub). تدعم Specify → Plan → Tasks → Implement وتعمل مع أكثر من 30 وكيلًا، من بينها Claude Code و GitHub Copilot.

AWS Kiro

يمرّ عبر Requirements → Design → Tasks قبل توليد أي شيفرة، مع موجّه Auto يختار أفضل نموذج لكل مهمّة، ويتوفّر عبر سطر الأوامر والويب معًا.

أدوات أخرى

كما تقدّم BMAD و OpenSpec و Tessl و Google Antigravity و Cursor تدفّقاتها الخاصة بنهج SDD. ومعظم الأدوات الرئيسية تدعمه بشكلٍ أو بآخر.

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

5. متى تستخدمه مقابل vibe coding

ما يهمّ ليس «أيهما الصواب» بل «متى تستخدم أيًّا منهما». والإجابة العملية لعام 2026 هي المزج (hybrid) — vibe للاستكشاف، والمدفوع بالمواصفات للإطلاق.

  • متى يناسب vibe coding: التحقّق من فكرة، أو النماذج الأولية القابلة للرمي، أو تجربة شيء صغير بمفردك. أي المرحلة التي تريد فيها فقط الوصول إلى «شيءٍ ما» بسرعة.
  • متى يناسب المدفوع بالمواصفات: الأنظمة الإنتاجية التي ستصونها على المدى الطويل، والتطوير الجماعي، والمنتجات التي تهمّ فيها المواصفات. أي حين تنظر إلى دورة حياة التطوير بأكملها.

إذن: ابدأ بـ vibe لإيجاد الاتجاه بسرعة، ثم — حالما تقرّر المضيّ قدمًا — انقله إلى مواصفات وابنِه بالكامل. فالنهجان ليسا متناقضين — الخطوة الذكية هي استخدام كلٍّ منهما في مرحلته.

6. كيف تجربه اليوم

يمكنك البدء بخطواتٍ صغيرة دون تثبيت أي أداة مخصّصة.

  • اكتب مواصفات من صفحة واحدة أولًا: للميزة التي تريدها، دوِّن «الغرض، والمدخلات/المخرجات، ومعايير القبول» كنقاطٍ في Markdown.
  • اجعل الذكاء الاصطناعي يقرأ المواصفات قبل أن تطلب الشيفرة: قل له «نفّذ بدقّة وفق هذه المواصفات؛ واسألني عن أي شيء غامض». لا تكتفِ بقول «ابنِه».
  • قسِّم المهام صغيرة: ليس كل شيء دفعةً واحدة — نفّذ ميزةً واحدة، راجِع، ثم انتقل إلى التالية. وتدوين الإجراء في Claude Skills يعزّز قابلية التكرار.
  • أبقِ المواصفات محدَّثة: حين يتغيّر شيء، أصلِح المواصفات قبل الشيفرة. فإبقاء المواصفات مصدرًا للحقيقة هو جوهر SDD.

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

الخلاصة

ثلاث خلاصات حول التطوير المدفوع بالمواصفات.

  • ما هو: كتابة «المواصفات» قبل الشيفرة، وجعل الذكاء الاصطناعي ينفّذ وفقها بوصفها مصدر الحقيقة. المواصفات هي الوثيقة المركزية.
  • لماذا: لأنه يمنع «انجراف المتطلبات والدَّيْن التقني» في vibe coding عند مرحلة التصميم، ويقلّص إعادة العمل.
  • متى: مزجٌ — vibe للاستكشاف، والمدفوع بالمواصفات للإطلاق. والمراجعة البشرية إلزامية.

ابدأ بـ«كتابة مواصفات من صفحة واحدة قبل أن تبني». ففي عصر الذكاء الاصطناعي، لا يصعد مَن يكتب الشيفرة الأسرع، بل مَن يستطيع تحديد ما سيُبنى بدقّة. واقرأ مقالَي vibe coding وهندسة السياق إلى جانب هذا المقال لتكتمل لديك الصورة عن التطوير بالذكاء الاصطناعي.

الأسئلة الشائعة

س. هل يستطيع المبتدئ في البرمجة ممارسة التطوير المدفوع بالمواصفات؟

ج. نعم — بل لعلّه الأكثر فاعلية للمبتدئين. فمجرّد تنظيم «ماذا تبني» بالكلمات قبل أي شيفرة يثبّت مخرجات الذكاء الاصطناعي ويرفع الجودة. ويمكنك البدء من ملاحظات بصيغة Markdown، دون أي أداة مخصّصة.

س. هل صار vibe coding متجاوَزًا الآن؟

ج. لا. فللاستكشاف والنمذجة، يبقى vibe coding هو الأسرع. وليست المسألة قديمًا في مقابل جديد — بل استخدام كلٍّ منهما بحسب المرحلة هو السائد في 2026: vibe للاستكشاف، والمدفوع بالمواصفات عند التوجّه إلى الإنتاج.

س. ما مدى تفصيل المواصفات المطلوب؟

ج. القاعدة هي تفصيلٌ يكفي لإيصال «الغرض، والمدخلات/المخرجات، ومعايير القبول». فالمفرط في الدقّة يصير جامدًا، والمفرط في الغموض يدفع الذكاء الاصطناعي إلى التخمين. وكما هي حال الأجزاء الستة لـالمطالبة (prompt) الجيدة، استهدِف الوسط المحدَّد والمرن في آنٍ معًا.

س. هل يُغني SDD عن مراجعة الشيفرة؟

ج. لا. تبقى المراجعة البشرية إلزامية مع التطوير المدفوع بالمواصفات. فـ SDD آلية لتوجيه الذكاء الاصطناعي في الاتجاه الصحيح، وليس أداة لتجاوز الفحوصات. ولا تُطلِق بأمان إلا حين يراجع إنسانٌ المواصفات والتنفيذ معًا.