Armut Meyvelerini Yiyor: Super PM'den Yarı Otonom Ürün Ekibine

Sohbetin ikinci yarısında Sezer'e zor bir soru sorduk. Bu sistemden kendini, Deniz'i ve Fatma'yı çıkarsak, yerlerine bir junior PM ve bir junior developer koysak sistem yine işler mi? Cevap hiç beklemeden geldi: “Bence işlemez.”

Alive Podcast'in altıncı bölümünde konuğumuz Armut'un Director of Product'ı Sezer Bakay'dı. Nisan'daki Alive konferansında Sezer'i dinleyenler hatırlar. Orada Super PM adını verdikleri plugin'i anlatmıştı: PM'lerin tekrar eden işlerini skill'lere dönüştüren, şirketin bağlamına ve araçlarına bağlanan bir paket. Bu bölümde altı ay sonra o plugin'e ne olduğunu ve üç kişilik çekirdek bir ekiple sıfırdan bir uygulamayı yarı otonom bir yapıyla nasıl geliştirmeye çalıştıklarını konuştuk.

Önceki bölümlerde Kodgem'in on kişilik ekibini, kendi bir buçuk kişilik departmanlarımızı ve kod bilmeden agent ekibi kuran bir CFO'yu konuşmuştuk. Bu kez yıllardır oturmuş süreçleri olan, birden fazla ülkede çalışan bir ürün şirketinin içine baktık.

Bir plugin'den şirket içi bir pazara

Super PM aslında lojistik bir dertten doğmuş. Skill'leri ve iş akışlarını tasarlamak kolay; zor olan, bunları versiyon kontrolüyle bütün ekibe aynı anda dağıtmak ve herkesin katkı verebileceği bir yapı kurmak. Altı ayın sonunda Sezer'in vardığı yer net: Yön doğruymuş. Super PM hala aktif olarak kullanılıyor, yeni skill'ler ekleniyor, eskiler kullanıldıkça iterasyon görüyor. Artık PM'ler kendi yazdıkları skill'leri eklemek için PR açıyor.

