في 2017، كانت الإجابة المتفق عليها لـ “كيف نجعل الذكاء الاصطناعي يُولّد واجهة مستخدم مؤسسية” هي ضبط نموذج على جسم كود وأمل أن يتم تجميع الناتج. لم يسأل أحد ما إذا كان الكود هو هدف المخرج الصحيح. بعد سبع سنوات من نتائج إنتاجية مختلطة، بنينا البديل: اجعل النموذج يُصدر JSON descriptor من 40 سطرًا، ودَع إطارًا حتميًا يعرضه. شاشة قائمة مقاولين في أحد نشرات عملائنا هي 38 سطرًا من JSON. المكافئ في Angular المكتوب يدويًا الذي استُبدل كان 412 سطرًا من TypeScript وHTML وSCSS. عُشر مساحة السطح، سلوك متطابق.
هذه النسبة هي السبب في أن خط أنابيب توليد الذكاء الاصطناعي لدينا يعمل في الإنتاج. وهي أيضًا السبب في أن معظم واجهات المستخدم المؤسسية المُولَّدة بالذكاء الاصطناعي لا تعمل.
مشكلة توليد الكود مباشرة
عندما يُولّد نموذج مكون React، يتخذ مئات القرارات الدقيقة. أسماء المتغيرات، وإدارة الحالة، ونهج CSS، ومعالجة الأخطاء، وجلب البيانات. شغّل الموجّه نفسه مرتَين وستحصل على تنفيذَين عاملَين لا يتشاركان أي هيكل تقريبًا. للعرض التوضيحي، هذا جيد. لنظام مؤسسي إنتاجي، هذا غير ممكن.
تحتاج المؤسسات إلى قابلية إعادة الإنتاج. تحتاج إلى قابلية التدقيق. تحتاج إلى الإشارة إلى شاشة وإثبات بالضبط ما تفعله، ومن يمكنه رؤية ماذا، وكيف جرى حساب رقم. توليد الكود الحر لا يستطيع تقديم أي من ذلك على المستوى المعماري.
في أيام Oracle الخاصة بي حوالي 2014، بنيت مُولّد شاشة CRM “مدفوع بالميتاداتا” لشركة تأمين إقليمية — صفوف في جدول تهيئة تصف كل حقل وتسمية وتحقق. عمل بشكل جميل لحوالي ستة أشهر. ثم احتاج مطوّر إلى تمييز شرطي لم يُغطِّه مخطط الميتاداتا، فأضاف عمود VARCHAR2(4000) يُسمى custom_js_hook. خلال عام، كان هذا العمود يحتوي على شظايا JavaScript غير موثقة بقيمة 380 شاشة، وكان “النظام الإعلاني” مجرد طريقة أبطأ لكتابة الكود. ذلك الفشل هو السبب في أن مخطط الواصف لدينا صارم افتراضيًا والتمديدات عبارة عن وحدات مُسمّاة ومُكتَّبة، وليست سلاسل حرة.
الرؤية التي غيّرت نهجنا
أمضينا نحو ستة أشهر في تجربة استراتيجيات توليد مختلفة قبل أن نصل إلى القاعدة التي أعادت تنظيم كل شيء. لا تُولّد التطبيق. ولّد وصف التطبيق.
يُحدّد JSON descriptor ما تفعله الشاشة. حقولها، وتخطيطها، وقواعد التحقق، ومصادر البيانات، والأذونات، والإجراءات. لا يقول شيئًا عن كيفية عرض تلك الشاشة. يمتلك الإطار العرض، حتميًا، بالطريقة نفسها في كل مرة.
كيف يبدو الواصف في الممارسة
يُصرّح واصف قائمة نموذجي بنقطة نهاية مصدر البيانات ومعاملات الاستعلام، والأعمدة بأنواعها وسلوك الفرز، وتكوين المرشح والبحث، والإجراءات المتاحة ومتطلبات الأذونات لها، وأي علاقات master-detail مع كيانات أخرى.
هذا كل شيء. لا JSX، ولا معالِجات أحداث، ولا تنسيق. يتعامل الإطار مع العرض، ويتعامل عميل الواجهة البرمجية مع الشبكة، وتتعامل طبقة الأذونات مع التحكم في الوصول. الواصف أسهل في الكتابة، وأسهل في المراجعة، وأسهل بكثير في التعديل.
لماذا يهم هذا لتوليد الذكاء الاصطناعي
توجيه النموذج إلى الواصفات بدلًا من الكود يُغيّر أربعة أشياء في آن واحد.
كفاءة الرموز. الواصف أصغر بنحو 10 مرات من المكون المكافئ. التوليد أسرع وأرخص، ونافذة السياق تحتوي المزيد من النظام المحيط.
الاتساق. يعرض الإطار كل واصف بشكل متطابق. لا يوجد انحراف معماري بين الشاشات المكتوبة يوم الاثنين والشاشات المكتوبة يوم الثلاثاء.
قابلية المراجعة. يمكن لمدير منتج قراءة JSON descriptor وفهم الشاشة. لا يمكنهم قراءة 400 سطر من TypeScript، ولا ينبغي لهم ذلك.
قابلية المقارنة. عندما يتغير الواصف، يُظهر الفرق التغيير الدلالي الفعلي. “أُضيف عمود Priority، النوع select، الخيارات High/Medium/Low.” هذا منتج ذو معنى لمراجع بشري أو مدقق SOX.
فتحة الهروب
الواصفات ليست شاملة. بعض الشاشات تحتاج إلى مكونات مخصصة، أو تخطيطات غير اعتيادية، أو سلوكيات لا يتوقعها الإطار. نتعامل مع ذلك بقاعدة واحدة: يمكن لأي واصف الإشارة إلى مكون مخصص مكتوب بـ TypeScript قياسي.
في نشرنا، يُغطي الإطار نحو 90% من الشاشات المؤسسية. الـ 10% المتبقية تستخدم كودًا مخصصًا حيث تكسب تعقيدها. حتى هذه المكونات المخصصة ترث أنماط الإطار للوصول إلى البيانات، والأذونات، ومعالجة الأخطاء.
الميزة المركّبة
كل واصف جديد يجعل النظام أذكى. يتعلم الذكاء الاصطناعي من الواصفات الموجودة لصياغة واصفات أفضل. تستوعب مكتبة المكونات الحالات الاستثنائية عند ظهورها. الأنماط التي تُحل مرة واحدة تصبح متاحة لكل شاشة مستقبلية.
مع مرور الوقت، يتقارب النظام نحو حالة يستغرق فيها توليد شاشة مؤسسية جديدة ثوانٍ ويكون المخرج جاهزًا للإنتاج فورًا. ليس لأن النموذج أصبح أذكى. بل لأننا جعلنا المشكلة أصغر.