Specification-first convergence with an AI coding agent: a case study of dismantling a core architectural invariant across 189 files in a 717k-line codebase with no test oracle and no human code review

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

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

حدثت هذه التجربة داخل تطبيق برمجيات خاص وكبير يُستخدم للمساعدة في برمجة الذكاء الاصطناعي. احتوى النظام، المكتوب بلغة تسمى "تايب سكريبت" (TypeScript)، على أكثر من 717,000 سطر من الكود موزعة على ما يقرب من 3,650 ملفاً. كان قطعة برمجية حية ونشطة تُستخدم يومياً، وليس نموذجاً نظرياً. وكانت المهمة المسندة إلى وكيل الذكاء الاصطناعي هي تفكيك قاعدة جوهرية كانت تحكم النظام منذ إنشائه. هذه القاعدة، المعروفة باسم "الثابت" (invariant)، تضمن أنه كلما بدأ المستخدم محادثة مع الذكاء الاصطناعي، تظل النافذة التي تعرض تلك المحادثة مفتوحة طوال مدة الطلب. إذا أغلق المستخدم النافذة، تنتهي المحادثة. وكان الهدف هو كسر هذه القاعدة: يجب أن يتمكن المستخدم من إغلاق النافذة، وتستمر المحادثة في العمل في الخلفية، لتكون جاهزة لإعادة الفتح والاستئناف تماماً من حيث توقفت، دون فقدان أي بيانات أو تكرار أي كلمات.

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

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

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

شملت العملية بأكملها 189 ملفاً، وبلغ إجمالي الملفات التي تغيرت 288 ملفاً عند تضمين استخراج الكود القديم. تضمنت التغييرات أكثر من 34,000 سطر جديد من الكود وحذف أكثر من 16,000 سطر. ومن المثير للدهشة أن إعادة الهيكلة الضخمة هذه اكتملت في ثلاثة أيام. بلغت تكلفة معالجة الذكاء الاصطناعي المطلوبة للمهمة 2,430 دولاراً أمريكياً. وطوال فترة الثلاثة أيام، لم يتم تشغيل البرنامج ولو لمرة واحدة بواسطة إنسان. كانت المرة الأولى التي يتم فيها تنفيذ البرنامج فعلياً هي بعد دورة التحقق السابعة عشرة، عندما اختبر المؤلف أخيراً السلوك الجديد.

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

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

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