مرحبا بكم فى كبسولات الحوسبة السحابية من ألف محترف سحابي حيث نقدم مقدمة مبسطة للخدمات الرئيسية لأيه دبليو اس (AWS).
لماذا هذه الكبسولات؟
سوف تساعدك هذه الكبسولات من “ألف محترف حوسبي” على التعرف على العديد من الخدمات و المكونات السحابية المقدمة من AWS.
هذه الكبسولة هي ملخص لقاء مجتمع AWS مصر (AWS Egypt Meetup) الذي عُقد أونلاين يوم الثلاثاء 30 يونيو 2026 (من 8:30 إلى 9:30 مساءً بتوقيت القاهرة، عبر Google Meet). قُدّمت الجلسة باللغة العربية، ونُشرت نسختها الإنجليزية على مدونة swac.blog.
قدّمتُ مؤخرًا لقاءً أونلاين لمجتمع AWS مصر بعنوان “From Vibe Coding to Agentic Engineering with Kiro | SDD”، كما تحدثت عن نفس الموضوع في مؤتمر DevOpsDays Cairo 2026. وكما فعلت في كبسولة بناء تطبيق ويب بدون خادم (serverless) على AWS، أحوّل في هذه الكبسولة الجلسة المباشرة إلى محتوى مكتوب يمكنك قراءته على مهل. سأشرح ما هو التطوير الموجه بالمواصفات (Spec-Driven Development) فعليًا، وكيف تطبّقه أداة Kiro IDE من AWS، ثم نستعرض خادم MCP لخدمة العملاء الذي صممناه مباشرةً، مع مقارنته بنسخة أكمل من نفس الفكرة بُنيت خارج Kiro.
أولًا: لماذا لم يكن “Vibe Coding” هو الأداة المناسبة لهذه الجلسة؟
ما زالت معظم عروض البرمجة بالذكاء الاصطناعي تتبع نفس الحلقة: تكتب طلبًا (prompt)، ترى النتيجة، ثم تكتب طلبًا آخر. هذا مقبول لكتابة سكربت مؤقت، لكنه ينهار عندما تحتاج من الذكاء الاصطناعي أن يستوعب نظامًا كاملًا: نموذج بيانات، وخمسة موارد API، والعقد (contract) الذي يربط بينها.
كانت فكرة الجلسة، وهي لقاء مجاني مدته ساعة واحدة عبر Google Meet، أن نعرض البديل: التطوير الموجه بالمواصفات (SDD). أي أن تكتب ما الذي ستبنيه وكيف ستبنيه قبل أن تطلب من الوكيل (agent) كتابة الكود، باستخدام Kiro من AWS كمثال عملي، وباستخدام بروتوكول سياق النموذج المفتوح (Model Context Protocol – MCP) الذي طورته شركة Anthropic كشيء يستحق أن نبنيه بهذه المواصفات.
ثانيًا: ما هو التطوير الموجه بالمواصفات بكلمات بسيطة؟
تعريف IBM لمنهجية التطوير الموجه بالمواصفات نقطة انطلاق جيدة: هي منهجية تُكتب فيها مواصفات تفصيلية لما سيتم بناؤه ويُتفق عليها قبل بدء التطوير، بحيث تصبح هذه المواصفات المصدر الوحيد للحقيقة (single source of truth) لكل من البشر ووكلاء الذكاء الاصطناعي الذين يعملون على الكود.
ويقدّم مقال IBM المنهجية كطيف من الممارسات، لا كممارسة واحدة ثابتة:
- المواصفات أولًا (Spec-first): تكتب المواصفات مرة واحدة لتوضيح الفكرة في البداية، ثم تتركها تتقادم مع تطور الكود. وهذا كافٍ للميزات الصغيرة قصيرة العمر.
- المواصفات المرتبطة بالكود (Spec-anchored): تتطور المواصفات مع الكود، وغالبًا ما يُفرض ذلك عبر الاختبارات في CI/CD. وهذه هي النقطة المثلى لمعظم الفرق.
- المواصفات كمصدر (Spec-as-source): المواصفات هي المصدر الحقيقي، وأي تغيير فيها يعيد توليد الكود مباشرةً. ثقة عالية وأتمتة عالية، لكنها ليست لأصحاب القلوب الضعيفة.
وهناك فخ يستحق أن نسمّيه: المبالغة في هندسة المواصفات نفسها. إذا كنت ما زلت تناقش اسم حقل في JSON بعد ثلاثة أسابيع، فالمواصفات توقفت عن توفير وقتك وبدأت تستهلكه. والقاعدة العملية من الجلسة: يجب أن تبقى تكلفة تحسين المواصفات أقل من تكلفة إصلاح سوء فهم لاحقًا. وفي اللحظة التي ينقلب فيها ذلك، توقف عن التلميع وابدأ البناء.
ومن الملخصات الجميلة التي ظهرت في مواد التحضير: هندسة الذكاء الاصطناعي ≈ البرمجة بالمواصفات + الضوابط (guardrails). المواصفات تعطي الوكيل نية واضحة لا لبس فيها، والضوابط (الاختبارات، ومراحل المراجعة، وأدوات الـ linting) تُبقيه ملتزمًا.
ثالثًا: Kiro ورؤية AWS لـالتطوير الموجه بالمواصفات
Kiro هي بيئة التطوير الوكيلية (agentic IDE) من AWS، مبنية على Code OSS، وهو نفس الأساس مفتوح المصدر الذي بُني عليه VS Code، مع دمج سير عمل المواصفات داخل المنتج نفسه بدلًا من إضافته كأسلوب في كتابة الطلبات. عندما تبدأ ميزة جديدة، يُنتج Kiro ثلاثة مستندات بالتتابع، و(هذا هو الجزء الهيكلي) لن يولّد كود التنفيذ قبل أن تراجع المستندين الأولين:
requirements.md(يمكنك اعتباره PRD): المتطلبات الوظيفية وغير الوظيفية، مكتوبة بلغة منظمة قابلة للاختبار (يستخدم Kiro صيغة EARS لكتابة معايير القبول).design.md(المواصفات SPEC): المعمارية، بما فيها الطبقات ونموذج البيانات وواجهة الـ API ومعالجة الأخطاء.tasks.md(الخطة PLAN): خطوات التنفيذ المرتبة والقابلة للمتابعة التي سينفذها الوكيل فعليًا.
البداية: Kiro IDE و Kiro CLI
التثبيت بسيط: حمّل ملف التثبيت المناسب لنظام التشغيل من kiro.dev/downloads، ثم سجّل الدخول (يمكنك استخدام AWS Builder ID)، ويمكنك استيراد إعدادات وإضافات VS Code الحالية عند أول تشغيل. وهذه بعض النقاط المهمة إذا كنت تقيّم الأداة:
- داخل الـ IDE تختار صراحةً بين وضعي “Vibe” و “Spec”. لا يفرض Kiro التطوير الموجه بالمواصفات على كل ضغطة زر؛ بل هو وضع تختاره لأي عمل يستحق هذا التنظيم.
- يمكنك اختيار نموذج محدد أو تركه على Auto. لكل نموذج معامل استهلاك رصيد (credit multiplier) خاص به، والنماذج مفتوحة الأوزان (open-weight) أقل تكلفة بشكل ملحوظ لكل طلب.
- يوجد Kiro CLI بجانب الـ IDE، مع أوامر slash على غرار Claude Code و Codex CLI و GitHub Copilot CLI، فسير عمل المواصفات غير مقيّد بمحرر واحد.
- التسعير يتغير بسرعة. عند الإطلاق كان لدى Kiro ثلاث باقات، وحتى يونيو 2026 أصبحت خمس باقات. راجع kiro.dev/pricing مباشرةً، فهذا النوع من التفاصيل يتقادم بسرعة.
وإذا أردت خلفية أوسع مما تتسع له هذه الكبسولة، فمقال IBM السابق ومقارنة Birgitta Böckeler بين Kiro و spec-kit و Tessl على موقع martinfowler.com كانا أكثر مرجعين اعتمدت عليهما الجلسة.
رابعًا: البناء المباشر: خادم MCP لخدمة العملاء
خلال الساعة المتاحة، اختار العرض هدفًا صغيرًا وواقعيًا عن قصد، مقسمًا على مرحلتين (sprints):
- المرحلة الأولى: واجهة REST API بلغة Node.js فوق قاعدة بيانات SQLite لخدمة العملاء (حوالي 100 عميل، ومشترياتهم، ومدفوعاتهم، وسجل تواصلهم مع الدعم)، موثقة بالكامل باستخدام Swagger/OpenAPI وقابلة للاختبار من Postman.
- المرحلة الثانية: تغليف نفس طبقة الخدمات كـخادم MCP، بحيث يستطيع عميل مثل Claude Desktop أن يطرح أسئلة بلغة طبيعية مثل “من هو العميل صاحب أكبر عدد من مشكلات الدعم؟” ويحصل على إجابات مبنية على قاعدة البيانات الحقيقية لا على التخمين.
(إذا كنت تتساءل لماذا SQLite وليس قاعدة بيانات مُدارة، فالسبب فقط هو إبقاء العرض مستقلًا بذاته. أما لأحمال العمل الإنتاجية على AWS، فكبسولة SQL vs NoSQL في AWS: متى تختار RDS أو DynamoDB؟ تشرح هذا القرار.)
الطلب الأولي الذي أُعطي لـ Kiro، وهو منقول تقريبًا حرفيًا من ملاحظات التحضير، طلب منه أن يتصرف كمعماري برمجيات أول (senior software architect) وأن يتبع عملية منظمة: يفهم الـ PRD، ويُعدّ خطة تنفيذ، ويكتب مواصفات تقنية، ثم يتوقف قبل كتابة أي كود حتى تتم مراجعة هذه المواصفات. وهذا القيد الأخير هو جوهر التطوير الموجه بالمواصفات: إنه نقطة تفتيش مقصودة، وليس مصادفة في طريقة عمل الأداة.
خامسًا: نفس الفكرة، بطريقتين مختلفتين
رسمت جلسة Kiro المباشرة الخطة، لكنها لم تُخرج خادمًا مكتملًا خلال الجلسة. وللمقارنة، إليك معمارية تنفيذ أكمل لنفس الفكرة تمامًا، بُني بشكل منفصل (باستخدام Cursor مع سير عمل بنموذجين: أحدهما يكتب الكود والآخر يراجعه، وليس باستخدام Kiro). وهو مرجع مفيد لما يعنيه “الانتهاء” بالنسبة لهذه المواصفات تحديدًا:
نقطتا الدخول، واجهة REST API وخادم MCP، تقعان فوق نفس طبقتي الخدمات والمستودعات (repositories)، وتتعاملان مع قاعدة بيانات واحدة عبر better-sqlite3. وهذا هو نفس المبدأ الذي يُفترض أن تجبرك خطوة design.md في Kiro على كتابته صراحةً: طبقة بيانات/خدمات واحدة، وفوقها عدة طبقات نقل (transports) رفيعة.
يوفّر خادم MCP خمس أدوات (tools)، كلها مدعومة بطبقة الخدمات المشتركة:
| الأداة | ما الذي تجيب عنه |
|---|---|
get_top_customers | العملاء الأعلى إنفاقًا (أو الأكثر نشاطًا، أو الأكثر مشكلات دعم) مرتبين |
get_customer_summary | الملف الكامل لعميل واحد: الطلبات والمدفوعات وسجل التواصل |
get_customer_issues | تذاكر ومشكلات الدعم المرتبطة بعميل |
search_interactions | بحث نصي حر في سجلات التواصل مع الدعم |
get_revenue_stats | مؤشرات الإيرادات الإجمالية على مستوى البيانات |
عمليًا، هذا يكفي لكي يرسم Claude Desktop مخططًا بيانيًا لأعلى العملاء إنفاقًا، أو يحلل سؤالًا مثل “من صاحب أكبر عدد من الطلبات ولماذا؟” باستخدام بيانات SQLite الحية. إنه نفس نوع الأسئلة التي يطرحها قائد فريق الدعم على لوحة BI، لكن بخادم MCP يُبنى في خمس دقائق بدلًا من مشروع تقارير كامل.
سادسًا: Kiro مقابل “جمّعها بنفسك”: مقارنة صريحة
كلا الأسلوبين ينتج نفس الشكل ذي المستندات الثلاثة (المتطلبات ← التصميم ← المهام)، لكن مكان هذا الشكل يختلف:
- Kiro يفرض التسلسل هيكليًا داخل IDE واحد، مع بوابات تمنع الكود من سبق المواصفات.
- سير العمل بنموذجين (Cursor يكتب الكود، ونموذج ثانٍ يراجع) يحقق انضباطًا مشابهًا عبر العملية وملفات القواعد (rules files)، لا عبر بوابات داخل الـ IDE. يحتاج إعدادًا أكثر، لكنه مستقل عن الأداة وأسهل في تطويعه لأسلوب فريقك.
لا يوجد أسلوب واحد هو “الإجابة الصحيحة”. Kiro هو الطريق الأسرع إذا أردت أن يُفرض عليك الانضباط تلقائيًا. والأسلوب اليدوي أنسب إذا كانت لديك بالفعل معايير مراجعة لا تريد التخلي عنها.
سابعًا: أهم الدروس عن التطوير الموجه بالمواصفات
- التطوير الموجه بالمواصفات ليس فكرة خاصة بـ Kiro. إنه قريب فلسفيًا من TDD و BDD، ويسأل “هل حددنا ما الذي نبنيه؟” قبل أن يسأل “هل ينجح الكود في الاختبار؟”
- فخ المبالغة في الهندسة حقيقي: اجعل حجم المواصفات متناسبًا مع المخاطر الفعلية للميزة، لا مع أقصى درجة تفصيل ممكنة نظريًا.
- بروتوكول MCP مناسب جدًا لهذا النوع من مشكلات الأدوات الداخلية: غلّف طبقة خدمات تثق بها، واعرض عددًا قليلًا من الأدوات ذات الأسماء الواضحة، ودع تطبيق المحادثة يتولى الاستعلام. واقرنه بقاعدة بيانات متجهية (راجع كبسولة اختيار قاعدة البيانات المتجهية (Vector Store) على AWS) عندما تحتاج أيضًا إلى بحث دلالي في بيانات غير منظمة.
خلاصة القول: البرمجة بالإحساس (vibe coding) ما زالت رائعة للاستكشاف. لكن بمجرد أن يكتب وكيل ذكاء اصطناعي كودًا ستضطر لصيانته، تصبح المواصفات القصيرة المُراجَعة أرخص تأمين يمكنك شراؤه. جرّب وضع Spec في Kiro على ميزتك الصغيرة القادمة، ولاحظ كم من إعادة العمل سيوفر عليك.
اذا اردت التعرف على المزيد من خدمات ايه دبليو اس يمكنك قراءة هذه الكبسولة عن خدمات ايه دبليو اس السحابية، كما يمكنك قراءة النسخة الإنجليزية من هذا المقال على مدونة swac.blog.
اذا اعجبتكم هذه الكبسولة السحابية فسارعوا بالاشتراك فى قائمة ألف محترف حوسبي البريدية ليصلكم كل جديد – نقوم بنشر كبسولة جديدة كل فترة قصيرة على أمل أن نساعدكم فى تطوير مهاراتكم التقنية.
كذلك تابعونا على منصات التواصل الاجتماعى لتصلكم عروضنا الجديدة و كوبونات توفير ألف محترف سحابي.