سُلَّم الذكاء

كم من الذكاء نحتاج فعلًا؟

سُلَّم ذكاء للبرمجيات، وبديل عن اقتصاد وكلاء البرمجة.

أفكر منذ مدة في سؤال بسيط:

كم من الذكاء يلزم فعلًا لبناء البرمجيات؟

لا أسأل عن مقدار الذكاء المتاح، ولا عن حجم أحدث نموذج. أسأل: كم نحتاج منه للشيء المحدد الذي نريد بناءه؟

خذ تطبيق محادثة مثلًا.

يحتاج إلى واجهة، وسيل من الرسائل، وقنوات، وعضوية، وطريقة لمعرفة من هو متصل الآن. هذه قطع مألوفة من البرمجيات. بناها المهندسون آلاف المرات.

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

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

هذه طريقة غريبة لشراء البرمجيات.

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

أظن أن هناك طريقًا آخر.

سُلَّم الذكاء

تخيّل أن البرمجيات يمكن أن تُبنى من مكتبة من السلوكيات الموجودة.

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

والآن تخيّل أنك تطلب تطبيق محادثة.

ينظر النظام في الطلب ويسأل:

• أي الأجزاء موجودة بالفعل؟

• أي الأجزاء يمكن تجميعها من قطع موجودة؟

• أي الأجزاء تحتاج إلى تعديل بسيط؟

• أي الأجزاء جديدة حقًا؟

هنا يأتي دور سُلَّم الذكاء.

تصوّره سُلَّمًا للجهد. في أسفله عمل معروف سلفًا. وفي أعلاه يضطر النظام إلى ابتكار شيء جديد.

كلما وقع الطلب في درجة أدنى من السُلَّم، احتاج إلى ذكاء أقل.

يبدو هذا بديهيًا. نحن نفعله في كل مجال آخر.

المصنع لا يعيد تصميم الكرسي كلما طلب أحدهم كرسيًا. يستعمل المكوّنات نفسها، والآلات نفسها، والطريقة نفسها. يصير العمل أرخص لأن المعرفة محفوظة في الطريقة.

والبرمجيات يمكن أن تعمل بالطريقة نفسها.

القطعة الناقصة هي وسيلة لحفظ سلوك البرنامج وإعادة استعماله.

السلوكيات هي لبنات البناء

أبني منذ عام نظامًا يقوم على هذه الفكرة.

وحدة العمل فيه هي السلوك: قطعة من برنامج قابلة لإعادة الاستعمال، بحالتها وأحداثها وبياناتها.

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

والفرق المهم أن السلوك ليس مجرد نص أو مقطع شيفرة. إنه شيء يعرف النظام كيف يبنيه من جديد.

ومتى وُجد السلوك، فلا ينبغي أن نحتاج إلى نموذج قوي ليعيد اكتشافه كلما طلب أحدهم الشيء نفسه.

هذا هو أساس سُلَّم الذكاء.

وقد بنيت هذا في Almadar Studio، وهو الآن في نسخة تجريبية ومتاح مجانًا.

أربع درجات، من الإعادة إلى الابتكار

للسُلَّم أربعة مستويات.

1. الإعادة

التطبيق نفسه، أو خطة بنائه نفسها، موجودة من قبل.

يعيد النظام بناءه من سلوكياته المحفوظة.

لا حاجة إلى أي استدعاء لنموذج. العمل حتمي النتيجة.

هذا أرخص أنواع صنع البرمجيات: النظام يعرف مسبقًا ما عليه أن يفعل.

2. إصابة كاملة

التطبيق المطلوب قريب جدًا من شيء في المكتبة.

ربما تريد تطبيق محادثة بتسميات مختلفة، أو بألوان مختلفة، أو بحقول إضافية قليلة.

نموذج صغير يستطيع أن يملأ هذه الفروق. والباقي يأتي من سلوكيات موجودة.

الجزء المكلف من صنع البرمجيات قد تمّ من قبل.

3. إصابة جزئية

بعض أجزاء الطلب موجودة، وبعضها غير موجود.

يعيد النظام استعمال السلوكيات المعروفة، ويرسل القطع الناقصة فقط إلى نموذج أقوى.

إن كان تطبيق المحادثة يحتاج إلى سيل رسائل مألوف وإلى نوع جديد من سياسات المحادثة، فلا داعي لإعادة اختراع سيل الرسائل.

أعد استعمال المعروف. وأنفق الذكاء حيث يلزم.

4. إخفاق

لا شيء في المكتبة قريب بما يكفي.

هنا يحتاج النظام إلى تأليف سلوك جديد، والتحقق منه، وإصلاحه إن لزم.

هنا يستحق نموذج البرمجة القوي مكانه.

وهذه هي النقطة المهمة: ليس كل طلب يجب أن يصل إلى هذا المستوى.

اليوم يعامل وكلاء البرمجة كل طلب غالبًا كأنه مسألة برمجية جديدة. حتى حين يكون العمل مألوفًا، يبدؤون بالكتابة.

السُلَّم يقلب هذا رأسًا على عقب.

كيف يبدو هذا في الواقع

تضم مكتبة المدار اليوم ما يزيد قليلًا على ألف سلوك، منها مكوّنات ذرية ومكوّنات أكبر مركّبة منها.

تطبيق محادثة فوري، مثلًا، يمكن تجميعه من سلوكيات:

• سيل الرسائل.

• القنوات.

• عضوية القنوات.

• المستخدمين المتصلين.

• سياسات المحادثة.

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

لا يحتاج أي من هذه المكوّنات إلى أن يُكتب خصوصًا للمحادثة.

