مطوّر بمساعدة الذكاء الاصطناعي يبني بدائل لـ Adobe وOffice في شهرين تقريباً

سنوات من عمل فريق كبير تتقلّص إلى شهرين تقريباً من عمل مطوّر واحد مع الذكاء الاصطناعي. هذه هي القصة التي يتناولها موقع Habr: يتصدى المؤلف لبناء مجموعة من التطبيقات الرسومية والمكتبية المعقدة، يُفترض أن تنافس Adobe وMicrosoft Office. ويزعم عنوان المادة الأصلية أن العمالقة «قُتلوا». وهذه مبالغة كبيرة، إذ لا يتضمن الإعلان أسماء المشاريع، ولا عدد المستخدمين، ولا اختبارات مقارنة.

ما المعروف من المادة

المعلومات المتاحة في الجزء المنشور قليلة، لكنها دالّة:

• الفريق: مطوّر واحد ومجموعة صغيرة من المساعدين؛
• الأداة: الذكاء الاصطناعي لتوليد الكود، وربما لجزء كبير من الواجهة أيضاً؛
• المدة: شهران تقريباً مقابل عدة سنوات في النهج الكلاسيكي؛
• الهدف: تطبيقات رسومية ومكتبية تضاهي منتجات Adobe وMicrosoft؛
• نموذج التوزيع: open source؛
• القضايا التي يعد المؤلف بتناولها: المخاطر القانونية، وتأثير ذلك في مستقبل التطوير، والقرب من النظائر التجارية.

أما ما غاب عن المادة فلا يمكن افتراضه: لا توجد بيانات عن دعم صيغ PSD أو DOCX أو XLSX، ولا عن الأداء مع الملفات الكبيرة، ولا عن عدد الأخطاء البرمجية. وهذه المعايير تحديداً هي ما يفصل بين العرض التجريبي والبديل الفعلي لأداة العمل. فقيمة Photoshop وOffice لا تكمن في مجموعة الأزرار، بل في التوافق، والعمل مع المستندات الثقيلة، وعقود من إصلاح الأخطاء.

أين يقع الحد القانوني

التشابه مع النسخ الأصلية هو الخطر الرئيسي هنا. فحق المؤلف يحمي الكود المحدد والتصميم، لكنه لا يحمي الفكرة ولا الوظائف. ففي قضية Google ضد Oracle اعتبرت المحكمة العليا الأمريكية في عام 2021 أن نسخ تصريحات Java API يندرج ضمن الاستخدام العادل، وفي نزاع SAS Institute ضد World Programming قضت محكمة العدل الأوروبية بأن وظائف البرنامج لا يحميها حق المؤلف. وعليه فإن إعادة إنتاج إمكانات Photoshop أمر قانوني. أما نسخ الأيقونات والأسماء وعناصر الواجهة المميزة والتصميم القابل للتمييز فمحفوف بالمخاطر، لأن العلامات التجارية وحماية المظهر الخارجي تدخل هنا على الخط.

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

ما الذي يتغير بالنسبة إلى المطوّرين

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

والتهديد الحقيقي لـ Adobe وMicrosoft لا يكمن في متحمس واحد، بل في أن تكثر مشاريع من هذا النوع. ولدى الشركتين وسائل حماية: الخدمات السحابية، ومنظومة الإضافات، والعقود المؤسسية، وعادات ملايين المستخدمين.

كيف تُقرأ مثل هذه القصص

إذا كنت تبني منتجاً، فتحقق من ثلاثة أمور. الأول: افتح ملفات حقيقية من عملك وانظر هل يختل التنسيق وتخطيط الصفحة. الثاني: ادرس رخصة المشروع ومصدر الكود، خصوصاً إذا كنت تخطط لاستخدام تجاري. الثالث: قيّم نشاط المجتمع خارج دائرة المنشئ، أي عدد المساهمين (contributors)، وسرعة إغلاق الأخطاء، وانتظام الإصدارات. وما دامت هذه البيانات غير متوافرة، فنحن أمام عرض مقنع لسرعة التطوير بالذكاء الاصطناعي، لا أمام بديل لـ Adobe وOffice.