تمهل، هذا هو الحل لعصر الوكيل

العنوان الأصلي: أفكار حول التباطؤ الشديد
المؤلف الأصلي: ماريو زيكنر
ترجمة: بيغي، بلوك بيتس

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

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

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

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

فيما يلي النص الأصلي:

إن التعبير على وجه السلحفاة هو الطريقة التي أنظر بها إلى هذه الصناعة

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

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

خلال موسم عطلة عيد الميلاد، أصدرت شركتا Anthropic و OpenAI أيضًا بعض "الرصيد المجاني"، مما جذب الناس مثل ماكينة القمار. بالنسبة للكثيرين، كانت هذه أول تجربة حقيقية لهم لسحر "برمجة الوكلاء". تتزايد المشاركة.

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

كل شيء ينهار

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

أعترف بأن هذا الوضع كان موجوداً قبل ظهور العميل. لكن المشكلة تتفاقم بشكل واضح الآن.

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

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

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

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

لماذا لا ينبغي لنا استخدام الوكيل بهذه الطريقة

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

أنت تقوم ببناء طبقة هيكلية للتحكم في جيش من العملاء الآليين. لقد قمت بتثبيت برنامج Beads، لكنك لا تدرك تمامًا أنه في الأساس "برنامج ضار" لا يمكن إزالته. أنت تفعل ذلك فقط لأن المصادر الإلكترونية تقول "الجميع يفعل ذلك". إذا لم تفعل ذلك بهذه الطريقة، فأنت "ngmi" (لن تنجح).

أنت تستهلك نفسك باستمرار في "حلقة تشبه حلقة الدمى المتداخلة".

انظر - لقد أنشأت شركة أنثروبيك مترجم لغة C باستخدام مجموعة من الوكلاء، على الرغم من أنه لا يزال يعاني من مشاكل الآن، إلا أن نموذج الجيل التالي سيكون قادرًا بالتأكيد على إصلاحها، أليس كذلك؟

انظر الآن - لقد قامت شركة Cursor ببناء متصفح باستخدام مجموعة كبيرة من الوكلاء، على الرغم من أنه غير قابل للاستخدام بشكل أساسي الآن ولا يزال يحتاج إلى تدخل يدوي من حين لآخر، إلا أن نموذج الجيل التالي سيكون بالتأكيد قادرًا على التعامل معه، أليس كذلك؟

"موزع"، "فرق تسد"، "أنظمة مستقلة"، "مصنع الضوء الأسود"، "ستة أشهر لحل مشكلة برمجية"، "البرمجيات كخدمة ماتت، جدتي أنشأت للتو متجرًا على Shopify باستخدام Claw"...

تبدو هذه الروايات مثيرة.

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

ومع ذلك، على الأقل في أوساط المطورين التي أعمل بها، لم أرَ حتى الآن حالة فعالة حقًا لهذه الطريقة. بالطبع، ربما نكون جميعاً عديمي الخبرة.

تراكم الأخطاء في غياب التعلم، وعدم وجود اختناقات، وتأخر الانفجارات

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

لكن "الآلات" ليست بشرًا. بعد تكرار نفس الخطأ عدة مرات، يتعلم البشر عادةً عدم تكراره - إما أن يتم توبيخهم من قبل شخص ما، أو أنهم يتغيرون في عملية تعلم حقيقية.

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

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

الفرق الرئيسي هو التالي: البشر هم عنق الزجاجة؛ أما العملاء فليسوا كذلك.

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

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

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

عند هذه النقطة تدرك ما يلي: لم يعد بإمكانك الوثوق بقاعدة البيانات هذه.

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

تهانينا، لقد حفرت لنفسك (ولشركتك) حفرة.

تاجر التعقيد

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

ما ينتهي بك الأمر إليه هو نظام معقد للغاية، يمزج بين العديد من التقليدات السيئة لـ "أفضل الممارسات الصناعية"، ولم تفرض أي قيود قبل أن تخرج المشاكل عن السيطرة.

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

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

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

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

معدل استرجاع البحث الآلي منخفض

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

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

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

تعتمد كيفية قيام الوكيل بذلك على الأدوات التي تزوده بها: يمكن أن يكون Bash + ripgrep، أو يمكن أن يكون فهرسًا للرموز قابلًا للبحث، أو خدمة LSP، أو قاعدة بيانات متجهة...

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

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

فكيف يمكننا تجنب كل هذا؟

كيف ينبغي لنا التعاون مع الوكلاء (على الأقل في الوقت الحالي)

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

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

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

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

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

لكن ما أريد التأكيد عليه حقاً هو: خفف السرعة قليلاً.

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

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

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

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

عندما يتعطل النظام، يمكنك أن تبذل جهدًا لإصلاحه؛ وعندما يكون التصميم معيبًا منذ البداية، يمكنك فهم المشكلة وإعادة هيكلته بشكل أفضل. في الواقع، ليس من المهم وجود وكيل أم لا.

كل هذا يتطلب انضباطاً. كل هذا لا ينفصل عن البشر.

[ المقال الأصلي ]