الذكاء الاصطناعي ترجم 30 عامًا من COBOL بإتقان. ثم أعطب قاعدة البيانات.

كانت ليلة ثلاثاء، وكنت أحدّق في تتبّع مكدّس (stack trace) لا معنى له على الإطلاق.

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

لم يكن الخلل في Java. كانت Java سليمة نحويًّا. كان الخلل فيما لم يره الذكاء الاصطناعي أبدًا.

متغيّر يُدعى TRN-LIMIT — مُعرَّف ليس في الملف المصدري الذي ترجمه الذكاء الاصطناعي، بل في COPYBOOK مُضمَّن قبل آلاف الأسطر في سلسلة التنفيذ — كان يحتوي على جملة REDEFINES. وهذا بناء في COBOL يُفسَّر فيه عنوان الذاكرة نفسه على أنه نوعان مختلفان من البيانات تبعًا لعَلَم (flag) يُضبَط في وحدة مختلفة تمامًا. رأى الذكاء الاصطناعي TRN-LIMIT كحقل رقمي بسيط. لكنه لم يكن كذلك. كان عددًا عشريًّا مُحزَّمًا (packed decimal) يتنكّر في هيئة عدد صحيح تبعًا لسياق التشغيل. هلوَس الذكاء الاصطناعي بتعريف قياسي، فكتب تطبيق Java بيانات ثنائية فاسدة في عمود بقاعدة البيانات.

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

مشكلة الـ 1.52 تريليون دولار التي لا يريد أحد الحديث عنها

إليك الواقع المُقلِق للاقتصاد العالمي في عام 2025: 43% من الأنظمة المصرفية ما زالت تعمل على COBOL، وتعالج تلك الأنظمة 95% من جميع معاملات أجهزة الصراف الآلي. أما البرمجيات التي تُشغّل شركات Fortune 500؟ فقد كُتب نحو 70% منها قبل أكثر من عقدين. أما الدَّين التقني في الولايات المتحدة وحدها فقد تضخّم إلى ما يُقدَّر بـ 1.52 تريليون دولار.

والأشخاص الذين كتبوا هذه الشيفرة يتقاعدون. لا "قد يتقاعدون يومًا ما" — بل يغادرون الآن، حاملين معهم عقودًا من المعرفة المؤسسية. وفي غضون ذلك، تذهب 80% من ميزانيات تقنية المعلومات الفيدرالية إلى إبقاء الأنظمة القديمة على قيد الحياة، فلا يتبقّى سوى 20% بالكاد لأي شيء جديد.

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

الأرقام تؤكّد هذا. إذ يفشل ما بين 70% و80% من مشاريع تحديث الأنظمة القديمة في تحقيق أهدافها. وكان ذلك صحيحًا قبل أن يدخل الذكاء الاصطناعي التوليدي المشهد.

لماذا ظنّ الجميع أن GPT قادر على إصلاح هذا؟

أتفهّم ذلك. حقًّا أتفهّمه. حين ظهر GPT-4، انطلقت سوق الاستشارات البرمجية بأقصى سرعة. فجأةً صار لدى كل شركة "مُسرِّع ترحيل COBOL" — وهو، إذا نظرتَ تحت الغطاء، غلاف رقيق حول نموذج أساس. تُلصِق فقرة COBOL خاصتك، فتستعيد دالة Java. سِحرٌ.

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

أخطر خلل ليس ذاك الذي يُعطّل نظامك. بل هو الذي يُفسِد بياناتك بصمت لمدة ستة أشهر قبل أن يلاحظه أحد.

المشكلة معماريّة، وتعود إلى كيفية معالجة نماذج اللغة الكبيرة للمعلومات. تستخدم نماذج اللغة الكبيرة آلية انتباه (attention) لترجيح أهمية أجزاء مُدخَلاتها المختلفة. وتتباهى النماذج الحديثة بنوافذ سياق تصل إلى مليون رمز (token). لكن الأبحاث برهنت على ظاهرة تُسمّى تأثير "الضياع في المنتصف": إذ تُظهِر نماذج اللغة الكبيرة منحنى أداء على شكل حرف U، فتستذكر المعلومات في بداية المُوجَّه ونهايته جيّدًا، لكن أداءها يتدهور بشكل كبير مع أي شيء في المنتصف.

