من Vibe Coding إلى Spec Coding: تطور البرمجة بالذكاء الاصطناعي

"الكود هو إسقاط بخس للنية." الكود هو إسقاط بخس للنية.
Sean Grove، OpenAI، معرض مهندسي الذكاء الاصطناعي العالمي 2025

الفكرة الأساسية لـ Spec Coding: كل شيء هو Markdown

قبل التعمق في Spec Coding، فهم أولاً الفلسفة الكامنة وراء Claude Code: كل شيء هو Markdown.

في فلسفة تصميم Claude Code، سجلات العمليات ونقل المعلومات وحتى المحادثات مع النموذج يمكن جميعها أن تكون Markdown:

CLAUDE.md: مستند Markdown لاتفاقيات المشروع
.claude/rules/: مجموعة من ملفات القواعد الطبقية بتنسيق Markdown
specs/: أوصاف Markdown لمتطلبات الميزات
سجل المحادثات: سجلات دردشة Claude Code هي نفسها بتنسيق Markdown
AGENTS.md: تعليمات Markdown تحدد سلوك الوكيل

هذا بالضبط جوهر Spec Coding: المواصفة نفسها هي كود. عندما تكتب المتطلبات وقرارات التصميم ومعايير القبول في Markdown، فأنت بالفعل تكتب "كودًا" - سيقرأ الذكاء الاصطناعي هذا Markdown ثم يولد التنفيذ الحقيقي.

لخص Josh Beckman حديث Grove بشكل ممتاز:

"هندسة البرمجيات (والتشريع والمراجعة القانونية) هي إصلاح المواصفات." هندسة البرمجيات (والتشريع والمراجعة القانونية) هي إصلاح المواصفات.

في Claude Code، عملية "إصلاح المواصفات" هذه هي: تعديل Markdown -> يقرأ الذكاء الاصطناعي Markdown -> توليد/تعديل الكود -> التحقق من النتيجة. سير العمل بالكامل مدفوع بـ Markdown.

1. حديث Sean Grove "The New Code": حديث يغير طريقة تفكيرك

في 2025، أعطى باحث OpenAI Sean Grove حديثًا بعنوان "The New Code" في معرض مهندسي الذكاء الاصطناعي العالمي، وأحدث زلزالاً في مجتمع المطورين بأكمله. اقترح فكرة م disruptive: لمدة 70 عامًا كنا نكتب كودًا لحل المشاكل، لكن الكود هو مجرد إسقاط بخس للنية - المواصفات هي "الكود الجديد" الحقيقي.

ذلك الحديث أنتج نموذج تطوير جديد: Spec Coding - جعل وثائق المواصفات، وليس الكود، المنتج الأساسي للتطوير، والسماح للذكاء الاصطناعي بتوليد الكود من المواصفة.

بدءًا من حديث Grove، ستساعدك هذه المقالة في فهم الأفكار الأساسية لـ Spec Coding، ومراجعة حدود Vibe Coding، وكيفية تطبيق هذه المنهجية في التطوير الفعلي مع Claude Code.

📚 ما ستتعلمه

فهم الأفكار الرئيسية في حديث Sean Grove "The New Code"
إتقان المفاهيم الأساسية ومنهجية Spec Coding
التعرف على قيمة Vibe Coding وسقفه أيضًا
تعلم كيفية ممارسة سير عمل Spec Coding في Claude Code
إتقان استراتيجية انتقال تدريجية من Vibe Coding إلى Spec Coding

1. حديث Sean Grove "The New Code": حديث يغير طريقة تفكيرك

في 2025، أعطى باحث OpenAI Sean Grove حديثًا بعنوان "The New Code" في معرض مهندسي الذكاء الاصطناعي العالمي. يُنظر لهذا الحديث على نطاق واسع كنقطة انطلاق فكرية لحركة Spec Coding.

أسس Grove سابقًا OneGraph، شركة أدوات مطوري GraphQL استحوذت عليها Netlify لاحقًا، ويعمل الآن على محاذاة التفكير في OpenAI - مساعدة تحويل النية عالية المستوى إلى مواصفات قابلة للتنفيذ ومعايير تقييم.

1.1 الحجة الأساسية: الكود هو إسقاط بخس للنية

المفهوم الأساسي لحديث Grove يمكن تلخيصه في جملة واحدة:

الكود هو إسقاط بخس للنية. الكود هو إسقاط بخس للنية.

ماذا يعني هذا؟ عندما تكون لديك فكرة في رأسك وتحولها إلى كود، تُفقد كمية هائلة من السياق على طول الطريق - لماذا اخترت هذا النهج، ما المفاضلات التي فكرت فيها، وأي القيود كانت مهمة. الكود النهائي يحافظ فقط على "كيفية الفعل"، بينما يفقد "لماذا يجب أن يُفعل هكذا."

الأمر مثل ضغط كتاب في تغريدة - تنخفض كثافة المعلومات بشكل حاد، وتتدهور النية الأصلية بشكل كبير.

1.2 جوهر البرمجة هو التواصل

اقترح Grove فكرة بسيطة لكن عميقة:

"إذا كنت تستطيع التواصل بفعالية، يمكنك البرمجة." إذا كنت تستطيع التواصل بفعالية، يمكنك البرمجة.

