Manus ile Manus'u yeniden inşa etmek: Ne değişti, ne bozuldu ve şimdi nasıl çalışıyoruz
Yazar: Tao Zhang, Kurucu Ortak ve Baş Ürün Yöneticisi, Manus
Eylül ayının sonlarında, Manus 2.0 için son hazırlıklar sırasında, mühendislerimizden birine Slack üzerinden birkaç özellik isteği ve hata raporu gönderdim. Daha sonra işlerin nasıl gittiğini kontrol etmeye gittim. Ekranında bir dizi açık agent oturumu vardı, bazıları Manus'ta bazıları Codex'teydi. Birine tıkladım. Prompt, Slack mesajımdı — kelimesi kelimesine yapıştırılmıştı.
Bir yıl önce olsaydı, mesajımı okur, ne demek istediğimi çözer ve ardından kodu yazardı. Şimdi bir agent isteği okuyor, ilgili kodu buluyor ve bir değişiklik öneriyor. Mühendisin işi çalışmayı yönlendirmek, kontrol etmek ve sonucun sorumluluğunu üstlenmek. Çoğu zaman bir istek çalışıyor, onu beklemiyor. Bugün burada bir mühendisin aynı anda 10 ila 20 isteği hareket halinde tutması yaygın.
Ekibimizin bu kadar hızlı uyum sağlamasıyla gurur duyuyorum. Aynı zamanda tedirginim. Bu hız doğru mu? Henüz fark etmediğimiz neler var?
Manus'ta agent'lar inşa ediyoruz, bu yüzden kendimizi iki kurala bağlıyoruz. Kendi ürünümüzü gerçek iş için kullanıyoruz. Ve AI'ın çalışmayı bıraktığı yerleri aramaya devam ediyoruz.
İnsanlar ve agent'lar varsayılan olarak yan yana çalıştığında bir şirketin içinde neler olduğunu belgelemek istiyorum. Bu yazı üç ekibi — mühendislik, ürün ve pazarlama — kapsıyor ve işe yaramayan şeyleri de içeriyor. Bu, devam eden bir deneyin raporu, bir "AI-native organizasyon" tanımı değil.
Şimdiye kadar öğrendiklerimiz:
•Yarı yol diye bir şey yok. Eski çalışma biçimlerine AI eklemek bazen gürültü yarattı. Her şey ancak döngü kapandığında değişti.
•Agent'ların bütün resme ihtiyacı var. Daha iyi bağlam, bizim için daha iyi prompt'lardan daha fazla iş gördü.
•Güven; testlerden ve bağlamdan gelir, yalnızca model kalitesinden değil.
•Özerkliğin bir bitiş çizgisine ihtiyacı var. Agent'lar yalnızca başarı kontrol edilebildiğinde kendi başlarına çalışabilir. Diğer her yerde kararı bir insan verir.
•Darboğaz yer değiştirir. Mühendislik hızlandığında, ne inşa edileceğine karar vermek kısıt haline geldi.
•İnsanların rolü azalmadı. Daha yüksek etkili şeylere odaklanır hale geldi.
1. Yarı yol diye bir şey yok
2026'dan önce, çoğu şirketin yaptığını yaptık: zaten çalıştığımız şekle AI ekledik. Bu, desteğin sorunları bir AI özetiyle işaretlemesi, mühendislerin kodlama asistanları kullanması ve botların kanallara analiz göndermesi anlamına geliyordu. Her parça kendi başına yararlıydı, ancak parçaların çoğu birbirine bağlı değildi. Döngü gerçekten kapanana kadar, aynı eski yöntemle çalışıyorduk, sadece birbirinin üstünde konuşan bir sürü AI vardı.
Sık sık geri döndüğümüz bir söz var: yazılım mühendisliği, zamana entegre edilmiş programlamadır. Kod yazmayı ölçmek kolaydır; karmaşık bir ürünü yıllarca sağlıklı tutmak değildir. Yüksek oranda AI ile yazılmış kod, gerçek ilerleme anlamına gelebilir ya da birinin sonradan temizlemek zorunda kalacağı bir karmaşa yığmak anlamına gelebilir.
Önemsediğimiz test daha zor. Manus, bir yılı aşkın süredir yayında olan karmaşık bir ürün. Her kişi daha fazlasını yaparken, çökmeden yeni çalışma biçimleri altında gelişmeye devam edebilir mi? Şimdiye kadar cevap evet.
2. Agent'a bütün resmi verin
Çoğu teknoloji şirketi gibi, en çok zamanı devirlerde kaybediyorduk. Bir frontend mühendisi ve bir backend mühendisi, her biri bir isteği yorumlar, bir arayüz üzerinde anlaşır ve ardından uyumsuzlukları düzeltmek için günler harcardı. İki kişinin bir gereksinimi aynı şekilde anlaması nadirdir.
Eğer AI tüm stack boyunca kod yazabiliyorsa, bir kişi bir isteği uçtan uca sahiplenebilir miydi? Engel bağlamdı. Kodumuz ayrı depolarda yaşıyordu, bu yüzden hiçbir agent tüm sistemi aynı anda göremezdi.
Buna verdiğimiz yanıt dahili bir deneyle başladı. AI'ın mümkün olduğunca az insan girdisi ve neredeyse hiç elle yazılmış kod olmadan bir ürün geliştirmede ne kadar ileri gidebileceğini görmek istedik. Bu süreçte geliştirdiğimiz yöntem, şimdi Manus-mono veya Mono olarak adlandırdığımız dahili aracımız haline geldi.
Mono depolarımızı birleştirmez. Tek bir giriş noktası ve Agent için yazılmış bir kılavuzdan ibarettir: her deponun ne yaptığı, nasıl bir araya geldikleri ve nasıl çalıştığımız. Agent ihtiyaç duyduğu şeyleri çeker. Ayrıca bir mimari karar kayıtları kütüphanesi tutuyoruz, böylece her Agent oturumu sadece kodla değil, geçmiş kararların arkasındaki akıl yürütmeyle başlar. Herhangi biri bir Agent ile çalıştığında, o Agent kendisinden önce gelenlerin bağlamına sahiptir.
Mono adım adım büyüdü ve her adım, bir öncekinin ortaya çıkardığı darboğazı giderdi:
1.Sistemin tamamını görün. Hiçbir deponun tek başına içermediği iş bağlamını ekledik ve paralel çalışma için Git worktree'leri kullandık.
2.Yerel olarak doğrulayın. Test ortamına bir push eskiden 5 ila 10 dakika sürerdi. Şimdi Manus yığınının tamamı bir dizüstü bilgisayarda çalışıyor ve kontroller saniyeler sürüyor.
3.Üretim sorunlarını hata ayıklayın. Kapsamlı izinlerle Mono, üretimdeki hataları teşhis etmek için ihtiyaç duyduğu günlükleri, yapılandırmayı ve hata raporlarını okuyabilir.
4.Sürümleri uçtan uca yürütün. Mono artık çalışmanın eskiden takıldığı sürüm adımlarını yönetiyor. Onay kararlarını hâlâ insanlar veriyor.
5.Uçtan uca test edin. Doğrulama yavaş bir parça haline geldiğinde, Mono test hesaplarıyla gerçek kullanıcı akışlarını bir tarayıcıda ve bir mobil simülatörde çalıştırmaya başladı.
(Mono'nun nasıl çalıştığı ve nasıl evrildiği. Bir takım arkadaşı tarafından Manus ile yapıldı.)
İnsanlar bazen Mono'nun bir kod wiki'si olup olmadığını soruyor. Dokümantasyon bunun bir parçası, ancak geri kalanı kodun etrafındaki her şey: nasıl test ettiğimiz, nasıl sürüm yayınladığımız, ne karar verdiğimiz ve neden, Agent'ın neye dokunmasına izin verilip neye izin verilmediği.
Zamanla Mono, insanların katkılarıyla daha iyi hale gelen paylaşımlı bir bilgi tabanı haline geldi. Örneğin, operasyon mühendisimiz sürümlerde yardım istenmekten bıkmıştı, bu yüzden sürüm sürecini Mono'ya yazdı. Artık herkes bir sürüm yürütebilir ve Agent da yapabilir, ancak onay hâlâ sürüm haklarına sahip insanlara aittir. Takımın çalışma şeklini seviyorum: bir kişi kendi hayal kırıklığını giderdi ve bu, tüm şirketin biraz daha hızlanmasını sağladı.
Takım artık bir kişinin her platformda bir istek yayınlayabileceğini varsayıyor. Mobil takımımız bu süre boyunca yedi kişi oldu. İki ürün genelinde dört uygulamayı sürdürüyorlar ve web ile aynı hızda ilerliyorlar.
Mono şirkette yukarıdan aşağıya bir emir olmadan yayıldı. Bence kültür bunu araç kadar açıklıyor. AI'ın sınırlarını test etmek, var olma nedenlerimizden biri ve organizasyonumuz yatay. Bir araç, ancak organizasyonun izin verdiği kadar ileri gider.
3. Döngüyü kapatın: bir kullanıcının hata raporundan doğrulanmış bir düzeltmeye
Mono, herkesin ürünün herhangi bir parçası üzerinde çalışmasına izin verdi. Bu yarısıydı. Diğer yarısı, Agent'ların sorunları kendi başlarına bulmalarına izin vermekti.
Çoğu internet şirketinde, bir kullanıcının hata raporu, onu düzeltebilecek bir mühendise ulaşmadan önce destek, ürün ve triyaj aşamalarından geçer.
Bizim için, dahili bir Agent artık raporu önce araştırıyor ve sorunu, ona neden olan değişikliğe kadar takip ediyor. Ardından Slack'te paylaşım yapıyor ve o değişikliğin sahibi olan mühendisi etiketliyor. Mühendis, bunun düzeltmesinin kendisine ait olup olmadığına karar veriyor ve kendi Agent'ına devrediyor. Ayrı bir Agent, önemli olan testleri ve akışları çalıştırarak düzeltmeyi kontrol ediyor.
Üç Agent, üç rol: biri triyaj yapar, biri işi yapar, biri kontrol eder. Ortadaki kişi kararları verir. Mühendislik işimizin giderek artan bir kısmı artık bu şekilde başlıyor; bir Agent bir sorunu bir kişiye getiriyor.
Bu döngünün net sınırları var. Kullanıcı raporlarını okuyan Agent kodu değiştiremez. Yalnızca araştırabilir ve bize geri bildirim verebilir. Değişiklikler, mühendisin kararından sonra mühendisin kendi Agent'ından gelir. Hiçbir şey, sürüm haklarına sahip bir kişinin onayı olmadan yayınlanmaz.
4. Agent tarafından yazılan koda nasıl güvenmeyi öğrendik
Uzun bir süre boyunca, ana dalımıza giren her değişiklik iki kıdemli mühendisten birinin onayına ihtiyaç duyuyordu. AI'a bu adımı atlayacak kadar güvenmiyorduk. Agent'lar daha fazla kod ürettikçe, bu inceleme adımı darboğaz haline geldi.
Saf kodlama yeteneği açısından, modeller zaten güçlüydü. Aradaki farkın iki şeye dayandığını fark ettik. İlk olarak, insanlar kendi işlerini nasıl test edeceklerini bilirler. İkincisi, insanlar yukarı ve aşağı akıştaki tartışmaların bir parçası olmuşlardır, bu yüzden iş için "doğru"nun ne anlama geldiğini bilirler. Doğru kod, doğru ürünle aynı şey değildir.
İkisini de ele aldık:
•Agent'ların tartışmaya katılmasına izin verdik. Her mühendisin agent'ı artık eklendiği Slack konularında yer alıyor ve bağlamı takip ediyor. Biri sonunda "Başla" dediğinde, agent ekibin ne karar verdiğini ve nedenini zaten biliyor.
•Agent'ların uçtan uca test etmesine izin verdik. Backend ekibimizle birlikte çalışarak, agent'lara her değişiklikten sonra Manus'ta gerçek akışları ve regresyon testlerini çalıştırma yeteneği verdik. Test kapsamı büyüdükçe, güvenimiz de onunla birlikte büyüdü.
Bugün, her değişiklik bu doğrulamadan ve mevcut en güçlü modeli çalıştıran bir kod inceleme botundan geçiyor; ödemeler gibi hassas alanlar için ek kurallar var. Bot, insan kararını değil, kuyruğu değiştirdi. Bir agent pull request açabilir, ancak bir kişinin açık onayı olmadan ana dalımıza birleştiremez. Neyin inşa edileceğine ve kimin yayınlayabileceğine hâlâ insanlar karar verir.
5. Özerklik nihai bir hedef gerektirir
Güvenin sınırları vardır ve bunu zor yoldan öğrendik.
Bir noktada, herkes tamamen özerk agent döngüleri konusunda heyecanlıydı, bu yüzden bir tane denedik. Bir agent, dahili geri bildirim kanallarımızdan geri bildirim topladı ve her bir öğe için bir proje başlattı. Bir takım arkadaşı, hafta sonu boyunca çalışmasına izin verdi. Pazartesi sabahı, 200'den fazla öğe onun kararını bekliyordu.
Agent'ın bu kararları da vermesine neden izin vermeyelim? Özerk döngüler, sistem hedefin karşılanıp karşılanmadığını kontrol edebildiğinde çalışır. Testler geçer veya başarısız olur; bir sayfa yüklenir veya yüklenmez. Çoğu gerçek işin böyle bir kontrolü yoktur. Bir kişinin işin bitip bitmediğine ve hatta yapılmaya değer olup olmadığına karar vermesi gerekir.
O hafta sonundan iki ders çıkardık. İlk olarak, insanlar denetimsiz bir döngünün yarattığı hızda kararlar alamaz. İkincisi, eğer hiç kimse bir şeyin yapılıp yapılmaması gerektiğine karar vermezse, kimse sonucun sahibi olmaz. 3. bölümdeki hata düzeltme döngüsü çalışıyor çünkü testler başarıyı tanımlar. Ürün kararlarının testleri yoktur, bu yüzden Manus'taki her ürün değişikliği hâlâ bir kişinin bunun yapılmaya değer olup olmadığına karar vermesiyle başlar.
6. Mühendislik hızlandığında, ürün darboğaz haline geldi
Geleneksel bir ürün süreci birçok devretmeye sahiptir ve her birinde öncelikler biraz kayar. Kodlama agent'ları mühendisleri daha hızlı hale getirdikçe, yeni bir sorun ortaya çıktı: iyi gereksinimler yazacak kadar ürün yöneticisi yoktu. İlk kez, mühendislik kısıtlama değildi.
Manus'ta ilk çözümümüz, birkaç mühendisten keşiften lansmana kadar bir sorunun sahibi olan "inşaatçılar" olmalarını istemekti. Hem teknik hem de ürün muhakemesine sahip çok az kişi vardı. Sonra PM'lerin kod değiştirmesine izin verdik. Bu da takıldı. Devretmeler hâlâ oradaydı ve bir mühendisin içgüdüleri olmadan, PM'ler metin ve etkileşimleri değiştirebilir ancak temel mantığı değiştiremezdi.
Mono her iki sorunu da çözdü çünkü kuralları beraberinde taşıyor:
•Model çağrılarına veya maliyete dokunan herhangi bir değişiklik, kod yazılmadan önce sahibinin onayını gerektirir.
•Her değişiklik, bir mühendisin değişikliği ile aynı inceleme ve testlerden geçer.
•Mono, test hesaplarıyla kaydolma ve ödeme sürecini adım adım inceleyebilir ve her adımı kaydedebilir, böylece bir PM bir şeyin tam olarak nerede bozulduğunu gösterebilir.
Pratikte bunun nasıl göründüğünü anlatalım. Konuşmadan metne üzerinde çalışan bir PM, Manus'a 10'dan fazla modeli karşılaştırmalı olarak değerlendirtti, ardından birini seçti. Frontend kodunu Mono üzerinden çekti, tasarım sistemimizde bir demo oluşturdu ve Manus'a her kullanıcı senaryosunu inceleyebilmesi için görsel olarak oluşturttu. Demoyu bir videoya dönüştürdü. Plan, özelliği web ve masaüstü UI dahil olmak üzere kendisinin inşa etmesine yetecek kadar netti.
Süreç boyunca insanlar üç karar verdi. O, modeli seçti. Ürün ve tasarım ekibi demoyu inceledi. Yayınlama yetkisine sahip bir mühendis kodu inceledi. Bir yıl önce bunların hiçbiri mümkün değildi.
Bunu, insanın döngünün içinde olmasından döngünün üzerinde olmasına geçiş olarak tanımlıyoruz. AI eskiden bir görevin %70-80'ini yapar, insanlar gerisini tamamlardı. Şimdi insanlar kuralları belirliyor, birkaç agent'ı denetliyor, kilit noktalarda yöntemleri ve sonuçları kontrol ediyor, gerektiğinde devreye giriyor ve sonucun sahipliğini üstleniyor.
Bazı PM'ler artık yazılı bir spesifikasyon veya mockup yerine kısa bir video teslim ediyor. Birkaç dakika içinde kullanım senaryosunu, her ekranı, her tıklamanın ne yaptığını, uç durumların nasıl davrandığını ve her şeyin arka planda nasıl çalıştığını gösteriyor. Bizim için tasarım, mühendislik ve QA, "tamamlandı" demenin ne anlama geldiği konusunda daha hızlı anlaşıyor ve PM bunu bir kez açıklıyor.
(Ses girişi için ürün gereksinimi videosu)
Bugün PM'lerimizin yaklaşık yarısı özellikleri kendi başına yayına alıyor ve her PM kod commit'lemiş durumda. Tasarımcılar da başladı. Bir PM, Manus Studio arayüzünün büyük bölümünü Manus 2.0'da yazdı. Bir diğeri Video Editor'ı yazdı. Bunların her birinin arkasında, rolünün eskiden kapsadığı alanın ötesine geçmek için aylarca uğraşan biri var. En çok gurur duyduğum şey bu.
Bu, herkesin bir inşa edici olması gerektiği anlamına gelmez. Bir şirkette herkes inşa edebildiğinde, insanlar var olmaması gereken şeyleri yayına alabilir. Ürün ekibimiz sık sık tek bir soru sorar: "Eğer bu bir saniye sürseydi ve hiçbir maliyeti olmasaydı, yayınlar mıydın?" Bazen cevap hayır oluyor. Hâlâ neyin inşa edileceğine, neyin edilmeyeceğine ve kullanıcıların sonunda ne göreceğine karar veren modül sahiplerine ihtiyacımız var. Ayrıca Mono gibi altyapıyı sürdüren insanlara da ihtiyacımız var. İnşa etmek kolaylaştığında, ne inşa edileceğine karar vermek daha da önem kazanır.
7. Pazarlama iş akışının içinde bir AI takım arkadaşı
Bir pazarlama ortaklığı; senaryo incelemesi, fiyatlandırma, sözleşmeler, onaylar, ödeme, lansman ve sonuç değerlendirmesi aşamalarından geçer. Bu adımlar e-postada, sözleşme araçlarında, onay sistemlerinde, elektronik tablolarda ve reklam platformlarında yürütülür. İşin büyük bölümü eskiden bunlar arasında bilgi taşımaktı ve bu da muhakeme gerektiren yaratıcı iş için çok az zaman bırakıyordu.
Küçük bir sorunla başladık: ortak içeriği veya bir reklam yayına girdiğinde bunu genellikle geç duyuyorduk. Bu yüzden AI'ya içerik yayınlandığında bunu tespit eden bir script yazdırdık. Sonra performans verilerini istedik. Sonra geçmiş ortaklıkların bir değerlendirmesini. Sonra tüm iç iş akışı bağlandı: bir sözleşme imzalandığında veya bir onay geçtiğinde, agent durumu günceller ve bir sonraki adımın sahibini bilgilendirir.
Manus tüm bunları bir iç siteye inşa etti. İnsanlar için bu, dashboard'lar ve bir takvim. Agent için ise bir dizi araç. Bu araçları iş akışımız içinde kullanan agent, bizim AI takım arkadaşı dediğimiz şey. Yalnızca ekibin bağladığı kanallarda ve sistemlerde çalışır, erişimi bu iş akışıyla sınırlıdır.
İşte yaptıkları:
•Kendi kuyruğunu yönetir. Birçok kişi ona aynı anda mesaj gönderir, bu yüzden herkesle tek bir "ön masa" oturumunda konuşur ve görevleri paralel oturumlara aktarır. Bir mesajın kendisi için alakalı olup olmadığına, ardından mevcut işi kesmeli mi yoksa beklemeli mi olduğuna karar verir. Bu kuralları geliştirme sırasında kendisi önerdi ve biz tutmadan önce inceledik.
•İletilen bağlamdan öğrenir. Bir strateji değişikliği eskiden bir toplantı ve yazılı bir brief anlamına gelirdi. Şimdi pazarlama liderimiz tartışmayı iletiyor ve "Bunu öğren" diyor.
•Uzun soluklu hedefleri gözünün önünde tutar. Bir keresinde, eklendiği bir Slack thread'indeki takım arkadaşları bir projenin hangi aşamada olduğunu hatırlayamadı. Etiketlenmeden şöyle yanıt verdi: "B hâlâ test aşamasında. B'ye bakmadan önce A'nın sonuçlarını beklemeli miyiz?"
•Gerçekleri diğer ekiplerle kontrol eder. 3D model rigging'i yayına aldıktan sonra ürün ekibine neyin desteklendiğini sordu. Rigging'in balıklar, yılanlar ve dört ayaklılar dahil yedi kategoriyi kapsadığını öğrendi, böylece açıklamalarımız doğru kaldı.
Takım arkadaşları artık onu senaryo ve fiyatlandırma değerlendirmelerine dahil ediyor, çünkü geçmiş ortaklık kayıtlarımızı okumuş durumda. Kararı yine insanlar veriyor.
İç site, agent dahil kendi kullanıcılarından da iyileşebilir. Agent bir sürtüşmeyle karşılaştığında, bir feedback endpoint'i aracılığıyla talep gönderir. Bu, Manus 2.0'daki Automations aracılığıyla Manus'ta bir geliştirme görevi açar ve yayınlanmadan önce bir mühendis değişikliği inceler. Yaklaşık bir haftadır çalışıyor. Buna güvenmeden önce çok daha fazla vakaya ihtiyacımız var.
Peki ekipteki insanlar ne yapıyor? Üç şey onlarda kalıyor. Her önemli kararı veriyor ve sahipleniyorlar. Agent'ın görmediği durumları ele alıyor ve ona ne yapması veya kime sorması gerektiğini öğretiyorlar. Ve analizi yeni bir açıya işaret ettiğinde onu yönlendiriyorlar.
8. Birbirinizi daha az kesin
Tüm bu ekiplerde, birçok soru artık birini bölmeyi gerektirmiyor.
Önce Agent'a sorun. Bir ekip arkadaşımız, bulut bilgisayarda çalışan ve konu başlığına yanıt veren bir Slack botunu Mono üzerinde geliştirdi. En çok mühendis olmayanlar kullanıyor. Bu özellik nasıl çalışıyor? Bu string nerede? Bu yayınlandı mı? Artık önce sorumlu kişiyi bulmaları gerekmiyor.
Durum güncellemesi istemek yerine oturumu açın. Bir mühendisin ilerlemesi eskiden kendi AI sohbetlerinde yaşıyordu ve oturumdan çıktığında görünmez oluyordu. Bu yüzden bir projenin üyelerinin birbirlerinin oturumlarını görmesine ve katılma isteği göndermesine olanak tanıyan dahili bir özellik geliştirdik. Bir mühendis bir özelliğin büyük kısmını agent ile oluşturabilir, ardından bir PM aynı oturuma katılarak boşlukları, stilleri ve metinleri ayarlayabilir. Başkasının oturumuna bir şey göndermek için o kişinin onayı gerekir ve izinler üzerinde hâlâ çalışıyoruz.
(Örnekleme amaçlıdır: bir mühendis, bir PM ve bir tasarımcının tek bir oturumda nasıl çalıştığı. Gerçek bir fiyatlandırma değişikliği değildir.)
Amaç birbirimizle daha az konuşmak değil. Birbirimizi daha az bölmek.
Yalnızca karar verilmesi gerekene karar verin. En yoğun AI kullanıcımız, tek bir görevi olan bir ana oturum sürdürüyor: kararını gerektiren şeyleri her biri için bir öneriyle birlikte listelemek. Slack yoğunlaştığında ondan uzak duruyor ve "Şu anda neye karar vermem gerekiyor?" diye soruyor.
Ben de benzer bir şey yapıyorum. Günde 20'den fazla yapılacak işim var ve kamuoyuyla paylaştığım gibi DEHB'im var. Benim için en zor olan başlamak. Artık her yapılacak iş, her birini kendi görevine dönüştüren özel bir Manus Project'e giriyor. Yapabileceklerini başlatıyor. Emin olmadığında bana arka plan hakkında soru soruyor ve hangi PM'in sahiplenmesi gerektiğini soruyor. Ardından kendi Slack, Gmail ve Notion'uma verdiğim erişimi kullanarak bağlamı topluyor ve PM'e tek satırlık bir not yerine eksiksiz bir talep sunuyor. Benim için değişim yalnızca verimlilikle ilgili değil. Artık günümün çok daha az bir kısmını nereden başlayacağım konusunda kaygılanarak geçiriyorum ve bu kişisel düzeyde çok büyük bir şey.
9. Maliyete değer mi?
AI'ya çok harcıyoruz ve bu harcamayı yakından takip ediyoruz. Bunu kimsenin performansını değerlendirmek için kullanmıyoruz. Harcamanın kendisini değerlendirmek için kullanıyoruz: şimdi karşılığını veriyor mu, yoksa bizi ileride mi hazırlıyor?
Bize neler kazandırdığını düşündüğümüz ve maliyetin nereye gideceğini beklediğimiz şöyle:
•Zaman ve dikkat kazandırıyor. Bir ekip büyüdükçe koordinasyon herkesin dikkatini tüketiyor. AI her kişinin dikkatini koruyor ve onlara işlerinin daha tam bir sahipliğini veriyor. Ve hâlâ işe alım yapıyoruz.
•En iyi modelleri kullanmak, AI'nin sınırlarının nerede olduğunu öğrenmemizin yoludur. Bölüm 4'te açıklanan doğrulama ve kod incelemesi kurulumu, elde edebildiğimiz en güçlü modeller üzerinde çalışıyor. Geliştirici verimliliğinden sorumlu meslektaşımız bunu en iyi getirili harcamamız olarak nitelendiriyor.
•Maliyet, ürün üzerinden düşmeli. Geliştirmemizin daha fazlası artık kendi ürünümüz olan Manus Studio'da gerçekleşiyor, dolayısıyla kullanım verilerimiz bize tokens'ın nerede boşa harcandığını gösteriyor. Düzeltmeler ürüne giriyor, bu yüzden Manus'u kullanıcılar için de daha verimli hale getirmeleri gerekir. Modeller ucuzladıkça ve biz israfı kaldırdıkça bugünkü maliyetlerin önemli ölçüde düşmesini bekliyoruz. Bu bir inanç, bir söz değil!
10. Henüz işe yaramayan şeyler
Daha az kesinti var, ancak dikkat daha parçalı. Günde dört veya beş iş halleden biri, şimdi aynı anda 20 veya 30 işi birden ilerletiyor olabilir. Her geçiş, bağlamın yeniden yüklenmesi anlamına geliyor. AI insanların yapabileceklerini genişletiyor ve aynı zamanda onları daha fazlasını yapmaya itiyor. Bir PM bana, bir görev çalışırken başka bir agent başlatmaya karşı koyamadığını söyledi. Daha fazla şey yapmak amaç değil. Bunu kutlanacak bir tempo olarak değil, çözülmesi gereken bir sorun olarak ele alıyoruz.
Bilgi daha dağınık. Ürün başkanımız eskiden her değişikliği ve nedenini bilirdi. Şimdi bazen bir sorunun ekran görüntüsünü alıp Mono'ya "Bunu kim değiştirdi?" diye soruyor. Komik ama soru gerçek. Herkesin ürünü değiştirme yetkisi olduğunda, bütünden kim sorumlu?
İzin paylaşımının yeniden tasarlanması gerekiyor. İş paylaşılabilir ve devredilebilir hale geldiğinde ve agent'lar konuşmalarımızın daha fazlasında yer aldığında, neyin açık neyin onay gerektirdiğine karar vermemiz gerekiyor.
Çözümlerimiz hâlâ temel düzeyde. Şu an için bir agent diğerlerini denetliyor ve yalnızca tıkananları ve insan kararı gerektirenleri raporluyor. Bunun daha iyi olabileceğini biliyoruz.
11. Sırada ne inşa ediyoruz
Bu sorunlar, muhtemelen diğer takımların da ihtiyaç duyacağı ürün çalışmalarına işaret ediyor. Bu özellikleri önceden planlamadık. Kendi karşılaştığımız sorunlardan doğdular.
•Paylaşılan çalışma alanları olarak oturumlar. Bir kişi bir sorunu dile getirir, bir tasarımcı bir çözüm önerir, bir mühendis onu geliştirir ve bir PM onu yürütür — hepsi aynı yerde.
•Cihazlar ve kişiler arasında hareket eden iş. Yerel ve bulut makineler bağlı kalır, böylece insanlar uzaklaştığında iş devam edebilir.
•İnsanların düşünmediği seçenekleri bulan Agent'lar. Bir şirketin sistemleri içinde, doğru izinlerle çalışan bir Agent, sadece talimatları yerine getirmekle kalmayıp çözümler önerebilmelidir.
Bunları önce kendimiz üzerinde deneyeceğiz, sonra kullanıcılara sunacağız.
12. İnsanlar şimdi ne yapıyor
Bir sıra Agent oturumu açık olan mühendis, sadece verimlilikle ilgili bir hikaye değil. Bu, bir organizasyonun neyle çalıştığına dair bir değişim. Şirketler eskiden bilgiyi roller ve hiyerarşi aracılığıyla hareket ettirirdi. Bir kişinin yapabileceği şey, kaç kişiden ve kaynaktan yararlanabildiğine bağlıydı. Şimdi AI'ya bağlam ve araç vermek için biraz zaman harcıyoruz, ve değerlendirme ve karar vermek için daha fazla zaman harcıyoruz. Gittikçe daha sık, bir sorunu bize getiren bir Agent oluyor. Bu konuda ne yapılacağına karar vermek hâlâ bizim işimiz.
Bununla ilgili şakalaştık: Manus bu kadar şey yapabiliyorsa, neden ofise gelesiniz? Bırakın Agent'lar halletsin. Ama önemli soruların hâlâ insanların dile getirmesine, tartışmasına ve karar vermesine ihtiyacı var. Örneğin, iyi bir ürün ne sayılır? Veya, biraz abartarak: AI'nın sınırlarını zorlamaya devam eden gerçek gelirli harika bir ürün mü inşa etmeli, yoksa kâr marjının peşinden mi gitmeli? AI hangisini istediğimizi bilmez. Biz biliriz. Kültür ve güven, günden güne ve önemli anlarda birlikte çalışmaktan doğar. İşte her oturumdaki işin dayandığı temel budur.
Yani, şimdilik cevabımız şu. AI-native bir organizasyon olarak deneyimimizde, insanların rolü azalmadı. En büyük etkiyi yaratabilecekleri alanlara daha fazla odaklandı: sorunu tanımla, kaliteyi değerlendir, neyin yapmaya değer olduğuna karar ver, sonucun sahipliğini üstlen.
İşte bu yüzden hâlâ işe alım yapıyoruz. İnsanların becerileri ve değerlendirmeleri bu çalışma şeklinin merkezinde — ve bu yakın zamanda değişmiyor.
Bunu yazarken, bir yıl sonra bu yazının ne söyleyeceğini merak ediyorum. Her şirketin farklı hedefleri, yapıları ve kültürü var, bu yüzden standart bir cevap veya nihai bir biçim olmayabilir. Ama Agent inşa eden bir şirket için, insanların ve AI'nın nasıl birlikte çalıştığını çözmek isteğe bağlı değil. Bu işin bir parçası. Devam edeceğiz ve öğrendiklerimizi paylaşmaya devam edeceğiz.
Rakamlar hakkında bir not. Bu yazıdaki rakamlar iç kayıtlardan geliyor. Takım boyutları ve PM teslimat rakamları Ekim sonu itibarıyladır. Bazı noktalar ölçümler yerine tahminler veya bir kişinin deneyimidir.
