التطوير المبني على المواصفات (Spec-Driven Development): كيف توقف وكلاء البرمجة عن التخمين في 2026؟

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

الخطأ هنا ليس في النموذج، بل في المدخل. طلبت شيئاً غامضاً، فملأ هو الفراغات بالتخمين. ومن هذه الملاحظة البسيطة وُلدت واحدة من أهم ممارسات 2026 الهندسية: التطوير المبني على المواصفات (Spec-Driven Development).

الفكرة في جملة واحدة

بدل أن تكتب كوداً ثم توثّقه لاحقاً، تبدأ بمواصفة مكتوبة بدقّة، وتجعلها المصدر الوحيد للحقيقة الذي يبني منه الوكيل ويختبر ويتحقّق.

قد تبدو هذه عودةً إلى التوثيق الثقيل القديم، لكن الفرق جوهري ويستحقّ التوقّف عنده:

المواصفة التقليدية كان يقرأها بشر ثم تُنسى في مجلّد. المواصفة في هذا النموذج تُنفَّذ: هي بوابة تحقّق يمرّ منها الكود، ومرجع يُقاس عليه الناتج آلياً.

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

لماذا ظهرت الحاجة إليها الآن تحديداً؟

ثلاثة أسباب متراكبة:

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

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

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

مراحل العمل السبع

الممارسة استقرّت عملياً على سبع مراحل متتابعة، كل واحدة تضيّق دائرة الغموض:

1. الدستور (Constitution)

مبادئ المشروع وحدوده الثابتة: لغة ونمط الكود، ما يُسمح به وما يُمنع، معايير الأمان، أسلوب التعامل مع الأخطاء. تُكتب مرّة وتنطبق على كل شيء بعدها.

2. التحديد (Specify)

ماذا نبني بالضبط: المتطلّبات، السيناريوهات، ومعايير القبول. لا تقنيات هنا ولا أسماء مكتبات — سلوك مطلوب فقط.

3. التوضيح (Clarify)

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

4. التخطيط (Plan)

هنا فقط تدخل التقنية: المعمارية، تدفّق البيانات، القيود التشغيلية والأدائية.

5. المهام (Tasks)

تفكيك الخطّة إلى وحدات تنفيذية صغيرة قابلة للإنجاز والمراجعة كلٌّ على حدة.

6. التنفيذ (Implement)

الوكيل يكتب الكود والاختبارات. هذه المرحلة — المفاجئة للكثيرين — هي الأقصر والأقل أهمية في المنظومة كلها.

7. التحقّق (Validate)

مطابقة الناتج بالمواصفة بنداً ببند. ليس «هل يعمل؟» بل «هل يفعل ما اتّفقنا عليه بالضبط؟»

ماذا تربح عملياً؟

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

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

نصائح لكتابة مواصفة مفيدة فعلاً

من الخبرة المتراكمة هذا العام:

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

الجدل القائم: هل ما زلنا نحتاج نقاط توقّف بشرية؟

هذا أكثر سؤال مفتوح في المجال حالياً، ويستحقّ عرضاً أميناً للطرفين.

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

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

الموقف العملي الوسط الذي تتبنّاه فرق كثيرة: أتمتة المراحل التقنية، والاحتفاظ بنقطة توقّف بشرية واحدة إلزامية بعد مرحلة التوضيح — لأن هذه تحديداً هي المرحلة التي تُحسم فيها القرارات التي لا يملك الوكيل معلومات كافية لحسمها.

متى لا تحتاج هذا النموذج؟

الأمانة تقتضي القول إنه ليس مناسباً لكل شيء. تجاوزه حين تكون المهمة:

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

القاعدة العملية: كلّما زاد عدد المتعاملين مع الكود — بشراً كانوا أو وكلاء — وزاد عمره المتوقّع، زادت قيمة المواصفة.

أسئلة شائعة

أليست هذه عودةً إلى منهجيات التوثيق الثقيلة القديمة؟

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

هل أحتاج أدوات خاصة لتطبيقه؟

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

كم يستغرق كتابة مواصفة جيدة؟

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

الخلاصة

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

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