Evet" Demenin Maliyeti Değişti: Yeni Denge

⏱️ 5 dk okuma📅 17 Temmuz 2026👁️ görüntülenme

Bir zamanlar küçük bir özellik talebinin en pahalı kısmı kodu yazmaktı. Bugün ise çoğu zaman en pahalı kısım, o kodun yazılıp yazılmayacağını tartıştığımız toplantı hâline geldi. GitHub Blog’da Dalia Abuadas’ın kaleme aldığı yazı, tam da bu sessiz kırılmayı ele alıyor: Kod üretmenin maliyeti düştü, ama sahiplenmenin maliyeti aynı kaldı. Bu durum, mühendislik içgüdülerimizi yeniden ayarlamamızı gerektiriyor.

Küçük İstekler Neden Küçük Değildi?

Mühendisler erken dönemde şunu öğrenir: “Küçük” diye gelen taleplerin çoğu aslında küçük değildir. Testler, dağıtım planı, uç durumları düşünecek biri ve yayına çıktıktan sonra davranışı sahiplenecek bir sorumlu gerekir. Yanlış bir bileşene dokunan iki saatlik bir değişiklik, iki haftalık bir dikkat dağınıklığına dönüşebilir. Bu yüzden geri iteriz: Bu gerçekten gerekli mi? Bu sürüme mi girmeli? Zaten anlaştığımız bir sözleşmeyi bozuyor mu?

Yazar bu içgüdüden vazgeçmeyi önermiyor. Ancak bu içgüdünün dayandığı bir varsayımın sessizce çöktüğünü söylüyor: Kodun ilk sürümünü yazmanın pahalı adım olduğu varsayımı. Belirli bir değişiklik sınıfı için bu artık geçerli değil. Bu değişiklikleri diğerlerinden ayırt edebiliyorsanız, “bu kapsamda mı?” sorusunu iki günlük bir tartışma yerine otuz dakikada yanıtlanabilecek bir soruyla değiştirebilirsiniz.

Tartışma Genellikle Yamadan Daha Pahalı

Yazıda tekrarlayan bir örüntüden söz ediliyor. Birisi küçük bir değişiklik istiyor; örneğin backend’de zaten var olan bir last_active_at zaman damgasını ayarlar sayfasında göstermek. Ekip bir başlıkta kırk dakika harcıyor. Biri riskli olduğunu söylüyor. Bir başkası iki yıl önceki bir migration’ı hatırlıyor. Bir başkası son teslim tarihinden bahsediyor. Sonunda “muhtemelen bir-iki gün, daha da olabilir” gibi düşük güvenli bir tahminde karar kılınıyor; çünkü kimse gerçekten denememiş.

Bu süreç, denemenin pahalı olduğu dönemde anlamlıydı. Yaptığınız işi bırakıp bağlamı zihninize yüklemeniz, değişikliği elle yapmanız, testleri yazmanız ve ardından ikincil-üçüncül sonuçları keşfetmeniz gerekiyordu. İlk deneme ucuzsa, sınırı savunmak sınırı geçmekten daha pahalı olabiliyor.

Bir ajan, o başlığın ısınmasının aldığı sürede ilk yamayı üretebilir. Bu ne bedavadır ne de otomatik olarak doğrudur. Ama yeterince ucuzdur; dolayısıyla akıllıca hamle çoğu zaman tahmin etmeyi bırakıp gerçek bir diff’e bakmaktır.

İlk Yama Ürün Değil, Fiyat Sorgusudur

Buradaki hata, üretilen yamayı teslim edilecek çıktı gibi görmek. Değil. O bir sonda. Soyut bir kapsam tartışmasını sorgulayabileceğiniz somut bir esere dönüştürüyor:

Beklediğiniz dosyalara mı dokunuyor, yoksa beş farklı pakete mi yayılıyor?
Testler açık mı, yoksa değişiklik test edilmeye direniyor mu?
Mevcut soyutlamaları koruyor mu?
Sessizce yeni bir ürün kararı mı gerektiriyor?
Bu davranışı altı ay sonra sahiplenmekten rahatsız olur muydunuz?

Bunlar “bu kapsamı aşıyor mu?” sorusundan daha iyi sorulardır; çünkü artık his değil, kanıt üzerinden konuşuyorsunuz. Eğer last_active_at talebi geçen bir testle birlikte dört satırlık bir diff olarak dönerse, gönderin. Pahalı olan zaten tartışmaydı. Ancak aynı istek auth middleware’ine dokunarak geri dönerse, isteğin aslında hiç küçük olmadığını öğrenmiş olursunuz. Üstelik bunu iki günde değil, otuz dakikada öğrenmişsinizdir.

Yazarın altını çizdiği nokta önemli: Bu, kararı yapay zekâya bırakmak değil. Bu, insan yargısını daha ucuz ve daha iyi bilgilendirilmiş hâle getirmek için yapay zekâyı kullanmaktır.

Yazması Ucuz, Sahiplenmesi Ucuz Değil