يجادل بأن عمل البرمجة الفعلي يشكل فقط 10-20% من التطوير. الـ 80% الأخرى هي تواصل منظم حول المتطلبات والأهداف - فهم ما يريده المستخدمون، التوافق مع الفريق على الحلول، تحديد معايير القبول، والتعامل مع الحالات الحدية.

هذا يعني أن جوهر قدرة البرمجة ليس إتقان بناء جملة لغة معينة، بل القدرة على تحويل النية الغامضة إلى أوصاف دقيقة.

1.3 من يكتب المواصفة هو المبرمج

هذه هي الفكرة الأكثر تحطيمًا للأفكار السابقة من Grove:

"من يكتب المواصفة - سواء كان مدير منتج، أو مشرع، أو مهندس، أو مسوق - هو الآن المبرمج." من يكتب المواصفة - سواء كان مدير منتج، أو مشرع، أو مهندس، أو مسوق - هو الآن المبرمج.

مع تحسن الذكاء الاصطناعي بشكل متزايد في تحويل المواصفات إلى كود، يتحول عمل البرمجة الحقيقي من "كتابة الكود" إلى "كتابة المواصفات." من يستطيع التعبير عن النية بدقة أكبر يصبح "المبرمج" الأكثر قيمة.

1.4 يمكن أن يكون للمواصفات سلسلة أدوات مثل الكود

أشار Grove إلى أن المواصفات يمكن أن يكون لها سلسلة أدوات كاملة تمامًا مثل الكود:

"المواصفات تعطينا فعليًا سلسلة أدوات مشابهة جدًا، لكنها موجهة للنوايا بدلاً من بناء الجملة."

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

1.5 مواصفة نموذج OpenAI: دليل حي

استخدم Grove وثيقة Model Spec الخاصة بـ OpenAI كدليل.

عندما اكتشفت OpenAI مشكلة النفاق، لم يعيدوا تدريب النموذج. بدلاً من ذلك، عدّلوا وثيقة المواصفات. الانتشار تغيير تلقائيًا عبر النظام، وتم تصحيح المشكلة.

هذا يثبت نقطة حاسمة: المواصفة نفسها يمكنها أن تعمل ككود قابل للتنفيذ. تغيير المواصفة يعادل تغيير السلوك، بدون لمس سطر واحد من الكود التقليدي.

لخص Josh Beckman حديث Grove بشكل ممتاز:

"هندسة البرمجيات (والتشريع والمراجعة القانونية) هي إصلاح المواصفات." هندسة البرمجيات (والتشريع والمراجعة القانونية) هي إصلاح المواصفات.

2. Spec Coding: المواصفة ككود

2.1 ما هو Spec Coding

Spec Coding، ويسمى أيضًا التطوير الموجه بالمواصفات (SDD)، هو منهجية تعامل وثائق المواصفات كالمنتج الأساسي للتطوير.

الفكرة الأساسية هي: اكتب المواصفة بوضوح أولاً، ثم دع الذكاء الاصطناعي يولد الكود من تلك المواصفة. المواصفة هي مصدر الحقيقة، والكود هو فقط المنتج المشتق من التنفيذ.

تصريح Robert C. Martin الكلاسيكي من Clean Code يصبح ذا صلة جديدة في عصر الذكاء الاصطناعي:

"تحديد المتطلبات بدقة بحيث يمكن للآلة تنفيذها هو البرمجة." تحديد المتطلبات بدقة بحيث يمكن للآلة تنفيذها هو البرمجة.

2.2 مقارنة Vibe Coding و Spec Coding

البعد	Vibe Coding	Spec Coding
النهج	Prompts ارتجالية، تكرار ذهاب وإياب	كتابة مواصفة كاملة أولاً، ثم توليد الكود
الأفضل لـ	النماذج الأولية، هاكاثونات، الاستكشاف	أنظمة الإنتاج، تعاون الفريق، عمل المؤسسات
جودة الكود	سريع لكن هش	منظم، قابل للاختبار، قابل للتدقيق
معدل نجاح المحاولة الأولى	غير مستقر	يستهدف 95%+
إمكانية إعادة الاستخدام	Prompts لمرة واحدة	المواصفات يمكن إعادة استخدامها عبر المشاريع
الأمان	سهل التغاضي عن الأشياء	مدمج في طبقة المواصفة
التوثيق	مفقود أو متأخر دائمًا	المواصفة هي التوثيق وتبقى محدثة
تعاون الفريق	يعتمد على مهارة الـ prompt الفردية	مواصفات مشتركة، معايير مشتركة

الاثنان ليسا متعارضين. كما يشير Brad Jolicoeur:

"المهندسون الأذكياء سيستخدمون حتى vibe coding كخطوة أولى لتوليد المسودة الأولية للمواصفة." المهندسون الأذكياء سيستخدمون حتى vibe coding كخطوة أولى لتوليد المسودة الأولية للمواصفة.

2.3 بنية المواصفة ثلاثية الطبقات لـ Spec Coding

لخص المهندسون في Red Hat نموذج مواصفة عملي ثلاثي الطبقات:

الطبقة 1: المواصفة الوظيفية (ماذا)

وصف النتيجة المتوقعة بلغة طبيعية والإجابة على "ماذا يجب أن يفعل":

markdown

