الاستراتيجية
كيف فزت بـ 6 هاكاثونات متتالية بمنهجية واحدة
Panaversity، برونزي → بلاتيني → مصنع الوكلاء. صفر إخفاقات عبر 6 هاكاثونات، 85% إعادة استخدام الكود، ونموذج تنفيذ من أربع جلسات يمكن لأي مطور نسخه. هذا هو الدليل التفصيلي بالضبط.
- المنهجية
- هاكاثون
- Spec-First
- CLAUDE.md
في هذه الصفحة · 7
شُحن H3 ومعه 149 اختباراً ناجحاً. كتبتُ منها ربما 22.
أما الـ 127 الباقية فجاءت من H2، الذي ورث معظم مجموعته من H1، الذي ورثها بدوره من H0. هذه هي الحيلة كلها. ستة هاكاثونات متتالية في Panaversity — من H0 إلى H5، من البرونزي إلى البلاتيني إلى مصنع الوكلاء — ولم يكن ما حملني يوماً هو سرعتي في الكتابة أثناء الحدث، بل مقدار ما استطعت رفض إعادة كتابته من الحدث السابق.
معظم النصائح حول الهاكاثونات تُحسّن المتغير الخطأ. فهي تتعامل مع كل حدث كبداية من الصفر: اختر حزمة تقنية، جهّز الهيكل، اركض، اعرض، ثم اهجر المشروع. هذا النموذج يحصر سقفك عند ما يستطيع شخص واحد بناءه في 72 ساعة. أما النموذج التراكمي فلا سقف له، لأن كل حدث يبدأ من حيث انتهى سابقه.
لوحة النتائج
| # | المشروع | النتيجة | المنقول إلى التالي |
|---|---|---|---|
| H0 | Personal AI CTO | برونزي | — (أرسى المنهجية) |
| H1 | Course Companion FTE | فضي | 70% من H0 |
| H2 | AI-Powered Todo | فضي | 70% من H1 |
| H3 | Advanced Todo | ذهبي | 85% من H2 |
| H4 | Cloud-Native Deployment | بلاتيني | حوسبة H3 في حاويات مباشرة |
| H5 | Agent Factory | مكتمل | هندسة وكلاء من طبقتين |
اقرأ عمود «المنقول إلى التالي» من أعلى إلى أسفل. يسير هكذا: 70، 70، 85 — ثم يتوقف عند H4 عن كونه نسبة مئوية أصلاً، لأن H4 كان H3 نفسه. لم أبنِ تطبيقاً جديداً لجولة البلاتيني. أخذتُ تطبيق الجولة الذهبية وأضفت إليه بناءات Docker متعددة المراحل، وملفات تعريف Kubernetes — وهي منصة تنسيق الحاويات التي تدير النشر والتوسّع — وشبكة خدمات Dapr، ونظام نشر واشتراك عبر Kafka، وحزمة مراقبة من Prometheus وGrafana وJaeger.
هذا ليس كسلاً، بل هو جوهر الفكرة. كان محكّمو H4 يقيّمون النشر السحابي الأصيل، فذهب 100% من جهدي إلى النشر السحابي الأصيل. أما كل من أعاد بناء تطبيقه من الصفر فقد أنفق ميزانيته في استعادة أرض كان يملكها أصلاً.
إعادة الاستخدام قرار تصميمي، لا مصادفة
لا يمكنك أن تقرر إعادة استخدام الكود في الليلة السابقة للهاكاثون. إعادة الاستخدام تُقرَّر قبل ذلك بأشهر، من خلال المكان الذي تضع فيه حدودك المعمارية.
ارتفعت النسبة 70% → 70% → 85% لسبب محدد: كان H0 وH1 لا يزالان يبحثان عن مواضع الفصل الصحيحة. وبحلول H2 كان الشكل قد استقر — واجهة أمامية بـ Next.js وTypeScript، وواجهة خلفية بـ FastAPI، وقيود دستورية تقف بين المستخدم والنموذج — وما إن توقف الشكل عن الحركة حتى قفزت نسبة التوريث.
وهذا ما ينتقل فعلاً بين المشاريع، مرتباً تقريبياً حسب القيمة:
- مجموعة الاختبارات. صارت اختبارات H2 الـ 89 أرضيةً لاختبارات H3 الـ 149. الاختبارات هي أكثر ما تملكه قابليةً للنقل، لأنها تُرمّز السلوك لا التنفيذ.
- طبقة القيود. الأنماط الدستورية التي كُتبت في H0 كانت لا تزال تعمل في H3 دون تعديل يُذكر.
- البنية التحتية المتكررة. المصادقة، وإدارة جلسات قاعدة البيانات، والترحيلات، وأغلفة الأخطاء، وإعدادات CI. مملة — والمملّ هو بالضبط ما تريد التوقف عن إعادة كتابته.
- النصوص المكتوبة. المواصفات، وبنية ملف README، وملاحظات الهندسة المعمارية. قيمتها مبخوسة — وسيأتي تفصيل ذلك أدناه.
أما ما لا ينتقل فهو منطق المجال، وهذا أمر جيد. فمنطق المجال هو الجزء الذي ينظر إليه المحكّمون فعلاً.
نموذج الجلسات الأربع
كل بناء من H2 فصاعداً جرى في أربع جلسات، مدة كل منها ثلاث ساعات تقريباً. ليست أربعة أيام. أربع جلسات، بينها توقف صارم وتسليم مكتوب.
الجلسة 1 — المواصفات. لا كود إطلاقاً. المُخرَج هو ملف SPEC.md: ماذا يفعل النظام، وما الذي لا يفعله صراحةً، ونموذج البيانات، وقائمة نقاط النهاية، ومعايير القبول. وإن عجزتُ عن كتابة معايير القبول فأنا لم أفهم الميزة بعد، ولن تُصلح كتابةُ الكود ذلك.
الجلسة 2 — الهيكل العظمي. كل نقطة نهاية موجودة وتُعيد الشكل الصحيح ببيانات خاطئة. كل صفحة لها مسار. مجموعة الاختبارات تعمل وتفشل بصدق. النظام موصول من طرفه إلى طرفه وأجوف تماماً.
الجلسة 3 — التعبئة. الآن يدخل منطق المجال، معيار قبول واحداً في كل مرة، في مواجهة اختبارات موجودة سلفاً. هذه هي الجلسة الوحيدة التي أكتب فيها ما يسميه معظم الناس «التطبيق»، وهي تمضي سريعاً لأن الجلستين 1 و2 نزعتا منها كل قرار.
الجلسة 4 — التمتين والعرض. الحالات الحدّية، ومسارات الفشل، والنشر، والسرد. المحكّمون يرون عرضاً، لا مستودعاً.
التوقف الصارم أهم من الساعات الثلاث. الجلسة التي تمتد أكثر من اللازم تنتهي والحالة في رأسك لا على القرص — والحالة التي في رأسك لا تنجو حتى الهاكاثون التالي. هذه هي آلية التراكم بكاملها، والإرهاق هو ما يكسرها.
CLAUDE.md هو الأثر الأسرع تراكماً
أعلى ملف أثراً عبر الأحداث الستة كلها لم يكن كود التطبيق، بل ملف التعليمات الذي يخبر Claude Code كيف يعمل هذا المستودع تحديداً.
الملف الجيد يسجّل الأشياء التي يخطئ فيها القادم الجديد: أي ملف إعدادات يفوز حين يوجد ملفان، وأي الأوامر تعمل فعلاً، وأي قيد تعلّمناه بكسر بيئة الإنتاج. وقد نما ملفي ليضم قسماً أسميه جدول الحقيقة الأساسية — قائمة بكل ادعاء يقوله المشروع عن نفسه، وبجانبه ما يستطيع الكود إثباته فعلياً.
هذا الجدول موجود بسبب نمط فشل يكلّف من نقاط الهاكاثون أكثر مما يكلّفه أي خلل برمجي: أن تصف قدرة لم تبنِها. والوقوع فيه سهل بلا قصد. تخطط لخادم MCP — وهو بروتوكول يوحّد الطريقة التي يصل بها الوكيل إلى الأدوات الخارجية — وتكتب قسم README عن خادم MCP الخاص بك، ثم ينفد الوقت، فتشحن نقطة نهاية HTTP تشبه MCP شكلاً لا جوهراً — وعندها تصبح وثائقك كاذبة، ويكتشف المحكّم الذي يفتح الكود ذلك قبل أن تخبره أنت.
اكتب الادعاء وبجانبه الواقع. وحين يختلفان، إما أن تبني الشيء أو تحذف الجملة.
القيود الدستورية من H0، لا من H3
كان H0 يسمى Personal AI CTO وفاز بالبرونزي — أضعف نتيجة في السلسلة. وهو أيضاً الأهم فيها، لأنه المكان الذي بُنيت فيه طبقة القيود.
وبحلول H3 كانت تلك الطبقة قد نضجت إلى بنية حقيقية: سبعة أنماط BLOCK تغطي الغش الأكاديمي والنشاط غير القانوني والمحتوى الضار، إضافة إلى خمسة أنماط FLAG للحالات التي تستحق تحذيراً لا رفضاً.
والقرار التصميمي الجدير بالسرقة هو أن الطبقة الأولى حتمية — مطابقة أنماط بسيطة، دون أي استدعاء للنموذج. يبدو ذلك بدائياً بجوار مصنّف يعتمد على LLM — أي نموذج لغوي كبير — وهو كذلك فعلاً. لكنه أيضاً الطبقة التي تعمل حين يموت مفتاح واجهة برمجة التطبيقات لديك، أو تنفد حصتك، أو يتعطل المزوّد أثناء عرضك التقديمي. حاجز الحماية الذي لا يعمل إلا حين يعمل كل شيء آخر ليس حاجز حماية.
أما الطبقة الثانية، المصنّف القائم على النموذج، فتلتقط كل ما تفوّته الأنماط. شغّلهما بعلاقة «أو» منطقية، والحتمية أولاً. تحصل على دقة عالية مجاناً، ولا تدفع مقابل الشمول إلا عند الحاجة.
الإخفاق الذي شكّل المنهجية
عبارة «صفر إخفاقات عبر ستة هاكاثونات» تحتاج إلى حاشية، وأفضّل أن أضعها بنفسي على أن يعثر عليها غيري.
أخذ H0 البرونزي. وأخذ H1 وH2 الفضي. هذه ليست إخفاقات، لكنها ليست انتصارات أيضاً — إنها ثلاثة أحداث متتالية أنهيتها بشكل محترم وأنا أراقب ما يفعله أصحاب المراكز الذهبية على نحو مختلف. والمنهجية في هذا المقال هي في معظمها وصف لما غيّرته بعد H2، والقفزة من الفضي إلى الذهبي في H3 هي الدليل على أنها نجحت.
كل من يبيعك منهجية نجحت من اليوم الأول إنما يبيعك قصة حُذف منها H0.
ما ينبغي أن تنسخه
إن أخذت أربعة أشياء فقط:
- اختر حزمة تقنية وتوقف عن التنقل. إعادة الاستخدام تتطلب أساساً مستقراً. ملاحقة أحدث إطار عمل في كل حدث تُصفّر رصيدك الموروث.
- اكتب المواصفات في جلسة منفصلة عن الكود. ليست ساعة منفصلة، بل جلسة منفصلة، بينهما توقف.
- احتفظ بملف تعليمات، وأبقِه صادقاً. الحقيقة الأساسية بجوار الادعاء.
- ابنِ طبقة قيودك مرة واحدة، مبكراً، والحتمية أولاً. فهي تنجو من كل مشروع لاحق ومن كل انقطاع لدى المزوّد.
التراكم هو الاستراتيجية. ستة أحداث، قاعدة كود واحدة، وكل جولة تُنفَق على ما طلبه المحكّمون فعلاً.
عن الكاتب
Asadullah Shafique
مهندس أنظمة ذكاء اصطناعي وكيلة
أبني أنظمة متعددة الوكلاء على OpenAI Agents SDK مع أدوات MCP وحواجز حماية دستورية وتقييم على مستوى مسار التنفيذ، وأكتب هنا عن البنية والتقدير الهندسي وراءها.