كيف نبني Salty Poker: spec-driven development

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

منذ اليوم الأول، اتّخذنا قراراً متعمّداً ببناء هذه المنصة باستخدام spec-driven development. إنها منهجية تكتسب زخماً حقيقياً في أوساط الهندسة المدعومة بالذكاء الاصطناعي، وهي الأساس الذي يستند إليه كل ما نبنيه.

ما يعنيه spec-driven development

قبل أن يُكتَب سطر واحد من كود الإنتاج، كُتبت المواصفات أولاً. أكثر من 100 صفحة. ثلاثة وعشرون موديولاً يغطّي كل ميدان في النظام — البنية التحتية، مخطّط قاعدة البيانات، عقود API، حدود الخدمات، ضوابط الامتثال، خطوط CI/CD، وأدلّة تشغيل runbook.

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

هناك أيضاً نمط فشل يستحقّ أن يُسمّى: spec-once — حيث تُطلق المواصفات المشروع ثم تُهجَر بهدوء كلّما تعمّق البناء. يتحوّل المخطّط إلى أثر تاريخي.

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

لماذا هذا مهمّ لمنصّة بوكر

تفشل منصّات البوكر بطرق يمكن التنبّؤ بها — وتعود معظم هذه الإخفاقات إلى نفس السبب الجذري تقريباً: اختصارات تُؤخَذ في وقت مبكّر وتتراكم لتتحوّل إلى مشاكل خطيرة لاحقاً.

نظام wallet بُني بدون ledger مزدوج القيد كما ينبغي. محرّك لعبة لم يُختبَر تحت ضغط الحالات الطرفية. طبقة امتثال ملصقة لاحقاً بدلاً من أن تكون مدمجة منذ اليوم الأول. منصّة تعمل جيداً عند 50 لاعباً وتنهار عند 500.

Spec-driven development هو الانضباط الذي يمنع ذلك. كل حدّ بين خدمة وأخرى يُعرَّف قبل أن يُبنى. كل تدفّق بيانات يُوثَّق قبل أن يُنفَّذ. كل متطلّب امتثال يدخل المواصفات قبل أن تُشغَّل أي migration واحدة. لا توجد قرارات من نوع "سنعرف ذلك لاحقاً" — لأن "لاحقاً" هو الوقت الذي يكون فيه اللاعبون على الطاولات.

Agentic AI كمحرّك تنفيذ

نحن نستخدم agentic AI لبناء هذه المنصة — وثمّة فارق مهمّ بين هذا وأدوات الذكاء الاصطناعي التي يعرفها معظم الناس.

الـ agentic AI لا يكتفي بالإجابة على أسئلة أو باستكمال الكود تلقائياً. بل ينفّذ سير عمل متعدّد الخطوات بشكل مستقل داخل حدود محدّدة — يكتب الكود، ويشغّل الاختبارات، ويمسك الأخطاء، ويصلحها، ويقوم بعمل commit — دون الحاجة لأن يشرف إنسان على كل إجراء. يعمل على مهمّة من بدايتها إلى نهايتها، ويعيد التحكم حين يصطدم بقرار محجوز للإنسان.

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

الـ agent لا يقرّر ما يجب بناؤه. المواصفات تقرّر. والـ agent ينفّذ.

النتيجة

منصّة بُنيت بالصرامة التي تستحقّها. كل قرار معماري موثَّق. كل حدّ بين خدمة وأخرى مقصود. كل متطلّب امتثال عُولج قبل أن يصبح مشكلة.

هذا ما نبنيه. وستشعرون بالفرق حين تلعبون عليه.

أكتب عن spec-driven development بوصفه منهجية — القرارات، الأدوات، بنية الجلسات، وما يعنيه الأمر خارج نطاق البوكر — على The Salty Korean. إن كان جانب الهندسة هذا يثير اهتمامكم، فالتحليلات الأعمق هناك.

للمزيد عن المنهجية: Using Spec-Driven Development with Claude Code بقلم Heeki Park.

Stay salty.