## ميزة مصادقة المستخدم

### قصص المستخدم
- كمستخدم جديد، أريد التسجيل ببريدي الإلكتروني
- كمستخدم مسجل، أريد تسجيل الدخول بالبريد الإلكتروني وكلمة المرور
- كمستخدم نسيت كلمة مروري، أريد إعادة تعيينها بالبريد الإلكتروني

### معايير القبول
- التحقق من تنسيق البريد الإلكتروني وقوة كلمة المرور أثناء التسجيل
- قفل الحساب لمدة 15 دقيقة بعد 5 محاولات تسجيل دخول فاشلة
- روابط إعادة تعيين كلمة المرور صالحة لمدة 30 دقيقة

الطبقة 2: مواصفة مستقلة عن اللغة (كيف - طبقة البنية)

تحديد هياكل البيانات وأنماط البنية ومتطلبات الأمان:

markdown

## التصميم التقني

### نموذج البيانات
- جدول users: id، email، password_hash، created_at، locked_until
- جدول sessions: id، user_id، token، expires_at

### تصميم API
- POST /api/auth/register -> 201 Created
- POST /api/auth/login -> 200 OK + JWT
- POST /api/auth/reset-password -> 202 Accepted

### متطلبات الأمان
- كلمات المرور تستخدم bcrypt بعامل تكلفة >= 12
- JWT تنتهي خلال 15 دقيقة، رمز التحديث خلال 7 أيام
- تفعيل تحديد المعدل على جميع نقاط النهاية

الطبقة 3: مواصفة خاصة باللغة (كيف - طبقة التنفيذ)

متطلبات الإصدار، إطار الاختبار، ومعايير التوثيق:

markdown

## قيود التنفيذ

### تقنيات المشروع
- بيئة التشغيل: Node.js 20+
- الإطار: Express 5
- ORM: Prisma
- الاختبار: Vitest

### اتفاقيات الكود
- استخدام وضع TypeScript strict
- استخدام فئة AppError مخصصة لمعالجة الأخطاء
- جميع نقاط نهاية API تتطلب تعليقات JSDoc

3. ممارسة Spec Coding في Claude Code

بمجرد فهم النظرية، السؤال التالي هو كيفية تطبيقها في Claude Code. فلسفة تصميم Claude Code تتلاءم طبيعيًا مع Spec Coding - فملف CLAUDE.md ودليل Rules وأمر /plan هي جميعها أشكال من التطوير الموجه بالمواصفات.

عندما تبني OpenAI نفسها مشاريع مع Codex، تستخدم نمطًا مشابهًا: استخدام ملف AGENTS.md كموصفة لتوجيه وكيل الذكاء الاصطناعي. درستهم الأساسية هي: عندما يعاني الوكيل، تعامل مع ذلك كإشارة - حدد ما هو مفقود، سواء كان أدوات أو حواجز حماية أو توثيق، ثم أضفه للمستودع. هذا يتماشى تمامًا مع Spec Coding: المواصفات كائنات حية وينبغي أن تستمر في التطور.

بحث من Augment Code يدعم نفس الاستنتاج: المواصفات القابلة للتنفيذ تبقى دقيقة لأن وكلاء الذكاء الاصطناعي يولدون الكود مباشرة منها، مما يخلق وظيفة إجبارية - المواصفات القديمة تنتج تنفيذات معطلة. هذا يعني أن المواصفات لا تتعفن بالطريقة التي يتعفن بها التوثيق التقليدي.

3.1 الخطوة الأولى: استخدام `CLAUDE.md` لإنشاء مواصفات المشروع

CLAUDE.md هو "المواصفة الحية" لمشروعك. في كل مرة يبدأ فيها Claude Code، يقرأ هذا الملف، وهو ما يعادل إعطاء الذكاء الاصطناعي دليل مشروع دائم.

في الفصل السابق دليل البدء السريع الأساسي لـ Claude Code، تعلمنا بالفعل كيفية إنشاء CLAUDE.md. في سياق Spec Coding، يصبح دوره أكثر أهمية - إنه ليس مجرد ملف إعدادات، بل نقطة الدخول لمواصفة المشروع.

يؤكد مهندسو LogRocket أن السياق المتين حاسم لوكلاء الذكاء الاصطناعي لأنه يمنع الهلوسة وعدم الكفاءة. بدون مواصفات، قد يجري وكيل الذكاء الاصطناعي تغييرات كبيرة وغير منضبطة على مشروع. CLAUDE.md هو خط الدفاع الأول الذي يوفر "السياق المتين."

markdown

# مواصفة مشروع التجارة الإلكترونية

## موقع المشروع
منصة تجارة إلكترونية SaaS للتجار الصغير والمتوسط، تدعم متاجر متعددة وقنوات دفع متعددة.

## قرارات البنية
- فصل الواجهة الأمامية والخلفية بتصميم API-first
- بنية واجهة خلفية مايكروسيرفيس، مع خدمات تتواصل عبر قائمة انتظار رسائل
- فصل قراءة/كتابة قاعدة البيانات

## القيود الأساسية
- تخزين جميع المبالغ النقدية كأعداد صحيحة بالسنت لتجنب مشاكل دقة الفاصلة العائمة
- آلة حالة الطلب يجب أن تتبع بدقة: قيد الانتظار -> مدفوع -> مشحون -> مكتمل
- نقاط نهاية الدفع المتعلقة يجب أن تكون idempotent

