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

هذه هي المشكلة المركزية التي يعالجها بيئة جديدة تسمى notlob، والتي ابتكرها الباحث آدم ت. بيرك. يقترح العمل عودة إلى فكرة قديمة تُعرف باسم "البرمجة الأدبية" (literate programming)، ولكن بتحديث يتناسب مع عصر يقرأ فيه كل من البشر والوكلاء الاصطناعيين نفس المستندات. في هذا النظام، ليس المشروع البرمجي مجرد مجموعة من الملفات المنفصلة للكود والتوثيق والاختبارات، بل هو مستند واحد متدفق يشبه المقال. يشرح النص الأفكار والدوافع والتصميم، بينما تُدمج التعليمات القابلة للتنفيذ مباشرة داخل النثر. لقد بنى الباحثون نظامًا يعمل يعامل هذا المستند المدمج كونه المصدر الأساسي للحقيقة. عندما يقرأ النظام الملف، فإنه لا يرى مجرد كلمات؛ بل يبني خريطة مفصلة لكيفية ارتباط كل اسم ومفهوم وقطعة كود ببعضها البعض. هذه الخريطة، التي يسميها المؤلف "رسم بياني للأسماء" (name-graph)، تسمح للوكيل الآلي بالتنقل في المشروع ليس عبر البحث عن الكلمات المفتاحية، بل عبر تتبع الروابط المنطقية بين الأفكار، تمامًا كما يتبع القارئ البشري خيط الفكرة عبر كتاب.

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

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

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

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

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

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

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