Spec-Driven Development: الأصل والمنهجية والأدوات وما لا يخبرك به الضجيج

١٣ مارس ٢٠٢٦

متاح - Kiro: خطة مجانية على kiro.dev

spec-driven-development
sdd
methodology
ai-agents
kiro
claude-code
vibe-coding
news-date:2026-03-13
created-at:2026-03-13
updated-at:2026-03-13

tl;dr — SDD هو استجابة مشروعة لمشكلة حقيقية مع وكلاء الذكاء الاصطناعي. المفهوم منطقي، والأدوات غير ناضجة، والتكلفة مرتفعة، وأدلة ROI لا تزال شبه قصصية بالكامل. يستحق الفهم. يستحق الريبة.

المشكلة التي أفرزت كل هذا

لفهم سبب ظهور Spec-Driven Development، لا بد من التراجع خطوة للوراء.

في عام 2025، توقف وكلاء الذكاء الاصطناعي كـ Claude Code وCursor وCodex عن كونهم مجرد إكمال تلقائي مُبالَغ في تقديره، وباتوا يُنفّذون مهام معقدة باستقلالية تامة. ومع ذلك ظهرت ظاهرة vibe coding: تصف ما تريده بلغة طبيعية، يُولّد الوكيل مئات الأسطر من الكود، وأنت توافق دون أن تفهم بالكامل ما تم إنجازه.

النتيجة؟ كود يعمل حتى اللحظة التي يحتاج فيها إلى صيانة. قرارات معمارية غير مرئية. دَيْن تقني يتراكم بسرعة صناعية.

الدراسة الأكثر صرامة في هذا الموضوع — التي أجرتها METR عام 2025 مع مطورين ذوي خبرة في مشاريع open source حقيقية — خلصت إلى أن المطورين الذين يستخدمون أدوات الذكاء الاصطناعي كانوا، في المتوسط، أبطأ بنسبة 19% مقارنةً بعملهم بدونها. ليس أسرع. السبب: الـ prompts غير المنظمة تُفضي إلى حلقات تصحيح أخطاء تستهلك كل الوقت الذي وُفّر في توليد الكود أولاً.

Spec-Driven Development هو محاولة الصناعة لحل هذه المشكلة من جذورها.

من أين جاءت الفكرة

فكرة كتابة المواصفات قبل كتابة الكود ليست جديدة. إنها قديمة قِدَم هندسة البرمجيات نفسها.

1963: مارغريت هاملتون، وهي تدير برمجيات بعثات Apollo لدى NASA، صاغت مصطلح “هندسة البرمجيات” لأن البرامج نمت إلى ما هو أبعد من قدرة أي شخص على استيعابها بالكامل. أدركت: هذه هندسة، وتحتاج إلى عملية.

1968: نظّمت NATO مؤتمراً في برلين حدّد رسمياً أزمة البرمجيات (Software Crisis): أصبحت الحواسيب تتيح برامج بالغة التعقيد لدرجة أنه لا يمكن إدارتها بصورة ملائمة. لقد تجاوز حجم الكود القدرةَ البشرية على التفكير فيه.

1972: لخّص Dijkstra في محاضرة جائزة Turing: “حين لم تكن هناك آلات، لم يكن البرمجة مشكلة. حين كانت لدينا حواسيب قليلة وضعيفة، أصبحت البرمجة مشكلة طفيفة. الآن لدينا حواسيب عملاقة، وأصبحت البرمجة مشكلة عملاقة بالمثل.”

كان رد الفعل في تلك الحقبة هو العملية: Waterfall كمعيار DoD، ثم Agile عام 2001، ثم CI/CD في السحابة الذي أتاح Agile على نطاق واسع.

الآن نحن في الدورة التالية. وصف Drew Breunig، الباحث الذي شاع مصطلح SDD عام 2026، الأمر بدقة: “أزمة برمجياتنا الحالية هي عجزنا عن إدارة قواعد الكود المعقدة التي تتيحها النماذج الجديدة. في السابق كانت المشكلة أننا لا نستطيع استيعاب كل الكود في أذهاننا. أما الآن فلا نستطيع حتى قراءة كل كودنا.”

