بعد خبرتي الطويلة في مجال التقنية، لم أعد أتحمس لأداة لمجرد أنها جديدة. ما يهمني هو سؤال واحد: هل تستحق الثقة في مخرجاتها، أم أنها مجرد أداة جديدة بواجهة جذابة لها نتائج عادية؟
هذا السؤال بالتحديد كان الدافع خلف تجربة خضتها مؤخرًا: بناء تطبيق كامل، بدءًا من فكرة مجردة تفتقر إلى هوية بصرية أو نظام تصميم أو حتى واجهات، معتمدًا فقط على أدوات الذكاء الاصطناعي. ليس كتجربة استكشافية، بل كاختبار جاد لما إذا كانت هذه الأدوات جاهزة للمساعدة في إنتاج تطبيقات يعتمد عليها.
لماذا كانت هذه التجربة مختلفة
في الأونة الأخيرة بنيت عددًا كبيرًا من التطبيقات بالذكاء الاصطناعي، لكنها كانت جميعها تطبيقات داخلية: أدوات لأتمتة عمليات معينة، أو تسريع وتيرة العمل داخل الفريق. حتى إني بنيت في وقت من الأوقات plugin كاملًا لتطبيق الهوية البصرية للشركة تلقائيًا على كل هذه الأدوات الداخلية، لضمان اتساق الشكل دون الحاجة لتصميم كل واجهة من الصفر.
هذا النوع من التطبيقات له معيار نجاح مختلف تمامًا: تطبيقات هدفها أنها تحل مشكلة و طالما يتم استخدامها فلا توجد مشكلة. تجربة المستخدم فيها ثانوية غالبًا، لأن المستخدم موظف مضطر للتفاعل مع الأداة بحكم عمله، وليس مستخدم يختار استخدامها أو لا.
التطبيق الذي أتحدث عنه هنا كان مختلفًا جذريًا. هنا لم يكن يكفي أن تعمل الوظيفة، بل كان لا بد من الاهتمام بتجربة المستخدم فعليًا، وبالتفاصيل الدقيقة في التصميم: المسافات، التباين، تسلسل التفاعل. هذا الفارق تحديدًا هو ما حوّل المشروع من تكرار لما أجيده، إلى تحدٍّ حقيقي بالنسبة لي.
(ملاحظة قبل أن نبدأ: طبيعة المشروع تمنعني من ذكر اسم التطبيق أو مشاركة صور له أو أرقام دقيقة عنه. لكن كل مثال في هذا المقال مبني على مواقف فعلية مررت بها أثناء التجربة، بلا أي تفاصيل تكشف هوية المنتج.)
سؤال يسبق كل تجربة
قبل أن أبدأ، من المهم توضيح شيء: أغلب الحماس حول أدوات الذكاء الاصطناعي في البرمجة قائم على شعور المستخدم بالسرعة، لا على قياس فعلي للجودة. وهذا ما كشفته دراسة بحثية نشرتها مؤسسة METR في يوليو ٢٠٢٥، شملت ١٦ مطورًا محترفًا يعملون على مشاريع مفتوحة المصدر ضخمة ولديهم سنوات خبرة كبيرة في البرمجة. النتيجة كانت مفاجئة: استخدام أدوات الذكاء الاصطناعي في البرمجة جعلهم أبطأ فعليًا بنسبة ١٩٪، بينما شعر هؤلاء المطورون أنفسهم أنهم أصبحوا أسرع بنسبة ٢٠٪. فجوة تقارب ٤٠ نقطة مئوية بين الإحساس والواقع وهي ليست خطأ تقدير بسيطًا، بل انعكاس كامل للاتجاه.
هذه الفجوة دفعتني للتعامل مع التجربة بمعايير صارمة، لا بانبهار عابر.
الفجوة الأساسية: التصميم
خبرتي في التقنية لا تعني بالضرورة خبرة عميقة في التصميم. خلفيتي التقنية تشمل أكثر من ٩ سنوات عملت خلالها في البرمجة مباشرة، قبل أن أنتقل لاحقًا إلى القيادة والإدارة التقنية. لكن هذه الخلفية البرمجية، رغم عمقها، لم تكن يومًا خلفية تصميم. لا UX ولا UI بالمعنى الاحترافي. هذه كانت نقطة الضعف الملموسة في المشروع: لا نظام تصميم جاهز، ولا حس بصري مُتمرّس أستطيع الاعتماد عليه وحدي لإنتاج واجهات منسجمة وجذابة عبر عشرات الشاشات.
هنا كانت القيمة المضافة الأكبر للأدوات: لم تُستخدم لتسريع شيء أنا بالفعل أجيده، بل لسدّ فجوة معرفية حقيقية.
١- الهوية البصرية: بحث، لا توليد عشوائي
بدل تصميم شعار من الصفر في مرحلة مبكرة جدًا من المشروع، بحثت عن صورة يمكن أن تقوم بدور الهوية المؤقتة. القرار هنا لم يكن تقنيًا بقدر ما كان قرارًا متعلقًا بالأولويات: لا قيمة في استثمار وقت في هوية نهائية قبل أن يثبت المنتج نفسه.
٢- نظام التصميم مع Claude: اختبار الاتساق، لا الشكل فقط
استخدمت Claude Design لبناء نظام تصميم (design system) متكامل: الألوان والخطوط والمكونات. أي شخص يعمل في هذا المجال يعرف أن السهل هو إنتاج مكوّن جميل بمفرده، والصعب هو إنتاج نظام متسق تتبعه عشرات الشاشات دون أن يفقد وحدته.
يكتب أندرو هانت وديفيد توماس في كتابهما "The Pragmatic Programmer" عن فكرة "النوافذ المكسورة - Broken Windows Theory": خلل صغير يُترك دون إصلاح يتحول بسرعة إلى عادة إهمال تبتلع جودة المشروع بالكامل. هذا بالضبط ما كنت أراقبه أثناء بناء نظام التصميم: هل ستظهر "نافذة مكسورة" أولى في الشاشة العاشرة، أم يظل النظام متماسكًا؟ النتيجة كانت ممتازة ولم تظهر أي مشكلة، وهذا ما أعطاني الثقة للمتابعة.
٣- تحديد الواجهات: انضباط قبل التنفيذ
قبل الدخول في أي تصميم، حددت قائمة الواجهات (Screens) المطلوبة للمنتج. هذه خطوة تبدو بديهية، لكنها غالبًا أول ما يُتجاوز تحت إغراء سرعة الأدوات الحديثة. الانضباط في هذه المرحلة هو ما يحدد إن كان الناتج النهائي منتجًا متجانسًا أم مجموعة شاشات منفصلة.
٤- التصميم مع pen.dev: تقييم الالتزام بالنظام
استخدمت pen.dev لتصميم الواجهات بناءً على نظام التصميم الذي أنتجه Claude Design. المعيار الذي قست عليه هنا لم يكن "هل الشاشة جميلة"، بل "هل التزمت بالنظام الذي بنيناه". الالتزام كان عاليًا، وهذا ما يميّز أداة قابلة للاستخدام في سياق إنتاجي عن أداة تنتج نماذج معزولة.
٥- دورات التحسين: حيث يظهر الفارق
النسخة الأولى من أي تصميم بالذكاء الاصطناعي ليست النسخة النهائية أبدًا، وهذا متوقع. ما يهم هو كيف تستجيب الأداة للتعليقات الكثيرة والدقيقة. مررت بأكثر من دورة تحسين، وكل دورة كانت اختبارًا لمدى فهم الأداة للسياق المتراكم، لا لمجرد تنفيذ أوامر منفصلة.
٦- البرمجة مع Claude Code: المرحلة الحاسمة
في النهاية، استخدمت Claude Code لتحويل الواجهات إلى تطبيق يعمل، بالاعتماد الكامل على نفس الواجهات المصممة سابقًا. على عكس التصميم، هذه مرحلة أملك فيها خبرة عميقة تسمح لي بالحكم على كل سطر، وهذه هي المرحلة التي تكشف كل شيء: كود قابل للصيانة أم كود يعمل ظاهريًا فقط؟ وتكشف أيضًا ما إن كان الالتزام بالتصميم هيكليًا، أو مجرد تفسير حر له لا يتجاوز السطح.
وهنا تحضر دراسة METR مجددًا، بزاوية مختلفة هذه المرة: جزء كبير من البطء الذي رصدته الدراسة لدى المطورين المحترفين كان بسبب الوقت الذي يقضونه في مراجعة وتصحيح الكود الناتج عن الذكاء الاصطناعي، لا في كتابته من الصفر. من واقع خبرتي في مراجعة كود فرق كاملة على مدى سنوات، هذه المراجعة ليست عبئًا زائدًا، بل هي جوهر العمل. الأداة تنتج، والخبرة تحكم.
الخلاصة
يشبّه إيثان موليك في كتابه "Co-Intelligence" العلاقة بالذكاء الاصطناعي بالتعامل مع متدرّب سريع للغاية، حريص على إرضائك، لكنه عرضة للانحراف عن الدقة إن لم تراقبه باستمرار. هذا الوصف يلخّص بدقة ما خرجت به من التجربة كاملة.
وهنا يمكن تلخيص منهجية هذه التجربة كاملة في نموذج من ثلاث خطوات، قابل لإعادة الاستخدام في أي مشروع تستعين فيه بأدوات الذكاء الاصطناعي:
١. حدّد بصدق أين تملك خبرة حقيقية للحكم على المخرج، وأين لا تملك. لا تسأل "هل هذه الأداة جيدة؟" بشكل عام، بل اسأل "هل أنا مؤهل للحكم على هذا المخرج بعينه؟"
٢. فوّض الأداة في مناطق الفجوة، لا في مناطق قوتك. استخدام الأداة كبديل لخبرة تملكها أصلاً يخفي ضعف الأداة ذاتها؛ استخدامها لسدّ فجوة يكشف قيمتها بوضوح.
٣. استخدم خبرتك كبوابة مراجعة نهائية قبل القبول، وتحديدًا في المنطقة التي تملك فيها الخبرة الكافية للحكم (كما حدث في مرحلة البرمجة هنا). القرار والتقييم، والرفض حين يلزم الرفض؛ هذه كلها تبقى دائمًا بيد من يقود العملية.
لو كنت تفكر في مسار مشابه: استخدم الأدوات، ولكن لا تتنازل عن معاييرك المهنية عند كل خطوة. هذا الفرق هو ما يحدد إن كان الناتج النهائي منتجًا حقيقيًا أم عرضًا تقديميًا لامعًا.
المصادر
دراسة METR (يوليو ٢٠٢٥): Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity، والورقة العلمية على arXiv: arxiv.org/abs/2507.09089
كتاب "The Pragmatic Programmer" لأندرو هانت وديفيد توماس: صفحة الكتاب على Goodreads
كتاب "Co-Intelligence: Living and Working with AI" لإيثان موليك: صفحة الكتاب على Amazon