في مشروع تحديث، قد يبلغ طول برنامج COBOL واحد آلاف الأسطر، مع إحالته إلى copybooks يبلغ طول كل منها آلاف الأسطر بدوره. فإذا كان تعريف MAX-TRANSACTION-LIMIT واقعًا في منتصف ذلك السياق الضخم، فمن المرجّح إحصائيًّا أن يفوّته الذكاء الاصطناعي. وحين يفوّت شيئًا، فإنه لا يتوقّف ليسأل. بل يهلوِس. يخترع تعريفًا معقولًا ويمضي.

ماذا يحدث حين تعامِل الشيفرة كنصّ؟

هذا هو الخطأ الجوهري الذي أراه في منظومة "غلاف الذكاء الاصطناعي" برمّتها، وهو الحُجّة التي ظللتُ أتجادل بشأنها مع مستثمر مُحتمَل في وقت مبكّر. نظر إلى نهجنا — بناء رسوم بيانية معرفية لمستودعات الشيفرة — وقال: "لماذا لا تستخدمون فقط نافذة سياق أكبر؟ سيُصلِح GPT-5 هذا."

فتحتُ برنامج COBOL على حاسوبي المحمول. قلت: "جِد لي تعريف ACCOUNT-BALANCE".

بحث في الملف. لم يستطع العثور عليه. لأنه لم يكن في ذلك الملف. كان في copybook، مُضمَّن عبر جملة في السطر 47، والذي أحال بدوره إلى قسم بيانات مشترك يديره فريق مختلف تمامًا.

قلت: "تخيّل الآن أنك نموذج لغة كبير. أنت تُجري بحثًا بالتشابه المتّجهي عن شيفرة تتعلّق بـ 'معالجة المدفوعات'. ستجد خمس كُتَل تذكر كلمة 'مدفوعات'. وستُغفِل تمامًا الملف المُسمّى GlobalVarDef.cbl الذي يُعرِّف معدّل الضريبة المُستخدَم في منطق المدفوعات — لأن ذلك الملف لا يذكر كلمة 'مدفوعات' في أي مكان قط."

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

الشيفرة ليست لغة طبيعية. فعبارة "جلس القط على الحصير" تعني الشيء نفسه تقريبًا بصرف النظر عمّا قرأتَه قبل خمسين صفحة. لكن x = y + 1 لا يعني شيئًا ما لم تعرف التعريفات والأنواع والحالات الراهنة لـ x وy — والتي قد تكون مُعرَّفة في ملف مختلف، أو وحدة مختلفة، أو موروثة من صنف أب.

لقد كتبتُ عن هذه المشكلة البنيوية بتعمُّق في النسخة التفاعلية من بحثنا. والخلاصة المختصرة: البرمجيات ليست نصًّا. البرمجيات رسم بياني.

الليلة التي توقّفنا فيها عن بناء غلاف أفضل

كانت هناك لحظة — أتذكّرها بوضوح — حين كان فريقي يتناقش حول معماريتنا. كان أمامنا مساران. المسار الأول: بناء خطّ أنابيب RAG أذكى. تقطيع أفضل، وتضمينات (embeddings) أفضل، ومُوجِّهات أفضل. التكرار على نهج الغلاف حتى يعمل بشكل جيد بما يكفي. المسار الثاني: نبذ النموذج القائم على النصّ برمّته، ومعاملة الشيفرة على حقيقتها — نظام علائقي من المنطق.

كان المسار الأول أسرع. وكان المسار الأول ما يفهمه المستثمرون. وكان للمسار الأول عشرات المنافسين الذين يُثبِتون بالفعل وجود طلب في السوق.

أمسك كبير مهندسيّ بلوح أبيض ورسم برنامج COBOL كرسم بياني. عُقَد للمتغيّرات والدوال وملفات copybooks وجداول قاعدة البيانات. وحوافّ لـ CALLS، READS، UPDATES_TABLE، IMPORTS_COPYBOOK. ثم تتبّعَت سلسلة تبعية: الوحدة A تستدعي الوحدة B، التي تُعدِّل المتغيّر X، الذي تقرأه الوحدة C في دليل مختلف تمامًا.

قالت: "اطلب من بحث متّجهي أن يجد تلك السلسلة".

لم يستطع أحد.

تلك كانت الليلة التي التزمنا فيها ببناء ما نُسمّيه الآن رسمًا بيانيًّا معرفيًّا واعيًا بالمستودع — قاعدة بيانات رسم بياني موحّدة تجمع البنية الساكنة للشيفرة (أشجار البناء الجُمَلي المُجرَّدة، ورسوم الاستدعاء البيانية) مع المعنى الدلالي لمنطق العمل (التوثيق، والتعليقات، ومقصد المتغيّر). لم نكن سنبني مترجِمًا أفضل. كنّا سنبني خريطة.