وكلاء الذكاء الاصطناعي يُتيحون حجماً من الإنتاج يُضاهي Waterfall بإيقاع Agile. هذه هي المشكلة التي يسعى SDD إلى معالجتها.

ما هو Spec-Driven Development

SDD هو منهجية تطوير تعتبر المواصفة الأرتيفاكت الأساسي — لا الكود.

بدلاً من الدورة التقليدية prompt → كود → تكرار، تصبح الدورة:

Spec → Plan → Tasks → Code

تحدد المواصفة النية والقيود ومعايير القبول والبنية المعمارية قبل أي تنفيذ. ثم يُنفّذ وكيل الذكاء الاصطناعي استناداً إلى هذا المدخل المُهيكَل بدلاً من تفسير وصف مبهم.

تمييز مهم: مع أدوات كـ Spec Kit وKiro وTessl، تُولّد الذكاء الاصطناعي المواصفة نفسها. تصف الهدف بلغة طبيعية، ويُنتج الوكيل ملفات المواصفات — عادةً requirements.md وdesign.md وtasks.md — التي سيستخدمها هو ذاته سياقاً في التنفيذ. المواصفة ليست وثيقة تُكتب يدوياً مسبقاً من قِبَل محللين؛ بل تنبثق من الحوار بين المطور والوكيل، قبل الكود بفترة وجيزة.

هذا يُغيّر تشخيص المشكلات الكلاسيكية المتعلقة بالمواصفات: لم تعد المسافة بين المواصفة والكود أسابيع أو فرقاً مختلفة. المواصفة والكود يُولَّدان في نفس الدورة، بنفس الأداة، بفارق دقائق قليلة. المشكلة التي تبقى ليست الفصل الزمني — بل العمل المسبق وتكلفة الرموز (tokens) وتدهور السياق عبر التكرارات، وما يحدث بعد النشر حين تتباين الواقع مما كان محدداً.

ثمة مستويات مختلفة لاعتماد SDD:

Spec-first: تُولَّد المواصفة قبل التنفيذ وتُستخدم مرشداً لتلك المهمة. بعد اكتمالها، تُهمَل.

Spec-anchored: تُحفَظ المواصفة بعد المهمة لتوجيه التطور والصيانة المستقبلية للنظام. إنها أرتيفاكت حي يرافق الكود.

Spec-as-source: المستوى الأطموح. المواصفة هي الكود المصدري. الكود المُولَّد مجرد أرتيفاكت مُصرَّف من المواصفة، مُوسَم بـ // GENERATED FROM SPEC - DO NOT EDIT. تسعى Tessl إلى تحقيق ذلك.

مثلث SDD — ولماذا الدورة أصعب مما تبدو

جاءت المساهمة الأكثر صدقاً في النقاش من Breunig في مارس 2026، بعد أن بنى مشروع whenwords (مكتبة open source لا تحتوي سطراً واحداً من الكود — مواصفة فحسب + 750 اختباراً للمطابقة) ورصد كيف تطورت مشاريع مماثلة.

درسه الجوهري: SDD ليس معادلة خطية. إنه دورة تغذية راجعة.

يقترح مثلث SDD: المواصفة والاختبارات والكود عُقَد ثلاث تحتاج إلى مزامنة دائمة. حين يتقدم الكود، يجب تحديث المواصفة. حين تتغير المواصفة، تحتاج إلى اختبارات جديدة. حين تفشل الاختبارات، يجب تغيير الكود — وأحياناً تكون المواصفة هي الخاطئة أصلاً.

المشكلة أن الحفاظ على مزامنة هذه العقد الثلاث أمر عسير:

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

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

منظومة الأدوات

انفجر فضاء أدوات SDD بين أواخر 2024 ومطلع 2026. من المفيد فهم طبقاته:

الطبقة 1 — أُطر المواصفات: تُعرّف أرتيفاكتات المواصفة وتُديرها → Spec Kit وTessl وKiro وBMAD وOpenSpec وcc-sdd

الطبقة 2 — أنظمة التخطيط والمهام: تحوّل المواصفات إلى رسوم بيانية للمهام القابلة للتنفيذ → Taskmaster وAgent OS وBeads وFeature-Driven-Flow

الطبقة 3 — وكلاء التنفيذ: يكتبون الكود ويعدّلونه → Claude Code وCursor Agent وCodex وDevika وOpenDevin وCrewAI

