Yapay zekâ, ertelenen işleri yapılabilir kılıyor

PeşinTaksit'in altyapısını sadeleştirmek için 3–5 gün ayırmayacaktım. Bir kenarda duran, pek üzerine düşmediğim küçük bir projeydi. Çalıştığı sürece eski yapısıyla kalmasına razıydım.

Yine de benim yönetmem gereken dört container vardı: MariaDB, Redis, Fastify backend ve Nuxt frontend. Bunların her biri kendi başına anlaşılır tercihlerdi. Bir araya geldiklerinde ise projeye vermek istediğim dikkatten fazlasını isteyen bir yapı çıkmıştı. Temizlemek istiyordum, fakat o temizlik için birkaç günümü vermek istemiyordum.

AI ile yaptığım sadeleştirmede dört container'ın yerini tek bir Cloudflare Workers deployment'ı aldı. İşe başlamam ile yeni yapıyı canlıya almam arasında yaklaşık bir saat vardı.

Bir saat gözlediğim süreydi. 3–5 gün ise işe başlamadan önceki tahminim. Aynı işi AI kullanmadan tekrar yapmadım. Buradan güvenilir bir hız çarpanı hesaplayamam.

Ama verdiğim kararı biliyorum: Günler ayırmayacağım işi yaptım. PeşinTaksit birden daha önemli olmadı. Yapılacak temizlik, projeye ayırmaya razı olduğum zamana sığdı.

Ertelemek de bir karar

Çalışan bir sistemi sırf daha yenisi var diye değiştirmek zorunda değiliz. Bakımı zahmetli olsa bile bazen olduğu gibi bırakmak daha makul. Müşterinin beklediği iş dururken, ekibin birkaç haftasını eski bir kütüphaneyi sökmeye ayırmak kolay savunulacak bir tercih olmayabilir.

Bu yüzden teknik iş listesinde bir şeyin uzun süredir durması, onun unutulduğunu göstermez. Ekip ne yapılacağını biliyor, faydasını da görüyor olabilir. Yalnızca bedelini ödemeye razı değildir. PeşinTaksit'teki durumum buydu.

Yazma, dönüştürme ve düzeltme işi daha az zaman aldığında o kararın dayanağı değişir. Daha önceki tahmini olduğu yerde bırakıp yalnızca yeni projelerde AI kullanmaya başlarsak bu fırsatı kaçırırız. Bir zamanlar yapılmaya değmeyen işler arasında, bugün bitirilebilecek olanlar da bulunabilir.

Asana'nın beş yılı bu yüzden anlamlı

OpenAI'ın yayımladığı Asana vakası, beş yıl sürmesi beklenen bir işin iki takvim haftasında tamamlandığını söylüyor. Yaklaşık 6 milyon dolarlık mühendislik tahmininin karşısına da 12 bin dolarlık model ve altyapı giderini koyuyor.

Asana'nın kendi yazısında daha tanıdık bir durum var. Ekip, eski test kütüphanesi Enzyme'dan çıkmak için zaten çalışıyor. Beş yıl, o zamanki ilerleme hızıyla kalan işin biteceği tahmini zaman. Bir ekibin kesintisiz beş yıl boyunca yalnızca bu işi yapacağı anlamına gelmiyor.

6 milyon dolar da elle yapılacak iş için kaba bir emek hesabı. Üstelik yalnızca kütüphane değişimini değil, ek test iyileştirmelerini ve altyapı temizliğini de kapsıyor. 12 bin dolara ise insan emeği dahil değil. Bu iki rakamı birbirinden çıkarıp tasarruf yazamayız. Asana ile OpenAI ortaklığı kapsamında yayımlanan anlatıda kontrollü bir karşılaştırma da yok.

Yine de geriye somut bir sonuç kalıyor: Yavaş ilerleyen bir iş tamamlanmış. PeşinTaksit ile Asana'nın ölçeği elbette farklı. Ortak taraf, eski tempoda sürüncemede kalacak bir işi bitirebilmek. Başka şirketin süresini kendi projemize vaat olarak almak yerine, bizim bekleyen işimizin hesabını yenilemek daha yararlı.

Yazılan kodu kimin kontrol edeceği hâlâ önemli

Bir temizliğe zaman ayırmaya razı olmak için yalnızca kodun ne kadar hızlı yazılacağını bilmek yetmiyor. Çıkan işi incelemeye ne kadar zaman gidecek? Yanlış bir şey varsa bunu nasıl fark edeceğiz? Geçişin sonunda neyin çalışmaya devam etmesi gerektiğini kim biliyor?

