Skip to main content

كيف تتحول المهمة إلى إنتاج

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

شرط مسبق — مالك أم منفّذلا يعمل المرشّح إلا حين أكون مالك مجالي

أعادت Promova تشكيل طريقة تفكيري: لا أن أكون مطوّرًا فحسب، بل أن أتحقّق من كل مهمة تصلني. ليس «كيف أبني هذا» بل «ما الذي يقدّمه للعمل». لكنّ هذا المرشّح لا يعمل إلا بشرط واحد.

أنا مالك مجالي

تمرّ المهمة عبر المرشّح فورًا. أنا مسؤول عن النتيجة، لذا يحقّ لي أن أقول «لا ينبغي بناء هذا أصلًا» أو «لا ينبغي أن أبنيه أنا».

أنا منفّذ

لا مرشّح. هناك مهمة وموعد نهائي وتسليم. لا عيب في ذلك — إنه ببساطة اتفاق مختلف.

الفارق ليس المهارة بل التفويض. الوحدة المستقلّة التي تملك مجالها بالكامل تكلّف الشركة أقلّ من المنفّذ — لأنها لا تبني ما لا لزوم له.

قبل الكود

  1. تصل مهمة

    لا أبدأ بسؤال «كيف أبني هذا». السؤال الأول هو ما الذي يقدّمه هذا للعمل؛ والثاني هو ما إذا كان يجب بناؤه يدويًا، ومن قِبَلي أصلًا.

  2. المرشّح الأول — هل يمكن تجنّب العمل اليدوي تمامًا؟

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

    مخارج من المسار
    • يتولّاه وكيل

      يُضبَط مرّة واحدة ولا يعود إلى أحد بعدها. من ثمّ يعمل الوكيل ويُنجزها بالكامل بمفرده، دون أي تدخّل.

      مراجعة تلقائية للكود · تصل التحليلات مباشرة إلى قناة Slack مخصّصة بدل سحب السجلّات يدويًا

    • يتولّاه صاحب الطلب

      لا تصلني المهمة أصلًا. من يحتاجها يُنجزها بنفسه بمساعدة الذكاء الاصطناعي — ودوري أن أبني المسار مرّة واحدة.

      حملة تواصل بريدية · منصّة مؤثّرين

    • يتولّاه الفريق

      ميزة أو إضافة مخيطة داخل النظام، يُجري الفريق التغييرات من خلالها بنفسه — دون تذكرة ودون مطوّر.

      إضافة إعادة توجيه في نظام إدارة المحتوى بعهدة فريق تحسين محركات البحث

  3. المرشّح الثاني — تسريع الكتابة نفسها

    اجتازت المهمة المرشّح الأول، إذن هي لي. السؤال التالي: هل هذا روتين على مستوى الكود؟ إذا تكرّر النمط — أنماط الأزرار، بنية متكرّرة — أكتب له مهارة (skill) أولًا ثم الكود بعد ذلك. أطول مرّة واحدة، وأسرع في كل مرّة بعدها.

القرار

  1. وضع التخطيط (Plan mode) — التحليل قبل أي سطر

    عليّ أن أعيش هذا الكود لا أن أتلقّاه. الخطة تُقرّر من يكتبه.

    لا أعرف هذا الكود
    أكتبه بنفسي.
    أعرف هذا الكود
    يكتبه الوكيل.
    لم أكن أعرفه، لكن الخطة أوضحته
    يكتبه الوكيل.

التسليم

  1. التنفيذ

    يبدأ الكتابة من اختاره الخطة — أنا أو الوكيل.

  2. الفحوصات في dev — الوكيل

    الوكيل هو من يفحص، لا أنا: يُشغّل المسار عبر Playwright أو يقرأ الأخطاء مباشرةً من خادم Next.js في وضع dev عبر MCP. لا يُستهلك هنا شيء من طاقتي.

  3. الفحوصات في وضع build — الوكيل

    الـ dev يكذب. أجزاء (chunks) مختلفة، وتحسينات مختلفة، وسلوك مختلف. شيء يعمل في dev ويموت في build أمر كلاسيكي، لذا يحصل build على تمريرة خاصّة به — يقودها الوكيل مرّة أخرى.

  4. اختبارات الوحدة + Playwright

    فقط بعد أن يعمل فعلًا. اختبارات وحدة للمنطق، وPlaywright للمسار — يكتبها الوكيل أيضًا.

  5. بيئة الاختبار (staging) — هنا أتدخّل

    أول موضع أفحصه بيدي بنفسي. محليًّا فقط حين تكون المهمة حسّاسة. ثم تذهب إلى ضمان الجودة (QA) — بهذا الترتيب لا العكس.

  6. Pull request

    يراجعها وكلاء يحملون المهارات (skills) المسؤولة عن تلك المنطقة من المشروع: تغيير الأداء يُقاس على قواعد الأداء، وتغيير المدفوعات على قواعد المدفوعات.

  7. بيئة الإنتاج

    إطلاق.

  8. الفحص النهائي

    ضمان الجودة على بيئة الإنتاج. إن صمد — انتهى.

الأساس
  • OOP
  • SOLID
  • DRY
  • KISS
  • YAGNI
  • CI/CD

بمعرفة ممارسات المعمارية والحفاظ على ترتيب الخطوات، يمكن كتابة الكود بسرعة وجودة في آنٍ واحد. السرعة تأتي من التسلسل لا من كتابة أسرع.

الخبرة في تقنية بعينها تُنتج دائمًا كودًا أفضل — وهذا ليس محلّ نقاش. لكنها لا تنتقل: غيّر التقنية تبدأ من الصفر. أما فهم مسار التطوير والمعمارية والمبادئ فينتقل بالكامل. وهو ما يتيح العمل في قاعدة كود لا تعرفها بعد: وضع التخطيط (الخطوة 04) يُظهر كيف بُني هذا المشروع تحديدًا، أما الحكم على صواب الحل فأنت تُتقنه أصلًا.