لماذا أسّسنا المدار

لقد بنيتُ التطبيق ذاته اثنتي عشرة مرّة على الأقل. شركات مختلفة، صناعات مختلفة، شعارات مختلفة على شاشة تسجيل الدخول,لكن تحت السطح، نفس الأنماط مراراً وتكراراً. إدارة المستخدمين. نماذج CRUD. جداول البيانات. Dashboards. إدارة الـ State. نفس القرارات المعمارية، نفس الـ boilerplate، نفس الأخطاء في نفس الأماكن.

في لحظة ما، توقّفت وسألت نفسي: لماذا لا نزال نفعل هذا؟

فخّ الـ Boilerplate

في بداية مسيرتي المهنية، ظننت أن التكرار مجرّد جزء من الوظيفة. تتعلّم framework، تبني تطبيقاً، ثم تنتقل للمشروع التالي وتبني التطبيق ذاته مجدداً بأسماء حقول مختلفة. كل مشروع جديد كان يبدأ بأسابيع من الإعداد: authentication، routing، database models، API endpoints، form validation، error handling. العمل المثير للاهتمام,الـ business logic الفعلي الذي يميّز كل مشروع,كان ربما 20% من إجمالي الجهد. أما الـ 80% المتبقية فكانت plumbing.

أمضيت سنوات أقنع نفسي أن هذا طبيعي. الجميع يفعل ذلك. الـ Frameworks تساعد. الـ Libraries تساعد. لكنها تساعد فقط عند الأطراف. المشكلة الجوهرية بقيت: كل تطبيق أبنيه كان متطابقاً بنسبة 80% مع السابق، وكنت أعيد كتابة تلك النسبة من الصفر في كل مرة.

الهدر كان مذهلاً حين توقّفت فعلاً لحسابه. ليس وقتي فقط، بل وقت فِرَق بأكملها. مصمّمون يعيدون تصميم نفس الأنماط. مختبرون يعيدون اختبار نفس المسارات. مدراء مشاريع يعيدون تقدير نفس المهام. لقد حوّلنا تطوير البرمجيات إلى خط تجميع يدوي باهظ الثمن، حيث يقضي مهندسون ماهرون معظم وقتهم في عمل تستطيع الآلة إنجازه,لو أعطاها أحدهم التعليمات الصحيحة.

مشكلة الـ Scale

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

على هذا النطاق، تصبح هشاشة التطوير التقليدي مستحيلة التجاهل. حين يعمل عشرات المطوّرين عبر مئات الملفات، يصبح كل تغيير مخاطرة. أحدهم يعيد تسمية حقل في الـ backend لكن ينسى الـ frontend. أحدهم يضيف حالة جديدة لسير عمل لكن لا يُحدّث منطق التحقق. أحدهم يصلح خطأ في مكان ويُحدث خطأين جديدين في مكان آخر. قاعدة الكود تنمو، الفريق ينمو، تكلفة التنسيق تنمو، وكل شيء يصبح أبطأ وأغلى مع كل شهر يمرّ.

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

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

لحظة الإدراك

الفكرة لم تأتِ في ومضة واحدة. كانت أشبه بتراكم بطيء من الملاحظات بلغ في النهاية نقطة التحوّل.

كنت أراقب صعود الـ Large Language Models وأفكّر فيما يستطيع الذكاء الاصطناعي فعله حقاً لتطوير البرمجيات. ليس الـ autocomplete للكود,ذلك بدا كوضع محرّك أسرع على عربة حصان. الفرصة الحقيقية كانت أعمق: ماذا لو استطاع الذكاء الاصطناعي توليد تطبيقات كاملة، ليس سطراً بسطر، بل دفعة واحدة، من وصف عالي المستوى؟

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

عندها تواءمت القطع. ماذا لو أنشأنا لغة schemas,طريقة لوصف السلوك الكامل لتطبيق في وثيقة declarative واحدة؟ ليس الـ data model فقط، بل الـ states، والـ transitions، وأنماط الـ UI، والـ business rules. كل ما يفعله التطبيق، مُلتقَط في مكان واحد.

لو امتلكتَ تلك اللغة، يستطيع compiler تحويلها إلى تطبيق عامل. ولو امتلكتَ ذلك الـ compiler، يستطيع الذكاء الاصطناعي توليد الـ schema من محادثة مع إنسان. الإنسان يصف ما يريد، الذكاء الاصطناعي يُنتج الـ schema، الـ compiler يُنتج التطبيق. بلا boilerplate. بلا إعادة. بلا هدر 80%.

المدار

الاسم جاء طبيعياً. "المدار" في الفيزياء ليس مساراً ثابتاً، بل حقل احتمالات,منطقة يُحتمل وجود الإلكترون فيها، محكومة بقوانين الكم. الإلكترون لا يحتاج تعليمات لكل حركة. قوانين النظام تحدّد سلوكه.

