-->

يوم كامل من ضغط Enter فقط

كتب أحد المطورين هذا: “عمري 33 عامًا وأظن أن Claude Code يُذيب دماغي. طوال ستة أشهر متواصلة كنت أفتح خمس أو ست نوافذ طرفية في آن واحد، أنتظر الردود لأضغط Enter في 90% من الوقت. هذا هو العمل كله الآن. وهو يفعل بي شيئًا ما.” ثم أقرّ بأن هذه قد تكون مشكلة في طريقة اعتماده على الأداة لا في الأداة نفسها، لكنه أصرّ على أن الأثر حقيقي على أي حال.

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

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

العمل الجديد المسمى Multi-Clauding

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

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

ما هو حقًا إحساس ذوبان الدماغ

“ذوبان الدماغ” يبدو استعارة مبالَغًا فيها، لكن بداخله تتراكب عدة ظواهر ملموسة رصدها علم الإدراك منذ زمن.

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

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

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

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

flowchart TB human["الإنسان: انتباه واحد فقط"] --> T1["نافذة 1
بانتظار الرد"] human --> T2["نافذة 2
بانتظار الرد"] human --> T3["نافذة 3
بانتظار الرد"] human --> T4["نافذة 4
بانتظار الرد"] T1 -.Enter.-> approve["اعتماد شكلي
90% دون مراجعة"] T2 -.Enter.-> approve T3 -.Enter.-> approve T4 -.Enter.-> approve approve --> cost["بقايا الانتباه
انهيار التدفق
الإشراف السلبي
فقدان المهارة"]

من مراقب إلى منسّق

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

السؤال الجوهري هو: لماذا يجب أن يكون الإنسان مراقبًا مباشرًا لست نوافذ؟ السبب عادةً أن عيني الإنسان وحدهما تستطيعان التأكد من صواب أو خطأ مخرَج الوكيل. وبما أن مسؤولية التحقق معلّقة كليًا على عيني الإنسان، فلا خيار أمامه سوى الجلوس بجانب كل نافذة. الإصبع الذي يضغط Enter ينوب في الحقيقة عن مُحقِّق. وذلك التحقق لا بد أن يكون متهاونًا.

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

flowchart TB design["الإنسان: التصميم والحكم"] --> orch["المنسّق"] orch --> A1["وكيل 1
صندوق رمل معزول"] orch --> A2["وكيل 2
صندوق رمل معزول"] orch --> A3["وكيل 3
صندوق رمل معزول"] A1 --> gate{"بوابة التحقق
اختبارات وسياسة وتدقيق"} A2 --> gate A3 --> gate gate -.ما يجتاز فقط.-> design

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

دلالات لمنتجات ThakiCloud

تلتقي هذه الرؤية بفلسفة تصميم Paxis التي نبنيها بدقة. Paxis هو مستوى تحكم Agent-Native Cloud يعمل فوق ai-platform الخاصة بـ ThakiCloud، ويعامل المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. هنا لا تكون الوكلاء المتوازية شيئًا يجلس الإنسان بجانبه ويراقبه عند كل نافذة، بل وحدات تنفيذ ذاتية يفوّضها منسّق وترشّحها بوابة.

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

يُضاف إلى هذا منظور البنية التحتية لـ ai-platform. الوكلاء المفوَّضون بهذه الطريقة يُجدوَلون على موارد GPU التي يديرها K8s و Kueue، ويُعزَلون بنظام متعدد المستأجرين. البنية التحتية تحمل إنتاجية التنفيذ الذاتي، وبوابات التحقق تحمي الجودة، والإنسان يجمع انتباهه على أكثر الأعمال إنسانية: التصميم والحكم. التنفيذ الذاتي منخفض التكلفة يخلق اقتصاديات الوكلاء، وتلك الاقتصاديات بدورها تحرر الناس من المراقبة المتكررة. مشكلة التكلفة الإدراكية للبرمجة الموازية بالذكاء الاصطناعي هي في النهاية مشكلة تحلّها بنية منصة تسحب الإنسان من عبء المعالجة الموازية.

الحدود والاعتراضات

لهذه القصة اعتراضات يجب ذكرها بأمانة.

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

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

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

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

المصادر

참고