Meta bu hafta Muse Code'u tanıttığında öne çıkan başlık rekabetteki konumlandırmasıydı: Claude Code, Codex ve Cursor'ın geliştirici iş akışları için verdiği mücadeleye katılan, terminal tabanlı bir kodlama ajanı daha. Ama Mark Zuckerberg'in aracı kendi ağzından tarif edişinin içine gömülü olan asıl ilginç sinyal, hayatını kod yazarak ya da kod inceleyerek kazanan herkes için başka bir şey.

Zuckerberg, Muse Code'un büyük görevlere yaklaşımını anlatırken şöyle yazdı: "Bir iş yeterince büyükse, izole çalışma kopyalarında (worktree) paralel çalışan ayrı alt ajanlara dağıtılıyor. Sizin çalışma kopyanıza asla dokunulmuyor. Test sırasında, bir oyun için altı özelliği aynı anda, hiçbir çakışma olmadan inşa ettirdik."

Bu bir özellik tanımı değil. Bu bir iş tanımı — sizin için.

"İzole çalışma kopyaları" gerçekte ne anlama geliyor

Bir git worktree'si, aynı deponun birden fazla dalını aynı anda ayrı dizinlere çıkarmanıza olanak tanır; böylece birden fazla iş kolu, biri diğerinin üzerine basmadan ilerleyebilir. Meta'nın anlattığına göre Muse Code, birkaç alt ajanın sizin canlı çalışma kopyanıza ya da birbirlerinin dosyalarına dokunmadan aynı anda kod yazabilmesi için bu mekanizmayı kullanıyor. Bu makul bir mühendislik tercihi: dosya düzeyindeki çakışmalar, çoklu ajan çatışmalarının mekanik olarak önlenmesi en kolay türüdür, dolayısıyla bunları mekanik olarak önleyip modelin asıl kodlamaya odaklanmasına alan açıyorsunuz.

Dikkat edilmesi gereken kelime "dağıtılıyor" (fans out). Bir insan geliştirici, altı paralel worktree'yi sırayla tek tek elden geçireceği altı kod akışı olarak deneyimlemez — bu, aşağı yukarı aynı anda masasına düşen altı akıştır ve her biri bir karar gerektirir: bu içeri alınsın mı, yeniden mi işlenmeli, kardeş bir ajanın başka bir worktree'de az önce yaptığı bir şeyle çelişiyor mu.

Asıl değişen beceri

Son birkaç yıldır, yapay zeka destekli kodlamanın hâkim modeli konuşma temelli ve tekildi: bir geliştirici, bir asistan, üretildiği anda aşağı yukarı gerçek zamanlı incelenen bir gidiş-geliş akışı. Bu beceri — iyi prompt yazmak, kötü bir öneriyi anında yakalamak, üzerinde yinelemek — hâlâ gerekli. Ama Muse Code'un tasarımının optimize ettiği beceri bu değil. Alt ajanlara dağıtma, sizin zaten farklı bir çalışma moduna geçmiş olduğunuzu varsayıyor: bir görevi baştan, bağımsız çalışabilecek parçalara ayırmak, ardından bir ajanı adım adım yönlendirmek yerine birkaç ajandan gelen bitmiş (ya da yarı bitmiş) çıktıyı bir arada incelemek.

Bu, bir chatbot ile ekranı ikiye bölüp birlikte kod yazan bir eşli programcıdan çok, bir sprint'i küçük bir ekibe bölüştüren bir teknik lidere daha yakın. Tek tek kodlama kararları, işbölümünden (işi gerçekten bağımsız çizgiler boyunca mı böldünüz?) ve inceleme aşamasından (altı paralel diff'in tek tek doğru ve hep birlikte tutarlı olup olmadığını hızlıca söyleyebiliyor musunuz?) daha az önemli.

İzolasyon çakışmaları çözer, tutarlılığı değil

