Manus के साथ Manus का पुनर्निर्माण: क्या बदला, क्या टूटा, और अब हम कैसे काम करते हैं
ताओ झांग द्वारा, सह-संस्थापक और मुख्य उत्पाद अधिकारी, Manus
सितंबर के अंत में, Manus 2.0 पर अंतिम प्रयास के दौरान, मैंने Slack पर अपने एक इंजीनियर को कुछ फीचर अनुरोध और बग रिपोर्ट भेजीं। बाद में मैं यह देखने गया कि वह कैसे काम कर रहा है। उसकी स्क्रीन पर खुले हुए agent सत्रों की एक पंक्ति थी, कुछ Manus में और कुछ Codex में। मैंने एक पर क्लिक किया। प्रॉम्प्ट मेरा Slack संदेश था, शब्दशः चिपकाया हुआ।
एक साल पहले, वह मेरा संदेश पढ़ता, मेरा मतलब समझता, और फिर कोड लिखता। अब एक agent अनुरोध पढ़ता है, संबंधित कोड ढूँढता है, और एक बदलाव का प्रस्ताव करता है। इंजीनियर का काम है काम को निर्देशित करना, जाँचना, और परिणाम का स्वामित्व लेना। अधिकांश समय एक अनुरोध चल रहा होता है, उस पर प्रतीक्षा नहीं कर रहा होता। आज, यहाँ यह आम बात है कि एक इंजीनियर के पास एक साथ 10 से 20 अनुरोध चल रहे होते हैं।
मुझे गर्व है कि हमारी टीम ने कितनी जल्दी अनुकूलन किया है। मैं असहज भी हूँ। क्या यह गति सही है? हमने अभी तक क्या नहीं देखा है?
हम Manus में agents बनाते हैं, इसलिए हम स्वयं को दो नियमों पर रखते हैं। हम वास्तविक काम के लिए अपने स्वयं के उत्पाद का उपयोग करते हैं। और हम उन जगहों की तलाश करते रहते हैं जहाँ AI काम करना बंद कर देता है।
मैं दस्तावेज़ करना चाहूँगा कि जब लोग और agents डिफ़ॉल्ट रूप से साथ-साथ काम करते हैं तो एक कंपनी के अंदर क्या होता है। यह पोस्ट तीन टीमों — इंजीनियरिंग, उत्पाद, और मार्केटिंग — को कवर करती है, और इसमें वह भी शामिल है जो काम नहीं किया है। यह प्रगति पर एक प्रयोग की रिपोर्ट है, न कि "AI-नेटिव संगठन" की परिभाषा।
हमने अब तक क्या सीखा है:
•कोई बीच का रास्ता नहीं है। पुराने काम करने के तरीकों में AI जोड़ने से कभी-कभी शोर बढ़ा। चीज़ें तभी बदलीं जब लूप बंद हुआ।
•Agents को पूरी तस्वीर चाहिए। बेहतर संदर्भ ने हमारे लिए बेहतर प्रॉम्प्ट्स से अधिक किया।
•विश्वास परीक्षणों और संदर्भ से आता है, केवल मॉडल गुणवत्ता से नहीं।
•स्वायत्तता के लिए एक समाप्ति रेखा चाहिए। Agents तभी स्वयं चल सकते हैं जब सफलता की जाँच की जा सके। बाकी हर जगह, एक व्यक्ति निर्णय करता है।
•अड़चन स्थान बदलती है। जब इंजीनियरिंग तेज़ हुई, तो यह तय करना कि क्या बनाना है, बाधा बन गया।
•लोगों की भूमिका कम नहीं हुई है। यह उच्च-प्रभाव वाली चीज़ों पर अधिक केंद्रित हो गई है।
1. कोई बीच का रास्ता नहीं है
2026 से पहले, हमने वही किया जो अधिकांश कंपनियों ने किया: हमने अपने पहले से काम करने के तरीके में AI जोड़ा। इसका मतलब था कि सपोर्ट AI सारांश के साथ समस्याओं को चिह्नित करता, इंजीनियर कोडिंग सहायकों का उपयोग करते, और बॉट्स चैनलों में विश्लेषण पोस्ट करते। हर टुकड़ा अपने आप में उपयोगी था, लेकिन बहुत से टुकड़े एक-दूसरे से जुड़े नहीं थे। जब तक लूप वास्तव में बंद नहीं हुआ, हम बस उसी पुराने तरीके से काम कर रहे थे, लेकिन बहुत सारे AI एक-दूसरे के ऊपर बात कर रहे थे।
एक पंक्ति है जिस पर हम अक्सर लौटते हैं: सॉफ्टवेयर इंजीनियरिंग समय के साथ एकीकृत प्रोग्रामिंग है। कोड लिखना मापना आसान है; एक जटिल उत्पाद को वर्षों तक स्वस्थ रखना नहीं। AI-लिखित कोड का उच्च प्रतिशत वास्तविक प्रगति का मतलब हो सकता है, या इसका मतलब कचरा जमा करना हो सकता है जिसे किसी को बाद में साफ करना होगा।
जो परीक्षण हमें परवाह है वह कठिन है। Manus एक जटिल उत्पाद है जो एक वर्ष से अधिक समय से लाइव है। क्या यह बिना ढहे नए काम करने के तरीकों के तहत सुधार करता रह सकता है, जबकि प्रत्येक व्यक्ति अधिक काम पूरा करता है? अब तक उत्तर हाँ है।
2. Agent को पूरी तस्वीर दें
अधिकांश तकनीकी कंपनियों की तरह, हमने सबसे अधिक समय हैंडऑफ़ पर खोया। एक फ्रंटएंड इंजीनियर और एक बैकएंड इंजीनियर प्रत्येक एक अनुरोध की व्याख्या करते, एक इंटरफ़ेस पर सहमत होते, और फिर बेमेल को ठीक करने में दिन बिताते। दो लोग शायद ही कभी एक आवश्यकता को एक ही तरह से समझते हैं।
यदि AI पूरे स्टैक में कोड लिख सकता है, तो क्या एक व्यक्ति एक अनुरोध को शुरू से अंत तक स्वामित्व में ले सकता है? बाधा संदर्भ थी। हमारा कोड अलग-अलग रिपॉजिटरी में रहता था, इसलिए कोई भी agent एक साथ पूरे सिस्टम को नहीं देख सकता था।
इसका हमारा उत्तर एक आंतरिक प्रयोग से शुरू हुआ। हम यह देखना चाहते थे कि AI किसी उत्पाद को बनाने में कितनी दूर तक जा सकता है, जिसमें मानव इनपुट न्यूनतम हो और लगभग कोई हाथ से लिखा कोड न हो। इस दौरान हमने जो पद्धति विकसित की वह आंतरिक टूल बन गई जिसे अब हम Manus-mono, या Mono कहते हैं।
Mono हमारी रिपॉजिटरीज़ को मर्ज नहीं करता। यह एक एकल एंट्री पॉइंट है और साथ ही Agent के लिए लिखी गई एक मैनुअल है: प्रत्येक रिपॉजिटरी क्या करती है, वे एक-दूसरे से कैसे जुड़ती हैं, और हम कैसे काम करते हैं। Agent जो भी चाहिए उसे खींच लेता है। हम आर्किटेक्चर निर्णय रिकॉर्ड की एक लाइब्रेरी भी रखते हैं, ताकि हर Agent सत्र पिछले निर्णयों के पीछे के तर्क के साथ शुरू हो, न कि केवल कोड के साथ। जब भी कोई Agent के साथ काम करता है, उस Agent के पास पहले आए हर व्यक्ति का संदर्भ होता है।
Mono चरणों में विकसित हुआ, और प्रत्येक चरण ने उस बाधा को ठीक किया जो पिछले चरण ने उजागर की थी:
1.पूरा सिस्टम देखें। हमने वह व्यावसायिक संदर्भ जोड़ा जो किसी एक रिपॉजिटरी में नहीं होता, और समानांतर कार्य के लिए Git worktrees का उपयोग किया।
2.स्थानीय स्तर पर सत्यापित करें। परीक्षण परिवेश में एक push में पहले 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 द्वारा लिखे गए कोड पर भरोसा करना कैसे सीखा
लंबे समय तक, हमारी मुख्य branch में जाने वाले हर बदलाव के लिए दो वरिष्ठ engineers में से किसी एक की मंजूरी की आवश्यकता होती थी। हम उस कदम को छोड़ने के लिए AI पर पर्याप्त भरोसा नहीं करते थे। जैसे-जैसे agents ने अधिक कोड तैयार किया, वह समीक्षा चरण एक अड़चन बन गया।
शुद्ध कोडिंग क्षमता के मामले में, मॉडल पहले से ही मजबूत थे। हमने पहचाना कि अंतर दो चीजों पर आता है। पहला, लोग जानते हैं कि अपने काम का परीक्षण कैसे करें। दूसरा, लोग upstream और downstream चर्चाओं का हिस्सा रहे हैं, इसलिए वे जानते हैं कि व्यवसाय के लिए "सही" का क्या अर्थ है। सही कोड सही उत्पाद के समान नहीं है।
हमने दोनों को संबोधित किया:
•Agents को चर्चा में शामिल होने दें। प्रत्येक engineer का agent अब उन Slack threads में बैठता है जिनमें उसे जोड़ा गया है, और संदर्भ का अनुसरण करता है। जब कोई अंततः कहता है "Go", तब agent पहले से जानता है कि टीम ने क्या निर्णय लिया और क्यों।
•Agents को end to end परीक्षण करने दें। हमारी backend टीम के साथ मिलकर, हमने agents को हर बदलाव के बाद Manus में वास्तविक flows और regression tests चलाने की क्षमता दी। जैसे-जैसे परीक्षण coverage बढ़ी, हमारा भरोसा भी बढ़ा।
आज, हर बदलाव उस सत्यापन से गुजरता है और उपलब्ध सबसे मजबूत मॉडल चलाने वाले एक कोड समीक्षा bot से गुजरता है, जिसमें भुगतान जैसे संवेदनशील क्षेत्रों के लिए अतिरिक्त नियम हैं। Bot ने कतार को बदल दिया, मानवीय निर्णय को नहीं। एक agent pull request खोल सकता है, लेकिन वह किसी व्यक्ति की स्पष्ट स्वीकृति के बिना हमारी मुख्य branch में merge नहीं कर सकता। लोग अभी भी तय करते हैं कि क्या बनाया जाए और कौन release कर सकता है।
5. स्वायत्तता को एक अंतिम लक्ष्य की आवश्यकता होती है
भरोसे की सीमाएँ होती हैं, और हमने यह कठिन तरीके से सीखा।
एक समय, हर कोई पूर्णतः स्वायत्त agent loops को लेकर उत्साहित था, इसलिए हमने एक की कोशिश की। एक agent ने हमारे आंतरिक feedback channels से feedback एकत्र किया और प्रत्येक item के लिए एक project शुरू किया। एक सहकर्मी ने इसे एक weekend भर चलने दिया। सोमवार सुबह, 200 से अधिक items उसके निर्णय का इंतजार कर रहे थे।
तो agent को वे निर्णय भी क्यों न लेने दें? स्वायत्त loops तब काम करते हैं जब सिस्टम यह जाँच सकता है कि लक्ष्य पूरा हुआ है या नहीं। परीक्षण पास होते हैं या विफल; एक पृष्ठ load होता है या नहीं। अधिकांश वास्तविक कार्य में ऐसी कोई जाँच नहीं होती। एक व्यक्ति को निर्णय करना होता है कि यह पूरा हुआ या नहीं, और क्या यह करने लायक था भी।
हमने उस weekend से दो सबक सीखे। पहला, लोग उतनी तेजी से निर्णय नहीं ले सकते जितनी तेजी से एक अनियंत्रित loop उन्हें बनाता है। दूसरा, यदि कोई यह तय नहीं करता कि कुछ किया जाना चाहिए या नहीं, तो कोई भी परिणाम का स्वामी नहीं होता। खंड 3 में बग-फिक्सिंग loop इसलिए काम करता है क्योंकि परीक्षण सफलता को परिभाषित करते हैं। उत्पाद निर्णयों के पास परीक्षण नहीं होते, इसलिए Manus में हर उत्पाद परिवर्तन अभी भी किसी व्यक्ति के यह तय करने से शुरू होता है कि यह करने लायक है या नहीं।
6. जब engineering तेज हुई, तो product एक अड़चन बन गया
एक पारंपरिक उत्पाद प्रक्रिया में कई handoffs होते हैं, और प्राथमिकताएँ प्रत्येक पर थोड़ी बहक जाती हैं। जैसे-जैसे coding agents ने engineers को तेज बनाया, एक नई समस्या सामने आई: अच्छी आवश्यकताएँ लिखने के लिए पर्याप्त product managers नहीं थे। पहली बार, engineering बाधा नहीं थी।
Manus में, हमारा पहला समाधान कुछ engineers से "builders" बनने के लिए कहना था जो किसी समस्या को खोज से launch तक अपने स्वामित्व में लें। कम ही लोगों के पास तकनीकी और उत्पाद दोनों का निर्णय था। आगे हमने PMs को कोड बदलने दिया। वह भी रुक गया। Handoffs अभी भी वहाँ थे, और engineer की सहज समझ के बिना, PMs copy और interactions बदल सकते थे लेकिन अंतर्निहित तर्क नहीं।
Mono ने दोनों समस्याओं को हल किया क्योंकि वह अपने साथ नियम लेकर चलता है:
•कोई भी बदलाव जो मॉडल कॉल या लागत को प्रभावित करता है, कोड लिखे जाने से पहले मालिक की स्वीकृति की आवश्यकता होती है।
•प्रत्येक बदलाव उसी समीक्षा और परीक्षण से गुजरता है जिससे एक engineer का बदलाव गुजरता है।
•Mono परीक्षण खातों के साथ sign-up और भुगतान से गुजर सकता है और प्रत्येक चरण को रिकॉर्ड कर सकता है, ताकि एक PM उस सटीक क्षण की ओर इशारा कर सके जब कुछ टूटता है।
व्यवहार में यह कैसा दिखता है, यहाँ देखें। speech-to-text पर काम कर रही एक PM ने Manus से 10 से अधिक मॉडलों का benchmark कराया, फिर एक को चुना। उन्होंने Mono के माध्यम से frontend कोड खींचा, हमारे design system में एक demo बनाया, और Manus से प्रत्येक उपयोगकर्ता परिदृश्य को एक छवि के रूप में render कराया ताकि वे समीक्षा कर सकें। उन्होंने demo को एक वीडियो में बदल दिया। योजना इतनी स्पष्ट थी कि उन्होंने स्वयं फीचर बनाया, जिसमें web और desktop UI शामिल थे।
इस प्रक्रिया में लोगों ने तीन निर्णय लिए। उसने मॉडल चुना। प्रोडक्ट और डिज़ाइन ने डेमो की समीक्षा की। रिलीज़ अधिकार वाले एक इंजीनियर ने कोड की समीक्षा की। एक साल पहले, यह सब संभव नहीं होता।
हम इसे ह्यूमन इन द लूप से ह्यूमन ऑन द लूप की ओर बढ़ने के रूप में वर्णित करते हैं। AI किसी कार्य का 70-80% करता था और लोग बाकी भरते थे। अब लोग नियम तय करते हैं, कई एजेंट्स की निगरानी करते हैं, महत्वपूर्ण बिंदुओं पर तरीकों और परिणामों की जाँच करते हैं, आवश्यकता पड़ने पर हस्तक्षेप करते हैं, और परिणाम के मालिक होते हैं।
कुछ PMs अब लिखित स्पेक या मॉकअप के बजाय एक छोटा वीडियो सौंपते हैं। कुछ मिनटों में, यह उपयोग का मामला, प्रत्येक स्क्रीन, प्रत्येक क्लिक क्या करती है, एज केस कैसे व्यवहार करते हैं, और यह सब अंदर से कैसे काम करता है, दिखाता है। हमारे लिए, डिज़ाइन, इंजीनियरिंग, और QA तेज़ी से इस बात पर सहमत होते हैं कि "हो गया" का क्या मतलब है, और PM इसे एक बार समझाता है।
(वॉइस इनपुट के लिए प्रोडक्ट रिक्वायरमेंट वीडियो)
आज हमारे लगभग आधे PMs अपने दम पर फीचर्स शिप करते हैं, और हर PM ने कोड कमिट किया है। डिज़ाइनरों ने भी शुरू कर दिया है। एक PM ने Manus 2.0 में Manus Studio इंटरफ़ेस का अधिकांश भाग लिखा। दूसरे ने Video Editor लिखा। इनमें से हर एक के पीछे कोई है जिसने महीनों तक अपनी भूमिका की सीमाओं से आगे बढ़ने के लिए प्रयास किया। मुझे इसी पर सबसे अधिक गर्व है।
इसका मतलब यह नहीं है कि हर किसी को बिल्डर होना चाहिए। जब किसी कंपनी में कोई भी निर्माण कर सकता है, तो लोग ऐसी चीज़ें शिप कर सकते हैं जिन्हें मौजूद नहीं होना चाहिए। हमारी प्रोडक्ट टीम अक्सर एक प्रश्न पूछती है: "अगर इसमें एक सेकंड लगे और कोई लागत न हो, तो क्या आप इसे शिप करेंगे?" कभी-कभी उत्तर नहीं होता है। हमें अभी भी ऐसे मॉड्यूल मालिकों की आवश्यकता है जो तय करें कि क्या बनाया जाए, क्या नहीं, और उपयोगकर्ता अंततः क्या देखें। हमें ऐसे लोगों की भी आवश्यकता है जो Mono जैसी बुनियादी संरचना को बनाए रखें। जब निर्माण आसान हो जाता है, तो यह तय करना कि क्या बनाया जाए, अधिक महत्वपूर्ण हो जाता है।
7. मार्केटिंग वर्कफ़्लो के भीतर एक AI टीममेट
एक मार्केटिंग साझेदारी स्क्रिप्ट समीक्षा, मूल्य निर्धारण, अनुबंध, अनुमोदन, भुगतान, लॉन्च, और परिणाम समीक्षा के माध्यम से आगे बढ़ती है। वे चरण ईमेल, अनुबंध टूल्स, अनुमोदन सिस्टम, स्प्रेडशीट्स, और विज्ञापन प्लेटफ़ॉर्म्स में रहते हैं। काम का अधिकांश हिस्सा उनके बीच जानकारी स्थानांतरित करने में जाता था, जिससे उस रचनात्मक कार्य के लिए बहुत कम समय बचता था जिसमें निर्णय की आवश्यकता होती है।
हमने एक छोटी समस्या से शुरुआत की: जब पार्टनर कंटेंट या विज्ञापन लाइव होता था, तो हमें अक्सर इसके बारे में देर से पता चलता था। इसलिए हमने AI से एक स्क्रिप्ट लिखवाई जो यह पता लगाती है कि कंटेंट कब प्रकाशित होता है। फिर हमें परफ़ॉर्मेंस डेटा चाहिए था। फिर पिछली साझेदारियों की समीक्षा। फिर पूरा आंतरिक वर्कफ़्लो जुड़ गया: जब कोई अनुबंध पर हस्ताक्षर होता है या कोई अनुमोदन स्पष्ट होता है, तो Agent स्थिति अपडेट करता है और जो भी अगले चरण का मालिक है, उसे सूचित करता है।
Manus ने यह सब एक आंतरिक साइट में बनाया। लोगों के लिए, यह डैशबोर्ड और एक कैलेंडर है। Agent के लिए, यह टूल्स का एक सेट है। जो Agent हमारे वर्कफ़्लो के भीतर उन टूल्स का उपयोग करता है, उसे हम AI टीममेट कहते हैं। यह केवल उन चैनलों और सिस्टमों में काम करता है जिनसे टीम ने इसे कनेक्ट किया है, जिसकी पहुँच इस वर्कफ़्लो तक सीमित है।
यह क्या करता है:
•यह अपनी कतार स्वयं प्रबंधित करता है। कई लोग एक साथ इसे संदेश भेजते हैं, इसलिए यह एक "फ्रंट डेस्क" सत्र में सभी से बात करता है और समानांतर सत्रों को कार्य सौंपता है। यह तय करता है कि कोई संदेश उसके लिए प्रासंगिक है या नहीं, फिर यह कि वर्तमान कार्य में बाधा डाले या प्रतीक्षा करे। इसने विकास के दौरान स्वयं इन नियमों का प्रस्ताव रखा, और हमने उन्हें रखने से पहले उनकी समीक्षा की।
•यह अग्रेषित संदर्भ से सीखता है। रणनीति में बदलाव का मतलब पहले एक बैठक और एक लिखित विवरण होता था। अब हमारे मार्केटिंग लीड चर्चा को अग्रेषित करते हैं और कहते हैं, "इसे सीखो।"
•यह दीर्घकालिक लक्ष्यों को ध्यान में रखता है। एक अवसर पर, एक Slack थ्रेड में टीममेट्स, जिसमें इसे जोड़ा गया था, याद नहीं रख सके कि कोई प्रोजेक्ट कहाँ खड़ा है। बिना टैग किए, इसने उत्तर दिया: "B अभी भी परीक्षण में है। क्या हमें B को देखने से पहले A के परिणामों की प्रतीक्षा करनी चाहिए?"
•यह अन्य टीमों के साथ तथ्यों की जाँच करता है। जब हमने 3D मॉडल रिगिंग लॉन्च किया, तो इसने प्रोडक्ट टीम से पूछा कि क्या समर्थित है। इसे पता चला कि रिगिंग सात श्रेणियों को कवर करता है, जिसमें मछली, साँप, और चौपाये शामिल हैं, इसलिए हमारे विवरण सटीक रहे।
टीममेट्स अब इसे स्क्रिप्ट और मूल्य निर्धारण समीक्षाओं में शामिल करते हैं, क्योंकि इसने हमारी पिछली साझेदारी के रिकॉर्ड पढ़े हैं। निर्णय अभी भी लोग लेते हैं।
आंतरिक साइट अपने स्वयं के उपयोगकर्ताओं से भी बेहतर हो सकती है, जिसमें Agent भी शामिल है। जब Agent को कोई बाधा मिलती है, तो यह एक फ़ीडबैक एंडपॉइंट के माध्यम से एक अनुरोध दर्ज करता है। यह Manus 2.0 में Automations के माध्यम से Manus में एक विकास कार्य खोलता है, और एक इंजीनियर इसे शिप करने से पहले बदलाव की समीक्षा करता है। यह लगभग एक सप्ताह से चल रहा है। इस पर निर्भर होने से पहले हमें कई और मामलों की आवश्यकता है।
तो टीम के लोग क्या करते हैं? तीन चीज़ें उनके पास ही रहती हैं। वे हर महत्वपूर्ण निर्णय लेते हैं और उसके मालिक होते हैं। वे ऐसे मामले संभालते हैं जिन्हें Agent ने नहीं देखा है, और इसे सिखाते हैं कि क्या करना है या किससे पूछना है। और जब भी इसका विश्लेषण किसी नए दृष्टिकोण की ओर इशारा करता है, वे इसे पुनर्निर्देशित करते हैं।
8. एक-दूसरे को कम बाधित करें
इन सभी टीमों में, कई प्रश्नों के लिए अब किसी को बीच में टोकने की आवश यकता नहीं है।
पहले Agent से पूछें। एक सहकर्मी ने Mono पर एक Slack बॉट बनाया जो क्लाउड कंप्यूटर पर चलता है और थ्रेड में उत्तर देता है। गैर-इंजीनियर इसका सबसे ज़्यादा उपयोग करते हैं। यह फीचर कैसे काम करता है? यह स्ट्रिंग कहाँ है? क्या यह शिप हो चुका है? अब उन्हें पहले मालिक को ढूँढने की ज़रूरत नहीं है।
स्टेटस अपडेट माँगने के बजाय सेशन खोलें। पहले किसी इंजीनियर की प्रगति उसकी अपनी AI चैट्स में रहती थी, जो लॉग ऑफ होते ही अदृश्य हो जाती थी। इसलिए हमने एक आंतरिक फीचर बनाया जो किसी प्रोजेक्ट के सदस्यों को एक-दूसरे के सेशन देखने और उसमें शामिल होने के लिए अनुरोध करने देता है। एक इंजीनियर Agent के साथ किसी फीचर का अधिकांश भाग बना सकता है, और फिर एक PM उसी सेशन में शामिल होकर स्पेसिंग, स्टाइल और कॉपी को समायोजित कर सकता है। किसी और के सेशन में पोस्ट करने के लिए उनकी स्वीकृति ज़रूरी है, और हम अभी भी अनुमतियों पर काम कर रहे हैं।
(उदाहरणात्मक उदाहरण: एक इंजीनियर, एक PM और एक डिज़ाइनर एक सेशन में कैसे काम करते हैं। यह कोई वास्तविक मूल्य निर्धारण परिवर्तन नहीं है।)
उद्देश्य एक-दूसरे से कम बात करना नहीं है। उद्देश्य एक-दूसरे को कम बाधित करना है।
केवल वही निर्णय लें जिसका निर्णय लेना आवश्यक है। हमारा सबसे भारी AI उपयोगकर्ता एक मुख्य सेशन रखता है जिसका एक ही काम है: उन चीज़ों की सूची बनाना जिनके लिए उसके निर्णय की आवश्यकता है, प्रत्येक के लिए एक सिफारिश के साथ। जब Slack व्यस्त हो जाता है, तो वह उससे बाहर रहकर पूछता है, "मुझे अभी क्या निर्णय लेने की आवश्यकता है?"
मैं भी कुछ ऐसा ही करता हूँ। मेरे पास एक दिन में 20 से अधिक काम होते हैं, और, जैसा कि मैंने सार्वजनिक रूप से साझा किया है, मुझे ADHD है। शुरुआत करना मेरे लिए सबसे कठिन हिस्सा है। अब हर काम एक समर्पित Manus प्रोजेक्ट में जाता है जो प्रत्येक को उसका अपना कार्य बना देता है। यह जो शुरू कर सकता है, शुरू कर देता है। जब यह अनिश्चित होता है, तो यह मुझसे पृष्ठभूमि पूछता है और यह भी कि इसे कौन सा PM संभाले। फिर, मेरे अपने Slack, Gmail और Notion तक दी गई पहुँच का उपयोग करके, यह संदर्भ इकट्ठा करता है और PM को एक-लाइन के नोट के बजाय एक पूरा अनुरोध सौंपता है। मेरे लिए, यह बदलाव केवल दक्षता के बारे में नहीं है। अब मैं अपने दिन का बहुत कम हिस्सा इस चिंता में बिताता हूँ कि कहाँ से शुरू करूँ, जो व्यक्तिगत स्तर पर बहुत बड़ी बात है।
9. क्या यह लागत के लायक है?
हम AI पर बहुत खर्च करते हैं, और हम उस खर्च पर बारीकी से नज़र रखते हैं। हम इसका उपयोग किसी के प्रदर्शन का आकलन करने के लिए नहीं करते। हम इसका उपयोग खर्च का ही आकलन करने के लिए करते हैं: क्या यह अभी भुगतान कर रहा है, या बाद के लिए तैयार कर रहा है?
यहाँ बताया गया है कि हमें क्या लगता है कि यह हमें क्या खरीदता है, और हम लागत कहाँ जाने की उम्मीद करते हैं:
•यह समय और ध्यान खरीदता है। जैसे-जैसे टीम बढ़ती है, समन्वय हर किसी के ध्यान को खा जाता है। AI प्रत्येक व्यक्ति के ध्यान की रक्षा करता है और उन्हें अपने काम का पूरा स्वामित्व देता है। और हम अभी भी भर्ती कर रहे हैं।
•सर्वोत्तम मॉडलों का उपयोग करना ही वह तरीका है जिससे हम सीखते हैं कि AI की सीमाएँ कहाँ हैं। सेक्शन 4 में वर्णित सत्यापन और कोड समीक्षा सेटअप सबसे मज़बूत मॉडलों पर चलता है जो हमें मिल सकते हैं। डेवलपर उत्पादकता का नेतृत्व करने वाले सहयोगी इसे हमारा सबसे अच्छा मूल्य वाला खर्च कहते हैं।
•लागत उत्पाद के माध्यम से घटनी चाहिए। हमारा अधिक विकास अब Manus Studio, हमारे अपने उत्पाद में होता है, इसलिए हमारा उपयोग डेटा हमें दिखाता है कि tokens कहाँ बर्बाद होते हैं। फिक्सेस उत्पाद में जाते हैं, इसलिए उन्हें Manus को उपयोगकर्ताओं के लिए भी अधिक कुशल बनाना चाहिए। हमें उम्मीद है कि मॉडल सस्ते होने और हमारे अपव्यय को हटाने के साथ आज की लागतें काफी हद तक कम हो जाएँगी। यह एक विश्वास है, वादा नहीं!
10. क्या अभी काम नहीं कर रहा
बाधाएँ कम हैं, लेकिन ध्यान अधिक खंडित है। कोई व्यक्ति जो पहले एक दिन में चार या पाँच चीज़ें संभालता था, अब एक साथ 20 या 30 आगे बढ़ा सकता है। हर स्विच का मतलब है संदर्भ को फिर से लोड करना। AI लोगों के करने की क्षमता का विस्तार करता है, और यह उन्हें और अधिक करने के लिए भी प्रेरित करता है। एक PM ने मुझे बताया कि जब भी कोई कार्य चल रहा होता है, वह दूसरा Agent शुरू करने से खुद को रोक नहीं पाती। अधिक चीज़ें करना लक्ष्य नहीं है। हम इसे हल करने की एक समस्या के रूप में देख रहे हैं, न कि जश्न मनाने की गति के रूप में।
जानकारी अधिक बिखरी हुई है। हमारे प्रोडक्ट प्रमुख पहले हर बदलाव और उसके कारण को जानते थे। अब वह कभी-कभी किसी समस्या का स्क्रीनशॉट लेते हैं और Mono से पूछते हैं, "इसे किसने बदला?" यह मज़ेदार है, लेकिन सवाल वास्तविक है। जब हर कोई उत्पाद बदलने के लिए सशक्त होता है, तो पूरे के लिए कौन ज़िम्मेदार है?
साझाकरण अनुमतियों को फिर से डिज़ाइन करने की आवश्यकता है। जब काम साझा और सौंपा जा सकता है, और Agents हमारी अधिक बातचीत में बैठते हैं, तो हमें यह तय करना होगा कि क्या खुला है और क्या अनुमोदन की आवश्यकता है।
हमारे फिक्सेस अभी भी बुनियादी हैं। फिलहाल, एक Agent दूसरों की निगरानी करता है और केवल यह रिपोर्ट करता है कि क्या अटका है और क्या मानव निर्णय की आवश्यकता है। हम जानते हैं कि यह बेहतर हो सकता है।
11. आगे हम क्या बना रहे हैं
ये समस्याएँ ऐसे प्रोडक्ट कार्य की ओर इशारा करती हैं जिसकी ज़रूरत संभवतः अन्य टीमों को भी होगी। हमने इन सुविधाओं की पहले से योजना नहीं बनाई थी। ये उन समस्याओं से उपजीं जिनका हम खुद बार-बार सामना करते रहे।
•साझा कार्यस्थल के रूप में सेशन। एक व्यक्ति समस्या उठाता है, एक डिज़ाइनर समाधान प्रस्तावित करता है, एक इंजीनियर उसे बनाता है, और एक PM उसे चलाता है — सब कुछ एक ही जगह पर।
•ऐसा कार्य जो डिवाइसों और लोगों के बीच चलता रहे। लोकल और क्लाउड मशीनें जुड़ी रहती हैं, ताकि लोगों के दूर जाने पर भी काम जारी रह सके।
•ऐसे Agent जो उन विकल्पों को ढूँढें जिनके बारे में लोगों ने सोचा भी न हो। किसी कंपनी के सिस्टम के भीतर सही अनुमतियों के साथ काम करने वाले Agent को केवल निर्देशों का पालन करने के बजाय समाधान सुझाने में सक्षम होना चाहिए।
हम इन्हें पहले खुद पर आज़माएंगे, फिर उपयोगकर्ताओं तक पहुँचाएंगे।
12. लोग अब क्या करते हैं
एक इंजीनियर जिसके सामने Agent सेशन की एक कतार खुली हो — यह केवल दक्षता की कहानी नहीं है। यह बदलाव है कि कोई संगठन किस आधार पर चलता है। कंपनियाँ पहले भूमिकाओं और पदानुक्रम के ज़रिए सूचना आगे बढ़ाती थीं। एक व्यक्ति क्या कर सकता था, यह इस पर निर्भर करता था कि वह कितने लोगों और संसाधनों का उपयोग कर सकता है। अब हम AI को संदर्भ और टूल देने में थोड़ा समय लगाते हैं, और निर्णय व फैसले लेने में अधिक समय। अधिकाधिक बार, कोई Agent ही हमारे पास समस्या लेकर आता है। उसके बारे में क्या करना है, यह तय करना अब भी हमारा काम है।
हम इस पर मज़ाक करते रहे हैं: अगर Manus इतना कुछ कर सकता है, तो दफ्तर आने की ज़रूरत ही क्या है? Agent खुद ही निपटा लेंगे। लेकिन महत्वपूर्ण सवालों को उठाने, उन पर बहस करने और निर्णय लेने के लिए अब भी लोगों की ज़रूरत है। उदाहरण के लिए, एक अच्छा प्रोडक्ट किसे माना जाए? या, थोड़ा अतिशयोक्ति से कहें तो: वास्तविक राजस्व वाला एक शानदार प्रोडक्ट बनाएँ जो AI की सीमाओं को लगातार आगे बढ़ाता रहे, या मुनाफे के पीछे जाएँ? AI नहीं जानता कि हम क्या चाहते हैं। हम जानते हैं। संस्कृति और विश्वास तब बनते हैं जब हम दिन-ब-दिन और महत्वपूर्ण क्षणों में मिलकर चीज़ों पर काम करते हैं। यही वह नींव है जिस पर हर सेशन का काम टिका होता है।
तो, फिलहाल, यह रहा हमारा जवाब। एक AI-नेटिव संगठन के रूप में हमारे प्रयोग में, लोगों की भूमिका कम नहीं हुई है। बल्कि यह उन क्षेत्रों पर अधिक केंद्रित हो गई है जहाँ उनका सबसे बड़ा प्रभाव हो सकता है: समस्या को परिभाषित करना, गुणवत्ता का आकलन करना, यह तय करना कि क्या करने लायक है, और परिणाम का स्वामित्व लेना।
यही कारण है कि हम अब भी भर्ती कर रहे हैं। लोगों के कौशल और निर्णय इस कार्यशैली के केंद्र में हैं — और यह निकट भविष्य में बदलने वाला नहीं है।
जैसा कि मैं यह लिख रहा हूँ, मुझे उत्सुकता है कि एक साल बाद इस पोस्ट में क्या लिखा होगा। हर कंपनी के लक्ष्य, संरचनाएँ और संस्कृति अलग होती हैं, इसलिए शायद कोई मानक उत्तर या अंतिम स्वरूप नहीं है। लेकिन Agent बनाने वाली कंपनी के लिए, यह समझना कि लोग और AI कैसे एक साथ काम करते हैं, वैकल्पिक नहीं है। यह काम का हिस्सा है। हम इसमें लगे रहेंगे, और जो सीखेंगे उसे साझा करते रहेंगे।
आंकड़ों के बारे में एक नोट। इस पोस्ट में दिए गए आंकड़े आंतरिक रिकॉर्ड से लिए गए हैं। टीम के आकार और PM शिपिंग के आंकड़े अक्टूबर के अंत तक के हैं। कुछ बिंदु मापन के बजाय अनुमान या किसी एक व्यक्ति का अनुभव हैं।
