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

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

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

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

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

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

The following is the original text:

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

ما يُعرف بـ"ضريبة التنسيق" هو في جوهره الثمن الذي تدفعه عندما تنسى هذا الأمر. والحل الوحيد الحقيقي هو أن تبدأ في تصميم انتباهك بنفس الطريقة التي تُصمم بها أي نظام متزامن.

سابقًا، شاركت في مناقشة دائرة مستديرة في Google I/O مع ريتشارد سيروتير وأجا هامرلي وسييرا جاسبان، حيث تحدثنا عن حالة هندسة البرمجيات الحالية وكيف يمكن أن تتطور في المستقبل. وفي نهاية المناقشة، سألنا ريتشارد: ما الشيء الوحيد الذي يجب على المطورين أن يأخذوه معهم ويغيروه بعد الاستماع؟

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

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

لقد قال ذلك بشكل صحيح تمامًا. أريد تفكيك هذا المفهوم بشكل أكثر شمولاً، لأنه ليس مشكلة انضباط ذاتي، بل مشكلة هندسية.

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

عدم التوازن الذي لم يُؤخذ في الاعتبار من قبل الناس

هناك عدم تناظر مخفي في سير العمل الخاص بالوكيل.

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

هذا الشخص أنت. وأنت واحد فقط.

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

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

أنت ذلك المورد أحادي الخيط

إذا كنت قد كتبت كودًا متزامنًا من قبل، فأنت بالفعل تمتلك الحدس لفهم هذه المسألة. فقط كنت تستخدم هذا الحدس في المكان الخطأ في الماضي.

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

أنت GIL الخاص بوكيل الذكاء الاصطناعي الخاص بك.

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

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

في تطوير الوكلاء، فإن هذا الجزء التسلسلي هو الحكم.

تشغيل 8 عوامل لن يسرّع وقت تقييمك. إنه سيجعل قائمة الانتظار الخاصة بالمهام التي تحتاج إلى معالجتك أطول فقط.

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

يُحسّن العامل المُضاف الجزء الذي لم يكن قيدًا أصلًا. القيد الحقيقي هو مرحلة المراجعة، ودفق النظام الكامل يساوي بالضبط دفق هذه المرحلة.

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

التمسك لا يحل الحدود الهيكلية

في تلك المائدة المستديرة، قلتُ جملةً: لم أشعر قطّ بأن أدواتي فعّالة بهذا القدر كما أشعر الآن، لكنني أيضًا لم أكن متعبًا بهذا القدر قطّ.

كلا الشعورين حقيقيان تمامًا، وينبعان من نفس السبب.

هذا الإرهاق له مصدر محدد جدًا: إنه الشعور الناتج عن ضغط معالج تسلسلي باستمرار إلى 100% دون أي هامش.

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

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

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

لا يمكنك حل قيد هيكلية بـ"الجهد الأكبر". هذه الضريبة ستُدفع دائمًا.

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

إما أن تدفع هذه الضريبة طواعية، أو تتركها تدمر ببطء فهمك لsistemasك في الظلام.

صمم انتباهك كما تصمم نظامًا

لذلك، يجب أن تعامل انتباهك كمورد متسلسل نادر.

لن تُصمّم نظامًا موزّعًا دون مراعاة أي عوائق أداء. لذا، امنح عقلك نفس الاحترام.

إليك بعض الطرق التي عملت حقًا من أجلي:

ستستخدم نظام التزامن الجيد آلية ضغط عكسي لتجنب التوسع اللانهائي للطابور. يجب على المنتجين تقليل سرعتهم لتناسب قدرة المستهلكين.

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

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

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

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

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

أكبر خطأ هو محاولة موازية المهام من الفئة الثانية أيضًا. معالجة متوازية لمهام معقدة متعددة لا تزيد من إنتاجيتك، بل تجعل القفل يُ争夺 باستمرار، مما يؤدي في النهاية إلى تدهور جميع النتائج.

كل تبديل سياق يكلفك تكلفة عالية. الجلوس مرة واحدة لمراجعة نتائج 4 وكلاء أرخص بكثير من مراجعة واحد، ثم القيام بأمور أخرى، ثم إعادة بدء العملية لمراجعة آخر.

اعطِ العامل حبلًا أطول. اترك العمل يتراكم قليلاً، ثم عالجه كدفعة واحدة.

لا تُضِع دماغك في أشياء يمكن للآلة التحقق منها بنفسها. اجعل العامل يكتب الاختبارات التي تمر، أو يولد لقطات شاشة.

دعها تثبت بنفسها الجزء الممل لكنه قابل للتحقق بنسبة 80%. بهذه الطريقة، سيحتاج انتباهك النادر فقط إلى التركيز على الـ 20% التي تتطلب حكمًا بشريًا.

الحاجز يتطلب أفضل وقت لديك، وليس الأوقات المتبقيّة المجزأة بين فحوصات الوكيل.

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

الترتيب ليس عملاً حقيقيًا. إنه مجرد تكلفة ناتجة عن العمل.

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

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

الانشغال لا يعني الإنتاجية العالية

This is very important because this failure mode is almost invisible to you personally.

ستعطيك 20 عميلًا قيد التشغيل شعورًا بـ "الإنتاجية المفرطة". لوحة القيادة ممتلئة، وكل شيء يتحرك. لكن هذا الشعور انفصل الآن عن دمج كود عالي الجودة فعليًا في الفرع الرئيسي.

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

ذكرت سييرا بحث مارغريت-آن ستوري عن الديون. تحدثنا عن الديون التقنية وعن الديون المعرفية.

عدم دفع ضريبة الترتيب سيؤدي إلى تراكم كلا الديونين معًا.

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

إذًا، الاستنتاج الحقيقي هو: تشغيل العامل ليس مهارة. أي شخص يمكنه تشغيل 20.

القدرة الحقيقية هي تصميم النظام حول المورد التسلسلي الذي لا يمكن نسخه أو تشغيله بالتوازي.

هذا المورد هو انتباهك.

صممه كما تصمم أي مكون حاسم يعتمد عليه في بيئة إنتاجية.