كيف تُحوِّل ثلاثين عامًا من COBOL إلى خريطة؟

تتألّف العملية من أربع مراحل، وسأُجنّبك تفاصيل التنفيذ — يمكنك أن تجدها في غوصنا التقني الكامل والمُعمَّق. لكن المفاهيم مهمّة، لأنها تُفسِّر لماذا ينجح هذا النهج حيث تفشل الأغلفة.

أولًا، نُحلِّل الشيفرة بنيويًّا، لا نصّيًّا. تستخدم خطوط أنابيب RAG القياسية "التقسيم الساذج" — إذ تقطع الملف كل 500 رمز، فتفصل غالبًا توقيع الدالة عن جسمها. أما نحن فنستخدم مُحلِّلات نحوية مثل Tree-sitter لتوليد أشجار بناء جُمَلي مُجرَّدة، تحترم الحدود المنطقية للشيفرة. فتُعامَل الدالة كوحدة منطقية كاملة، لا كامتداد نصّي عشوائي.

ثانيًا، نستخرج الكيانات والعلاقات. الأصناف، والفقرات، والمتغيّرات، وجداول قاعدة البيانات، ونقاط نهاية واجهات برمجة التطبيقات (API) — تصبح هذه عُقَدًا. والحوافّ بينها — CALLS، UPDATES_TABLE، DEFINES_VARIABLE — تصبح النسيج الرابط. ويمكننا الآن الاستعلام عن الرسم البياني: "أظهِر لي كل فقرة تُحدِّث حقل CUSTOMER-ID". نتائج دقيقة، فورًا. جرّب ذلك بأداة grep.

ثالثًا — وهنا يصبح الأمر مثيرًا للاهتمام — نحلّ الرموز عبر المستودع بأكمله. يرى المُحلِّل النحوي القياسي ACCT-NUM في الملف A وACCT-NUM في الملف B كسلسلتين نصّيتين مختلفتين. أما نظامنا فيُحدِّد أن كليهما يشير إلى المُدخَل نفسه في copybook مشترك، ويدمجهما في عُقدة واحدة. كما ندمج التوثيق مع الشيفرة: فإذا وصف مستند متطلّبات بصيغة PDF "واجهة برمجة تطبيقات المستخدم" واحتوت الشيفرة على صنف مُسمّى UserAPI، فإن النظام يربط المقصد بالتنفيذ.

رابعًا، نحسب الإغلاق التعدّي (transitive closure). أتذكر إخفاق المصرف؟ A يعتمد على B، وB يعتمد على C، ورأى الذكاء الاصطناعي A لكنه أغفل C. يجتاز رسمنا البياني بعمق — من A إلى B إلى C — لتحديد التعريف الجذري لكل متغيّر. وحين يُولِّد الذكاء الاصطناعي شيفرة للوحدة A، فإنه يستورد التعريفات الصحيحة من الوحدة C، حتى لو كانت الوحدة C في دليل أو مستودع مختلف تمامًا.

لماذا يفشل RAG القياسي في ترحيل الشيفرة؟

يعترض الناس دائمًا على هذا. سيقولون: "RAG يعمل جيّدًا مع الشيفرة. استخدِم فقط تضمينات أفضل".

دعني أعطيك ثلاثة سيناريوهات ينهار فيها البحث بالتشابه المتّجهي تمامًا:

يُعيد مطوِّر تسمية Account إلى Acct. ينخفض التشابه الدلالي، مع أن المنطق مُتطابِق. ودالة مُسمّاة FNC-001 تُنفِّذ حساب الفائدة لكنها لا تحتوي على أي تعليقات — البحث عن "حساب الفائدة" لن يجدها أبدًا. وأشيع إخفاق: يسترجع RAG المتّجهي اختبار وحدة وتعليقًا في واجهة المستخدم يذكران "مدفوعات"، لكنه يُغفِل منطق العمل الأساسي لأن أسماء المتغيّرات لا تُطابِق كلمات الاستعلام.

الاسترجاع القائم على الرسم البياني لا يسأل "ما النصّ الذي يبدو متشابهًا؟". بل يسأل "ما المرتبط منطقيًّا؟" — وهذا التمييز هو الفرق بين شيفرة تُترجَم وشيفرة تعمل.