Yapay zekâ döneminin en kritik ayrımı burada. Bir değişiklik, sadece kod üretilmesi ucuz olduğu için ucuz değildir. Ancak bir insan sonucu güvenle inceleyip sahiplenebiliyorsa ucuzdur.

Teknik olarak geçen ama kimsenin sahiplenmek istemediği bin satırlık bir diff, ucuz bir değişiklik değildir. Ertelenmiş bir maliyettir. O hâlde ayırıcı çizgi “bunu bir ajan yazabilir mi?” değil, “bir insan bunu doğrulayabilir mi?” sorusudur.

Backend’de zaten var olan bir görüntüleme alanını eklemek genellikle ucuzdur.
Yetkilendirme davranışını değiştirmek, diff ne kadar temiz olursa olsun ucuz değildir.
İyi test edilmiş bir yardımcıyı yeniden düzenlemek genellikle ucuzdur.
Veri saklama semantiğini değiştirmek ucuz değildir.

Kod önemsiz olsa bile kesin bir “hayır” hak eden pek çok değişiklik var. Ürün sözleşmesini değiştiren, destek yükü yaratan ya da gizlilik, faturalama veya uyumluluğa dokunan her şey bu kategoriye giriyor. Yapay zekâ bir aday üretmenin maliyetini düşürür; onu sahiplenmenin maliyetini düşürmez.

Kapsam Disiplinini Kanıta Yaklaştırın

Geleneksel olarak kapsam disiplini uygulamadan önce devreye girerdi; çünkü korunması gereken pahalı şey uygulamaydı. Şimdi bu disiplinin bir kısmı incelemeye kayabilir. Bu, planlamayı atlamak anlamına gelmiyor. Hangi planlamanın gerçekten karşılığını verdiği konusunda kesin olmak anlamına geliyor.

Küçük bir değişikliği yeniden tartışmaya açmadan önce, kısıtlı bir deneme isteyin. Kısıtlamalar burada işin özüdür:

Mümkün olan en küçük yamayı üret.
Mevcut özellik bayrağının arkasında tut.
Herkese açık sözleşmeyi değiştirme.
Testleri ekle veya güncelle.
Dokunduğun her dosyayı listele ve riskli gördüklerini işaret et.

Eğer ajan bu kısıtlar altında temiz bir yama üretemiyorsa, istek düşündüğünüzden büyüktür ve kimse taahhüt vermeden önce gerçek bir sahiplenme maliyeti taşıdığını bilirsiniz. Üretebiliyorsa, bu da size bir şey söyler. Her iki durumda da “bu kapsamda mı?” sorusunu “işte maliyeti şu, ödemek istiyor muyuz?” sorusuyla değiştirmiş olursunuz.

Yeni Beceri: Belirsizliği Fiyatlamak

Yapay zekâ destekli bir dünyanın en iyi mühendisleri, her şeye evet diyenler ya da refleksle hayır diyenler olmayacak. Belirsizliği hızlıca fiyatlayabilenler olacak. Bir talebin ne zaman uygulama kılığına girmiş bir ürün kararı olduğunu, incelemenin ne zaman yazmaktan daha zor olacağını ve bir değişikliğin ne zaman “sadece deneyip görmek” en sorumlu yanıt olacak kadar küçük olduğunu bileceklerdir.

Bu sonuncusu gerçekten yeni. “Deneyip görelim” eskiden bir geliştiriciyi başka işlerinden çekmek demekti. Şimdi, doğru türden bir görev için, bir ajana sınırları belli bir atama vermek ve sonucu daha iyi bir karar için kullanmak anlamına geliyor. Daha az tahmin, daha çok denetim. Uygulamayı kara kutu gibi görmek yerine somut eserleri değerlendirmek.

Kapsam kayması hâlâ gerçek bir sorun. Ama “hayır, çünkü her yeni kod fazla pahalı” argümanı iki yıl öncesine göre çok daha zayıf. Kod üretme maliyeti düştü; anlama, inceleme ve sahiplenme maliyeti düşmedi. Sorulacak asıl soru “bu daha fazla iş mi?” değil, “gerçek maliyet nerede?” Bazen küçük, sınırları belli bir değişiklik için gerçek maliyet, sadece öğrenmenin kendisi. Evet demenin maliyeti değişti; hayır demenin maliyeti de onunla birlikte değişmeli.

Pratikte Nasıl Uygulanır?

Yazının önerdiği yaklaşım, günlük iş akışına iki basit soruyla girebilir. Birincisi: Tartışmaya başlamadan önce, sınırlı bir denemeyle ilk yamayı görmek mümkün mü? İkincisi: Bu yama, bir insan tarafından güvenle sahiplenilebilir mi? Bu iki soru, kapsam tartışmalarını hislerden kanıtlara taşıyor. Kod inceleme tarafında yapay zekâ araçlarını değerlendirenler için, üretim kolaylığı ile sahiplenme zorluğu arasındaki dengeyi kurmak giderek daha kritik bir beceriye dönüşüyor.

Kaynaklar ve İleri Okuma

github.blog

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102