إعادة بناء Manus باستخدام Manus: ما الذي تغير، وما الذي تعطل، وكيف نعمل الآن
بقلم تاو تشانغ، الشريك المؤسس ومدير المنتجات، Manus
في أواخر سبتمبر، خلال المرحلة النهائية من العمل على Manus 2.0، أرسلت إلى أحد مهندسينا بعض طلبات الميزات وتقارير الأخطاء عبر Slack. لاحقاً ذهبت لأتفقد كيف يسير عمله. كانت شاشته تعرض صفاً من جلسات الـ Agent المفتوحة، بعضها في Manus وبعضها في Codex. نقرت على إحداها. كان الـ Prompt هو رسالتي على Slack، ملصوقة حرفياً كلمة بكلمة.
قبل عام، كان سيقرأ رسالتي، ويفهم ما أعنيه، ثم يكتب الكود. أما الآن فإن الـ Agent يقرأ الطلب، ويعثر على الكود المعني، ويقترح تغييراً. مهمة المهندس هي توجيه العمل والتحقق منه وتحمل مسؤولية النتيجة. في معظم الوقت يكون الطلب قيد التنفيذ، لا بانتظاره. اليوم، من الشائع هنا أن يكون لدى مهندس واحد ما بين 10 و20 طلباً تسير في الوقت ذاته.
أنا فخور بمدى سرعة تكيف فريقنا. وفي الوقت نفسه أشعر بشيء من القلق. هل هذه الوتيرة صحيحة؟ وما الذي لم ننتبه إليه بعد؟
نحن في Manus نبني Agent، لذا نلتزم بقاعدتين. نستخدم منتجنا في عمل حقيقي. ونواصل البحث عن المواضع التي يتوقف فيها AI عن العمل.
أودّ أن أوثّق ما يحدث داخل شركة حين يعمل الناس والـ Agent جنباً إلى جنب بشكل افتراضي. تتناول هذه التدوينة ثلاثة فرق — الهندسة والمنتج والتسويق — وتشمل ما لم ينجح أيضاً. إنها تقرير عن تجربة قيد التنفيذ، لا تعريف لـ"مؤسسة قائمة على AI".
ما تعلمناه حتى الآن:
•لا يوجد حل وسط. إضافة AI إلى طرق العمل القديمة أضافت أحياناً ضوضاء فقط. ولم تتغير الأمور إلا حين أُغلقت الحلقة.
•يحتاج الـ Agent إلى الصورة الكاملة. السياق الأفضل أفادنا أكثر من الـ Prompt الأفضل.
•الثقة تأتي من الاختبارات والسياق، لا من جودة النموذج وحدها.
•الاستقلالية تحتاج إلى خط نهاية. لا يمكن للـ Agent أن يعمل بمفرده إلا حين يمكن التحقق من النجاح. وفيما عدا ذلك، يقرر الإنسان.
•عنق الزجاجة يتنقل. حين تسارعت الهندسة، أصبح تحديد ما يجب بناؤه هو القيد.
•دور الأشخاص لم يتقلص. بل أصبح أكثر تركيزاً على الأمور ذات التأثير الأعلى.
1. لا يوجد حل وسط
قبل عام 2026، كنا نفعل ما تفعله معظم الشركات: أضفنا AI إلى طريقة عملنا القائمة. ما يعني أن فريق الدعم كان يُبرز المشكلات بملخص من AI، وكان المهندسون يستخدمون مساعدات برمجية، وتنشر الروبوتات تحليلات في القنوات. كل عنصر كان مفيداً بذاته، لكن قليلة هي العناصر التي كانت مرتبطة ببعضها. وإلى أن أُغلقت الحلقة فعلياً، كنا ببساطة نعمل بالطريقة القديمة ذاتها مع كثير من AI يتحدث بعضه فوق بعض.
هناك جملة نعود إليها كثيراً: هندسة البرمجيات هي البرمجة متكاملة عبر الزمن. كتابة الكود سهلة القياس؛ أما الحفاظ على صحة منتج معقد لسنوات فليس كذلك. نسبة عالية من الكود المكتوب بواسطة AI قد تعني تقدماً حقيقياً، وقد تعني تراكم ركام سيضطر أحد ما إلى تنظيفه لاحقاً.
الاختبار الذي نهتم به أصعب من ذلك. Manus منتج معقد ظل يعمل لأكثر من عام. هل يستطيع الاستمرار في التحسن في ظل طرق عمل جديدة دون أن ينهار، مع إنجاز كل شخص لمزيد من العمل؟ حتى الآن الإجابة نعم.
2. امنح الـ Agent الصورة الكاملة
مثل معظم شركات التكنولوجيا، أضعنا معظم الوقت عند نقاط التسليم بين الفرق. كان مهندس الواجهة الأمامية ومهندس الواجهة الخلفية يفسران الطلب كل على حدة، ويتفقان على واجهة، ثم يقضيان أياماً في إصلاح التناقضات. نادراً ما يفهم شخصان المتطلب بالطريقة نفسها.
إذا كان AI قادراً على كتابة الكود عبر كامل الـ Stack، فهل يمكن لشخص واحد أن يتولى الطلب من بدايته إلى نهايته؟ العقبة كانت السياق. كان الكود لدينا موزعاً على مستودعات منفصلة، لذا لم يكن بإمكان أي Agent أن يرى النظام بأكمله دفعة واحدة.
إجابتنا على ذلك بدأت بتجربة داخلية. أردنا أن نرى إلى أي مدى يمكن أن يذهب AI في بناء منتج بأقل قدر ممكن من المدخلات البشرية وبدون كتابة أي كود يدويًا تقريبًا. المنهج الذي طورناه خلال هذه الرحلة أصبح الأداة الداخلية التي نسميها الآن Manus-mono، أو Mono.
Mono لا يدمج مستودعاتنا. إنه نقطة دخول واحدة بالإضافة إلى دليل مكتوب لـ Agent: ماذا يفعل كل مستودع، وكيف تتكامل مع بعضها، وكيف نعمل. يسحب Agent ما يحتاجه. كما نحتفظ بمكتبة من سجلات قرارات العمارة، بحيث تبدأ كل جلسة Agent بالتفكير وراء القرارات السابقة، وليس فقط الكود. عندما يعمل أي شخص مع Agent، يكون لدى هذا Agent سياق كل من سبقه.
نما Mono على مراحل، وكل مرحلة أصلحت الاختناق الذي كشفته المرحلة السابقة:
1.رؤية النظام بأكمله. أضفنا سياق العمل الذي لا يحتوي عليه أي مستودع منفرد، واستخدمنا Git worktrees للعمل المتوازي.
2.التحقق محليًا. كان الدفع إلى بيئة الاختبار يستغرق من 5 إلى 10 دقائق. الآن تعمل حزمة Manus الكاملة على جهاز محمول، وتستغرق الفحوصات ثوانٍ.
3.تصحيح مشكلات الإنتاج. من خلال صلاحيات محدودة النطاق، يمكن لـ Mono قراءة السجلات والتكوين وتقارير الأخطاء التي يحتاجها لتشخيص الأخطاء في الإنتاج.
4.تشغيل الإصدارات من البداية إلى النهاية. يتولى Mono الآن خطوات الإصدار التي كان العمل يتوقف عندها. لا يزال الأشخاص هم من يتخذون قرارات الموافقة.
5.الاختبار من البداية إلى النهاية. عندما أصبح التحقق هو الجزء البطيء، بدأ Mono بتشغيل تدفقات مستخدم حقيقية بحسابات اختبار، في المتصفح وفي محاكي الهاتف المحمول.
(كيف يعمل Mono وكيف تطور. صُنع بواسطة زميل في الفريق مع Manus.)
يسأل الناس أحيانًا ما إذا كان Mono عبارة عن ويكي للكود. التوثيق جزء منه، لكن الباقي هو كل ما يحيط بالكود: كيف نختبر، وكيف نُصدر، وما نقرره ولماذا، وما الذي يُسمح لـ Agent بلمسه وما لا يُسمح له.
بمرور الوقت، أصبح Mono قاعدة معرفة مشتركة تتحسن كلما أضاف إليها الناس. على سبيل المثال، سئم مهندس العمليات لدينا من أن يُطلب منه المساعدة في الإصدارات، فكتب عملية الإصدار في Mono. الآن يمكن لأي شخص تشغيل إصدار، ويمكن لـ Agent ذلك أيضًا، لكن الموافقة لا تزال بيد الأشخاص الذين لديهم حقوق الإصدار. أحب كيف يعمل الفريق: شخص واحد أصلح إحباطه الخاص، مما أدى إلى أن تصبح الشركة بأكملها أسرع قليلاً.
يفترض الفريق الآن أن شخصًا واحدًا يمكنه إطلاق طلب على كل منصة. ظل فريق الهاتف المحمول لدينا مكونًا من سبعة أشخاص طوال هذا الوقت. يحافظون على أربعة تطبيقات عبر منتجين ويواكبون الويب.
انتشر Mono عبر الشركة دون أي تفويض من أعلى إلى أسفل. أعتقد أن الثقافة تفسر ذلك بقدر ما تفسره الأداة. اختبار حدود AI هو جزء من سبب وجودنا، ومنظمتنا مسطحة. الأداة تصل فقط إلى الحد الذي تسمح به المنظمة.
3. إغلاق الحلقة: من تقرير خطأ المستخدم إلى إصلاح تم التحقق منه
سمح Mono لأي شخص بالعمل على أي جزء من المنتج. كان ذلك نصف الأمر. النصف الآخر كان السماح لـ Agents بإيجاد المشكلات بأنفسهم.
في معظم شركات الإنترنت، يمر تقرير خطأ المستخدم عبر الدعم والمنتج والفرز قبل أن يصل إلى مهندس يمكنه إصلاحه.
بالنسبة لنا، يقوم Agent داخلي الآن بالتحقيق في التقرير أولاً ويتتبع المشكلة إلى التغيير الذي تسبب فيها. ثم ينشر في Slack ويشير إلى المهندس الذي يملك هذا التغيير. يقرر المهندس ما إذا كان من مسؤوليته إصلاحه ويسلمه إلى Agent الخاص به. ويقوم Agent منفصل بالتحقق من الإصلاح عن طريق تشغيل الاختبارات والتدفقات المهمة.
ثلاثة Agents، وثلاثة أدوار: واحد يفرز، وواحد يقوم بالعمل، وواحد يتحقق منه. الشخص في المنتصف يتخذ القرارات. حصة متزايدة من عملنا الهندسي تبدأ الآن بهذه الطريقة، حيث يجلب Agent مشكلة إلى شخص.
هذه الحلقة لها حدود واضحة. Agent الذي يقرأ تقارير المستخدمين لا يمكنه تغيير الكود. يمكنه فقط التحقيق وإبلاغنا. التغييرات تأتي من Agent الخاص بالمهندس، بعد أن يقرر المهندس. لا يتم إطلاق أي شيء دون موافقة من شخص لديه حقوق الإصدار.
4. كيف تعلمنا أن نثق بالكود الذي يكتبه الـ Agent
لفترة طويلة، كان كل تغيير يُدمج في الفرع الرئيسي يحتاج إلى موافقة أحد مهندسَين كبيرَين. لم نكن نثق بالـ AI بما يكفي لتخطّي تلك الخطوة. ومع ازدياد الكود الذي ينتجه الـ Agents، أصبحت خطوة المراجعة هذه عنق الزجاجة.
من حيث القدرة البرمجية الصرفة، كانت النماذج قوية بالفعل. أدركنا أن الفرق يعود إلى أمرين. أولاً، يعرف الناس كيف يختبرون عملهم. ثانياً، شارك الناس في النقاشات في المراحل السابقة واللاحقة، لذا يعرفون ما يعنيه "الصواب" بالنسبة للعمل. الكود الصحيح لا يعني بالضرورة المنتج الصحيح.
عالجنا كلا الأمرين:
•السماح للـ Agents بالانضمام إلى النقاش. الآن، يجلس Agent كل مهندس في محادثات Slack التي تمت إضافته إليها، ويتابع السياق. وعندما يقول أحدهم أخيراً "ابدأ"، يكون الـ Agent قد عرف بالفعل ما قرره الفريق ولماذا.
•السماح للـ Agents بالاختبار من البداية إلى النهاية. بالعمل مع فريق الـ backend لدينا، منحنا الـ Agents القدرة على تشغيل تدفقات حقيقية واختبارات انحدار في Manus بعد كل تغيير. ومع نمو تغطية الاختبارات، نمت ثقتنا معها.
اليوم، يمر كل تغيير عبر ذلك التحقق وعبر bot لمراجعة الكود يعمل بأقوى نموذج متاح، مع قواعد إضافية للمجالات الحساسة مثل المدفوعات. استبدل الـ bot الطابور، وليس القرار البشري. يمكن لـ Agent فتح pull request، لكنه لا يستطيع الدمج في الفرع الرئيسي دون موافقة صريحة من شخص. لا يزال الناس هم من يقررون ما الذي يُبنى ومن يستطيع الإصدار.
5. الاستقلالية تحتاج إلى هدف نهائي
للثقة حدود، واكتشفنا ذلك بالطريقة الصعبة.
في مرحلة ما، كان الجميع متحمسين لحلقات Agent المستقلة بالكامل، فجربنا واحدة. جمع Agent الملاحظات من قنوات الملاحظات الداخلية لدينا وبدأ مشروعاً لكل عنصر. تركه أحد زملائنا يعمل طوال عطلة نهاية الأسبوع. وفي صباح الاثنين، كان أكثر من 200 عنصر ينتظرون قراره.
لماذا لا ندع الـ Agent يتخذ تلك القرارات أيضاً؟ تعمل الحلقات المستقلة عندما يستطيع النظام التحقق مما إذا كان الهدف قد تحقق. تنجح الاختبارات أو تفشل؛ تُحمَّل الصفحة أو لا تُحمَّل. معظم العمل الحقيقي لا يحتوي على مثل هذا التحقق. يجب على شخص أن يحكم على ما إذا كان العمل قد اكتمل، وما إذا كان يستحق القيام به أصلاً.
خرجنا بدرسين من تلك العطلة. أولاً، لا يستطيع الناس اتخاذ القرارات بالسرعة التي تخلقها حلقة غير مُتحقَّق منها. ثانياً، إذا لم يقرر أحد ما إذا كان يجب فعل شيء ما، فلن يملك أحد النتيجة. تعمل حلقة إصلاح الأخطاء في القسم 3 لأن الاختبارات تُحدِّد النجاح. قرارات المنتج ليس لها اختبارات، لذا لا يزال كل تغيير في المنتج في Manus يبدأ بشخص يقرر ما إذا كان يستحق القيام به.
6. عندما أصبحت الهندسة أسرع، أصبح المنتج هو عنق الزجاجة
تتضمن عملية المنتج التقليدية العديد من عمليات التسليم، وتنحرف الأولويات قليلاً عند كل منها. ومع جعل الـ Agents البرمجية المهندسين أسرع، ظهرت مشكلة جديدة: لم يكن هناك عدد كافٍ من مديري المنتج لكتابة متطلبات جيدة. ولأول مرة، لم تكن الهندسة هي القيد.
في Manus، كان الحل الأول هو أن نطلب من بضعة مهندسين أن يصبحوا "بُناة" يمتلكون المشكلة من الاكتشاف إلى الإطلاق. قلة قليلة من الناس كانوا يمتلكون الحكم التقني والمنتجي معاً. بعد ذلك، سمحنا لمديري المنتج بتغيير الكود. وتعثر ذلك أيضاً. كانت عمليات التسليم لا تزال موجودة، ودون غريزة المهندس، يمكن لمديري المنتج تغيير النصوص والتفاعلات ولكن ليس المنطق الأساسي.
حلّ Mono كلتا المشكلتين لأنه يحمل القواعد معه:
•أي تغيير يلامس استدعاءات النماذج أو التكلفة يحتاج إلى موافقة المالك قبل كتابة الكود.
•يمر كل تغيير بنفس المراجعة والاختبار كتغيير يُجريه المهندس.
•يستطيع Mono المرور عبر التسجيل والدفع باستخدام حسابات اختبار وتسجيل كل خطوة، بحيث يستطيع مدير المنتج الإشارة إلى اللحظة الدقيقة التي يحدث فيها الخلل.
إليك كيف يبدو ذلك عملياً. طلبت مديرة منتج تعمل على تحويل الكلام إلى نص من Manus قياس أداء أكثر من 10 نماذج، ثم اختارت واحداً. سحبت كود الـ frontend عبر Mono، وبنت عرضاً تجريبياً في نظام التصميم لدينا، وطلبت من Manus عرض كل سيناريو مستخدم كصورة لتراجعها. حولت العرض التجريبي إلى فيديو. كانت الخطة واضحة بما يكفي لدرجة أنها بنت الميزة بنفسها، بما في ذلك واجهة الويب وسطح المكتب.
اتخذ الأشخاص ثلاثة قرارات على طول الطريق. اختارت هي النموذج. راجع فريق المنتج والتصميم العرض التوضيحي. راجع مهندس يملك صلاحيات الإصدار الكود. قبل عام، لم يكن أي من هذا ممكنًا.
نصف هذا بأنه انتقال من كون الإنسان داخل الحلقة إلى كونه على الحلقة. كان الـ AI سابقًا يقوم بـ 70-80% من المهمة ويكمل الأشخاص الباقي. الآن يضع الأشخاص القواعد، ويشرفون على عدة Agents، ويتحققون من الأساليب والنتائج في نقاط رئيسية، ويتدخلون عند الحاجة، ويتحملون مسؤولية النتيجة.
يسلّم بعض مديري المنتجات الآن مقطع فيديو قصيرًا بدلاً من مواصفات مكتوبة أو نماذج أولية. في بضع دقائق، يعرض حالة الاستخدام، وكل شاشة، وما يفعله كل نقر، وكيف تتصرف الحالات الحدية، وكيف يعمل كل شيء تحت السطح. بالنسبة لنا، يتفق التصميم والهندسة وضمان الجودة على ما تعنيه كلمة "منجز" بشكل أسرع، ويشرح مدير المنتج ذلك مرة واحدة.
(فيديو متطلبات المنتج للإدخال الصوتي)
اليوم، يقوم حوالي نصف مديري المنتج لدينا بإطلاق الميزات بأنفسهم، وقد ساهم كل مدير منتج بكتابة الكود. وقد بدأ المصممون أيضًا. كتب أحد مديري المنتج معظم واجهة Manus Studio في Manus 2.0. وكتب آخر محرر الفيديو. وراء كل من هذه الأعمال شخص قضى شهورًا يتجاوز ما كان دوره يغطيه سابقًا. وهذا ما أفتخر به أكثر.
هذا لا يعني أن على الجميع أن يكونوا بُناة. عندما يستطيع أي شخص في الشركة البناء، قد يُطلق الناس أشياء لا ينبغي أن توجد. غالبًا ما يطرح فريق المنتج لدينا سؤالاً واحدًا: "إذا استغرق هذا ثانية واحدة ولم يكلف شيئًا، هل ستطلقه؟" أحيانًا يكون الجواب لا. ما زلنا بحاجة إلى مالكي وحدات يقررون ما يُبنى، وما لا يُبنى، وما يراه المستخدمون في النهاية. ونحتاج أيضًا إلى أشخاص يحافظون على البنية التحتية مثل Mono. عندما يصبح البناء سهلاً، يصبح تحديد ما يجب بناؤه أكثر أهمية.
7. زميل AI داخل سير عمل التسويق
تمر شراكة تسويقية بمراجعة النص، والتسعير، والعقود، والموافقات، والدفع، والإطلاق، ومراجعة النتائج. تعيش هذه الخطوات في البريد الإلكتروني، وأدوات العقود، وأنظمة الموافقة، وجداول البيانات، ومنصات الإعلانات. كان الكثير من العمل سابقًا يتعلق بنقل المعلومات بينها، مما ترك وقتًا قليلاً للعمل الإبداعي الذي يتطلب الحكم.
بدأنا بمشكلة صغيرة واحدة: عندما يُنشر محتوى شريك أو إعلان، كنا غالبًا نسمع بذلك متأخرين. لذا طلبنا من AI كتابة سكريبت يكتشف متى يتم نشر المحتوى. ثم أردنا بيانات الأداء. ثم مراجعة للشراكات السابقة. ثم ربط سير العمل الداخلي بالكامل: عند توقيع عقد أو اعتماد موافقة، يُحدِّث الـ Agent الحالة ويُخطر من يملك الخطوة التالية.
بنى Manus كل هذا داخل موقع داخلي. بالنسبة للأشخاص، هي لوحات معلومات وتقويم. بالنسبة للـ Agent، هي مجموعة من الأدوات. الـ Agent الذي يستخدم تلك الأدوات داخل سير عملنا هو ما نسميه زميل AI. يعمل فقط في القنوات والأنظمة التي ربطه بها الفريق، مع صلاحيات محددة بهذا السير.
إليك ما يفعله:
•يُدير قائمة انتظاره الخاصة. يرسل إليه الكثير من الأشخاص رسائل في وقت واحد، لذا يتحدث مع الجميع في جلسة "مكتب استقبال" واحدة ويوزع المهام على جلسات متوازية. يقرر ما إذا كانت الرسالة ذات صلة به، ثم ما إذا كان سيقاطع العمل الحالي أو ينتظر. اقترح هذه القواعد بنفسه خلال التطوير، وقد راجعناها قبل الاحتفاظ بها.
•يتعلم من السياق المُعاد توجيهه. كان تغيير الاستراتيجية سابقًا يعني اجتماعًا وموجزًا مكتوبًا. الآن يُعيد قائد التسويق لدينا توجيه النقاش ويقول: "تعلم هذا."
•يُبقي الأهداف طويلة الأمد في الأفق. في إحدى المرات، في سلسلة محادثات على Slack كان قد أُضيف إليها، لم يستطع الزملاء تذكّر وضع مشروع ما. فأجاب دون أن يُشار إليه: "B لا يزال في الاختبار. هل ننتظر نتائج A قبل النظر إلى B؟"
•يتحقق من الحقائق مع الفرق الأخرى. بعد أن أطلقنا تجهيز نماذج 3D، سأل فريق المنتج عمّا هو مدعوم. علم أن التجهيز يغطي سبع فئات، بما في ذلك الأسماك والثعابين ورباعيات الأقدام، لذلك ظلت أوصافنا دقيقة.
يُدخله الزملاء الآن في مراجعات النصوص والتسعير، لأنه قرأ سجلات شراكاتنا السابقة. لا يزال الأشخاص هم من يتخذون القرار.
يمكن أيضًا للموقع الداخلي أن يتحسن من مستخدميه، بما في ذلك الـ Agent. عندما يواجه الـ Agent احتكاكًا، يقدّم طلبًا عبر نقطة نهاية للتعليقات. يفتح هذا مهمة تطوير في Manus من خلال Automations في Manus 2.0، ويراجع مهندس التغيير قبل إطلاقه. يعمل هذا منذ حوالي أسبوع. نحتاج إلى حالات كثيرة أخرى قبل أن نعتمد عليه.
إذن ماذا يفعل الأشخاص في الفريق؟ ثلاثة أمور تبقى معهم. يتخذون كل قرار مهم ويتحملون مسؤوليته. يتعاملون مع الحالات التي لم يرها الـ Agent، ويعلّمونه ماذا يفعل أو بمن يستعين. ويعيدون توجيهه كلما أشار تحليله إلى زاوية جديدة.
8. مقاطعة بعضنا البعض بشكل أقل
في جميع هذه الفرق، لم تعد الكثير من الأسئلة تتطلب مقاطعة شخص ما.
اسأل الـ Agent أولاً. أنشأ أحد زملاء الفريق بوت Slack على Mono يعمل على كمبيوتر سحابي ويرد في المحادثة. غير المهندسين هم من يستخدمونه أكثر. كيف تعمل هذه الميزة؟ أين توجد هذه السلسلة النصية؟ هل تم إطلاق هذا؟ لم يعدوا بحاجة إلى العثور على المالك أولاً.
افتح الجلسة بدلاً من طلب تحديث للحالة. كان تقدم المهندس يعيش في محادثات AI الخاصة به، غير مرئي بمجرد تسجيل خروجه. لذلك أنشأنا ميزة داخلية تتيح لأعضاء المشروع رؤية جلسات بعضهم البعض وطلب الانضمام إليها. قد يبني أحد المهندسين معظم ميزة ما مع الـ Agent، ثم ينضم مدير المنتج إلى نفس الجلسة لتعديل التباعد والأنماط والنصوص. يتطلب النشر في جلسة شخص آخر موافقته، وما زلنا نعمل على ضبط الأذونات.
(مثال توضيحي: كيف يعمل مهندس ومدير منتج ومصمم في جلسة واحدة. ليس تغييراً حقيقياً في التسعير.)
الهدف ليس التحدث مع بعضنا البعض بشكل أقل. بل مقاطعة بعضنا البعض بشكل أقل.
قرر فقط ما يحتاج إلى قرار. يحتفظ أكثر مستخدمي AI لدينا بجلسة رئيسية واحدة بوظيفة واحدة: إدراج ما يحتاج إلى قراره، مع توصية لكل منها. عندما يصبح Slack مزدحماً، يبقى بعيداً عنه ويسأل: "ما الذي أحتاج إلى اتخاذ قرار بشأنه الآن؟"
أفعل شيئاً مشابهاً. لدي أكثر من 20 مهمة في اليوم، وكما شاركت علناً، أعاني من اضطراب فرط الحركة ونقص الانتباه. البدء هو الجزء الأصعب بالنسبة لي. الآن تذهب كل مهمة إلى مشروع Manus مخصص يحول كل واحدة إلى مهمتها الخاصة. يبدأ ما يستطيع. عندما يكون غير متأكد، يسألني عن الخلفية وأي مدير منتج يجب أن يتولاها. ثم، باستخدام الوصول الذي منحته له إلى Slack و Gmail و Notion الخاصة بي، يجمع السياق ويسلم مدير المنتج طلباً كاملاً بدلاً من ملاحظة من سطر واحد. بالنسبة لي، التغيير لا يتعلق فقط بالكفاءة. أصبحت أقضي الآن وقتاً أقل بكثير من يومي في القلق بشأن من أين أبدأ، وهو أمر هائل على المستوى الشخصي.
9. هل يستحق التكلفة؟
ننفق الكثير على AI، ونتتبع هذا الإنفاق عن كثب. لا نستخدمه للحكم على أداء أي شخص. نستخدمه للحكم على الإنفاق نفسه: هل يؤتي ثماره الآن، أم يهيئنا للمستقبل؟
إليك ما نعتقد أنه يشتريه لنا، وأين نتوقع أن تذهب التكلفة:
•إنه يشتري الوقت والانتباه. مع نمو الفريق، يستهلك التنسيق انتباه الجميع. يحمي AI انتباه كل شخص ويمنحه ملكية أكثر اكتمالاً لعمله. ولا نزال نوظف.
•استخدام أفضل النماذج هو الطريقة التي نتعلم بها أين تكمن حدود AI. يعمل إعداد التحقق ومراجعة الكود الموصوف في القسم 4 على أقوى النماذج التي يمكننا الحصول عليها. يصفه الزميل الذي يقود إنتاجية المطورين بأنه أفضل إنفاق من حيث القيمة لدينا.
•يجب أن تنخفض التكلفة من خلال المنتج. المزيد من تطويرنا يحدث الآن في Manus Studio، منتجنا الخاص، لذا تظهر لنا بيانات الاستخدام أين يتم إهدار tokens. تذهب الإصلاحات إلى المنتج، لذا يجب أن تجعل Manus أكثر كفاءة للمستخدمين أيضاً. نتوقع أن تنخفض تكاليف اليوم بشكل كبير مع رخص النماذج وإزالتنا للهدر. هذا اعتقاد، وليس وعداً!
10. ما الذي لا يعمل بعد
هناك مقاطعات أقل، لكن الانتباه أكثر تشتتاً. الشخص الذي كان يتعامل مع أربع أو خمس مهام في اليوم قد يدفع الآن 20 أو 30 إلى الأمام في وقت واحد. كل تبديل يعني إعادة تحميل السياق. يوسع AI ما يمكن للناس القيام به، كما يدفعهم للقيام بالمزيد. أخبرتني إحدى مديرات المنتج أنه كلما كانت هناك مهمة قيد التشغيل، لا يمكنها مقاومة بدء Agent آخر. القيام بالمزيد من الأشياء ليس الهدف. نحن نتعامل مع هذا كمشكلة يجب حلها، وليس وتيرة يجب الاحتفال بها.
المعلومات أكثر تشتتاً. كان رئيس المنتج لدينا يعرف كل تغيير وسبب إجرائه. الآن يلتقط أحياناً صورة لمشكلة ويسأل Mono: "من غيّر هذا؟" الأمر مضحك، لكن السؤال حقيقي. عندما يُمكّن الجميع من تغيير المنتج، من المسؤول عن الكل؟
تحتاج أذونات المشاركة إلى إعادة تصميم. عندما يمكن مشاركة العمل وتسليمه، ويجلس الـ Agents في المزيد من محادثاتنا، علينا أن نقرر ما هو مفتوح وما يحتاج إلى موافقة.
إصلاحاتنا لا تزال أساسية. في الوقت الحالي، يشرف Agent واحد على الآخرين ويبلغ فقط عما هو عالق وما يحتاج إلى قرار بشري. نعلم أن هذا يمكن أن يكون أفضل.
11. ما الذي نبنيه بعد ذلك
تشير هذه المشكلات إلى أعمال منتج ستحتاجها فرق أخرى على الأرجح أيضاً. لم نخطط لهذه الميزات مسبقاً. بل جاءت من مشكلات ظللنا نواجهها بأنفسنا.
•الجلسات كمساحات عمل مشتركة. يطرح شخص مشكلة، ويقترح مصمم إصلاحاً، ويبنيه مهندس، ويديره مدير منتج، كل ذلك في المكان نفسه.
•العمل الذي ينتقل عبر الأجهزة والأشخاص. تبقى الأجهزة المحلية والسحابية متصلة، بحيث يمكن أن يستمر العمل عندما يبتعد الأشخاص.
•Agent تجد خيارات لم يفكر بها الأشخاص. ينبغي لـ Agent يعمل داخل أنظمة شركة، بالصلاحيات المناسبة، أن يكون قادراً على اقتراح حلول، لا مجرد تنفيذ التعليمات.
سنجرب هذه الأمور على أنفسنا أولاً، ثم نطرحها للمستخدمين.
12. ما يفعله الناس الآن
المهندس الذي يفتح صفاً من جلسات Agent ليس مجرد قصة عن الكفاءة. إنه تغيير في ما تقوم عليه المؤسسة. كانت الشركات تنقل المعلومات عبر الأدوار والتسلسل الهرمي. وما يستطيع شخص واحد فعله كان يعتمد على عدد الأشخاص والموارد التي يمكنه الاستفادة منها. أما الآن فنقضي وقتاً قليلاً في تزويد AI بالسياق والأدوات، ووقتاً أطول في إصدار الأحكام واتخاذ القرارات. وأكثر فأكثر، أصبح Agent هو من يطرح علينا المشكلة. أما تقرير ما يجب فعله حيالها فيبقى من مهمتنا.
لقد مزحنا بشأن ذلك: إذا كان Manus قادراً على فعل كل هذا، فلماذا نأتي إلى المكتب؟ لندع Agents يتوصلون إلى الحل. لكن الأسئلة المهمة ما زالت تحتاج إلى أشخاص يطرحونها ويتجادلون حولها ويقررون. على سبيل المثال، ما الذي يُعتبر منتجاً جيداً؟ أو، للمبالغة قليلاً: هل نبني منتجاً رائعاً بإيرادات حقيقية يواصل دفع حدود AI، أم نسعى وراء الهامش؟ لا يعرف AI أياً نريد. نحن نعرف. تنشأ الثقافة والثقة من العمل على الأمور معاً، يوماً بعد يوم وفي اللحظات المهمة. ذلك هو الأساس الذي يرتكز عليه العمل في كل جلسة.
إذن، في الوقت الحالي، هذا هو جوابنا. في تجربتنا كمؤسسة AI-native، لم يتقلص دور الأشخاص. بل أصبح أكثر تركيزاً على المجالات التي يمكنهم فيها إحداث أكبر أثر: تعريف المشكلة، والحكم على الجودة، وتقرير ما يستحق القيام به، وامتلاك النتيجة.
ولهذا السبب أيضاً ما زلنا نوظف. مهارات الأشخاص وأحكامهم في صميم طريقة العمل هذه — وهذا لن يتغير في أي وقت قريب.
بينما أكتب هذا، يتملكني الفضول بشأن ما ستقوله هذه التدوينة بعد عام من الآن. لكل شركة أهداف وهياكل وثقافة مختلفة، لذا قد لا يكون هناك جواب موحد ولا شكل نهائي. لكن بالنسبة لشركة تبني Agents، فإن معرفة كيف يعمل الأشخاص وAI معاً ليست خياراً. إنها جزء من العمل. سنواصل العمل على ذلك، وسنواصل مشاركة ما نتعلمه.
ملاحظة حول الأرقام. الأرقام في هذه التدوينة مأخوذة من السجلات الداخلية. أحجام الفرق وأرقام إطلاق مديري المنتج اعتباراً من أواخر أكتوبر. بعض النقاط تقديرات أو تجربة شخص واحد وليست قياسات.