لخص فريق Aviator المعلومات الرئيسية التي يجب أن تلتقطها المواصفات - وهذا بالضبط ما يجب أن يغطيه CLAUDE.md:

تنسيقات المدخلات والمخرجات وأنواع البيانات
قواعد العمل والحالات الحدية
تبعيات النظام والقيود
متطلبات الأداء وقابلية التوسع
معالجة الأخطاء ومتطلبات الأمان

3.2 الخطوة الثانية: استخدام دليل Rules لإدارة المواصفات الطبقية

مع نمو مشروعك، ملف CLAUDE.md واحد لن يكفي. عند هذه النقطة، استخدم دليل .claude/rules/ لتنظيم مواصفات طبقية.

هذا بالضبط ما يسميه Augment Code فكرة "المواصفات القابلة للتنفيذ": المواصفات ليست وثائق ثابتة، بل تعليمات حية يستهلكها وكلاء الذكاء الاصطناعي مباشرة. عندما تقسم القواعد في دليل Rules، يتم تحميل كل ملف قاعدة فقط عند تعديل الملفات ذات الصلة، مما يوفر الرموز ويحافظ على الدقة.

وجد مهندسو Tessl أن تقسيم المتطلبات إلى وثائق منظمة - مع PRD يحدد "ماذا ولماذا" ومواصفات تقنية تحدد "كيف" - يساعد في منع الذكاء الاصطناعي من تراكم الارتباك في المحادثات الطويلة ويحسن بشكل كبير اتساق المخرجات.

text

.claude/rules/
├── 00-architecture.md      # قواعد البنية (عالمية)
├── 01-security.md          # قواعد الأمان (عالمية)
├── 10-api-design.md        # قواعد تصميم API
├── 11-frontend-patterns.md # قواعد أنماط الواجهة الأمامية
├── 12-database.md          # قواعد قاعدة البيانات
└── 20-testing.md           # قواعد الاختبار

كل ملف قاعدة يمكنه تحديد نطاقه عبر frontmatter:

markdown

---
globs:
  - "src/api/**/*.ts"
  - "src/services/**/*.ts"
---

# قواعد تصميم API

## تصميم المسارات
- نمط RESTful، استخدم أسماء جمع: /api/v1/orders
- الموارد المتداخلة يمكن أن تذهب بمستويين كحد أقصى: /api/v1/users/123/orders

## تنسيق الاستجابة
- النجاح: { data, pagination? }
- الخطأ: { error: { code, message, details? } }

## يجب اتباع
- جميع عمليات الكتابة تتطلب مصادقة
- جميع نقاط نهاية القائمة يجب أن تدعم الصفحات
- العمليات الحساسة يجب أن تكتب سجلات تدقيق

بهذه الطريقة، عندما يعدل Claude Code ملفات متعلقة بـ API، سيحمل هذه المواصفة تلقائيًا ويتأكد من أن الكود المولد يتبع المعيار.

3.3 الخطوة الثالثة: استخدام `/plan` لتنفيذ Specify -> Plan -> Tasks -> Implement

سير عمل Spec Coding القياسي هو حلقة رباعية المراحل. قام GitHub Spec Kit بتوحيدها كـ Specify -> Plan -> Tasks -> Implement، وأمر /plan في Claude Code يدعم هذا التدفق طبيعيًا.

أكد فريق SpecThis على مبدأ رئيسي واحد: حدد الحدود قبل تشغيل الوكيل - اعرف ماذا يجب أن يتغير قبل حدوث أي تغييرات في الكود. هذه بالضبط قيمة /plan.

المرحلة 1: Specify

اكتب بوضوح ماذا تريد بناء أولاً. لا تتسرع في الكود:

text

/plan
أحتاج لتنفيذ ميزة استرداد الطلبات. المواصفة هي:

المتطلبات الوظيفية:
- يمكن للمستخدمين طلب استرداد كامل قبل الشحن
- خلال 7 أيام بعد الشحن، يمكن للمستخدمين طلب إرجاع واسترداد
- الاسترداد يتطلب موافقة المسؤول

معايير القبول:
- مبلغ الاسترداد لا يمكن أن يتجاوز المبلغ المدفوع فعليًا للطلب
- آلة حالة الاسترداد: مطلوب -> معتمد -> يسترد -> مسترد
- يتم استعادة المخزون بعد إكمال الاسترداد
- تسجيل كل عملية خلال العملية بالكامل

المرحلة 2: Plan

سيولد Claude خطة تقنية بناءً على مواصفتك:

text

📋 خطة تنفيذ ميزة الاسترداد

1. تصميم نموذج البيانات
   - إنشاء جدول refunds
   - إضافة حالات متعلقة بالاسترداد لآلة حالة الطلب

2. تصميم API
   - POST /api/orders/:id/refund - طلب استرداد
   - PUT /api/refunds/:id/approve - اعتماد استرداد
   - GET /api/refunds - قائمة الاسترداد

3. منطق الأعمال
   - فحوصات أهلية الاسترداد
   - حساب مبلغ الاسترداد
   - منطق استعادة المخزون

