بناء تطبيق بالذكاء الاصطناعي

أي جزء من التطبيق يبنيه الذكاء الاصطناعي فعلاً؟

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

إضافة سوق العمل لدينا، rgb-freelance، فيها ثلاثة مجلدات. مجلد الشاشات 3231 سطراً، ومجلد المنطق خلف الشاشات 11597 سطراً، والمظهر أي CSS وجافاسكريبت 3135 سطراً. أي 17963 سطراً في المجموع، حصة الشاشات فيها أقل قليلاً من الخُمس. وهذا ليس تطبيق موبايل ولا ندّعي ذلك؛ بل منتج ويب فيه مستخدمون ومشاريع ورسائل وملفات، وشكل تقسيمه هو الشكل الذي تراه في تطبيق الموبايل أيضاً.

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

فادعاء «ابنِ التطبيق بالذكاء الاصطناعي» ليس كذباً ولا هو القصة كاملة. وأدق منه: إنه يجعل الجزء الأسرع أسرع. فإن كان هذا توقعك ربحت ربحاً حقيقياً؛ وإن كان توقعك منتجاً منتهياً اكتشفت الفرق حين يصير لك مستخدمون حقيقيون.

سرعة النمذجة: ما تغيّر فعلاً

قبل قائمة المخاطر، اعتراف قلّما يُقال: شيء هنا تغيّر فعلاً، وتصغيره تهاون كتضخيمه.

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

وقيمة هذه السرعة الحقيقية في موضع قلّما يُفكَّر فيه: كلفة رمي العمل. فحين تستغرق النسخة الأولى نصف يوم يسهل التخلي عنها أيضاً. والفرق التي تنفق شهوراً على النسخة الأولى تتعلق بها بالقدر نفسه وتترك الفكرة السيئة متأخرةً. وهذا الموضع الوحيد الذي يكون فيه الكود الرخيص ميزة استراتيجية فعلاً لا مجرد توفير.

ولنقل الحد صراحةً لأنه يُطمس في كل مكان: النموذج الأولي ليس منتجاً. فالنموذج الذي يعمل لم يرَ بعد مستخدماً حقيقياً ولا شبكة ضعيفة ولا من يرسل إدخالاً خاطئاً عمداً. والمسافة بين الاثنين هي الثلثان نفساهما من القسم السابق، ولا نموذج يختصرها لك. وإن لقيت هذه الحجة من جهة الويب، فـفايب كودينغ؛ مزاياه وأخطاره يتخذ الموقف نفسه بتفصيل أكثر على الكود.

أربعة أشياء تنكسر في تطبيق كتبه نموذج

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

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

الثاني، الصلاحية التي لم يكتبها أحد. الكود المولَّد يبني المسار المتفائل كاملاً عادةً ولا يبني المسار المتشائم. وقائمة OWASP Mobile Top 10 تعطي المرتبة الأولى لسوء استعمال بيانات الاعتماد وتقيّم شيوعه شائعاً واكتشافه سهلاً وأثره شديداً؛ أي أن هذه الفئة من الأخطاء تقع كثيراً وتُوجد بسهولة، وهو مزيج سيئ. وأول سؤال يُطرح على كود مولَّد هو هذا: أين فُحص أن هذا المستخدم مسموح له بهذا؟

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

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

الترتيب الصحيح: المواصفات أولاً ثم الكود

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

فغيّر الترتيب. ثلاث تمريرات بهذا الترتيب، ولا تُسقط واحدة.

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

والتمريرة الثانية هي التوليد، ومدخلها مخرجات التمريرة الأولى لا وصفك الشفهي. والفرق بين الاثنين كبير: فحين تكون قائمة القدرات وشكل البيانات أمام النموذج لم يبقَ شيء للتخمين، والكود الذي ينتجه قابل للمقارنة بوثيقة.

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

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