إعادة التفكير في لغات البرمجة في عصر الذكاء الاصطناعي
عندما يكتب الذكاء الاصطناعي الكود: إعادة التفكير في لغة البرمجة
أُنشئت لغات البرمجة لتكون واجهة بين التفكير البشري والتنفيذ الآلي.
لكن هذا التمييز بات أقل وضوحًا الآن.
يعمل البشر بشكل طبيعي مع الأرقام العشرية، بينما تعمل أجهزة الكمبيوتر من خلال الحالات الثنائية لأن الأجهزة الرقمية مبنية على حالات كهربائية منفصلة. وقد قدمت لغات البرمجة تجريدًا مماثلاً: حيث منحت البشر طريقة منظمة للتعبير عن المنطق الذي يمكن للآلات تنفيذه في نهاية المطاف.
على مدى عقود، ظل هذا النموذج دون تغيير إلى حد كبير:
البشر ← لغة البرمجة ← المترجم (Compiler) ← الآلة
تطورت اللغات لتلبي الاحتياجات البشرية. فركزت لغة بايثون (Python) على سهولة القراءة، وأسست جافا (Java) هيكلية صريحة وقابلية للنقل، بينما جعلت راست (Rust) الملكية وسلامة الذاكرة جزءًا من اللغة نفسها، مما مكن المطورين من التفكير بدقة أكبر في كيفية تصرف البرامج.
والآن، يتحدى الذكاء الاصطناعي الافتراضات الكامنة وراء هذا النموذج.
عندما يتم إنشاء البرمجيات بشكل متزايد بواسطة الآلات بدلاً من كتابتها سطرًا بسطر بواسطة المطورين، لا يعود السؤال ببساطة هو كيف ينبغي للبشر التواصل مع أجهزة الكمبيوتر، بل يصبح سؤالاً أكثر جوهرية:
ما الذي يجب أن تحسنه لغة البرمجة عندما يكون الكاتب الأساسي نظام ذكاء اصطناعي؟
من سهولة القراءة البشرية إلى سهولة التوليد الآلي
تعمل وكلاء برمجة الذكاء الاصطناعي اليوم إلى حد كبير ضمن النظام البرمجي الحالي: Python وJavaScript وJava وC++ وRust واللغات المحيطة بها.
ويرجع ذلك جزئيًا إلى حجم هذه اللغات، فقد تراكمت لديها أنظمة بيئية ضخمة من الكود المصدري، والوثائق، والمكتبات، والأمثلة، ومعرفة المطورين. وقد تم تدريب نماذج الذكاء الاصطناعي على نطاق واسع على تلك المواد، مما جعل اللغات الراسخة بيئة العمل الطبيعية لتوليد الكود.
لكن الانتشار الواسع لا يجعل بالضرورة اللغة مثالية للبرمجيات التي تولدها الآلة.
تستكشف الأعمال التجريبية بالفعل بدائل أخرى. حيث تتساءل مشاريع مثل ilo عما إذا كان ينبغي لبنية البرمجة (syntax) أن تظل متمحورة حول اصطلاحات ظهرت في المقام الأول للمطورين البشر.
بالنسبة لنظام ذكاء اصطناعي يولد ملايين الرموز (tokens)، فإن الحسابات الاقتصادية تختلف. فاللغة المفيدة قد تضع تركيزًا أكبر على التمثيل المدمج، والتعبير المقيد، والاتساق الهيكلي، والحد من الغموض.
وهذا يغير هدف التصميم.
فالسؤال ذو الصلة لم يعد ببساطة ما إذا كان الكود سهلاً على المطور قراءته، بل ما إذا كان بإمكان النظام توليد هذا الكود وتعديله وفهمه بأقل قدر من الفرص لحدوث سلوك غير مقصود.
وقد تكون البنية البرمجية (syntax) هي الجزء الأقل أهمية في هذه المشكلة.
يمكن للذكاء الاصطناعي معرفة أين توضع الأقواس والفاصلة المنقوطة. وتحدث الإخفاقات الأكثر أهمية على مستوى المعنى (semantics): مثل استدعاء واجهة برمجة تطبيقات (API) غير متاحة، أو انتهاك عقد الواجهة، أو إدخال تبعية غير متوافقة، أو تغيير مكون واحد بطريقة تؤدي إلى فشل غير متوقع في مكان آخر.
لذلك، فإن التحدي الرئيسي لا يكمن بالضرورة في جعل لغات البرمجة أسهل في الكتابة بالنسبة للذكاء الاصطناعي.
بل يكمن في جعل إنتاج البرمجيات الخاطئة أكثر صعوبة على الذكاء الاصطناعي.
التحقق يصبح جزءًا من نموذج البرمجة
هنا تكتسب أنظمة الانماط (type systems)، والعقود (contracts)، والتحقق الرسمي (formal verification) أهمية استراتيجية.
يفصل التطوير التقليدي إلى حد كبير بين التوليد والتحقق: حيث يتم كتابة الكود أولاً، ثم اختباره ومراجعته ونشره من خلال ضوابط متطورة بشكل متزايد.
وتغير البرمجيات المولدة بالذكاء الاصطناعي اقتصاديات هذه العملية. فعندما يتمكن وكيل من إنتاج وتعديل الكود بحجم وسرعة يفوقان قدرة المراجعة البشرية، لا يمكن أن يظل التحقق مجرد نشاط في نهاية المطاف.
قد تحتاج بيئة التطوير نفسها إلى تقييد ما يمكن للذكاء الاصطناعي توليده.
يوضح البحث في توليد الأكواد المقيدة بالانماط (type-constrained code generation) هذا الاتجاه. فبدلاً من السماح للنموذج بتوليد بنية عشوائية والتحقق من النتيجة لاحقًا، يمكن تقييد عملية التوليد بالأنواع والهياكل والقواعد المتاحة داخل البرنامج.
هذا يخلق علاقة مختلفة بين المطور، والذكاء الاصطناعي، وبيئة البرمجة.
الهدف ليس إثبات أن الذكاء الاصطناعي لن يرتكب أي خطأ أبدًا، فهذا توقع غير واقعي.
بل الهدف هو تصميم أنظمة يتم فيها تقييد الأخطاء وإظهارها وحلها قبل أن تتحول إلى إخفاقات على مستوى النظام بأكمله.
في هندسة البرمجيات المدعومة بالذكاء الاصطناعي، قد يصبح التحقق بنفس أهمية التوليد.
ويمتد هذا المبدأ إلى ما هو أبعد من لغات البرمجة، إذ يشير إلى بيئات تطوير تكون فيها الأذونات، والواجهات، والثوابت (invariants)، والتبعيات، والسلوكيات المتوقعة أجزاءً صريحة من النموذج البرمجي.
ما وراء الكود المصدري
ويتبع ذلك سؤال أكثر جوهرية.
لماذا يحتاج الذكاء الاصطناعي إلى توليد كود مصدري في المقام الأول؟
يوجد الكود المصدري جزئيًا لأن البشر يحتاجون إلى تمثيل عملي للبرمجيات. يكتب المطورون نصوصًا لأن النصوص سهلة الوصول والنقل والمراجعة.
لكن الآلة في النهاية تنفذ شيئًا آخر: تمثيلاً مهيكلاً يتم إنتاجه من خلال التحليل (parsing) أو الترجمة (compilation) أو التفسير (interpretation).
بالنسبة لنظام الذكاء الاصطناعي، قد لا تكون الطبقة النصية ضرورية دائمًا.
فبدلاً من:
الذكاء الاصطناعي ← الكود المصدري ← المحلل (Parser) ← هيكل البرنامج
يمكن أن تنتقل البنية الهيكلية نحو:
الذكاء الاصطناعي ← هيكل البرنامج
تستكشف مناهج تجريبية مثل Zerolang هذا الاتجاه من خلال تمثيل البرامج عبر هياكل دلالية تشمل الرموز، والأنواع، والعلاقات، والتأثيرات. ويمكن أن يظل الكود القابل للقراءة من قبل البشر متاحًا، ولكنه يصبح مجرد تمثيل للنموذج البرمجي الأساسي بدلاً من أن يكون التعريف الوحيد للبرمجيات.
ويمكن أن يكون لهذا التمييز آثار كبيرة.
اليوم، الافتراض السائد هو:
الكود المصدري هو البرنامج.
لكن البنية البرمجية المستقبلية قد تعامل النموذج المهيكل الأساسي كمرجع نهائي، مع عمل الكود المصدري كأحد التمثيلات الموجهة للبشر لهذا النموذج.
وهذا يمثل أكثر من مجرد لغة برمجة جديدة؛ إنه يمثل طبقة تجريد مختلفة للبرمجيات نفسها.
دور المطور ينتقل إلى مستوى أعلى في الهرم
مع زيادة قدرة أنظمة الذكاء الاصطناعي على توليد كميات هائلة من البرمجيات، تصبح مراجعة كل تفاصيل التنفيذ أمرًا غير عملي بشكل متزايد.
لذلك، تنتقل قيمة التدخل البشري نحو الحدود، والقيود، والسلوك المقصود للنظام.
وتصبح الأسئلة الحاسمة هي:
ما الذي يهدف النظام إلى فعله؟
ما الذي يجب ألا يفعله أبدًا؟
ما هي الموارد والبيانات التي يمكنه الوصول إليها؟
ما هي الواجهات والتبعيات المسموح بها؟
ما هي الخصائص الأمنية التي يجب أن تظل ثابتة دون تغيير؟
ما هي السلوكيات التي تتطلب تحققًا رسميًا (formal verification)؟
ما هي الأدلة الكافية لإثبات أن النظام يتصرف كما هو مقصود؟
هذا لا يعني اختفاء هندسة البرمجيات، بل هو تحول في مكان تطبيق التقييم الهندسي.
قد يقضي المطورون وقتًا أقل في كتابة التعليمات الفردية ووقتًا أطول في تحديد سلوك النظام، وبنيته الهيكلية، وقيوده، وآليات التحقق منه.
ومن غير المرجح أن تختفي اللغات الحالية نتيجة لذلك؛ فأنظمتها البيئية، وأدواتها، ومكتباتها، ومعرفتها المتراكمة تمثل بنية تحتية ضخمة. والأرجح هو أنها ستصبح بشكل متزايد أهدافًا للتنفيذ داخل بيئة تطوير أوسع تعتمد أصلاً على الذكاء الاصطناعي.
وقد يصبح التمييز بين التمثيلات الموجهة للبشر وتلك الموجهة للآلة أكثر أهمية.
حيث يمكن لأحد التمثيلات أن يركز على التوليد والتحويل والتحقق.
بينما يركز الآخر على الفهم البشري والحوكمة والتحكم.
النموذج البرمجي الناشئ
قد تبدو البنية الناتجة أقل شبهًا بتطوير البرمجيات التقليدي وأقرب إلى:
النية البشرية ← وكيل الذكاء الاصطناعي ← نموذج البرنامج ← التحقق والترجمة ← الآلة
التحول المهم لا يقتصر ببساطة على الانتقال من الكود المكتوب بشريًا إلى الكود المولد بالذكاء الاصطناعي.
بل هو الانتقال من الكود كمنتج أساسي إلى البرمجيات كنظام مهيكل وقابل للتحقق من النوايا والسلوكيات والقيود.
هذا التمييز مهم لأن حجم البرمجيات لم يعد مقيدًا فقط بمدى سرعة كتابة البشر لها. ومع وفرة التوليد، تنتقل القدرة النادرة نحو تحديد ما يُسمح للبرمجيات بفعله، وإثبات قيامها بذلك بثقة كافية.
لذلك، قد لا يتم تعريف الجيل القادم من لغات البرمجة بمدى تشابهها مع بايثون أو جافا أو راست.
بل قد يتم تعريفها بمدى فعاليتها في تمثيل النوايا، وتقييد السلوك المولد آليًا، وجعل البرمجيات قابلة للتحقق.
وإذا كانت الآلات تكتب البرمجيات بشكل متزايد لآلات أخرى، فإن السؤال على المدى الطويل لم يعد ما إذا كان الذكاء الاصطناعي سيخلق لغة برمجة أخرى.
بل هو ما إذا كان الكود المصدري المقروء بشريًا سيظل المنتج الأساسي لتطوير البرمجيات، أم سيصبح مجرد واجهة واحدة لنموذج حوسبة أعمق.
الكاتب: عبد الرحمن الأحمر
خبير استشاري في Devista ولديه خبرة في هندسة البرمجيات. ويهتم بشكل خاص بالذكاء الاصطناعي، والذكاء الاصطناعي الوكيل (agentic AI)، والقيادة الهندسية.