بُنيت مرة واحدة. ويمكن استعمالها من جديد.

هذا هو الفرق بين أن تطلب من نموذج أن يكتب تطبيقًا وأن تطلب من نظام أن يجمّعه.

الطريقة الأولى تبدأ من صفحة بيضاء.

والثانية تبدأ من مكتبة.

تكلفة الذكاء

أختبر هذا محليًا على جهازي، مع نماذج برمجة مختلفة.

النتائج أولية، لكنها تبيّن لماذا يهم هذا الأمر.

تطبيق تجارة إلكترونية جديد احتاج إلى 62 استدعاء للنموذج، ونحو 1.1 مليون رمز، و13 دقيقة على نموذج برمجة بثلاثين مليار معامل. والتكلفة التقديرية نحو ثمانية سنتات.

الطلب نفسه على نموذج عام بسبعة وعشرين مليار معامل احتاج إلى 127 استدعاء، ونحو 3 ملايين رمز، وانتهت مهلته بعد 41 دقيقة. ولم يُنتَج أي تطبيق.

تعديل صغير على لوحة متابعة موجودة احتاج إلى 12 استدعاء ونحو أربع دقائق على ذلك النموذج العام نفسه. وعلى نموذج أصغر احتاج التعديل إلى ثلاثة استدعاءات و21 ثانية.

هذه ليست قياسات إنتاجية، والأرقام ستتغير مع تحسّن النظام. لكنها توضح أمرًا مهمًا.

تكلفة البرمجيات ليست تكلفة النموذج وحدها. إنها تكلفة مقدار العمل الذي يضطر النموذج إلى إعادة اكتشافه.

حين يستطيع النظام إعادة استعمال سلوكيات معروفة، يقلّ مقدار الذكاء المطلوب.

وحين يقلّ مقدار الذكاء، تقلّ التكلفة معه.

المكتبة تتراكم

هذا هو الجزء الذي أجده الأكثر إثارة.

كل سلوك جديد يُضاف إلى المكتبة قد يجعل بناء التطبيقات القادمة أرخص.

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

تصير المكتبة نوعًا من الذاكرة المشتركة للبرمجيات.

وكلما زاد ما فيها، قلّ احتياج النظام إلى البدء من الصفر.

وهذا يصنع نموذجًا اقتصاديًا مختلفًا لوكلاء البرمجة.

بدل أن ندفع لنموذج ليعيد صنع المعرفة نفسها مرة بعد مرة، نحفظ المعرفة ونعيد استعمالها.

وبدل أن نعامل كل تطبيق كأنه مشروع برمجة جديد، نعامله كتركيب من سلوكيات معروفة وقدر صغير من العمل الجديد.

وسُلَّم الذكاء هو الطريقة التي نقيس بها هذا الفرق.

يجب أن يصير صنع البرمجيات أرخص

وراء كل هذا سؤال أكبر.

من ينبغي أن يكون قادرًا على بناء البرمجيات؟

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

قد يكون هذا نموذج عمل نافعًا للشركات التي تبيع الذكاء.

لكنه ليس بالضرورة نموذجًا جيدًا للناس الذين يريدون أن يبنوا أشياء.

أفضّل أن أرى صنع البرمجيات يسير في الاتجاه المعاكس.

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

لا ينبغي أن تحتاج شركة صغيرة إلى أغلى نموذج في العالم لتبني أداة داخلية نافعة.

ولا ينبغي أن يدفع مطوّر ثمن سلسلة طويلة من استدعاءات النماذج ليعيد صنع مكوّن موجود بالفعل.

ويجب أن يستطيع أي مجتمع أن يبني على عمل الآخرين من غير أن يشتري الذكاء نفسه مرة أخرى.

هذا ما يعنيه لي جعل التقنية سلعة متاحة للجميع.

ليس أن يصير الذكاء أقل قيمة.

بل ألا نضطر إلى إنفاق ذكاء غالٍ على عمل قد أُنجز من قبل.

البديل عن وكيل البرمجة

لا أظن أن وكلاء البرمجة سيختفون.

هم نافعون. يستطيعون كتابة الشيفرة، واستكشاف الأفكار، وحل مسائل كانت ستأخذ وقتًا طويلًا.

لكني أظن أننا أخطأنا حين عاملنا وكيل البرمجة كأنه عملية تطوير البرمجيات كلها.

نموذج يجلس أمام مشروع فارغ ليس الطريقة الوحيدة لبناء البرمجيات.

نستطيع أن نبني أنظمة تعرف ما بُني من قبل.

أنظمة تستطيع أن تقيس العمل قبل أن تبدأ.

أنظمة تستعمل نماذج صغيرة للمهام المألوفة، ونماذج قوية فقط حين يلزم شيء جديد حقًا.

أنظمة تصير أرخص كلما كبرت مكتباتها.

هذا هو الاتجاه الذي أستكشفه مع المدار.

الهدف ليس بناء روبوت محادثة أفضل يكتب شيفرة أكثر.

الهدف بناء نظام تُحفظ فيه معرفة البرمجيات وتُشارَك ويُعاد استعمالها.

نظام لا يبدأ فيه التطبيق التالي من صفحة بيضاء.

نظام يكون فيه الذكاء المطلوب لبناء شيء متناسبًا مع مقدار جِدّة ذلك الشيء فعلًا.

ونظام تقترب فيه تكلفة بناء البرمجيات من تكلفة تجميعها.

قد لا يكون مستقبل وكلاء البرمجة في جعل النماذج أذكى.

قد يكون في جعلها تحتاج إلى ذكاء أقل من الأساس.