ما نُسمّيه GraphRAG يعمل على البنية، لا على التشابه. فحين يسأل أحدهم "أعِد هيكلة منطق المدفوعات"، يستخدم النظام البحث المتّجهي للعثور على نقطة الدخول — مثلًا، فقرة ProcessPayment. لكنه بعد ذلك، بدلًا من التوقّف، يجتاز حوافّ الرسم البياني. فيسحب الروتينات الفرعية عبر حوافّ CALLS، وتعريفات المتغيّرات عبر حوافّ READS، وملفات copybooks عبر حوافّ INCLUDES. وقد تكون هذه القطع المترابطة متباينة نصّيًّا لكنها غير قابلة للفصل منطقيًّا.

تُظهِر الأبحاث أن GraphRAG يتفوّق بشكل كبير على RAG المتّجهي في الاستدلال متعدّد القفزات — أي ربط الحقائق المفصولة بعدة خطوات. وفي البرمجيات، يكاد كل خلل جدّي أن يكون إخفاقًا في الاستدلال متعدّد القفزات. إذا غيّرتُ منطق سعر الفائدة في الوحدة A، فأي شاشات تقارير في الوحدة Z ستتعطّل؟ RAG المتّجهي لا يستطيع الإجابة على هذا. أما الرسم البياني فيستطيع، لأنه يجتاز سلسلة استدعاءات الدوال التي تربطها.

مشكلة GOTO (أو: لماذا تجعل COBOL الذكاء الاصطناعي يهلوِس الحلقات)

أريد أن أُخبرك عن تحدٍّ تقني محدّد كاد أن يُحطِّمنا، لأنه يوضّح لماذا هذا العمل أصعب بكثير ممّا يفترض الناس.

لدى COBOL جملة GOTO. أما Java فلا. GOTO تتيح لتنفيذ البرنامج القفز إلى أي مكان — أمامًا، وخلفًا، وإلى منتصف كتلة أخرى. وهي تخلق "شيفرة السباغيتي" التي يُحذِّرك منها كل أستاذ في علوم الحاسوب. ترجمة GOTO ليست مشكلة بناء جملة. بل هي مشكلة طوبولوجيا.

شاهدنا ثلاث أدوات ذكاء اصطناعي تجارية مختلفة تحاول ترجمة وحدة COBOL ذات استخدام مكثّف لـ GOTO. واحدة وَلّدَت استدعاء دالة تعاودي (recursive) كان سيتسبّب في StackOverflowError في بيئة الإنتاج. وأخرى أنتجت حلقة while(true) دون أي شرط خروج. أما الثالثة — وهي المُفضّلة لديّ شخصيًّا — فقد اخترعت ببساطة تدفّق تحكّم لم يكن موجودًا في الشيفرة الأصلية. بدا معقولًا. لكنه كان خاطئًا تمامًا.

نهجنا: رسم وجهات GOTO كحوافّ في رسم بياني لتدفّق التحكّم. ثم استخدام التعرّف على الأنماط في الرسم البياني. GOTO تقفز رجوعًا إلى تسمية سابقة؟ تلك حلقة. GOTO تتخطّى كتلة؟ ذلك شرط. GOTO إلى فقرة خروج؟ تلك عبارة إرجاع. والذكاء الاصطناعي، مُوجَّهًا ببنية الرسم البياني، يُعيد هيكلة هذه القفزات إلى حلقات while، وكُتَل if/else، أو عبارات break/continue.

بدون الرسم البياني، الذكاء الاصطناعي يُخمِّن. ومع الرسم البياني، إنه يُهندِس.

الفرق بين روبوت الدردشة والوكيل

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

يأخذ روبوت الدردشة سؤالك، ويرسله إلى GPT-4، ويُعيد ما يأتي مهما كان. وإذا كان الناتج خاطئًا، فأنت تُنقِّحه يدويًّا. تلك هي سير العمل لكل غلاف ذكاء اصطناعي في السوق.

أما ما ننشره فهو وكلاء مستقلّون يُخطِّطون، ويُنفِّذون، ويُصحِّحون أنفسهم ذاتيًّا. يُحلِّل الوكيل شجرة البناء الجُمَلي المُجرَّدة (AST) لملف COBOL المُستهدَف، ويُحدِّد التبعيات، ويستعلم عن الرسم البياني المعرفي، ويُولِّد شيفرة Java، ثم يُترجِمها في بيئة معزولة (sandbox). وإذا أطلق المُترجِم خطأً — "المتغيّر غير موجود" — يقرأ الوكيل الخطأ، ويستعلم عن الرسم البياني عن التبعية المفقودة، ويُعيد التوليد. ثم يُشغِّل اختبارات وحدة مُشتقّة من تتبُّعات تنفيذ COBOL الأصلية للتحقّق من التكافؤ السلوكي.