4. التكاملات
   - الاتصال بواجهة برمجة تطبيقات استرداد مزود الدفع
   - إرسال إشعارات الاسترداد

المرحلة 3: Tasks

قسّم الخطة لمهام صغيرة يمكن تنفيذها بشكل مستقل، وأعطِ كل مهمة معيار إكمال واضح.

المرحلة 4: Implement

نفّذ مهمة واحدة في كل مرة، مع التحقق بعد إكمال كل واحدة.

3.4 مثال حقيقي: بناء نظام إشعارات مستخدم مع Spec Coding

لنستخدم مثالاً كاملاً لمقارنة Vibe Coding و Spec Coding. تظهر بيانات من Orchestrator.dev أن في استطلاع Stack Overflow 2025، 84% من المطورين يستخدمون أو يخططون لاستخدام أدوات الذكاء الاصطناعي، لكن 22% فقط راضون عن النتائج، و46% يعتقدون أن الدقة مشكلة. Spec Coding هي بالضبط المفتاح لسد فجوة الرضا هذه.

نهج Vibe Coding:

text

أنت: ابنِ ميزة إشعارات
الذكاء الاصطناعي: [يبدأ بكتابة الكود فورًا ويولد قائمة إشعارات بسيطة]

أنت: يجب أن تدعم المقروء وغير المقروء
الذكاء الاصطناعي: [يعدل الكود ويضيف حقل read]

أنت: تحتاج أيضًا أنواع إشعارات متعددة
الذكاء الاصطناعي: [يغيرها مرة أخرى ويضيف حقل type]

أنت: يجب أن تدفع الإشعارات للهواتف أيضًا
الذكاء الاصطناعي: [يجري إعادة كتابة كبيرة، والبنية السابقة لم تعد مناسبة جدًا...]

النتيجة: بعد أربع جولات من التغييرات، البنية قد أُطيحت مرارًا وتكرارًا، والكود يصبح أكثر فوضوية بمرور الوقت.

نهج Spec Coding:

اكتب أولاً مستند مواصفات specs/notification.md:

markdown

# مواصفة نظام إشعارات المستخدم

## المتطلبات الوظيفية
1. دعم ثلاث قنوات: إشعارات داخل التطبيق، إشعارات بريد إلكتروني، وإشعارات دفع
2. أنواع الإشعارات: إعلانات النظام، حالة الطلب، حملات ترويجية، تنبيهات أمنية
3. يمكن للمستخدمين تهيئة تفضيلات الإشعارات حسب القناة والنوع
4. دعم حالة مقروء/غير مقروء والتحديد الجماعي كمقروء

## نموذج البيانات
- جدول notifications: id، user_id، type، channel، title، content،
  is_read، created_at
- جدول notification_preferences: user_id، type، channel، enabled

## تصميم API
- GET /api/notifications?type=&is_read= - الحصول على قائمة الإشعارات (مقسمة لصفحات)
- PUT /api/notifications/:id/read - تحديد كمقروء
- PUT /api/notifications/read-all - تحديد الكل كمقروء
- GET /api/notification-preferences - الحصول على إعدادات التفضيلات
- PUT /api/notification-preferences - تحديث إعدادات التفضيلات

## معايير القبول
- عداد الإشعارات غير المقروءة يتحدث في الوقت الفعلي
- قائمة الإشعارات تدعم التمرير اللانهائي
- زمن تأخير إشعار الدفع < 3 ثوانٍ
- تغييرات التفضيلات تسري فورًا

ثم في Claude Code:

text

@specs/notification.md
نفّذ نظام إشعارات المستخدم وفقًا لهذه المواصفة.
ابدأ بنموذج البيانات، ثم نفذ API، وأخيرًا ابنِ مكونات الواجهة الأمامية.
توقف بعد إكمال كل وحدة، وسأؤكد قبل أن تستمر.

النتيجة: يهبط بنجاح من المحاولة الأولى، ببنية واضحة وبدون حاجة لهدم الأشياء وإعادة بنائها بشكل متكرر.

3.5 تعزيز Spec Coding مع Superpowers

في الفصل السابق قدرات Superpowers للتطوير بمستوى هندسي، تعلمنا عن نظام مهارات Superpowers. Spec Coding و Superpowers رفيقان طبيعيان:

مرحلة Spec Coding	مهارة Superpowers المطابقة
تحديد المواصفة	`brainstorming` - استخدام الأسئلة السقراطية لتوضيح المتطلبات
التخطيط التقني	`writing-plans` - تقسيم المواصفة لمهام صغيرة
التنفيذ التدريجي	`test-driven-development` - TDD أحمر-أخضر-إعادة هيكلة
التحقق من الجودة	`code-review` + `verification-before-completion`

مثال على الاستخدام المشترك:

text

@specs/notification.md
نفّذ نظام الإشعارات وفقًا لهذه المواصفة باستخدام TDD،
وساعدني في مراجعة الكود بعد الانتهاء

هذه التعليمة الواحدة تفعل كلاً من تفعيل سير عمل Spec Coding ومهارات Superpowers مثل TDD و Code Review، مما يشكل عملية تطوير هندسية كاملة.

3.6 التحكم في الإصدار والتطور المستمر للمواصفات

اقترح Vibe Coding Substack وجهة نظر مهمة: المواصفات هي الآن كود. إذا كانت المواصفات كودًا، فيجب إدارتها مثل الكود:

