تنفيذ مهمة برمجية بالذكاء الاصطناعي: تجربة من Issue إلى Pull Request
تنفيذ مهمة برمجية بالذكاء الاصطناعي من البداية للنهاية هو السؤال الذي أردنا اختباره عمليًا، وليس مجرد استخدام AI لكتابة بضعة أسطر من الكود.
الذكاء الاصطناعي يستطيع كتابة الكود. هذه لم تعد النقطة المثيرة للاهتمام.
السؤال الأكثر أهمية بالنسبة لي أصبح: هل يمكن أن أعطي الذكاء الاصطناعي مشكلة حقيقية في مشروع حقيقي، ثم أتركه يمر بدورة التطوير نفسها التي يمر بها المطور: يفهم المشكلة، يعدّل الكود، يكتب الاختبارات، ينشئ Pull Request، يخضع للمراجعة والـCI، ثم يصل إلى نقطة يصبح فيها التغيير جاهزًا للدمج؟
قررنا أن نجرب ذلك عمليًا.
ولم نخترع Todo App أو مشروعًا صغيرًا مخصصًا للتجربة. الاختبار تم على مشكلة فعلية ظهرت في مشروع يعمل بالفعل في Production.
المشكلة التي بدأنا بها
المشكلة كانت بسيطة ظاهريًا.
في أحد المواقع التي تعمل على نظام إدارة المحتوى الذي نطوره، كانت صورة الكاتب تظهر بشكل طبيعي في صفحة الكاتب، لكنها لا تظهر داخل صفحة المقال نفسه.
نفس الكاتب، نفس الصورة، ونفس البيانات.
لكن صفحة المقال كانت تعرض الصورة الافتراضية بدلًا من صورة الكاتب.
تم تحويل المشكلة إلى GitHub Issue واضحة تحتوي على السلوك الحالي، والسلوك المتوقع، وبعض النقاط التي يجب فحصها، بالإضافة إلى Acceptance Criteria تحدد متى يمكن اعتبار المشكلة محلولة.
من هنا بدأ الاختبار الحقيقي.
بدل أن يأخذ مطور الـIssue ويبدأ العمل عليها، أخذها وكيل ذكاء اصطناعي متصل بالـrepository.
ماذا طلبنا من الـAI؟
لم نقل له: غيّر السطر الفلاني في الملف الفلاني.
هذا كان سيحول التجربة إلى مجرد Code Generation.
الهدف كان أن يستلم المشكلة نفسها.
كان عليه أن يفهم لماذا صفحة الكاتب تستطيع الوصول إلى الصورة بينما صفحة المقال لا تستطيع، ثم يحدد التغيير المطلوب ويحافظ على السلوك الموجود في باقي النظام.
بعد التنفيذ ظهر Pull Request مستقل للمشكلة.
الـPR لم يحتوِ على تعديل الـHTML فقط. التغيير شمل أيضًا Regression Tests ووثائق للسلوك الجديد.
في النهاية وصل التغيير إلى 4 ملفات، مع 67 سطرًا مضافًا و8 أسطر محذوفة، عبر 3 commits.
الأرقام نفسها ليست مهمة. المهم هو أن الـAI لم يتعامل مع المهمة باعتبارها "اكتب لي سطر كود"، بل تعامل معها كتغيير Software Engineering يجب أن يمكن اختباره ومراجعته.
هل فهم الذكاء الاصطناعي سبب المشكلة فعلًا؟
نعم، وهنا بدأت التجربة تصبح مثيرة للاهتمام.
صفحة المقال كانت تضع الصورة الافتراضية داخل src، بينما تضع صورة الكاتب الحقيقية في data-original.
هذا يعني أن ظهور الصورة الحقيقية كان يعتمد على JavaScript يقوم لاحقًا باستبدال الصورة.
أما صفحة الكاتب فكانت تحل مسار الصورة بصورة مختلفة.
الحل الذي تم تنفيذه وحّد منطق اختيار الصورة.
إذا كان للـWriter صورة، يتم استخدامها. وإذا لم توجد، يتم الرجوع إلى صورة الـUser المرتبط به. وإذا لم توجد أي صورة، عندها فقط تظهر الصورة الافتراضية.
الأهم أن الصورة النهائية أصبحت توضع مباشرة في src، بدون الاعتماد على JavaScript حتى تظهر.
تم كذلك الحفاظ على معالجة مسار الصورة وإضافة أبعاد ثابتة للصورة وnative lazy loading.
هذا حل صغير، لكنه مثال جيد على الفرق بين توليد كود يبدو صحيحًا وبين فهم السلوك الموجود بالفعل داخل النظام.
وماذا عن الاختبارات؟
هذه كانت بالنسبة لي واحدة من أهم أجزاء التجربة.
الـAI أضاف Regression Test مخصصًا للمشكلة.
والاختبار لم يفحص Happy Path فقط.
تم اختبار وجود صورة مباشرة للكاتب، ووجود Writer بدون User مرتبط، واستخدام صورة الـUser القديم للكتاب الذين تم ترحيلهم، والصور ذات الـabsolute URLs، والقيم الفارغة، وحالة عدم وجود أي صورة، وحتى المقال الذي لا يوجد له Writer من الأساس.
وفي عملية التحقق النهائية نجحت 23 test بإجمالي 131 assertion في مجموعة الاختبارات المرتبطة بالتغيير.
هنا يصبح وجود الـAI أكثر قيمة.
لأن المطلوب لم يعد:
"اكتب لي Fix."
بل أصبح:
"غيّر السلوك، وأثبت لي آليًا أن الحالات التي تهمنا ما زالت تعمل."
بعد ذلك جاء AI آخر ليراجع AI
لم نرد أن يكون الوكيل الذي كتب الكود هو الحكم الوحيد على جودة ما كتبه.
لذلك لدينا خطوة مراجعة آلية منفصلة.
وكيل المراجعة يفحص الفرق بين الـbranch والـmain ويبحث عن مشكلات مصنفة حسب شدتها، مثل P0 وP1 وP2.
في هذه التجربة انتهت المراجعة بعد الجولة الأولى، ولم تجد Blocking Issues من مستويات P0 أو P1 أو P2.
النظام أعلن بعدها أن الـPull Request جاهز للمراجعة البشرية.
وهذه نقطة مهمة جدًا.
الهدف في الوقت الحالي ليس إزالة الإنسان من العملية بأي ثمن.
الهدف هو أن يصل التغيير إلى الإنسان بعد أن تكون الأعمال الميكانيكية المتكررة قد تمت بالفعل.
بدل أن يبدأ المهندس من Issue فارغة، يبدأ من PR يحتوي على Implementation واختبارات ونتيجة CI ومراجعة أولية.
لكن التجربة لم تكن مثالية
وهذا هو الجزء الذي يجعلها بالنسبة لي أكثر فائدة من Demo مصطنعة.
الجزء الأصعب لم يكن إصلاح صورة الكاتب.
كان البيئة المحيطة بالـAI.
واجهتنا أثناء بناء الـworkflow مشاكل مرتبطة ببيئة التنفيذ والاختبارات واستقرار الـCI.
المفارقة هنا مهمة.
الـAI يمكن أن يفهم bug ويعدل الكود بسرعة، لكن لو كانت بيئة الـCI غير مستقرة أو الـrepository نفسه لا يملك قواعد واضحة، لن تحصل على Software Engineering مستقلة.
ستحصل فقط على Agent سريع يصطدم بالمشاكل أسرع.
لذلك بدأت أقتنع أن مستقبل AI Coding لا يعتمد فقط على أن تصبح النماذج أذكى.
يعتمد بالقدر نفسه على هندسة البيئة التي تعمل داخلها هذه النماذج.
Repository واضح، اختبارات موثوقة، Coding conventions، CI قابل للتكرار، تعريف واضح لـDone، وسياسات تحدد ما يستطيع الـAgent تغييره وما لا يستطيع تغييره.
كلما كانت هذه الأشياء أفضل، زادت استقلالية الـAI.
هل نجحت التجربة؟
في هذه الحالة: نعم.
بدأنا بمشكلة حقيقية في Production.
تحولت المشكلة إلى Issue.
تم تنفيذ التعديل في Branch منفصل وإنشاء Pull Request.
أضيفت Regression Tests.
مرت Quality Gates بنجاح.
تم إجراء مراجعة آلية مستقلة ولم تظهر مشكلات Blocking.
وفي النهاية تم Merge للـPull Request وإغلاق الـIssue.
هذا أقرب كثيرًا لما أبحث عنه من استخدام الذكاء الاصطناعي في تطوير البرمجيات من مجرد فتح ChatGPT وطلب function جديدة.
لكن لا أعتبر أننا وصلنا بعد إلى:
Issue → AI → Production بدون بشر.
الأقرب حاليًا هو:
Issue → AI implementation → Tests → AI review → Human approval → Merge.
وهذا في حد ذاته تغيير كبير جدًا في طريقة العمل.
أين يظل دور المهندس؟
كلما استخدمت الـAI بهذه الطريقة، أصبح واضحًا أن دور المهندس لا يختفي، لكنه يتحرك إلى مستوى أعلى.
القيمة تصبح أقل في كتابة كل سطر يدويًا، وأكثر في تعريف المشكلة بصورة صحيحة، وتصميم الـarchitecture، ووضع القيود، وبناء الاختبارات، وتحديد معايير الجودة، ومراجعة القرارات التي قد تؤثر في أجزاء أخرى من النظام.
المشكلة الخطيرة ليست أن يكتب الـAI كودًا سيئًا.
المشكلة الأخطر أن تعطيه بيئة لا تستطيع اكتشاف أن الكود سيئ.
لهذا السبب أعتقد أن الشركات التي تريد الاستفادة الحقيقية من AI Coding يجب ألا تبدأ بسؤال:
ما أفضل Model للبرمجة؟
ربما السؤال الأفضل هو:
هل مشروعنا نفسه جاهز لأن يعمل عليه Agent بدون أن نمسك بيده في كل خطوة؟
هذه مجرد البداية
التجربة السابقة كانت Bug صغيرة نسبيًا، وهذا مقصود.
قبل أن نعطي Agent مهمة Architecture كبيرة أو Feature تمتد على أجزاء متعددة من النظام، نحتاج أن نعرف أين تنكسر الدورة.
الخطوة القادمة بالنسبة لنا ليست جعل الـAI يكتب المزيد من الكود فقط.
نريد أن نرى إلى أي مدى يمكن توسيع هذه الدورة لتصبح:
Requirement → Issue → Implementation → Tests → Review → Fixes → Merge
مع تدخل بشري أقل، لكن بدون التضحية بجودة البرمجيات.
وهنا تحديدًا تصبح المسألة أكثر إثارة للاهتمام.
لأننا لم نعد نتحدث عن AI يساعد Developer على كتابة الكود.
نحن نقترب تدريجيًا من بناء Software Development Workflow يعمل بالذكاء الاصطناعي، والإنسان يديره بدلًا من أن ينفذ كل خطوة داخله.
وهذا ما سنواصل اختباره عمليًا في مشاكس.
