معظم البرمجيات التي كان من الممكن أن تكون مفيدة لا تُبنى أصلًا.
ليس لأنها مستحيلة من الناحية التقنية، بل لأن المشكلة أصغر من أن تبرر ذلك. قد توفر أداة لترتيب بيانات عملية ترحيل، أو مراجعة مجموعة من العقود، أو تنسيق عملية تستمر أسبوعين ساعات كثيرة من العمل، ومع ذلك لا تبرر إنشاء مشروع برمجي. فتصميمها وتطويرها ونشرها وصيانتها يكلف أكثر من التعايش مع عدة جداول بيانات.
بدأ توليد الشيفرة يغيّر هذه المعادلة. عندما لا يعود الحصول على واجهة عملية يتطلب أسابيع، تظهر تطبيقات لا تحتاج إلى التحول إلى منتجات. تُنشأ من أجل هدف، وتعيش ما دام ذلك الهدف قائمًا، ثم يُستغنى عنها.
بدأت تُسمى تطبيقات الاستخدام الواحد أو التطبيقات القابلة للتخلص منها أو البرمجيات المؤقتة. لم يستقر الاسم بعد، لكن السؤال الذي تطرحه يستحق الاهتمام: إذا لم يعد إنشاء البرنامج هو الجزء المكلف، فأي برمجيات ما زالت تستحق أن تكون دائمة؟
كان على البرمجيات أن تدوم
ينطلق التطوير التقليدي من توقع منطقي: ينبغي استخدام التطبيق مرات كافية حتى يعوض الجهد المبذول في بنائه.
لذلك تحاول المنتجات تغطية حالات استخدام كثيرة. تضيف الإعدادات والصلاحيات وأدوات الاستيراد والشروحات والشاشات المخصصة لفئات مختلفة. تسمح هذه العمومية بتوزيع التكلفة على آلاف الأشخاص وعلى عدة سنوات، لكنها تجبر كل مستخدم على تكييف مشكلته مع الأداة.
أما الحاجة المؤقتة فتقع خارج هذه المعادلة الاقتصادية. إذا احتاج فريق إلى عرض شديد التحديد أثناء عملية ترحيل، فعادة ما يكون عليه حشره داخل Excel، أو الجمع بين أدوات متعددة، أو طلب تطوير داخلي لن يصبح أولوية على الأرجح.
تقلب تطبيقات الاستخدام الواحد الحساب رأسًا على عقب. فهي لا تسأل كم سنة سيعيش البرنامج، بل هل تتجاوز قيمة حل المهمة تكلفة توليده الآن. لا يعود التخلص من النتيجة هدرًا عندما تصبح إعادة بنائها أقل تكلفة من تعلم أداة عامة وإعدادها وصيانتها.
في أغسطس 2025، استخدم Anish Acharya تعبير البرمجيات القابلة للتخلص منها لوصف تطبيقات شخصية صغيرة لم يكن لها سابقًا معنى اقتصادي. لم يكن يتحدث عن شيفرة مبتكرة بوجه خاص. الجديد هو أن الأداة يمكن أن تكون ذات قيمة من دون أن تطمح إلى التوسع أو تحقيق الدخل أو البقاء.
تحت الاسم نفسه ثلاث أفكار مختلفة
ينبع جانب من الالتباس من إطلاق وصف تطبيق مولّد على أنظمة تعمل بطرق مختلفة تمامًا.
أبسط صورة هي توليد تطبيق تقليدي ثم التخلص منه لاحقًا. يكتب النموذج ملفات HTML أو JavaScript أو الجزء الخلفي الأولي. ويمكن تشغيل النتيجة وفحصها وتعديلها مثل أي برنامج آخر. عمرها قصير بقرار مقصود، لا لأنها بلا شيفرة.
أما الخطوة التالية فهي الواجهة التوليدية. بدل أن يجيب النظام دائمًا بالنص أو يعرض شاشة صُممت مسبقًا، ينشئ تمثيلًا يناسب الطلب: جدولًا أو محاكيًا أو رسمًا بيانيًا أو مجموعة من عناصر التحكم. قدمت Google هذا التوجه باسم Generative UI، وبدأت في اختباره داخل Gemini وفي وضع الذكاء الاصطناعي في Search من خلال Dynamic View في أواخر 2025.
هنا لا يُولّد بالضرورة منتج سيحتفظ به أحد، بل تُولّد أفضل طريقة للتفاعل مع إجابة.
أما الصورة الثالثة فأكثر جذرية بكثير: يجسد النموذج سلوك التطبيق أثناء استخدام الشخص له.
استكشفت Anthropic هذه الفكرة عبر Imagine with Claude. لم تكن في تلك التجربة وظيفة كاملة معدة قبل بدء التفاعل. كان Claude يبني البرنامج في الوقت الفعلي ويكيفه مع وصول تفاعلات جديدة. وظهر جزء من ذلك العمل لاحقًا في صيغة أكثر انضباطًا: رسوم ومرئيات تفاعلية تُنشأ داخل المحادثة.
أما Mirage، وهو نموذج أولي من Daniel Mewes، فيلغي التطبيق كله تقريبًا. يولّد النموذج HTML لشاشة، وعندما ينقر أحدهم زرًا يتلقى التفاعل وينتج الشاشة التالية. لا يوجد منطق أعمال دائم يحدد الانتقال؛ فالنموذج يتخيل ما ينبغي أن يحدث.
قد تبدو الأساليب الثلاثة متطابقة في عرض توضيحي، لكنها ليست كذلك من الناحية التقنية. في الأول تُولّد البرمجيات. وفي الثاني تُولّد واجهة فوق قدرات محددة. وفي الثالث يحاول النموذج أن يكون هو البرنامج.
حالة يكون فيها هذا التصور منطقيًا بالفعل
لنفكر في عملية ترحيل بنية تحتية. يحتاج الفريق لبضعة أيام إلى مطابقة جرد للموارد السحابية مع ملف لتكاليفها وقائمة بالمسؤولين عنها. وعليه تحديد الموارد التي لا مالك لها، وتجميع التبعيات، وإنتاج خطة إجراءات.
لو بُني تطبيق دائم لهذه العملية، لكان عليه دعم مزودين مستقبليين ومخططات بيانات مختلفة وعدد كبير من الاستثناءات. وسيصبح منتجًا كبيرًا. لكن العملية الحالية محدودة: ثلاثة مصادر معروفة وفريق صغير ومخرج واضح.
يمكن لتطبيق استخدام واحد إنشاء مساحة مراجعة لهذه المجموعة من البيانات، وتقديم مرشحات مصممة لها، وتصدير الخطة النهائية. عند انتهاء الترحيل تفقد الواجهة فائدتها، لكن الجرد المصحح والقرارات وسجل التغييرات لا تفقدها.
هذا الفرق هو الأساس. يمكن أن يكون التطبيق مؤقتًا، أما الحقيقة التي يتعامل معها فلا ينبغي أن تكون كذلك.
يناسب هذا النمط مهمة لها بداية ونهاية، وتكون بياناتها منضبطة وأخطاؤها قابلة للكشف، وينتج عنها مخرج يمكن الاحتفاظ به خارج الأداة. لكنه لا يناسب بالقدر نفسه الحالات التي يجب أن يكون فيها البرنامج هو نظام السجل، أو أن ينسق عمل مئات المستخدمين، أو ينفذ إجراءات يصعب التراجع عنها.
البنية الأكثر واقعية ليست تطبيقًا متخيّلًا
تفصل الصورة الأكثر متانة لهذه الفكرة بين طبقة دائمة وأخرى مؤقتة:
الهدف + السياق
↓
واجهة مولدة للمهمة
↓
إجراءات ومكونات مسموح بها
↓
واجهات API وقواعد وبيانات دائمةيقرر النموذج ما المعلومات المفيدة للعرض وما عناصر التحكم التي تساعد في تلك اللحظة. لكنه لا يقرر وحده كيفية حساب فاتورة، أو من يحق له اعتماد دفعة، أو أين يُحفظ السجل. تبقى هذه المسؤوليات داخل خدمات تقليدية.
يمكن أن نسمي ذلك نواة مستقرة وواجهة قابلة للتخلص منها.
يحل هذا الفصل عدة مشكلات في وقت واحد. تبقى البيانات بعد انتهاء الجلسة، ولا تعتمد الصلاحيات على نص الطلب، ويمكن التحقق من الإجراءات المهمة وتسجيلها. وتتغير الواجهة من دون الحاجة إلى إعادة توليد النظام الذي يحتفظ بالحقيقة.
وهو يفسر أيضًا تزايد الاهتمام بالمقاربات التصريحية. يسمح A2UI، الذي قدمته Google مشروعًا مفتوحًا في ديسمبر 2025، للوكيل بوصف واجهة باستخدام بيانات منظمة، ثم يترجم التطبيق المضيف ذلك الوصف إلى مكونات يعرفها مسبقًا.
يستطيع النموذج طلب جدول أو محدد أو نموذج إدخال من دون إرسال JavaScript اعتباطي. ويحتفظ المنتج بالسيطرة على التصميم وإمكانية الوصول والإجراءات المتاحة. هذا أقل حرية من توليد أي شيفرة ممكنة، لكن هذا القيد بالذات هو ما يجعله أكثر ملاءمة لبيئة الإنتاج.
المشكلة الصعبة ليست رسم الشاشة
يركز العرض التوضيحي للواجهة التوليدية غالبًا على اللحظة التي يظهر فيها شيء بصري. فهذا أسهل جزء يمكن عرضه، وهو الأكثر إثارة للإحساس بالجدة. لكنه ليس موضع تراكم المخاطر.
تبدأ التكلفة المهمة عندما يجب على الواجهة أن تفعل شيئًا حقيقيًا:
- الاحتفاظ بالحالة بين الجلسات؛
- التمييز بين المستخدمين وصلاحياتهم؛
- إنتاج الحساب نفسه عند إدخال البيانات نفسها؛
- الصمود عند فشل النموذج؛
- توضيح الإجراء الذي نُفذ وسبب تنفيذه؛
- إتاحة التراجع عن المعلومات أو استعادتها؛
- الحفاظ على سهولة الوصول والفهم حتى مع تغيرها.
سياق المحادثة ليس بديلًا لقاعدة البيانات. والتنبؤ المعقول ليس بديلًا لانتقال الحالة. كما أن الشاشة المقنعة لا تثبت أن البيانات المعروضة جاءت من المصدر الصحيح.
يكشف Mirage هذه القيود لأنه لا يحاول إخفاءها. يفقد النموذج الأولي بياناته عند إغلاق الجلسة، وقد يغير المعلومات بصورة غير متوقعة، وينتهي به الأمر إلى التعطل عندما يمتلئ السياق. هو مفيد كتجربة لأنه يبين إلى أي مدى يستطيع النموذج محاكاة البرمجيات، لكنه يبين أيضًا كبنية لماذا لا تكفي المحاكاة.
يخفض التوليد تكلفة النسخة الأولى. أما الثقة والتكامل والتشغيل فلكل منها تكلفة مختلفة ما زالت قائمة.
ما سنراه على الأرجح أولًا
لن يكون التغيير الأقرب اختفاء التطبيقات، بل اختفاء بعض شاشاتها الثابتة.
ستتمكن المنتجات التي تملك بيانات وواجهات API ذات قيمة من بناء عروض مختلفة بحسب المهمة. يمكن لنظام مالي أن يبقي دفتر الأستاذ وصلاحياته كما هما، وأن يولد في الوقت نفسه مساحة مخصصة للتحقيق في انحراف معين. ويمكن لمنصة تشغيل جمع عناصر التحكم اللازمة لحل حادثة محددة في عرض واحد، ثم إزالة ذلك العرض عند إغلاق الحادثة.
كذلك ستنمو البرمجيات المخصصة للذيل الطويل من الاحتياجات الداخلية: التسويات وعمليات الترحيل والمراجعات والإجراءات المؤقتة التي لم تبرر يومًا دخولها إلى خارطة الطريق. لن تحل محل الأنظمة الرئيسية، بل ستعتمد عليها لحل الجزء المحدد الذي ينتهي اليوم داخل جدول بيانات.
وسيولد بعض هذه الأدوات بتاريخ انتهاء صريح. عند انتهاء المشروع تُلغى بيانات اعتماده، وتُؤرشف النتيجة، ويُحذف النشر. ولكي يكون البرنامج مؤقتًا فعلًا، يجب أن تكون بنيته التحتية وصلاحيات الوصول إليه مؤقتة أيضًا، لا أن يُترك مستودع شيفرة مهجور فحسب.
وسيتغير موضع عمل المنتج. فبدلًا من تصميم الشاشات وحدها، سيصبح من الضروري تصميم المساحة التي يستطيع النموذج تركيبها داخلها: ما المكونات الموجودة، وما الإجراءات المسموح بها، وما البيانات الموثوقة، وما الحالات التي يجب ألا تُولد أبدًا.
سيبقى للديمومة أثرها
تصنع الواجهة المستقرة ذاكرة. بعد استخدامها عدة مرات نعرف مكان كل وظيفة، وما الذي سيحدث عند الضغط عليها، وكيف نشرح العملية لشخص آخر. هذه القدرة على التوقع مهمة في المهام المتكررة والحرجة.
ولتوليد تجربة مختلفة في كل جلسة تكاليفه أيضًا. فهو يضيف زمن انتظار، ويعقد الدعم، ويضاعف التركيبات التي ينبغي اختبارها. أحيانًا يكون أفضل نموذج إدخال هو النموذج المعتاد نفسه، لأن ملايين الأشخاص يعرفون بالفعل كيف يعمل.
لا تعلن تطبيقات الاستخدام الواحد نهاية البرمجيات التي تحظى بالصيانة. إنها توسع النطاق الذي يستحق أن نبني فيه شيئًا، وتمنح واجهة خاصة لمشكلات أصغر أو أقصر أو أكثر تحديدًا من أن تصبح منتجًا.
نظم الويب جزءًا كبيرًا من البرمجيات حول الصفحات، ونظمها الهاتف المحمول حول التطبيقات. أما الواجهة التوليدية فتقترح تنظيم جزء منها حول النوايا: تظهر الحاجة أولًا، ثم تظهر طريقة التفاعل معها.
وستظل تحتها أنظمة لا ترتجل. المسألة ليست الاختيار بين برنامج دائم وآخر قابل للتخلص منه، بل أن نحدد بدقة ما الذي يجب أن يتذكره النظام بعد زوال الواجهة.