التحكم في الإصدار: أبقِ ملفات المواصفات في Git والزمها مع الكود
تتبع التغييرات: كل تغيير في المواصفة له سجل التزام حتى تعرف من غيّر ماذا ولماذا
مراجعة الكود: تغييرات المواصفات يجب أن تمر أيضًا عبر مراجعة PR حتى يبقى الفريق متزامنًا
تكامل CI: تغييرات المواصفات تثير اختبارات آلية للتحقق مما إذا كان التنفيذ لا يزال يتوافق مع المواصفة

في Claude Code، هذا يعني أن CLAUDE.md و .claude/rules/ و دليل specs/ يجب أن يكونوا جميعًا تحت التحكم في الإصدار. تجربة Robomotion هي أن إصدار المواصفات مع التنفيذات يمنع الانحراف ويبقي كل شيء قابلاً للتدقيق.

ممارسة Harness Engineering في OpenAI تؤكد هذا أيضًا: ملف AGENTS.md الخاص بهم مكتوب بواسطة Codex نفسه ويُحدّث باستمرار مع تطور المشروع. عندما يواجه الوكيل صعوبات، الحل ليس تغيير الكود مباشرة، بل جعل Codex يحدّث المواصفة نفسها - مشكلاً حلقة شفاء ذاتي للمواصفات.

4. استراتيجية هجينة: الانتقال تدريجيًا من Vibe إلى Spec

الإجماع في الصناعة ليس "تخلَّ عن Vibe Coding"، بل اختر النهج الصحيح للسيناريو الصحيح.

4.1 متى تستخدم Vibe Coding

التحقق مما إذا كانت فكرة قابلة للتنفيذ، مع نموذج أولي مبني خلال 30 دقيقة
استكشاف تقنيات أو أطر عمل غير مألوفة
هاكاثونات أو عروض توضيحية داخلية
سكريبتات أو أدوات لمرة واحدة

4.2 متى تستخدم Spec Coding

تطوير ميزات الإنتاج
مشاريع تعاون متعددة الأشخاص
كود سيحتاج صيانة طويلة الأمد
مجالات حساسة مثل الأمان والمدفوعات أو البيانات
تصميم API وتكامل النظام

4.3 سير عمل تدريجي موصى به

المرحلة 1: استكشاف Vibe

استخدم Vibe Coding للتحقق من الفكرة بسرعة. لا تكتب مواصفات بعد، ولا تقلق بشأن جودة الكود:

text

ابنِ نافذة إشعارات منبثقة بسيطة حتى نرى كيف تبدو

المرحلة 2: صقل المواصفة

بمجرد تأكيد الجدوى، نظم ما تعلمته أثناء الاستكشاف في مواصفة. يمكنك حتى طلب مساعدة الذكاء الاصطناعي:

text

بناءً على نموذج ميزة الإشعارات الذي بنيناه للتو،
ساعدني في تنظيم مستند مواصفات وظيفية رسمي،
بما في ذلك نموذج البيانات وتصميم API ومعايير القبول

المرحلة 3: إعادة البناء مع المواصفة

بناءً على تلك المواصفة، أعد تنفيذ نسخة الإنتاج باستخدام Spec Coding:

text

@specs/notification.md
نفّذ هذا من الصفر وفقًا للمواصفة، ولا تشير لكود النموذج الأولي السابق

ميزة هذا سير العمل واضحة: استخدم سرعة Vibe Coding للتحقق من الاتجاه، وجودة Spec Coding لتسليم المنتج.

لخص Robomotion الأمر جيدًا:

"المواصفة هي مصدر الحقيقة. المخرج المولد بالذكاء الاصطناعي هو مسودة التنفيذ. التحقق ليس اختياريًا." المواصفة هي مصدر الحقيقة. المخرج المولد بالذكاء الاصطناعي هو مسودة التنفيذ. التحقق ليس اختياريًا.

5. أسئلة متكررة

س1: ألا يبدو Spec Coding بطيئًا جدًا؟

كتابة المواصفات تتطلب استثمارًا مقدمًا. لكن فريق Greg Ceccarelli استخدم Spec Coding لتسليم منتج macOS كامل بـ ثلاثة أشخاص في أربعة أسابيع - شيء شبه مستحيل في التطوير التقليدي.

الوقت الم spending في كتابة المواصفات مبكرًا سيُسترد لاحقًا من خلال إعادة عمل أقل، وأخطاء أقل، وتكلفة تواصل أقل.

س2: كم يجب أن تكون المواصفة مفصلة؟

اقتراح Robomotion هو: مواصفة عالية الجودة يمكن أن تكون صفحة واحدة فقط. المهم هو ما إذا كانت تجيب على هذه الأسئلة الثمانية:

ماذا نؤتمت؟
ما المدخل؟
ما المخرج؟
ما القيود؟
ما أوضاع الفشل؟
ما متطلبات الأمان؟
ما متطلبات الأداء؟
ما الاختبارات التي تثبت أنها تعمل؟

س3: ماذا لو كان الذكاء الاصطناعي يفعل بالضبط ما تقوله المواصفة فقط ويفوته ميزات "واضحة"؟

