كآبة مبرمج 'فايبر كود' في عصر الذكاء الاصطناعي

عنوان فرعي: كآبة برمجة 'فايبر كود' كمتخصص في علوم الحاسوب

اليوم سألت كلود كود: هل طريقتي صحيحة؟

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

في هذه الأيام، لا أكتب الكود بنفسي. أنا أوصل المتطلبات وأشرف على التقدم.

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

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

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

اليوم، استمعت إلى عرض تقديمي من السيد غوس كيم، مطور Moai SDK. تلقيت المشروع وطلبت من الذكاء الاصطناعي تحليله مرة أخرى، ووجدنا نقاط تحسين للمشروع. #87issue ما وجدناه هذه المرة هو أنهم كانوا يستخدمون EARS، وهو معيار متطلبات الفضاء الجوي من Rolls-Royce (IEEE RE'09)، والذي اعتمدته Amazon في تطويرها الأصيل للذكاء الاصطناعي (AI-native) في عام 2025. يقال إنها طريقة لمنع الذكاء الاصطناعي من تفسير معيار "الإنجاز" بشكل مختلف لكل مشكلة، وذلك باستخدام قواعد نحوية منظمة.

من خلال تكرار هذه الإجراءات، أواصل تحسين عملية التطوير القائمة على الذكاء الاصطناعي للمشروع. لقد قمت بتحليل وتحسين jikime-adk، وأوراق arXiv، وDueling LLMs من Google Cloud، وSpec-Driven Development من Thoughtworks. بالطبع، هذا ليس لأنني أعرف كل هذه الأمور بنفسي، بل لأنها أيضًا تحليلات قام بها كلود.

لقد قمت بتحليل open-swe من LangChain وتطبيق نمط ensure_no_empty_msg، وهو نمط يمنع الذكاء الاصطناعي من تقديم مراجعات بردود فارغة. وفي jikime-adk، طبقت نمطًا لتسجيل القرارات التي اتخذها الذكاء الاصطناعي والفخاخ التي اكتشفها، وذلك بإضافة قسم ## AI Context في رسائل الكوميت (commit messages) بحيث يمكن لسجل Git أن يكون مصدر استعادة حتى لو انقطع الاتصال.

بشكل عام، كان كل منهم يحل مشاكل متشابهة بشكل مستقل.

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

إن جميع منهجيات هندسة البرمجيات التي استخدمناها هي نتاج عقود من الفشل المتراكم. ظهرت Agile لأن Waterfall استمر في الفشل، وظهر TDD لأن التطوير بدون اختبارات كان يؤدي إلى مشاكل متكررة، لذا فإن لها أساسًا منطقيًا.

لكن ما قمت بجمعه الآن لم يتم تصميمه ليعمل معًا. معيار الفضاء الجوي ومطور مستقل كوري ووكيل LangChain موجودون في نظام واحد.

هذا القلق دفعني إلى البحث في الدراسات الخارجية. تزعم ورقة V-Bounce (arXiv 2408.03416) أن دور الإنسان في عصر الذكاء الاصطناعي يتغير من المنفذ إلى المدقق. هذا صحيح، لكنه مجرد نظرية ولم أجد تطبيقًا عمليًا لها. Spec-Driven Development من Thoughtworks يعتمد على أدوات معينة. وفي Anthropic، يزعمون أن 90% من كود Claude Code يكتبه Claude Code نفسه، لكنهم لم يكشفوا عن المنهجية.

في النهاية، كل من يطور بجدية باستخدام الذكاء الاصطناعي الآن يقوم بإنشاء طريقته الخاصة. لا توجد معايير.

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

الآن، أنا فقط أمسك باللجام بإحكام وأمضي قدمًا. لا أعرف إلى أين أذهب بعد، لكن آمل ألا أكون أعمى. أنا أصنع اللجام، وفي الحقيقة، هذه أول مرة أركب فيها حصانًا. يبدو أن هذا هو السرج الذي يمسك بـ 'برمجة فايبر كود'.