Üzerinde durmaya değer, çünkü gözden kaçması kolay: izole worktree'ler iki ajanın aynı dosyanın üzerine yazmasını engeller. Ama iki ajanın, aynı şeyi yapmanın iki farklı yolunu birbirinden bağımsız olarak icat etmesini hiçbir şekilde engellemez — ikinci bir tarih biçimlendirme yardımcısı, ikinci bir yeniden deneme sarmalayıcısı, yinelenen bir API rotası — çünkü ajanların hiçbiri diğerinin ne inşa ettiğini göremiyordu. Git izolasyonu bir dosya sistemi garantisidir, bir tasarım garantisi değil. Altı worktree'yi tekrar birleştiren inceleyici, yinelenen bir soyutlamanın, tutarsız bir adlandırma kuralının ya da sessizce farklı veri biçimleri varsayan iki özelliğin yakalanabileceği tek kontrol noktasıdır. Eğer bu inceleyici, paralel çıktının hacmi dikkatli okumayı geride bıraktığı için diff'leri hızlıca göz gezdiriyorsa, üretime giden şey tam olarak bu tür bir sapmadır.

Bu da, dağıtım araçları normalleştiğinde "kod incelemesi"nin ne anlama gelmesi gerektiğini yeniden çerçeveliyor: tek bir diff'in satır satır incelenmesi daha az önemli hale geliyor (ajanın sözdizimi genelde sorunsuzdur), diff'ler arası uzlaştırma ise daha önemli hale geliyor — paralel yapay zeka üretimi iş akışlarının ortak kurallar, ortak veri modelleri ve ortak hata yönetimi konusunda birbiriyle uyumlu olup olmadığını kontrol etmek.

Gerçekte neye doğru inşa etmeli

Bunların hiçbiri özellikle Muse Code'a özgü değil — aynı dağıtım deseni büyük kodlama ajanlarının genelinde ortaya çıkıyor, bu da onun tek bir satıcının bahsi olmaktan çok varsayılan bir mimariye dönüştüğünü gösteriyor. Hangi aracı kullanıyor olursanız olun, şimdiden pratik yapmaya değer birkaç somut şey var:

  • Temiz bir şekilde parçalara ayrılan görev tanımları yazın. Paralel çalışma istemeden önce, parçaların gerçekten bağımsız olup olmadığını kendinize sorun — aynı dosyalara, aynı paylaşılan sabitlere, aynı API sözleşmesine mi dokunuyorlar? Öyleyse bu, altı paralel ajanın işi değil; sırayla çalışan tek bir ajanın işi ya da paylaşılan kısımları önce sizin elle ayırmanız gereken bir iştir.
  • İncelemeyi diff noktasında değil, birleştirme noktasında yapmayı pratik edin. Birkaç tamamlanmış dalı yan yana çekip yalnızca "her biri tek tek doğru mu" değil, "bunlar birbiriyle uyumlu mu" diye sormayı alışkanlık haline getirin.
  • Git worktree temellerini bilin. Kullandığınız araçlar iç işleyişlerini bu şekilde anlatmaya devam edecekse, bir worktree'nin neyi garanti edip neyi etmediğini anlamak, çıktıya güvenmenin — ya da haklı olarak güvenmemenin — asgari şartıdır.
  • Paylaşılan şeylerin sahipliği konusunda netleşin. Sabitler, şemalar, paylaşılan yardımcı fonksiyonlar, adlandırma kuralları. Dağıtım başlamadan önce bunlardan ne kadarını netleştirirseniz, sonrasında o kadar az uzlaştırma işiniz olur.

Muse Code gibi araçlardan en çok faydayı sağlayacak kişiler, en iyi prompt yazanlar olmayacak. Bunlar, her üyesi bir model olsa bile, küçük, hızlı ve arada dağınıklaşan bir ekibi yönetmekte sessiz sedasız ustalaşmış olanlar olacak.