هذه بالفعل واحدة من قيود Spec Coding. ملاحظات مستخدمي GitHub Spec Kit هي أن الذكاء الاصطناعي سيفعل "بالضبط وفقط" ما هو مكتوب في المواصفة.

الحل هو إضافة قسم "متطلبات غير وظيفية" للمواصفة وإدراج التوقعات الشائعة هناك، مثل معالجة الأخطاء والتسجيل وإمكانية الوصول. أو تعيين قواعد عامة في CLAUDE.md.

س4: هل المشاريع الصغيرة تحتاج أيضًا Spec Coding؟

لا. Spec Coding الأنسب لـ:

مشاريع بمستوى الإنتاج
مشاريع تعاون الفريق
مشاريع تحتاج صيانة طويلة الأمد

للنماذج الأولية السريعة والسكريبتات لمرة واحدة وتجارب التعلم، Vibe Coding أكثر ملاءمة.

س5: كيف تجعل الفريق يتقبل Spec Coding؟

ابدأ بميزة صغيرة كتجربة. دع الفريق يرى كيف يقلل Spec Coding من إعادة العمل ويحسن نجاح المحاولة الأولى. يظهر استطلاع Stack Overflow 2025 أن 84% من المطورين يستخدمون أو يخططون لاستخدام أدوات الذكاء الاصطناعي، لكن 22% فقط راضون عن النتائج - Spec Coding هي بالضبط المفتاح لتحسين تلك الرضا.

6. الملخص

الانتقال من Vibe Coding إلى Spec Coding ليس ثورة. إنه تطور.

أوضح Sean Grove في "The New Code": لمدة 70 عامًا، كنا نكتب كودًا لحل المشاكل؛ الآن يجب أن نكتب مواصفات لتوليد الكود. الكود هو إسقاط بخس للنية، بينما المواصفات يمكنها التقاط النية والسياق والقيود بالكامل.

للمطورين الذين يستخدمون Claude Code، هذا التحول يحدث بالفعل:

CLAUDE.md الذي تكتبه هو مواصفة مشروعك
دليل Rules الذي تهيئه هو نظام مواصفاتك الطبقية
التخطيط الذي تجربه مع /plan هو تدفق Specify -> Plan -> Tasks
الجمع بين TDD و Code Review من Superpowers يمنحك سير عمل Spec Coding كامل

النتائج الرئيسية:

Vibe Coding مناسب للاستكشاف والنماذج الأولية، بينما Spec Coding مناسب للإنتاج والتعاون
المواصفة هي مصدر الحقيقة، والكود هو منتج تنفيذ مشتق منها
القدرة على كتابة المواصفات = قدرة البرمجة، وقدرة التواصل أهم من قدرة بناء الجملة
ابدأ صغيرًا: فقط بكتابة CLAUDE.md جيدًا، تكون قد اتخذت بالفعل الخطوة الأولى في Spec Coding

💡 الخطوة التالية

في الفصل التالي، سنتعلم كيفية استخدام قدرة Claude Code Agent Teams حتى تتمكن مثيلات ذكاء اصطناعي متعددة من التعاون كفريق تطوير حقيقي.

من Vibe Coding إلى Spec Coding: تطور البرمجة بالذكاء الاصطناعي

الفكرة الأساسية لـ Spec Coding: كل شيء هو Markdown

1. حديث Sean Grove "The New Code": حديث يغير طريقة تفكيرك

1. حديث Sean Grove "The New Code": حديث يغير طريقة تفكيرك

1.1 الحجة الأساسية: الكود هو إسقاط بخس للنية

1.2 جوهر البرمجة هو التواصل

1.3 من يكتب المواصفة هو المبرمج

1.4 يمكن أن يكون للمواصفات سلسلة أدوات مثل الكود

1.5 مواصفة نموذج OpenAI: دليل حي

2. Spec Coding: المواصفة ككود

2.1 ما هو Spec Coding

2.2 مقارنة Vibe Coding و Spec Coding

2.3 بنية المواصفة ثلاثية الطبقات لـ Spec Coding

3. ممارسة Spec Coding في Claude Code

3.1 الخطوة الأولى: استخدام `CLAUDE.md` لإنشاء مواصفات المشروع

3.2 الخطوة الثانية: استخدام دليل Rules لإدارة المواصفات الطبقية

3.3 الخطوة الثالثة: استخدام `/plan` لتنفيذ Specify -> Plan -> Tasks -> Implement

3.4 مثال حقيقي: بناء نظام إشعارات مستخدم مع Spec Coding

3.5 تعزيز Spec Coding مع Superpowers

3.6 التحكم في الإصدار والتطور المستمر للمواصفات

4. استراتيجية هجينة: الانتقال تدريجيًا من Vibe إلى Spec

4.1 متى تستخدم Vibe Coding

4.2 متى تستخدم Spec Coding

4.3 سير عمل تدريجي موصى به

5. أسئلة متكررة

س1: ألا يبدو Spec Coding بطيئًا جدًا؟

س2: كم يجب أن تكون المواصفة مفصلة؟

س3: ماذا لو كان الذكاء الاصطناعي يفعل بالضبط ما تقوله المواصفة فقط ويفوته ميزات "واضحة"؟

س4: هل المشاريع الصغيرة تحتاج أيضًا Spec Coding؟