الطبقة 4 — بيئات التطوير المتكاملة بالذكاء الاصطناعي: تدمج جميع الطبقات في سير عمل واحد → Kiro وWindsurf وCursor وClaude Code وCopilot

معظم المطورين اليوم يستخدمون الطبقة 3 فحسب — وهي تحديداً حيث تعيش مشكلة vibe coding.

جدول الأدوات ذات الصلة

الأداة	النوع	المقاربة	الحالة
Spec Kit (GitHub)	CLI	مواصفة دستورية + 4 مراحل	Open source, GA
Kiro (AWS)	IDE	نظام EARS، 3 وثائق	GA، طبقة مجانية
Tessl	CLI + Registry	Spec-as-source (الأكثر طموحاً)	بيتا مغلق
BMAD	CLI	متعدد الوكلاء، شخصيات حسب الدور	Open source
OpenSpec	CLI	سير عمل الاقتراح والموافقة	Open source
Plumb	CLI	مزامنة المواصفة/الاختبار/الكود عبر git hooks	PoC (`pip install plumb-dev`)
smart-ralph	CLI	هيكل أدنى لـ SDD	Open source

كيفية الاستخدام عملياً: Kiro مثالاً

Kiro هو نقطة الدخول الأكثر سهولة للمطورين الذين يستخدمون VS Code. إنه نسخة مشتقة من Code OSS (النواة المفتوحة المصدر لـ VS Code) أنشأها فريق صغير داخل AWS، وُضع عمداً خارج منظومة AWS — لا تحتاج إلى حساب AWS لاستخدامه.

التثبيت

زر kiro.dev ونزّل المثبّت لنظام تشغيلك. سجّل دخولك بحساب GitHub أو Google.

سير العمل في ثلاث خطوات

الخطوة 1 — المتطلبات

تصف ما تريد بناءه بلغة طبيعية. يُترجم Kiro ذلك إلى نظام EARS (Easy Approach to Requirements Syntax):

WHEN usuário submete formulário de login
  AND credenciais são válidas
THEN sistema deve autenticar o usuário
  AND redirecionar para o dashboard
  AND registrar o evento de login com timestamp

يفرض هذا النظام قيوداً صريحة وقابلة للقراءة آلياً. تراجع requirements.md المُولَّد وتعدّله قبل المضي قُدُماً.

الخطوة 2 — التصميم

يحلل Kiro قاعدة كودك الحالية ويُولّد design.md يتضمن القرارات المعمارية واختيارات المكدس وبنية المكونات. لمشروع React + Node.js ستجد شيئاً كهذا:

## Architecture

Frontend: React 18 com React Router v6
Backend: Express 4.x com middleware JWT
Database: PostgreSQL via Prisma ORM
Auth: bcrypt (salt rounds: 12) + JWT (access: 15min, refresh: 7d)
Testing: Jest + Supertest para integração

تراجع هذه الوثيقة قبل كتابة أي كود. تُكشَف هنا أي تعارضات مع البنية المعمارية الحقيقية للمشروع — لا بعد توليد 400 سطر.

الخطوة 3 — المهام

يُولّد Kiro ملف tasks.md يحتوي خطوات تنفيذ منفصلة مُرتَّبة حسب التبعيات:

- [ ] Task 1: Setup de banco de dados e schema de usuários
- [ ] Task 2: Endpoint POST /auth/register com validação Joi
- [ ] Task 3: Endpoint POST /auth/login com geração de tokens
- [ ] Task 4: Middleware de autenticação JWT
- [ ] Task 5: Endpoint POST /auth/refresh
- [ ] Task 6: Testes de integração para todos os endpoints

أنت تتحكم في المهام التي تُنفَّذ ومتى. الوكيل يُنفّذ مهمة واحدة في كل مرة مع نقاط مراجعة بينها.

ملفات التوجيه (Steering files)

إلى جانب وثائق المواصفة الثلاث، يدعم Kiro ملفات التوجيه — ملفات إعداد دائمة تُحدّد الأنماط لكامل قاعدة الكود:

# .kiro/steering/code-style.md
- Use TypeScript estrito, sem `any` implícito
- Prefira `async/await` sobre callbacks
- Nomes de variáveis em camelCase, constantes em SCREAMING_SNAKE_CASE
- Funções públicas devem ter JSDoc

