Membangun Ulang Manus dengan Manus: Apa yang berubah, apa yang rusak, dan bagaimana kami bekerja sekarang
Oleh Tao Zhang, Co-founder dan Chief Product Officer, Manus
Pada akhir September, saat dorongan terakhir pengembangan Manus 2.0, saya mengirimkan beberapa permintaan fitur dan laporan bug kepada salah satu engineer kami di Slack. Beberapa waktu kemudian saya memeriksa bagaimana kemajuannya. Layarnya menampilkan sederet sesi agent yang terbuka, beberapa di Manus dan beberapa di Codex. Saya mengklik salah satunya. Prompt-nya adalah pesan Slack saya, disalin kata demi kata.
Setahun lalu, dia akan membaca pesan saya, mencari tahu apa maksud saya, lalu menulis kodenya. Sekarang sebuah agent membaca permintaan tersebut, menemukan kode yang relevan, dan mengusulkan perubahan. Tugas engineer adalah mengarahkan pekerjaan, memeriksanya, dan bertanggung jawab atas hasilnya. Sebagian besar waktu permintaan itu sedang berjalan, bukan menunggu dia. Hari ini, hal yang umum di sini adalah seorang engineer memiliki 10 hingga 20 permintaan yang berjalan sekaligus.
Saya bangga dengan seberapa cepat tim kami beradaptasi. Saya juga merasa gelisah. Apakah kecepatan ini tepat? Apa yang belum kami perhatikan?
Kami membangun agent di Manus, jadi kami menerapkan dua aturan pada diri kami sendiri. Kami menggunakan produk kami sendiri untuk pekerjaan nyata. Dan kami terus mencari tempat-tempat di mana AI berhenti bekerja.
Saya ingin mendokumentasikan apa yang terjadi di dalam sebuah perusahaan ketika orang dan agent bekerja berdampingan secara default. Tulisan ini membahas tiga tim — engineering, produk, dan pemasaran — dan juga mencakup apa yang belum berhasil. Ini adalah laporan dari sebuah eksperimen yang sedang berlangsung, bukan definisi dari sebuah "organisasi AI-native".
Apa yang telah kami pelajari sejauh ini:
•Tidak ada titik tengah. Menambahkan AI ke cara kerja lama kadang justru menambah kebisingan. Hal-hal berubah hanya ketika loop-nya tertutup.
•Agent membutuhkan gambaran utuh. Konteks yang lebih baik lebih berarti bagi kami daripada prompt yang lebih baik.
•Kepercayaan datang dari pengujian dan konteks, bukan dari kualitas model saja.
•Otonomi membutuhkan garis finish. Agent dapat berjalan sendiri hanya ketika keberhasilan dapat diperiksa. Di tempat lain, keputusan ada di tangan manusia.
•Bottleneck berpindah. Ketika engineering menjadi lebih cepat, memutuskan apa yang akan dibangun menjadi kendala.
•Peran manusia tidak berkurang. Peran itu menjadi lebih fokus pada hal-hal yang berdampak lebih besar.
1. Tidak ada titik tengah
Sebelum 2026, kami melakukan apa yang dilakukan sebagian besar perusahaan: kami menambahkan AI ke cara kami sudah bekerja. Ini berarti dukungan akan menandai masalah dengan ringkasan AI, engineer menggunakan asisten pemrograman, dan bot memposting analisis di channel. Setiap bagian berguna dengan sendirinya, tetapi tidak banyak bagian yang terhubung satu sama lain. Sampai loop benar-benar tertutup, kami hanya bekerja dengan cara lama yang sama tetapi dengan banyak AI yang saling berbicara.
Ada sebuah kalimat yang sering kami renungkan: software engineering adalah pemrograman yang terintegrasi sepanjang waktu. Menulis kode mudah diukur; menjaga produk yang kompleks tetap sehat selama bertahun-tahun tidak. Persentase tinggi dari kode yang ditulis AI dapat berarti kemajuan nyata, atau dapat berarti menumpuknya sampah yang nantinya harus dibersihkan oleh seseorang.
Ujian yang kami pedulikan lebih sulit. Manus adalah produk kompleks yang telah berjalan selama lebih dari setahun. Dapatkah ia terus berkembang di bawah cara kerja baru tanpa runtuh, sementara setiap orang dapat menyelesaikan lebih banyak hal? Sejauh ini jawabannya ya.
2. Berikan agent gambaran utuh
Seperti kebanyakan perusahaan teknologi, kami kehilangan waktu paling banyak pada serah terima. Seorang frontend engineer dan backend engineer masing-masing akan menafsirkan sebuah permintaan, menyepakati antarmuka, lalu menghabiskan berhari-hari memperbaiki ketidakcocokan. Dua orang jarang memahami sebuah persyaratan dengan cara yang sama.
Jika AI dapat menulis kode di seluruh stack, bisakah satu orang menangani sebuah permintaan dari ujung ke ujung? Kendalanya adalah konteks. Kode kami berada di repositori terpisah, sehingga tidak ada agent yang bisa melihat keseluruhan sistem sekaligus.
Jawaban kami untuk itu dimulai dengan sebuah eksperimen internal. Kami ingin melihat sejauh mana AI dapat berjalan dalam membangun produk dengan masukan manusia sesedikit mungkin dan hampir tanpa kode yang ditulis tangan. Metode yang kami kembangkan sepanjang jalan menjadi alat internal yang sekarang kami sebut Manus-mono, atau Mono.
Mono tidak menggabungkan repositori kami. Ini adalah satu titik masuk tunggal ditambah panduan yang ditulis untuk Agent: apa yang dilakukan setiap repositori, bagaimana mereka saling berhubungan, dan bagaimana kami bekerja. Agent menarik apa pun yang dibutuhkannya. Kami juga menyimpan 库 catatan keputusan arsitektur, sehingga setiap sesi Agent dimulai dengan alasan di balik keputusan masa lalu, bukan hanya kodenya. Ketika siapa pun bekerja dengan Agent, Agent tersebut memiliki konteks dari semua orang yang datang sebelumnya.
Mono tumbuh dalam langkah-langkah, dan setiap langkah memperbaiki hambatan yang diungkap oleh langkah sebelumnya:
1.Lihat keseluruhan sistem. Kami menambahkan konteks bisnis yang tidak dimiliki oleh satu repositori pun, dan menggunakan Git worktrees untuk pekerjaan paralel.
2.Verifikasi secara lokal. Push ke lingkungan pengujian dulu memakan waktu 5 hingga 10 menit. Sekarang seluruh stack Manus berjalan di laptop, dan pemeriksaan hanya memakan waktu beberapa detik.
3.Debug masalah produksi. Dengan izin yang terbatas, Mono dapat membaca log, konfigurasi, dan laporan kesalahan yang dibutuhkannya untuk mendiagnosis bug di produksi.
4.Jalankan rilis dari ujung ke ujung. Mono sekarang menangani langkah-langkah rilis di mana pekerjaan dulu sering terhenti. Orang masih membuat keputusan persetujuan.
5.Uji dari ujung ke ujung. Ketika verifikasi menjadi bagian yang lambat, Mono mulai menjalankan alur pengguna nyata dengan akun uji, di browser dan di simulator mobile.
(Bagaimana Mono bekerja dan bagaimana ia berkembang. Dibuat oleh seorang rekan tim dengan Manus.)
Orang terkadang bertanya apakah Mono adalah wiki kode. Dokumentasi adalah salah satu bagiannya, tetapi sisanya adalah segala sesuatu di sekitar kode: bagaimana kami menguji, bagaimana kami merilis, apa yang kami putuskan dan mengapa, serta apa yang boleh dan tidak boleh disentuh oleh Agent.
Seiring waktu, Mono telah menjadi basis pengetahuan bersama yang menjadi lebih baik seiring orang menambahkannya. Misalnya, insinyur ops kami lelah dimintai bantuan dengan rilis, jadi dia menulis proses rilis ke dalam Mono. Sekarang siapa pun dapat menjalankan rilis, demikian juga Agent, tetapi persetujuan tetap berada di tangan orang-orang yang memiliki hak rilis. Saya suka cara tim bekerja: satu orang memperbaiki frustrasinya sendiri, yang menyebabkan seluruh perusahaan menjadi sedikit lebih cepat.
Tim sekarang berasumsi bahwa satu orang dapat mengirimkan permintaan di setiap platform. Tim mobile kami telah berjumlah tujuh orang selama ini. Mereka memelihara empat aplikasi di dua produk dan tetap mengikuti kecepatan web.
Mono menyebar ke seluruh perusahaan tanpa mandat dari atas ke bawah. Saya pikir budaya menjelaskan hal itu sebanyak alatnya. Menguji batas AI adalah bagian dari alasan keberadaan kami, dan organisasi kami datar. Alat hanya berjalan sejauh organisasi mengizinkannya.
3. Tutup loop: dari laporan bug pengguna ke perbaikan yang terverifikasi
Mono memungkinkan siapa pun untuk mengerjakan bagian apa pun dari produk. Itu adalah setengah bagiannya. Setengah lainnya adalah membiarkan Agent menemukan masalah sendiri.
Di sebagian besar perusahaan internet, laporan bug pengguna melewati dukungan, produk, dan triase sebelum mencapai insinyur yang dapat memperbaikinya.
Bagi kami, Agent internal sekarang menyelidiki laporan terlebih dahulu dan melacak masalah kembali ke perubahan yang menyebabkannya. Kemudian ia memposting di Slack dan menandai insinyur yang memiliki perubahan tersebut. Insinyur memutuskan apakah itu miliknya untuk diperbaiki dan menyerahkannya ke Agent miliknya sendiri. Agent terpisah memeriksa perbaikan dengan menjalankan pengujian dan alur yang penting.
Tiga Agent, tiga peran: satu melakukan triase, satu melakukan pekerjaan, satu memeriksanya. Orang di tengah membuat keputusan. Bagian yang terus berkembang dari pekerjaan rekayasa kami sekarang dimulai dengan cara ini, dengan Agent membawa masalah kepada seseorang.
Loop ini memiliki batasan yang jelas. Agent yang membaca laporan pengguna tidak dapat mengubah kode. Ia hanya dapat menyelidiki dan melaporkan kembali kepada kami. Perubahan datang dari Agent milik insinyur itu sendiri, setelah insinyur memutuskan. Tidak ada yang dirilis tanpa persetujuan dari orang yang memiliki hak rilis.
4. Bagaimana kami belajar mempercayai kode yang ditulis agent
Untuk waktu yang lama, setiap perubahan yang masuk ke branch utama kami memerlukan persetujuan dari salah satu dari dua senior engineer. Kami tidak cukup mempercayai AI untuk melewati langkah tersebut. Seiring agent menghasilkan lebih banyak kode, langkah review itu menjadi hambatan.
Dalam hal kemampuan coding murni, model-model tersebut sudah kuat. Kami menyadari perbedaannya terletak pada dua hal. Pertama, orang tahu cara menguji pekerjaan mereka. Kedua, orang telah menjadi bagian dari diskusi di hulu dan hilir, sehingga mereka tahu apa arti "benar" bagi bisnis. Kode yang benar tidak sama dengan produk yang benar.
Kami mengatasi keduanya:
•Biarkan agent bergabung dalam diskusi. Agent setiap engineer sekarang ada di thread Slack tempat ia ditambahkan, dan mengikuti konteksnya. Ketika seseorang akhirnya berkata "Go," agent sudah tahu apa yang telah diputuskan tim dan mengapa.
•Biarkan agent menguji secara end-to-end. Bekerja dengan tim backend kami, kami memberi agent kemampuan untuk menjalankan alur nyata dan tes regresi di Manus setelah setiap perubahan. Seiring cakupan tes bertambah, kepercayaan kami juga bertambah.
Saat ini, setiap perubahan melalui verifikasi tersebut dan melalui bot code review yang menjalankan model terkuat yang tersedia, dengan aturan tambahan untuk area sensitif seperti pembayaran. Bot menggantikan antrean, bukan keputusan manusia. Agent dapat membuka pull request, tetapi tidak dapat merge ke branch utama kami tanpa persetujuan eksplisit dari seseorang. Orang tetap memutuskan apa yang akan dibangun dan siapa yang dapat merilis.
5. Otonomi membutuhkan tujuan akhir
Kepercayaan memiliki batas, dan kami mengetahuinya dengan cara yang sulit.
Pada suatu titik, semua orang bersemangat tentang loop agent yang sepenuhnya otonom, jadi kami mencobanya. Sebuah agent mengumpulkan feedback dari saluran feedback internal kami dan memulai proyek untuk setiap item. Seorang rekan tim membiarkannya berjalan selama akhir pekan. Pada Senin pagi, lebih dari 200 item menunggu keputusannya.
Mengapa tidak membiarkan agent membuat keputusan itu juga? Loop otonom bekerja ketika sistem dapat memeriksa apakah tujuan telah terpenuhi. Tes lulus atau gagal; halaman dimuat atau tidak. Sebagian besar pekerjaan nyata tidak memiliki pemeriksaan seperti itu. Seseorang harus menilai apakah sudah selesai, dan apakah itu memang layak dilakukan.
Kami mengambil dua pelajaran dari akhir pekan itu. Pertama, orang tidak dapat membuat keputusan secepat loop tanpa periksa membuatnya. Kedua, jika tidak ada yang memutuskan apakah sesuatu harus dilakukan, tidak ada yang memiliki hasilnya. Loop perbaikan bug di bagian 3 bekerja karena tes mendefinisikan keberhasilan. Keputusan produk tidak memiliki tes, jadi setiap perubahan produk di Manus masih dimulai dengan seseorang yang memutuskan apakah itu layak dilakukan.
6. Ketika engineering menjadi lebih cepat, produk menjadi hambatan
Proses produk tradisional memiliki banyak serah terima, dan prioritas sedikit bergeser pada setiap tahap. Saat coding agent membuat engineer lebih cepat, muncul masalah baru: tidak ada cukup product manager untuk menulis persyaratan yang baik. Untuk pertama kalinya, engineering bukan lagi kendala.
Di Manus, perbaikan pertama kami adalah meminta beberapa engineer untuk menjadi "builder" yang memiliki masalah dari penemuan hingga peluncuran. Hanya sedikit orang yang memiliki penilaian teknis dan produk sekaligus. Selanjutnya kami membiarkan PM mengubah kode. Itu pun terhenti. Serah terima masih ada, dan tanpa insting engineer, PM dapat mengubah teks dan interaksi tetapi tidak logika yang mendasarinya.
Mono memecahkan kedua masalah tersebut karena ia membawa aturan bersamanya:
•Setiap perubahan yang menyentuh pemanggilan model atau biaya memerlukan persetujuan pemilik sebelum kode ditulis.
•Setiap perubahan melalui review dan pengujian yang sama seperti perubahan engineer.
•Mono dapat menelusuri sign-up dan pembayaran dengan akun tes dan mencatat setiap langkah, sehingga PM dapat menunjukkan momen tepat sesuatu rusak.
Berikut tampilannya dalam praktik. Seorang PM yang mengerjakan speech-to-text meminta Manus melakukan benchmark lebih dari 10 model, kemudian memilih satu. Dia menarik kode frontend melalui Mono, membangun demo dalam sistem desain kami, dan meminta Manus merender setiap skenario pengguna sebagai gambar untuk dia tinjau. Dia mengubah demo menjadi video. Rencananya cukup jelas sehingga dia membangun fitur itu sendiri, termasuk UI web dan desktop.
Orang-orang membuat tiga keputusan di sepanjang jalan. Dia memilih model. Produk dan desain meninjau demo. Seorang insinyur dengan hak rilis meninjau kode. Setahun yang lalu, tidak satu pun dari ini akan mungkin.
Kami menggambarkan ini sebagai beralih dari human in the loop menjadi human on the loop. AI dulu melakukan 70-80% dari sebuah tugas dan orang mengisi sisanya. Sekarang orang menetapkan aturan, mengawasi beberapa agent, memeriksa metode dan hasil di titik-titik penting, turun tangan saat diperlukan, dan memiliki hasilnya.
Beberapa PM sekarang menyerahkan video singkat alih-alih spesifikasi tertulis atau mockup. Dalam beberapa menit, video itu menunjukkan use case, setiap layar, apa yang dilakukan setiap klik, bagaimana edge case berperilaku, dan bagaimana semuanya bekerja di baliknya. Bagi kami, desain, teknik, dan QA menyepakati arti "selesai" lebih cepat, dan PM menjelaskannya satu kali.
(Video persyaratan produk untuk input suara)
Hari ini sekitar separuh PM kami merilis fitur sendiri, dan setiap PM telah melakukan commit kode. Para desainer pun sudah mulai. Satu PM menulis sebagian besar antarmuka Manus Studio di Manus 2.0. Yang lain menulis Video Editor. Di balik masing-masing ini ada seseorang yang menghabiskan berbulan-bulan mendorong melampaui apa yang biasanya menjadi cakupan perannya. Itulah yang paling saya banggakan.
Ini tidak berarti setiap orang harus menjadi builder. Ketika siapa pun di sebuah perusahaan dapat membangun, orang mungkin merilis hal-hal yang seharusnya tidak ada. Tim produk kami sering mengajukan satu pertanyaan: "Jika ini membutuhkan satu detik dan tidak berbiaya, apakah Anda akan merilisnya?" Terkadang jawabannya adalah tidak. Kami tetap membutuhkan pemilik modul yang memutuskan apa yang dibangun, apa yang tidak, dan apa yang akhirnya dilihat pengguna. Kami juga membutuhkan orang-orang yang memelihara infrastruktur seperti Mono. Ketika membangun menjadi mudah, memutuskan apa yang akan dibangun menjadi lebih penting.
7. Rekan satu tim AI di dalam alur kerja pemasaran
Kemitraan pemasaran bergerak melalui tinjauan naskah, penetapan harga, kontrak, persetujuan, pembayaran, peluncuran, dan tinjauan hasil. Langkah-langkah tersebut berada di email, alat kontrak, sistem persetujuan, spreadsheet, dan platform iklan. Sebagian besar pekerjaan dulu adalah memindahkan informasi di antaranya, yang menyisakan sedikit waktu untuk pekerjaan kreatif yang membutuhkan penilaian.
Kami mulai dengan satu masalah kecil: ketika konten mitra atau sebuah iklan tayang, kami sering mendengarnya terlambat. Jadi kami meminta AI menulis skrip yang mendeteksi kapan konten dipublikasikan. Lalu kami menginginkan data performa. Lalu tinjauan kemitraan masa lalu. Kemudian seluruh alur kerja internal terhubung: ketika kontrak ditandatangani atau sebuah persetujuan disetujui, agent memperbarui status dan memberi tahu siapa pun yang memiliki langkah berikutnya.
Manus membangun semua ini ke dalam situs internal. Bagi orang-orang, itu adalah dasbor dan kalender. Bagi agent, itu adalah seperangkat alat. Agent yang menggunakan alat-alat tersebut di dalam alur kerja kami adalah yang kami sebut sebagai rekan satu tim AI. Ia hanya bekerja di saluran dan sistem yang telah dihubungkan tim dengannya, dengan akses terbatas pada alur kerja ini.
Inilah yang dilakukannya:
•Ia mengelola antreannya sendiri. Banyak orang mengirim pesan kepadanya sekaligus, jadi ia berbicara dengan semua orang dalam satu sesi "meja depan" dan menyerahkan tugas ke sesi paralel. Ia memutuskan apakah sebuah pesan relevan dengannya, lalu apakah akan menginterupsi pekerjaan saat ini atau menunggu. Ia sendiri mengusulkan aturan-aturan ini selama pengembangan, dan kami meninjaunya sebelum mempertahankannya.
•Ia belajar dari konteks yang diteruskan. Perubahan strategi dulu berarti rapat dan brief tertulis. Sekarang pemimpin pemasaran kami meneruskan diskusi dan berkata, "Pelajari ini."
•Ia menjaga tujuan jangka panjang tetap terlihat. Pada satu kesempatan, rekan satu tim di sebuah thread Slack yang telah dimasukkan ke dalamnya tidak dapat mengingat di mana sebuah proyek berada. Tanpa di-tag, ia menjawab: "B masih dalam pengujian. Haruskah kita menunggu hasil A sebelum melihat B?"
•Ia memeriksa fakta dengan tim lain. Setelah kami meluncurkan rigging model 3D, ia bertanya kepada tim produk apa yang didukung. Ia mengetahui bahwa rigging mencakup tujuh kategori, termasuk ikan, ular, dan hewan berkaki empat, sehingga deskripsi kami tetap akurat.
Rekan satu tim sekarang mengajaknya dalam tinjauan naskah dan penetapan harga, karena ia telah membaca catatan kemitraan kami sebelumnya. Orang-orang tetap yang membuat keputusan.
Situs internal juga dapat meningkat dari penggunanya sendiri, termasuk agent. Ketika agent menemui hambatan, ia mengajukan permintaan melalui endpoint umpan balik. Itu membuka tugas pengembangan di Manus melalui Automations di Manus 2.0, dan seorang insinyur meninjau perubahan sebelum dirilis. Ini telah berjalan sekitar seminggu. Kami membutuhkan lebih banyak kasus sebelum kami mengandalkannya.
Jadi apa yang dilakukan orang-orang di tim? Tiga hal tetap pada mereka. Mereka membuat dan memiliki setiap keputusan penting. Mereka menangani kasus yang belum pernah dilihat agent, dan mengajarinya apa yang harus dilakukan atau kepada siapa harus bertanya. Dan mereka mengarahkannya kembali kapan pun analisisnya menunjuk ke sudut pandang baru.
8. Saling mengganggu lebih sedikit
Di seluruh tim-tim ini, banyak pertanyaan tidak lagi memerlukan menginterupsi seseorang.
Tanya Agent dulu. Seorang rekan tim membangun bot Slack di Mono yang berjalan di komputer cloud dan membalas di thread. Non-engineer paling sering menggunakannya. Bagaimana cara kerja fitur ini? Di mana string ini? Apakah ini sudah dirilis? Mereka tidak perlu lagi mencari pemiliknya terlebih dahulu.
Buka sesinya alih-alih meminta update status. Progres seorang engineer dulu tersimpan di chat AI mereka sendiri, tidak terlihat begitu mereka logout. Jadi kami membangun fitur internal yang memungkinkan anggota sebuah project melihat sesi satu sama lain dan meminta untuk bergabung. Seorang engineer mungkin membangun sebagian besar fitur dengan Agent, lalu seorang PM bergabung ke sesi yang sama untuk menyesuaikan spacing, style, dan copy. Memposting di sesi orang lain memerlukan persetujuan mereka, dan kami masih menyusun pengaturan izinnya.
(Contoh ilustratif: bagaimana seorang engineer, PM, dan desainer bekerja dalam satu sesi. Bukan perubahan harga yang sesungguhnya.)
Intinya bukan agar kita lebih sedikit berbicara satu sama lain. Intinya adalah agar kita lebih sedikit menginterupsi satu sama lain.
Putuskan hanya apa yang perlu diputuskan. Pengguna AI terberat kami mempertahankan satu sesi utama dengan satu tugas: mencantumkan apa yang memerlukan keputusannya, dengan rekomendasi untuk masing-masing. Ketika Slack menjadi sibuk, dia tidak ikut campur dan bertanya, "Apa yang perlu saya putuskan sekarang?"
Saya melakukan sesuatu yang serupa. Saya memiliki lebih dari 20 to-do setiap hari, dan, seperti yang telah saya bagikan secara publik, saya memiliki ADHD. Memulai adalah bagian tersulit bagi saya. Sekarang setiap to-do masuk ke Manus project khusus yang mengubah masing-masing menjadi tugasnya sendiri. Ia memulai apa yang bisa dimulainya. Ketika tidak yakin, ia bertanya kepada saya untuk latar belakang dan PM mana yang seharusnya menanganinya. Kemudian, menggunakan akses yang saya berikan ke Slack, Gmail, dan Notion saya sendiri, ia mengumpulkan konteks dan menyerahkan permintaan yang lengkap kepada PM alih-alih catatan satu baris. Bagi saya, perubahannya tidak hanya tentang efisiensi. Sekarang saya menghabiskan jauh lebih sedikit waktu dalam sehari untuk merasa cemas tentang dari mana harus memulai, yang sangat besar artinya di level pribadi.
9. Apakah sepadan dengan biayanya?
Kami menghabiskan banyak untuk AI, dan kami melacak pengeluaran itu dengan ketat. Kami tidak menggunakannya untuk menilai performa siapa pun. Kami menggunakannya untuk menilai pengeluaran itu sendiri: apakah ia membuahkan hasil sekarang, atau mempersiapkan kami untuk nanti?
Inilah yang menurut kami ia belikan untuk kami, dan ke mana kami memperkirakan biayanya akan bergerak:
•Ia membeli waktu dan perhatian. Seiring tim bertumbuh, koordinasi memakan perhatian setiap orang. AI melindungi perhatian setiap individu dan memberi mereka kepemilikan yang lebih penuh atas pekerjaan mereka. Dan kami masih merekrut.
•Menggunakan model terbaik adalah cara kami mempelajari di mana batasan AI. Setup verifikasi dan code review yang dijelaskan di bagian 4 berjalan pada model-model terkuat yang bisa kami dapatkan. Rekan yang memimpin produktivitas developer menyebutnya sebagai pengeluaran dengan nilai terbaik kami.
•Biaya seharusnya turun melalui produk. Lebih banyak pengembangan kami kini terjadi di Manus Studio, produk kami sendiri, sehingga data penggunaan kami menunjukkan di mana tokens terbuang. Perbaikannya masuk ke produk, sehingga seharusnya membuat Manus lebih efisien juga bagi pengguna. Kami memperkirakan biaya hari ini akan turun secara substansial seiring model menjadi lebih murah dan kami menghilangkan pemborosan. Itu adalah keyakinan, bukan janji!
10. Apa yang belum berfungsi
Interupsi lebih sedikit, tetapi perhatian lebih terpecah. Seseorang yang dulu menangani empat atau lima hal sehari sekarang mungkin mendorong 20 atau 30 hal maju sekaligus. Setiap perpindahan berarti memuat ulang konteks. AI memperluas apa yang dapat dilakukan orang, dan juga mendorong mereka untuk melakukan lebih banyak. Seorang PM memberitahu saya bahwa setiap kali ada tugas yang berjalan, dia tidak bisa menahan diri untuk memulai Agent lain. Melakukan lebih banyak hal bukanlah tujuannya. Kami memperlakukan ini sebagai masalah yang harus diselesaikan, bukan tempo yang harus dirayakan.
Informasi lebih tersebar. Head of product kami dulu mengetahui setiap perubahan dan alasannya dibuat. Sekarang dia terkadang mengambil screenshot sebuah masalah dan bertanya ke Mono, "Siapa yang mengubah ini?" Ini lucu, tetapi pertanyaannya nyata. Ketika semua orang diberdayakan untuk mengubah produk, siapa yang bertanggung jawab atas keseluruhan?
Izin berbagi perlu didesain ulang. Ketika pekerjaan bisa dibagikan dan dialihkan, dan Agent duduk di lebih banyak percakapan kami, kami harus memutuskan apa yang terbuka dan apa yang memerlukan persetujuan.
Perbaikan kami masih dasar. Untuk saat ini, satu Agent mengawasi yang lain dan hanya melaporkan apa yang macet dan apa yang memerlukan keputusan manusia. Kami tahu ini bisa lebih baik.
11. Apa yang kami bangun selanjutnya
Masalah-masalah ini mengarah pada pekerjaan produk yang mungkin juga dibutuhkan tim lain. Kami tidak merencanakan fitur-fitur ini sebelumnya. Semuanya muncul dari masalah yang terus kami hadapi sendiri.
•Sesi sebagai ruang kerja bersama. Satu orang mengangkat masalah, seorang desainer mengusulkan perbaikan, seorang engineer membangunnya, dan seorang PM menjalankannya, semua di tempat yang sama.
•Pekerjaan yang berpindah lintas perangkat dan orang. Mesin lokal dan cloud tetap terhubung, sehingga pekerjaan dapat berlanjut saat orang pergi.
•Agent yang menemukan opsi yang belum dipertimbangkan orang. Sebuah agent yang bekerja di dalam sistem perusahaan, dengan izin yang tepat, seharusnya dapat menyarankan solusi, bukan hanya menjalankan instruksi.
Kami akan mencoba ini pada diri kami sendiri terlebih dahulu, lalu membawanya kepada pengguna.
12. Apa yang dilakukan orang sekarang
Engineer dengan deretan sesi agent yang terbuka bukan sekadar cerita tentang efisiensi. Ini adalah perubahan dalam apa yang menjadi dasar operasi sebuah organisasi. Perusahaan dulu menggerakkan informasi melalui peran dan hierarki. Apa yang bisa dilakukan seseorang bergantung pada berapa banyak orang dan sumber daya yang bisa mereka manfaatkan. Sekarang kami menghabiskan sedikit waktu untuk memberikan konteks dan alat kepada AI, dan lebih banyak waktu untuk membuat penilaian dan keputusan. Semakin sering, agent-lah yang membawa masalah kepada kami. Memutuskan apa yang harus dilakukan tentangnya tetap menjadi tugas kami.
Kami pernah bercanda tentang hal ini: jika Manus bisa melakukan sebanyak ini, mengapa harus datang ke kantor? Biarkan agent yang menyelesaikannya. Tetapi pertanyaan-pertanyaan penting masih membutuhkan orang untuk mengangkatnya, memperdebatkannya, dan memutuskannya. Misalnya, apa yang dianggap sebagai produk yang baik? Atau, agak dilebih-lebihkan: membangun produk hebat dengan pendapatan nyata yang terus mendorong batas AI, atau mengejar margin? AI tidak tahu mana yang kami inginkan. Kami yang tahu. Budaya dan kepercayaan muncul dari menyelesaikan hal-hal bersama, hari demi hari dan di saat-saat yang penting. Itulah fondasi tempat pekerjaan di setiap sesi berpijak.
Jadi, untuk saat ini, inilah jawaban kami. Dalam eksperimen kami sebagai organisasi AI-native, peran manusia tidak berkurang. Peran itu menjadi lebih terfokus pada area di mana mereka dapat memberikan dampak terbesar: mendefinisikan masalah, menilai kualitas, memutuskan apa yang layak dilakukan, memiliki hasilnya.
Itu juga sebabnya kami masih merekrut. Keterampilan dan penilaian manusia berada di pusat cara kerja ini — dan itu tidak akan berubah dalam waktu dekat.
Saat saya menulis ini, saya penasaran apa yang akan dikatakan tulisan ini setahun dari sekarang. Setiap perusahaan memiliki tujuan, struktur, dan budaya yang berbeda, jadi mungkin tidak ada jawaban standar dan tidak ada bentuk akhir. Tetapi untuk perusahaan yang membangun agent, mencari tahu bagaimana manusia dan AI bekerja sama bukanlah pilihan. Itu adalah bagian dari pekerjaan. Kami akan terus melakukannya, dan kami akan terus membagikan apa yang kami pelajari.
Catatan tentang angka-angka. Angka-angka dalam tulisan ini berasal dari catatan internal. Ukuran tim dan angka pengiriman PM adalah per akhir Oktober. Beberapa poin merupakan estimasi atau pengalaman satu orang, bukan pengukuran.