س5: كيف تجعل الفريق يتقبل Spec Coding؟

6. الملخص

مراجع

متعلقة بحديث Sean Grove "The New Code"

منهجية Spec Coding

Vibe Coding مقابل Spec Coding

الأدوات والممارسات

من Vibe Coding إلى Spec Coding: تطور البرمجة بالذكاء الاصطناعي ​

الفكرة الأساسية لـ Spec Coding: كل شيء هو Markdown ​

1. حديث Sean Grove "The New Code": حديث يغير طريقة تفكيرك ​

1. حديث Sean Grove "The New Code": حديث يغير طريقة تفكيرك ​

1.1 الحجة الأساسية: الكود هو إسقاط بخس للنية ​

1.2 جوهر البرمجة هو التواصل ​

1.3 من يكتب المواصفة هو المبرمج ​

1.4 يمكن أن يكون للمواصفات سلسلة أدوات مثل الكود ​

1.5 مواصفة نموذج OpenAI: دليل حي ​

2. Spec Coding: المواصفة ككود ​

2.1 ما هو Spec Coding ​

2.2 مقارنة Vibe Coding و Spec Coding ​

2.3 بنية المواصفة ثلاثية الطبقات لـ Spec Coding ​

3. ممارسة Spec Coding في Claude Code ​

3.1 الخطوة الأولى: استخدام CLAUDE.md لإنشاء مواصفات المشروع ​

3.2 الخطوة الثانية: استخدام دليل Rules لإدارة المواصفات الطبقية ​

3.3 الخطوة الثالثة: استخدام /plan لتنفيذ Specify -> Plan -> Tasks -> Implement ​

3.4 مثال حقيقي: بناء نظام إشعارات مستخدم مع Spec Coding ​

3.5 تعزيز Spec Coding مع Superpowers ​

3.6 التحكم في الإصدار والتطور المستمر للمواصفات ​

4. استراتيجية هجينة: الانتقال تدريجيًا من Vibe إلى Spec ​

4.1 متى تستخدم Vibe Coding ​

4.2 متى تستخدم Spec Coding ​

4.3 سير عمل تدريجي موصى به ​

5. أسئلة متكررة ​

س1: ألا يبدو Spec Coding بطيئًا جدًا؟ ​

س2: كم يجب أن تكون المواصفة مفصلة؟ ​

س3: ماذا لو كان الذكاء الاصطناعي يفعل بالضبط ما تقوله المواصفة فقط ويفوته ميزات "واضحة"؟ ​

س4: هل المشاريع الصغيرة تحتاج أيضًا Spec Coding؟ ​

س5: كيف تجعل الفريق يتقبل Spec Coding؟ ​

6. الملخص ​

مراجع ​

متعلقة بحديث Sean Grove "The New Code" ​

منهجية Spec Coding ​

Vibe Coding مقابل Spec Coding ​

الأدوات والممارسات ​

من Vibe Coding إلى Spec Coding: تطور البرمجة بالذكاء الاصطناعي

الفكرة الأساسية لـ Spec Coding: كل شيء هو Markdown

1. حديث Sean Grove "The New Code": حديث يغير طريقة تفكيرك

1. حديث Sean Grove "The New Code": حديث يغير طريقة تفكيرك

1.1 الحجة الأساسية: الكود هو إسقاط بخس للنية

1.2 جوهر البرمجة هو التواصل

1.3 من يكتب المواصفة هو المبرمج

1.4 يمكن أن يكون للمواصفات سلسلة أدوات مثل الكود

1.5 مواصفة نموذج OpenAI: دليل حي

2. Spec Coding: المواصفة ككود

2.1 ما هو Spec Coding

2.2 مقارنة Vibe Coding و Spec Coding

2.3 بنية المواصفة ثلاثية الطبقات لـ Spec Coding

3. ممارسة Spec Coding في Claude Code

3.1 الخطوة الأولى: استخدام `CLAUDE.md` لإنشاء مواصفات المشروع

3.2 الخطوة الثانية: استخدام دليل Rules لإدارة المواصفات الطبقية

3.3 الخطوة الثالثة: استخدام `/plan` لتنفيذ Specify -> Plan -> Tasks -> Implement

3.4 مثال حقيقي: بناء نظام إشعارات مستخدم مع Spec Coding

3.5 تعزيز Spec Coding مع Superpowers

3.6 التحكم في الإصدار والتطور المستمر للمواصفات

4. استراتيجية هجينة: الانتقال تدريجيًا من Vibe إلى Spec

4.1 متى تستخدم Vibe Coding

4.2 متى تستخدم Spec Coding

4.3 سير عمل تدريجي موصى به

5. أسئلة متكررة

س1: ألا يبدو Spec Coding بطيئًا جدًا؟

س2: كم يجب أن تكون المواصفة مفصلة؟

س3: ماذا لو كان الذكاء الاصطناعي يفعل بالضبط ما تقوله المواصفة فقط ويفوته ميزات "واضحة"؟

س4: هل المشاريع الصغيرة تحتاج أيضًا Spec Coding؟

س5: كيف تجعل الفريق يتقبل Spec Coding؟

6. الملخص

مراجع

متعلقة بحديث Sean Grove "The New Code"

منهجية Spec Coding

Vibe Coding مقابل Spec Coding

الأدوات والممارسات