Habr: كاتب يجادل بأن نماذج LLM تجعل الواجهات الرسومية غير ضرورية

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

من أين جاءت الطبقة الفاصلة بين الإنسان والبرنامج

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

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

التسلسل الزمني المبسّط الذي يستند إليه الكاتب في طرحه:

• عقد 1950: بطاقات مثقبة ومفاتيح تبديل، والإنسان يتحدث بلغة الآلة؛
• عقدا 1960 و1970: سطر الأوامر، ويجب تذكّر الصياغة وترتيب المعاملات؛
• 1973–1984: من Xerox Alto إلى Macintosh، نوافذ رسومية ومؤشر فأرة؛
• 2007: iPhone، لمس مباشر للكائنات على الشاشة؛
• نوفمبر 2022: إطلاق ChatGPT، وصياغة الطلب بلغة عادية.

ما الذي تغيّره نماذج LLM تحديدًا

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

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

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

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

الخلاصات العملية لفرق المنتجات

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

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

ينشر الكاتب النسخة الكاملة مع العرض العملي على Habr. وحتى الآن يتضح الأهم: لم يعد السؤال «كيف نجعل الزر أكثر سهولة»، بل أصبح «هل يحتاج الإنسان إلى هذا الزر إذا كان الوكيل هو من سيضغطه».