الخطافات (Hooks)

يدعم Kiro خطافات قائمة على الأحداث — وكلاء يُشغَّلون تلقائياً استجابةً لمحفزات مُعرَّفة:

{
  "hooks": [
    {
      "name": "security-audit",
      "trigger": "on-save",
      "agent": "Verifique vulnerabilidades de segurança no arquivo salvo"
    },
    {
      "name": "test-generator",
      "trigger": "on-file-create",
      "pattern": "src/**/*.ts",
      "agent": "Gere testes unitários para o novo arquivo"
    }
  ]
}

ما يعمل بشكل جيد

مراجعة وثيقة تصميم قبل التنفيذ تختلف جوهرياً عن مراجعة 500 سطر من الكود المُولَّد بعد الانتهاء. المشكلات تظهر في المستوى الصحيح.
ملفات التوجيه تُلغي كمّاً هائلاً من الـ prompts المتكررة حول الأسلوب والاصطلاحات.
تدفق المهام المتسلسلة يُبقي سياق الوكيل مُركّزاً — مشكلة واحدة في كل مرة، لا نظام كامل دفعة واحدة.

ما لا يعمل بشكل جيد

أنتج Kiro 16 معياراً للقبول لإصلاح بسيط لخطأ في اختبارات مستقلة. للتغييرات الصغيرة، العبء الإضافي حقيقي.
يستغرق توليد المواصفة لمزايا متوسطة التعقيد 30 إلى 45 ثانية. هذا يُعطّل إيقاع التطوير السريع.
لنظام EARS منحنى تعلم. ليس بديهياً لمن لم يعمل قط مع المواصفات الرسمية.
يستخدم Kiro سجل امتدادات Open VSX (لا سجل Microsoft)، مما يعني غياب الدعم الرسمي لـ C# — قيد جدي لفرق .NET.
وضع Autopilot (تنفيذ مهام متعددة بلا إشراف) يُنتج نتائج أقل قابلية للتنبؤ. منطق الموافقة على كل مهمة هو أين تكمن القيمة الحقيقية.

الأسعار

خلال المعاينة العامة: مجاني (بحدود للتفاعلات). GA: مجاني (50 تفاعلاً/شهر) · Pro بـ 19$/شهر (1,000 تفاعل) · Pro+ بـ 39$/شهر (3,000 تفاعل)

المشكلات الحقيقية

1. العمل المسبق الذي يخالف غريزة المطور

وعد SDD مع الذكاء الاصطناعي هو أن المواصفة تُولَّد بسرعة — وهذا صحيح فعلاً. لكن “بسرعة” لا تعني “مجاناً”. قبل أي سطر كود مفيد، تمر بدورات مراجعة متعددة: تراجع المواصفة المُولَّدة، تُصحح النيات المُسَاء فهمها، تُعدّل الخطة المعمارية، توافق على المهام أو ترفضها. كل دورة تستلزم انتباهاً بشرياً حقيقياً.

لميزة متوسطة التعقيد، قد يكون هذا العبء أقل من تكلفة تصحيح كود vibe-coded لاحقاً. لإصلاح بسيط لخطأ، تتجاوز التكلفة الفائدة بفارق كبير — أنتج Kiro 16 معياراً للقبول لتصحيح بسيط في اختبارات مستقلة. العمل المسبق لا يختفي لأن الذكاء الاصطناعي يُولّد المواصفة؛ يتغير طابعه. بدلاً من الكتابة، تراجع وتقرر. أقل كُلفة، لكن ليس صفراً.

2. تكلفة الرموز مضاعفة في كل المراحل

كل مرحلة من SDD (مواصفة ← خطة ← مهام ← تنفيذ) تستهلك رموزاً (tokens) قبل كتابة سطر واحد من كود الإنتاج. مع نماذج الاستدلال، قد يبلغ الاستخدام الوكيلي 100 ضعف الاستخدام المعتاد.

جلسات SDD المكثفة مع Claude Code تصطدم بحد السياق باستمرار. عملية الضغط التلقائي تستغرق من 3 إلى 12 دقيقة. التكلفة ليست مالية فحسب — بل أيضاً من حيث الوقت وانقطاع التدفق. لا يوجد أي معيار مرجعي عام يُقارن التكلفة الإجمالية (الرموز + وقت المراجعة البشرية) لـ SDD مقابل التطوير المباشر.