Daha ilginci, aynı dert başka ekiplerde de çıkınca herkes kendi plugin'ini yapmaya başlamış. Hepsi şirket içi bir marketplace'te (plugin'lerin toplandığı ve dağıtıldığı ortak çatı) duruyor. Teknik olarak bu bir GitHub reposu: Plugin'i yüklüyorsun, oradan herkese dağılıyor.

QA'nın aracı herkesin işine yarıyor. Agent'a “beş işe teklif vermiş, elli fırsat almış, şu koşullarda hizmet veren bir kullanıcı” dediğinde bu senaryo doğrudan stage ortamında oluşuyor. Bir şeyi test etmek isteyen herkesin ortak ihtiyacı bu. Tasarımın plugin'i ise daha çok tasarımcıların kendi işine bakıyor. Sezer'e göre plugin dünyası bir matris gibi kurulacak: Bir kısmı yatayda herkese hizmet edecek, bir kısmı tek fonksiyonun operasyonunu taşıyacak.

Skill'lerin güncellenme sıklığında sabit bir ritim yok. Yeni bir skill ilk aşamalarında sık sık değişiyor. Sezer kabaca, olgunlaşmış bir skill'in en fazla iki üç haftada bir güncellendiğini söylüyor. Super PM'in ilk temel setindeki skill'ler artık çok daha seyrek değişiyor, çoğunlukla biri bir hata bildirince. Sezer ilk sürümde mükemmeli aramıyor. Elde iyi örnekler varsa oradan başlıyor, sonra skill'i kendi işinde kullanarak (dogfooding) hızla iterasyona sokuyor.

Skill'lerin ürettiği HTML çıktılar bir Google dokümanından çok daha esnek ama üzerinde yorum bırakıp tartışmak zor. Bunun için ekip Artifact Collab adında bir iç ürün yapmış. Bir Google dokümanındaki gibi yorum bırakılabiliyor, thread'lerde tartışılabiliyor, düzenleme yapılabiliyor. Claude kendi artifact'lerine paylaşma ve yorum özelliğini sonradan ekledi. Ama Claude kullanıcısı olmayan biri de o dokümana yorum yazabilsin diye ekip Artifact Collab'i kullanmaya devam ediyor. Diyagramlı, şemalı ve birkaç kişinin gözden geçirmesi gereken çıktılar artık buraya gidiyor.

Discovery'de daha çok soru

Delivery tarafının hızlandığını artık herkes konuşuyor. Biz discovery tarafını merak ettik. Sezer'in cevabı analiz etabından geldi. Bir PM'in günü genelde bir önseziyle başlar: Bir yorumda, bir NPS cevabında bir ipucu görür ve peşinden gider. Eskiden bunun için sorgular sıfırdan yazılıyor, sonuçlar gözle taranıyor, veriler elle çaprazlanıyordu. Bunun bir sınırı ve bir zaman bedeli vardı.

Eskiden bir analizde üç dört soru soruluyordu. Şimdi belki on, on bir soru soruluyor.

Burada işi yapan skill, adının çağrıştırdığı gibi bir “analiz skill'i” sayılmaz. Super PM'deki skill, gelen soruyu doğru SQL sorgusuna çeviriyor. Veri şemalarını, geçmiş sorguları ve o sorgulardaki istisnaları biliyor. Sonucu yorumlamak ise modele ve PM'e kalıyor. Sezer bunun skill'e dönüşebileceğini düşünmüyor, çünkü yorum her seferinde üzerinde çalışılan problemin bağlamına bağlı.

Problem tanımlandıktan sonraki shaping süreci ise yerinde duruyor. Bu iş kaç kişiye dokunuyor, neyi ne kadar oynatacak, maliyeti ne olur: Önceliklendirme aynı metriklerle yapılıyor. Değişen tek şey bu hesapların daha kolay ve daha hızlı yapılması.

Doğru iş için doğru model

Armut'ta herkes Claude kullanmıyor. ChatGPT kullananlar var; mühendislik de OpenRouter üzerinden merkezi bir yapı kurmaya başlamış.

Model seçimi de iş bazında yapılıyor. Arayüz metinlerinde ekip Claude'u beğenmiyor, Türkçede de çeviride de OpenAI modellerini daha iyi buluyor. Sezer'in kurduğu akışta Claude, metin yönetiminde kullandıkları Localize için anahtarın brief'ini hazırlıyor. Türkçe ve İtalyanca karşılıkların yazılması ve kritiği ise Codex'teki bir agent'a devrediliyor. İki agent arasında bir kontrat var: Brief'in yapısı belli, beklenen çıktının biçimi belli.

Araştırma ekibi de kendi derdini kendisi çözmüş. Müşteri görüşmeleri İtalyanca, İspanyolca ya da Türkçe kaydediliyor. Ekip n8n'de bir akış kurmuş; kayıt çevriliyor, işleniyor ve ekibin rapor formatına dönüşüyor. Neden n8n diye sorduk, çünkü bizim elimiz artık her şeyde Claude Code'a gidiyor. O an kolay gelmiş, sürükle bırak yapısı prototiplemeyi rahatlatmış. Sezer bugün olsa doğrudan kendi agent ortamında kurmayı denerdi. Yine de n8n'in iki avantajı var: Hangi modele gideceğini bir açılır menüden seçiyorsun ve bir klasöre dosya düştüğünde tetiklenen olay bazlı akışları kurmak çok daha kolay.

Üç kişilik task force

Yaz sonunda Armut sıfırdan yeni bir uygulama inisiyatifi başlatmış; içeriğini henüz paylaşamıyorlar. Bu uygulamayla aynı anda ikinci bir şeyi de test ediyorlar: Tamamen AI native çalışan bir ekip bu işi ne kadar ve nasıl götürebilir? Çekirdekte üç kişi var: Sezer, Armut'un CTO'su Deniz ve mühendislik direktörü Fatma. Başlarken bütün ön kabullerini masada bırakmışlar.

Bu kez fonksiyon bazında ayrı plugin'ler yerine tek bir task force plugin'i kurmuşlar. Hedef, ürün geliştirme döngüsünün tamamını bu tek paketle adreslemek.

Ortaya çıkan şey düz bir boru hattına benzemiyor. Sezer'in deyişiyle bir graph: Bazı adımlar kendi içinde döngüye giriyor, bazıları işi başka bir agent'a devrediyor, belirli noktalarda insan onayı gerekiyor. Üst seviyede kararları insanlar veriyor, yürütmede agent'lar kendi başına ilerliyor. Ekip bu yüzden yapıya yarı otonom diyor. Az önce anlattığımız metin akışı bile tek başına üç dört skill'den oluşuyor ve aralarındaki sıra önceden tanımlı.

Sohbet sırasında bir tahminde bulunduk: Deniz'e gitmeden önce konuşulan bir “Deniz skill'i” vardır herhalde. Sezer “güzel tahmin ettin, gerçekten var” dedi. Biz de eğitimlerde benzer bir CTO skill'i kuruyoruz; on soruda yedisi orada çözülüyor, üçü hala gerçek CTO'ya gidiyor.

Biz itiraz ettik: Agent'ın bilmediği o iki üç yıllık vizyon da sonuçta bir bağlam, verilse olmaz mı? Sezer burada Laplace'ın şeytanını hatırlattı. Evrendeki bütün atomların konumunu ve hızını bilen bir varlık geleceği de bilirdi. Teorik olarak doğru. Ama bir insan karar verirken o an aklına gelmeyen, ancak durumla karşılaşınca hatırladığı birçok şeyi de kullanıyor. Agent'a ancak o an aklına gelen bağlamı verebiliyorsun.

Sistemin bugünkü hali ekibi memnun ediyor. Çıktılar hızlı ve kaliteli; dokümantasyon kendiliğinden ve senkron tutuluyor, ortak bir hafıza sayesinde bilgi kaybolmuyor. Sezer'in fark ettiği bir yan etki var. Sohbetten bir gün önce Fatma bir işin Asana kaydını açıp açmadığını sormuş, Sezer hatırlayamamış. Aynı anda o kadar çok iş yürüyor ki “nerede kalmıştık” sorusunu artık agent'a soruyor. İşin durumunu agent'a bıraktıkça insan kendi takibini kaybetmeye başlıyor. Bunun uzun vadede iyi mi kötü mü olduğunu Sezer de bilmiyor.

Iron Man zırhı ve junior sorusu

Üç deneyimli insanın yerine iki junior koyunca sistem neden işlemez? Sezer'e göre üçünün sisteme kattığı şey muhakeme ve eleştirel düşünce. Domain bilgileri ve deneyimleri var; birçok noktayı birleştirebiliyorlar. Agent'ın sahip olduğu bağlamın çok ötesinde bir bağlamla yön veriyorlar.

Junior'da bu henüz oluşmadı. Sezer burada task relevant maturity (göreve özgü olgunluk) kavramını kullandı: Bir kişi bir görevde olgunlaşmadan ona o görevi tamamen bırakmak doğru bir strateji olmaz. O olgunluğun nasıl oluşacağı ayrı bir koçluk problemi. Belki de geleceğin ekipleri Star Wars'taki gibi usta çırak ilişkisiyle yürüyecek.

Bir çıkış yolu da Claude ile Codex arasındaki kontrattan çıktı. Agent'lar arasında brief'i ve çıktısı belli bir protokol kurulabiliyorsa, aynı protokolle bir junior'a da üzerinde pratik yapabileceği kontrollü görevler verilebilir. Hangi görevlerin, hangi protokolle verileceği ise liderlerin çalışması gereken yeni bir alan.

Biz şunu düşündük: Bu problem eskiden de yok muydu? Bir junior PM'in spec'ini okur, eksiğini gösterirdik. Bugün aynı koçluğu skill'i düzelterek yapıyoruz. Sezer katıldı ama bir farkın altını çizdi. Eskiden işler yavaş aktığı için yanlış bir karar görünür kalıyordu ve araya girmek kolaydı. Şimdi bir değişiklik bir günde yayına çıkabiliyor. Araç güçlendikçe özensiz AI çıktısına (AI slop) düşme ihtimalinin de büyüdüğünü ekledik, Sezer buna da katıldı.

Armut meyvelerini yiyor

Task force'ta işlerin bu kadar iyi akmasının sebebini Sezer skill'lerde aramıyor.

Tasarım tarafında özenle hazırlanmış bir design library var. Frontend'de bu kütüphanenin karşılığı olan, bütün bileşenlerin dokümantasyonuyla birlikte düzenli durduğu bir monorepo var. Ürünün içeriğine dair Notion'da bolca doküman var. Her projenin bir shaping dokümanı var ve bu dokümanın formatı yıllardır aynı. Drive'daki klasör yapıları birbirine benziyor, dokümanlar Asana kayıtlarına bağlı. Agent bu Lego parçalarını bir araya getiriyor. Sezer'in tarifiyle AI öncesinden gelen bir iş yapma kültürünün meyvesini bugün Armut yiyor.

Kaynaklarla model arasında bir katman da var. Orkestratör skill'in içinde, hangi konuda önce nereye bakılacağı tanımlı. Slack'teki konuşmalar da bu kaynaklardan biri. Super PM'i kapatıp aynı soruyu sorduklarında aldıkları cevap da bunu gösteriyor. Altyapı yoksa agent'ın yapabileceği şey çok sınırlı kalıyor.

Öğle saatindeyiz

Sırada ne olduğunu sorduk. İlk iş, task force'taki çalışma sistemini olgunlaştırıp farklı ekiplerin farklı problem tiplerinde kullanabileceği hale getirmek. İkincisi yaygınlaşma. Kullanım artıyor ama herkese ulaşmış değil. Sezer bugünü öğle saatine benzetiyor: Güneş tepede, günün telaşı ortada, akşamın sakinliğine daha var.

Yine de gidişattan umutlu. Beklemediği ekiplerden insanlar kapısını çalıyor. Müşteri deneyimi ekibi yıllardır var olan bir problemi otomasyonla çözmek için gelmiş. İnsanlar bir şeyin artık yapılabildiğini fark edip kendi problemleri için kolları sıvıyor. Sezer değişimi burada görüyor. Bu küçük girişimler bir araya geldikçe şirketin kendiliğinden bir kaizen düzenine, yani küçük adımlarla sürekli iyileşmeye yaklaşacağını umuyor.

Eylül sonunda iki ofisin Ayvalık'ta toplandığı şirket buluşmasında da benzer bir şey görülmüş. Yönetimden bir sunum AI benimsemeye ayrılmış; slayttaki dört kademeden en uçtaki kullanıcılar hep aynı şeyi söylemiş: Bu iş enerji veriyor. Sezer de katılıyor. Bir kere psikolojik bariyeri aştıktan sonra insan kendiliğinden ileri gidiyor. Biz de eğitimlerde “bu kadar kolay mıydı?” cümlesini çok duyuyoruz. Bilgi bariyeri büyük ölçüde kalktı; geriye çoğunlukla psikolojik olanı kaldı.

Bizim çıkarımımız

Geçen bölümde Vedat Mizrahi'nin sistemini ayakta tutanın yıllardır düzgün tuttuğu arşiv olduğunu görmüştük. Sezer aynı şeyi şirket ölçeğinde anlattı. Aynı formattaki shaping dokümanları, düzenli bir monorepo, Asana'ya bağlanmış Drive klasörleri. Bunların hiçbiri AI için kurulmamıştı. Bugün task force'u taşıyan şey bunlar.

Junior sorusu ise açık kaldı. Armut'ta sistem çalışıyor, çünkü zırhın içinde ne yaptığını bilen üç kişi var. Yeni gelenin o zırhı giymeden önce nasıl olgunlaşacağına dair henüz kimsenin oturmuş bir cevabı yok. Sezer'in kontrat fikri bize mantıklı geldi: Önce agent'lar arasında kurduğun protokolü insana da uygulamak.

Bu tür hikayeleri 3-4 Aralık'ta İstanbul'da Alive AI'da da dinleyeceğiz. Ekibinde junior'larla AI arasında böyle bir düzen kurduysan LinkedIn'den ya da selam@brick.institute adresinden bize yaz.

Senin şirketinde bugün yarı otonom bir ekip kurulsa, agent'ın gidip bakacağı düzgün bir doküman var mı? Canlı kalın. 🧱