هكذا بالضبط نفكّر في مكوّنات البرمجيات. كل قطعة في التطبيق,مستخدم، فاتورة، مهمة,هي وحدة مدارية. لها شكل بيانات (الـ entity)، ومجموعة سلوكيات (الـ traits)، ومكان في الواجهة (الـ pages). هذه الوحدات لا تحتاج معرفة التفاصيل الداخلية لبعضها البعض. تتواصل عبر الأحداث، كالجسيمات التي تتبادل الطاقة. القوانين تُعرَّف مرة واحدة، والنظام يعمل.

لم يكن هذا مجرّد استعارة جميلة. كان مبدأً معمارياً. البرمجيات لا ينبغي أن تكون monolith تبنيها من الأسفل للأعلى، تربط كل قطعة بكل قطعة أخرى. ينبغي أن تكون نظاماً من مكوّنات مستقلة تدور حول بيانات مشتركة، تتفاعل عبر واجهات محدّدة بوضوح. غيّر مكوّناً واحداً، وبقية النظام يتكيّف,لأن القوانين صريحة، وليست مدفونة في آلاف الأسطر من الكود الـ imperative.

شخصان، وليس عشرين

أسّسنا المدار في ليوبليانا، سلوفينيا. شخصان، وليس عشرين. كان ذلك مقصوداً.

لقد رأينا ما يحدث حين تحاول الشركات حل التعقيد بزيادة عدد الموظفين. ينتهي بك الأمر بمزيد من التعقيد، لا أقل. مزيد من تكلفة التواصل، مزيد من التنسيق، مزيد من الاجتماعات حول الاجتماعات. أفضل البرمجيات التي رأيتها في حياتي بناها فِرَق صغيرة ذات آراء قوية وقيود واضحة.

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

تبيّن أن ليوبليانا المكان المثالي لهذا النوع من العمل. مدينة صغيرة هادئة بإنترنت سريع وبلا مشتّتات. لا سيرك venture capital، لا hype cycle، لا ضغط لتوظيف خمسين مهندساً ثم اكتشاف المنتج لاحقاً. مجرّد شخصين في غرفة، يحلّان مشكلة صعبة لأنهما يؤمنان بأهميتها.

الأرقام

وضعنا لأنفسنا هدفاً ملموساً: تخفيض التكلفة بنسبة 87%. ليس وعداً غامضاً بـ "زيادة الإنتاجية",بل تخفيض فعلي قابل للقياس في الوقت والمال اللازمين لبناء تطبيق تجاري.

من أين يأتي هذا الرقم؟ جمعنا متطلبات مشاريع حقيقية وقسّمناها إلى أصغر feature ممكن. ثم قارنّا الجهد المطلوب لبناء كل feature باستخدام المدار مقابل التطوير التقليدي بمساعدة LLMs. حين جمعنا النتائج على كامل النطاق، كان الفرق تقريباً 87%. أسابيع بدل أشهر. آلاف بدل عشرات الآلاف.

لكن تخفيض التكلفة هو نصف القصة فقط. النصف الآخر هو الملكية. مع المدار، أنت تملك كل شيء. الـ schema لك. الكود المُولَّد لك. لا vendor lock-in، لا اشتراك شهري للوصول إلى تطبيقك، لا منصة تستطيع تغيير أسعارها أو الإغلاق وأخذ برمجياتك معها. تصف ما تريد، نولّده لك، ويصبح ملكك بالكامل.

هذا أهم مما يدركه معظم الناس. رأيتُ شركات رهينة لمنصات تعتمد عليها. الأسعار ترتفع، الميزات تُزال، الـ APIs تتغيّر دون سابق إنذار. حين تملك الـ source code والـ schema الذي يولّده، أنت حر. تستطيع استضافته في أي مكان، تعديله في أي وقت، ولا تقلق أبداً من أن قرارات مورّد تجارية تؤثر على قراراتك.

ما نبنيه

المدار لم يكتمل بعد. ما زلنا في البداية، ما زلنا نصقل لغة الـ schema، ما زلنا نوسّع مكتبة الـ patterns، ما زلنا نحسّن الـ compiler. لكن الفكرة الجوهرية تعمل. بنينا تطبيقات حقيقية لعملاء حقيقيين,أنظمة كانت ستستغرق أشهراً وفِرقاً كبيرة، سُلِّمت في أسابيع بشخصين وملف schema و compiler.

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

بدأنا المدار لأننا سئمنا من بناء الشيء ذاته مراراً وتكراراً. واصلنا بناءه لأننا أدركنا أننا لسنا الوحيدين.

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