3. تدهور السياق عبر التكرارات

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

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

4. المواصفات تصبح مُضلِّلة بعد النشر

مع أدوات SDD الحديثة، المواصفة ليست “بعيدة عن الكود” — بل تُولَّد في نفس الدورة، بنفس الأداة، قبل التنفيذ بدقائق. المشكلة الكلاسيكية للمواصفات التي يكتبها محللون منفصلون عن الواقع التقني لا تنطبق هنا.

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

أداة Plumb لـ Breunig تحاول معالجة هذا: أداة CLI تتصل بـ git commit، تقرأ آثار الوكيل، تستخرج القرارات المتخذة أثناء التنفيذ، وتطلب موافقة المطور قبل تحديث المواصفة. إنها PoC لا منتج جاهز — لكنها تشير إلى الاتجاه الصحيح.

5. تكاثر الأرتيفاكتات دون رعاية حقيقية

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

6. المواصفات لا تُلغي اللاحتمية

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

7. خطر Waterfall مع الذكاء الاصطناعي في الحلقة

أكثر الانتقادات بنيويةً تأتي من Thoughtworks ومن تحليلات مستقلة: SDD كما يُمارَس حالياً يخاطر بأن يكون waterfall مع الذكاء الاصطناعي في الحلقة. ما زلت تُحدّد كل شيء مسبقاً وتأمل أن يتعاون الواقع. لتطوير استكشافي بمتطلبات مجهولة فعلاً، المقاربات الموجّهة بالسياق تتكيف بشكل أفضل.

متى يكون منطقياً استخدامه

SDD بصيغته الحالية يُنطَق به في:

فرق المؤسسات التي تطور على قواعد كود كبيرة وقائمة حيث الانجراف المعماري مُكلف
البيئات الخاضعة للتنظيم حيث مسارات التدقيق وتتبع المتطلبات إلزامية (EU AI Act، القطاع المالي، الصحة)
المجالات المستقرة ذات العقود الواضحة: واجهات برمجية (APIs)، مخططات البيانات، قواعد الامتثال
الفرق الناضجة في TDD أو BDD التي تريد توسيع هذا الانضباط إلى طبقة الذكاء الاصطناعي
المحاكاة وقابلية النقل: حالة الاستخدام التي يتألق فيها SDD أكثر هي إعادة تطبيق نظام قائم بلغة أخرى، مستخدماً اختبارات النظام الأصلي كمواصفة

SDD على الأرجح مبالغة في:

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

التشخيص الأمين

SDD استجابة مشروعة لمشكلة حقيقية. vibe coding يُولّد كوداً أسرع مما تستطيع الفرق حوكمته. المواصفات أداة لاستعادة هذه الحوكمة.

لكن التوازي مع TDD مثير للتأمل. TDD عمره 25 عاماً، لديه أدلة تجريبية واسعة، ومع ذلك يبلغ الاعتماد الفعلي في السوق نحو 8% بالمعنى الدقيق (كتابة الاختبارات قبل الكود، باتساق). SDD يُثير الضجيج لأنه يحل مشكلة مرئية في عصر الوكلاء، لكنه يرث التحدي الجوهري ذاته: المطورون يُفضّلون التسليم. أي منهجية تُضيف عملاً مسبقاً ستصطدم بهذه الغريزة.

غياب النقد العام السهل الوصول هو نفسه إشارة. حين تكون الفوائد سهلة الإيجاد والمقايضات ليست كذلك، فالمنهجية لا تزال في مرحلة التسويق لا النضج. Spec-Driven Development لم يدفع ثمن التذكرة بعد.

الأدوات التي تستحق المتابعة: Spec Kit لمرونته كمصدر مفتوح واستقلاليته عن بيئات التطوير، Kiro لسير العمل المُهيكَل في بيئة التطوير المتكاملة، Tessl للرؤية الأكثر طموحاً لـ spec-as-source (التي لم تُثبَت بعد)، وPlumb كمرجع للمشكلة الأصعب وغير المحلولة — الحفاظ على المواصفات حيّة بعد التنفيذ الأولي.