Yapay zeka araçlarının çıktısının belli bir kalite eşiğini aşarak tecrübeli yazılımcıları da artık bir cismin yaklaştığına ikna etmesinin üzerinden bir yıl ya geçmiştir, ya geçmemiştir.
Biz de bir süredir Sobamail’in yazılım geliştirme süreçlerini yapay zeka etrafında yeniden şekillendirme üzerine çalışıyoruz. Bu çalışmaların sonucunda bazı süreçlerin yavaş yavaş netleştiğini görünce, edindiğimiz deneyimleri paylaşmak ve üzerine fikir alışverişi yapabileceğimiz bir zemin oluşturmak için bu yazıyı yazmaya karar verdim.
Öncelikle şu kısım net: Yazılım hala yazılım. Zaman baskısıyla işin gereklerini göz ardı ederseniz, "gelecekteki siz"in başını yine belaya sokuyorsunuz. Ürettiğiniz kodun arkasını düzenli olarak toplamanız hala gerekiyor. Karmaşıklıkla mücadele de aynı kararlılıkla devam ediyor.
Yani evet, büyük dil modeli teknolojisi -doğru kullanıldığında- ekibinizin çalışan koda ulaşmasını ciddi biçimde hızlandırıyor. Ama sizi doğru yola sokmuyor. Yalakalığa programlanmış bir makineden zaten bu tarz bir şey beklememek gerekli.
Biz yeni oyuncağımıza biraz temkinli yaklaştık diyebilirdim ama başkalarıyla konuştuğumda gördüğüm hikaye az çok aynı. Önce web arayüzünden kod kopyala yapıştır yaparak, sonra da IDE entegrasyonları üzerinden ufak tefek fonksiyonlar yazdırarak yama üretme işi bu gün uçtan uca özelliklerin tamamen dil modeli tarafından gerçeklendiği bir dünyaya yerini bırakmış durumda.
Peki uzun süren işlemlerde modelin yolunu kaybetmemesi için ne yapmak gerekiyor? Ya da daha teknik bir deyişle, dil modeline verilen bağlamın içeriğinin nasıl yönetilmesi gerekiyor?
Başta bunu düz yolda araba kullanırken şeritte kalmak için yapılan ufak düzeltmeler gibi işi bir bağlam birimine sığacak parçalara bölerek modelin her yazdığını okuyup her adımını sürekli denetlemek olduğunu düşündük ancak ilk büyük işte bu zulme katlanılmayacağını net bir şekilde anladık. Eğer yıllarını kendisini mesleğinde geliştirmeye adamış bir mühendisin bütün mesaisi dil modelinin elinden tutmakla harcanacaksa, burada etkin bir kaynak kullanımından söz edilemezdi.
Eğer yazılım projesi bir ağaçsa, kod bu ağacın yapraklarıdır.
Bu prensipten hareketle Opus’la bir meta-tartışmaya girdim ve neticede ortaya modelin “handoff looping” dediği bir skill ortaya çıktı.
Handoff loop mantığında yapılması gereken işi bir paragraf yazı olarak olarak
modele aktarıyorsunuz. Model bu paragraf rehberliğinde mevcut kodunuzda bir
gezintiye çıkıyor (buna “measurement” diyor) ve sizin paragrafınızı sizin
kodunuzun sunduğu imkanlar açısından inceleyip eksikleri belirliyor ve bu
eksikleri nasıl parça parça gidereceğini (bu parçalara da “pass” diyor)
detaylıca anlattığı bir kaç tane .md belgesi (bunlara “loop document” diyor)
ve bir shell script (buna “driver” diyor) hazırlayarak size dönüş yapıyor.
Bundan sonra (modelin “signoff round” dediği) toplantı aşamasına geçiliyor ve model size sorularını soruyor. Siz bu soruları cevapladıkça (cevaplara “owner verdict” diyor) bunları loop dokümanlarına işliyor ve ortaya bir iş planı çıkıyor.
Modelle toplantınız bittikten sonra driver scriptini çalıştırıyorsunuz ve mühendisin mesaisi bitiyor ve modelinki başlıyor. Driver script, modeli sürekli aynı prompt ile çalıştırarak verilen işte ilerledikçe güncellediği belgeleri tekrar tekrar okumasını sağlıyor. Model her parçayı tamamladıktan sonra commitlerini yapıp dokumanlarını bir sonraki işi işaret edecek şekilde güncelleyip kendisini kapatıyor. Böylece modelin sürekli temiz bağlam ile sürekli bir sonraki işi yaptığı ve ya bir yerde tıkanıp pes ettiği ya da işi tamamlayıp çalışmayı bıraktığı bir yapı ortaya çıkıyor.
Modelleri bu mantıkla günlerce çalıştırmak mümkün. Arada bir başka bir modele “bizim loop ne durumda dokumanları oku ve bana özetini çıkart” diyerek yapılan işi denetlemek de mümkün. Modelin kendi dokümanlarını okumayı asla tavsiye etmiyorum. Temiz bir modele mevcut durumun özetini çıkarttırmak zamanın çok daha etkin kullanılmasını sağlıyor.
Skill’i Github’a koyunca bu yazıyı güncelleyeceğim.