Koddan önce öğrenilen davranış
ProgramBench’te bir eylemci kodu görmeden programı yeniden kuruyor. Elinde çalıştırılabilir dosya ve belgeler var; davranışı yoklayarak öğreniyor. Cohere’in deneyinde bir Sol yöneticisine bağlanan planlayıcılar bu yoklamaları çoğaltıyor: planlayıcı sayısı ikiden 16’ya çıktığında toplam denemeler 15’ten 109’a yükseliyor. Burada ekip üyelerinin topladığı bilgi, yazılacak kodun öncesinde ortaya çıkıyor. Benim için bulgunun merkezi bu görev yapısı. Aynı sonucu bir yazılım ekibinin her işinde beklemek, yeniden keşfedilmesi gereken davranışla zaten okunabilir kaynak kodunu aynı başlangıç koşulu saymak olur.[1]
Ölçülen çıktı da önemli. ProgramBench’in 200 görevinde bildirilen oran, gizli testlerden geçilen payın ortalaması. Tamamen çözülmüş programların oranını vermiyor. Tek Sol eylemcisi planlama, uygulama ve doğrulama düzeninde yüzde 57,7 alırken, bloklayan ekip yüzde 63,1’e ulaşıyor. Bu artış, yeniden kurulan programların davranışının daha büyük bölümünün testlerle uyuştuğunu gösteriyor. Her programın kullanıma hazır olduğu anlamına gelmiyor. Başarıyı iş teslimi olarak okuyan bir ekip için ölçütün paydasındaki bu ayrım, planlayıcı sayısından önce geliyor.[1]
Aynı ekip, başka başlangıç koşulu
Maliyet karşılaştırması, iş bölümü seçiminin de deneyin parçası olduğunu gösteriyor. Asenkron olarak yalnızca planlama yaptırılan düzen yüzde 63,6’ya 249 dolarla ulaşıyor. Bütün aşamalarda ekip kullanılan düzen yüzde 63,2 için 510 dolar harcıyor. Güçlü yöneticiye 16 ucuz Luna planlayıcı bağlanan sabit ekip ise yüzde 61,8’i 155 dolara elde ediyor. Bu sonuca bakıp ucuz planlayıcıların her zaman aynı kaliteyi koruduğunu söyleyemem: sabit ekipler yalnızca bir kez çalıştırıldı. Dinamik düzenlerin çoğundaki üç tekrarın belirsizlik hesabını bu tek çalışmaya aktarmak mümkün değil.[1]
Mevcut kaynak kodunun bulunduğu Commit0-Lite, aynı fikri başka bir başlangıç koşulunda sınıyor. On ekip düzeninin sekizinde uygulama işini bölmek, planlama işini bölmekten daha iyi sonuç veriyor. Bu karşılaştırma, kara kutunun bilgi eksikliğinin planlamaya değer kattığı yorumunu destekliyor. Yine de tek açıklama bu olmayabilir. İkinci kümede yalnızca 16 Python deposu var ve tek Sol eylemcisi zaten bunların 12’sini çözüyor. Farklı depo seçimi ve yükselmek için kalan dar alan da stratejilerin sırasını etkileyebilir. Görev türüyle örneklem büyüklüğü birlikte değiştiği için aralarındaki etkileri ayırmak gerekiyor.[1]
İş bölümü için ölçülebilir bir dayanak
Bu deneyin güçlü tarafı, ekip kurmayı tek bir açma kapama kararı olarak bırakmaması. Bekleyen veya asenkron çalışan yardımcılar, planlama veya uygulama görevleri ve güçlü ya da daha küçük modeller ayrı ayrı karşılaştırılıyor. Böylece puan kazancının hangi düzenle elde edildiği görülebiliyor. Sonuçlar deneyleri yapan Cohere araştırmacılarına ait; başka bir ekibin aynı sonuçları elde ettiği gösterilmiyor. Deneyin anlattığı sınırlar korununca bulgu kullanışlı: programı yoklayarak bilgi toplamak ile bilinen kod üzerinde değişiklik yapmak, aynı iş bölümü sorununu yaratmıyor.[1]
Benim bu çalışmadan çıkardığım karar ölçütü, yardımcının kaç işlem yaptığıyla yöneticinin görevi ne kadar daha iyi tamamladığını birlikte izlemek. 109 yoklama, tek başına 109 yararlı keşif sayılmıyor. Planlama kazancı, aynı programlarda benzer maliyetle çalışan düzenler arasında ve tamamen çözülmüş görev sayısı ayrıca verilerek karşılaştırıldığında daha anlaşılır olur. Mevcut deney, ek eylemcilerin özellikle davranışın keşfedildiği yerde işe yaradığını düşündürüyor. Bunun sınırı, kodun baştan elde olduğu küçük ikinci örneklemde görülebiliyor. Ekip büyüklüğünü seçerken başlangıçtaki bilgi eksikliğini ölçmek, genel bir çok eylemci üstünlüğü kabulünden daha sağlam dayanak sunuyor.[1]