Airbnb'nin yaklaşık 3.500 test dosyasını taşıdığı çalışmada ekip bu soruları işin içine yerleştirmiş. Dosyalar aşama aşama doğrulanıyor. Kontrol geçmeden ilerlenmiyor, hatalar modele geri veriliyor. İlgili kod ve iyi örnekler ekleniyor. Otomasyonun bitiremediği dosyaları mühendisler tamamlıyor.

Airbnb altı haftada bitirdiğini bildiriyor. Şirketin kendi vaka anlatımı bu; süre, başka bir projenin ne kadar süreceğini söylemiyor. Fakat işin nasıl tamamlandığını gösteriyor. Modelin yazdığı kodun arkasında, hatayı yakalayan ve işi yeniden düzeltmeye gönderen bir düzen var.

Testleri değiştirdiğimiz bir işte bunun ayrı bir önemi var. Bir testi sadeleştirirken yakalaması gereken hatayı artık yakalayamaz hâle getirebiliriz. Test yine geçer. Ekranda yeşil görmekle eski davranışın korunduğunu bilmek aynı şey değil. Bu incelemenin emeğini baştan hesaba katmadığımızda, işin yalnızca en hızlı kısmına bakmış oluruz.

Her parçayı AI'a yazdırmak gerekmiyor

Uber'in JUnit geçişinde toplu üretken AI denemesi başarısız olmuş. Ekip dönüşümü, tanımlı kurallarla kodu değiştiren OpenRewrite ile yapmış. AI'ı test ve derleme hatalarını incelemek için kullanmış.

Önce eski ve yeni testlerin birlikte çalışabileceği altyapıyı hazırlamışlar. Geçiş sırasında test hatası veren dosyaları da eski sürüme döndürmüşler. Sonucu mümkün kılan tercih, bütün işi modele vermekte ısrar etmek olmamış.

Bu da bekleyen bir işi yeniden açarken masada durmalı. Tekrarlanan değişiklikleri mevcut bir araç zaten yapabiliyorsa onu kullanabiliriz. Zor kalan dosyaları elle düzeltmek de makul olabilir. Amacımız, hangi araca ne kadar iş yaptırdığımızı göstermek değil, eski yükü kaldırmak.

Küçük başlayıp yarım bırakmamak

PeşinTaksit'te bitiş noktası somuttu: Dört ayrı container'ı yönetmeyi bırakıp daha sade bir yapıya geçtim. Ekip işlerinde de başlangıç kapsamını böyle bir sonuca bağlamak yararlı. Bir modülün eski bağımlılığını tamamen çıkarabilmek veya gereksiz bir servisi kapatabilmek, dosya sayısından daha anlamlı bir hedef.

Bunun için bütün sistemi bir kerede değiştirmek gerekmiyor. Önce sınırlı bir parçayı deneyip kodun yazılmasına, incelenmesine ve düzeltilmesine giden zamanı görmek mümkün. Yalnızca kolay dosyaları seçersek kendimizi yanıltabiliriz. Sık karşılaşılan durumların yanında zor bir istisnanın da denemeye girmesi, kalan işin hesabını daha dürüst kılar.

Bazen bu deneme, işin hâlâ pahalı olduğunu gösterir. Eski sistemin ne yaptığını kimse tam bilmiyorsa, hızlı kod üretmek bu eksikliği kapatmaz. Önce beklenen davranışı ortaya çıkarmak gerekir. Bu yükü de fiyatın içine koyup beklemeye devam edebiliriz.

Üretime geçişin sorumlusu da belli olmalı. Çalıştığını neye göre kabul edeceğiz, sorun çıktığında kim durduracak, nasıl geri döneceğiz? Veri taşınıyorsa eski uygulamayı açmak yetmeyebilir. Arada gelen yeni kayıtların ne olacağını da çözmek gerekir. Eski yapıyı ne zaman kapatacağımız ve yenisini kimin izleyeceği, işin sonuna bırakılacak ayrıntılar değil.

Benim PeşinTaksit'te kazandığım, hiç ayırmayacağım birkaç günü takvimde boşaltmak değildi. Bekleteceğim bir işi bitirdim. Ekiplerin iş listesinde de bu gözle bakılacak işler olabilir. O işlerden birinin eski tahminini küçük bir denemeyle yenilemek, başlamak için yeterli.

Yararlı okumalar

• The Pulse: We need to talk about migrations with AI: Yazının çıkış noktası olan tartışma, Asana'nın süre ve maliyet tahminlerini önceliklendirme bağlamında ele alıyor. Vakalar karşılaştırmalı hız kanıtı değil. Uber'de AI'ın sınırlı rolü için yukarıdaki birincil anlatım esas alınmalı.