تنقل حلقة الترجمة-والإصلاح هذه عبء التحقّق من الإنسان إلى النظام. لكن — وهذا مهمّ للغاية في الصناعات الخاضعة للتنظيم — يوفّر الرسم البياني المعرفي قابلية تفسير كاملة. فيمكن للمطوِّر أن يرى بالضبط لماذا اتّخذ الذكاء الاصطناعي كل قرار: "استورد الذكاء الاصطناعي com.bank.logic لأنه وجد تبعية على COPYBOOK-X". ليس "ثِق بي، أنا ذكاء اصطناعي". بل: إليك سلسلة الاستشهاد لهذا المنطق.

في المصارف، يجب أن يكون كل سطر من الشيفرة قابلًا للتدقيق. لا يمكنك نشر صندوق أسود "ربّما" أصاب. أنت بحاجة إلى نظام قادر على إظهار عمله.

ماذا عن الشيفرة الميتة؟

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

يُحدِّد رسم الاستدعاء البياني لدينا العُقَد غير القابلة للوصول — الفقرات أو الملفات التي لا حوافّ واردة إليها، أي أن لا شيء يستدعيها. ونُعلِّم هذه الشيفرة الميتة للحذف قبل أن يبدأ الترحيل. وفي خبرتنا، يقلّل هذا عادةً قاعدة الشيفرة بنسبة 20-30%. وهذا ليس تحسينًا طفيفًا. إنه إزالة رُبع العمل ورُبع سطح الهجوم.

"ألن تحلّ نوافذ السياق الأكبر هذا؟"

ما زلتُ أتلقّى هذا السؤال باستمرار. الافتراض هو أنه إذا كان بإمكان GPT-5 أو Claude 4 التعامل مع عشرة ملايين رمز، فإن مشكلة "الضياع في المنتصف" تزول.

لن تزول. وإليك السبب.

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

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

الخريطة هي الأصل

إليك ما كنت أتمنّى لو أنني فهمته في البداية: الرسم البياني المعرفي ليس مجرّد أداة للترحيل. إنه أصل دائم.

بمجرد أن توجد قاعدة شيفرتك كرسم بياني، فإنها تبقى تمثيلًا حيًّا لنظامك. ومع تطوّر شيفرة Java الجديدة، يتحدّث الرسم البياني. فتحصل على توثيق آلي محدّث دائمًا. وتحصل على كشف الانحراف المعماري — إذ يُنبِّهك النظام إذا انتهكت شيفرة جديدة قواعد النمطية (modularity) التي حدّدتها. وتحصل على تحليل الأثر عند الطلب: "إذا غيّرتُ هذه الدالة، فما الذي يتعطّل؟"

التحديث ليس حدثًا لمرة واحدة. إنه دورة حياة. فالمؤسسات التي تعامله كمشروع — بتاريخ بداية وتاريخ نهاية — هي التي تجد نفسها عائدةً إلى حيث بدأت بعد خمس سنوات، غارقةً في جيل جديد من الدَّين التقني.

الشيفرة ليست نصًّا

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

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

لقد بنينا الخريطة. وهي تعمل — لا لأننا أذكى من الفِرَق التي تبني نماذج الأساس، بل لأننا طرحنا سؤالًا مختلفًا. هم سألوا: "كيف نجعل الذكاء الاصطناعي يفهم النصّ بشكل أفضل؟". ونحن سألنا: "ماذا لو لم تكن المشكلة نصًّا على الإطلاق؟"

مستقبل تحديث الأنظمة القديمة ليس نموذج لغة أكبر. بل هو نظام يفهم البرمجيات بالطريقة التي تعمل بها البرمجيات فعليًّا — كبنية، لا كسلاسل نصّية.

تلك هي المراهنة التي راهنّاها في Veriprajna. ففي كل يوم، تكتشف مؤسسة أخرى أن شيفرة Java المُولَّدة بالذكاء الاصطناعي لديها تُترجَم بشكل رائع وتفشل بشكل كارثي. وفي كل يوم، تصبح الفجوة بين الترجمة النحوية والفهم الدلالي أغلى ثمنًا من أن تُتجاهَل. والمؤسسات التي تسدّ تلك الفجوة لن تُحدِّث شيفرتها فحسب. بل ستفهمها أخيرًا — كثير منها للمرة الأولى.