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

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

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

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

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

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

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

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

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

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

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

كل شيء قد تعطل

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

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

لا نرى الوضع الحقيقي داخل الشركات، لكن في بعض الأحيان تتسرب بعض المعلومات، مثل الشائعات حول “تعطل AWS بسبب الذكاء الاصطناعي”. قامت Amazon Web Services بسرعة بـ “تصحيح” هذا البيان، لكن تلا ذلك مباشرةً إطلاق خطة إعادة هيكلة داخلية لمدة 90 يومًا.

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

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

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

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

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

أنت تبني طبقة تنسيق، لتوجيه جيش من الوكلاء الآليين. لقد قمت بتثبيت Beads، لكنك لا تعرف في الأساس أنها تشبه “برمجيات خبيثة” غير قابلة للإزالة. مجرد لأن الإنترنت يقول “الجميع يفعل ذلك”. إذا لم تفعل ذلك، فسوف “تفشل” (ngmi).

أنت تستنزف نفسك في حلقة “التكرار الذاتي”.

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

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

“التوزيع”، “التفكيك”، “الأنظمة الذاتية”، “المصانع المظلمة”، “حل مشاكل البرمجيات في ستة أشهر”، “خدمات SaaS ماتت، جدتي استخدمت Claw لبناء Shopify”…

تبدو هذه السرديات رائعة.

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

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

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

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

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

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

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

الفرق الأكثر أهمية هو: البشر هم الاختناق، بينما الوكلاء ليسوا كذلك.

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

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

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

في هذه اللحظة، تدرك أنك لم تعد تثق في هذا الكود.

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

مبروك، لقد وضعت نفسك (وشركتك) في مأزق كبير.

بائع التعقيد

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

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

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

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

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

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

معدل استرجاع بحث الوكالات منخفض جدًا

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

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

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

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

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

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

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

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

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

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

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

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

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

لكنني أريد أن أؤكد: حقًا، يجب أن نتباطأ قليلاً.

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

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

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

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

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

كل هذا يتطلب الانضباط. كل هذا يحتاج إلى البشر.

[رابط النص الأصلي]

انقر لمعرفة المزيد حول الوظائف المتاحة في BlockBeats

مرحبًا بك في الانضمام إلى مجتمع BlockBeats الرسمي:

مجموعة الاشتراك على تيليجرام: https://t.me/theblockbeats

مجموعة النقاش على تيليجرام: https://t.me/BlockBeats_App

الحساب الرسمي على تويتر: https://twitter.com/BlockBeatsAsia