Yazılım ekipleri genellikle kod kalitesi üzerine tartışır: Temiz mi, okunabilir mi, iyi test edilmiş mi ya da AI tarafından mı üretilmiş? Tüm bu sorular önemli olsa da, asıl kritik soru çoğunlukla gözden kaçar:
Bu davranışın ne olduğu ve neden var olduğu, kod deposu tarafından kanıtlanabiliyor mu?
Geliştiriciye, ürün yöneticisine ya da dört yıldır takımda olup bu tuhaf kenar durumun kasıtlı olduğunu bilen kişiye değil — doğrudan koda bakıldığında. Çünkü sistemler yaşlandıkça, "nasıl çalıştığı" ile "kodun kanıtlayabildiği şey" arasındaki fark giderek açılır. Ve bu boşlukta hatalar saklanır.
Kodun davranışıyla aynı şey olmadığı gerçeği
Bir kod deposu size kodu, commit geçmişini, dosyaları kimlerin değiştirdiğini ve ne zaman değiştirdiğini gösterebilir. Ancak kod geçmişi, davranış geçmişi değildir.
Git size şunu söyleyebilir:
Bu fonksiyon Salı günü değiştirildi.
Ancak genellikle şunu söyleyemez:
Bu fonksiyon, ödeme sağlayıcısının 24 saat boyunca başarısız olayları yeniden denemesi nedeniyle tekrar eden webhook gönderimlerini işler. Bu mantığı idempotency testleri güncellenmeden değiştirmek risklidir.
İkinci cümle, ekiplerin aslında ihtiyaç duyduğu şey — ve birçok kod tabanında sadece birinin aklındadır. Bazen 2022’den bir Slack konuşmasında, bulunamayan bir Jira biletinde ya da o an anlamlı görünen bir PR yorumunda yaşar. Bazen hiçbir yerde yoktur.
Kod hâlâ çalışır. Testler hâlâ geçer. Takım hâlâ yayınlar. Ancak kod deposu artık neden var olduğunu kaybetmiştir.
AI sorunu kötüleştirdi, ama onu ortaya çıkaran AI değildi
AI kodlama araçlarını suçlamak kolay. AI temiz görünen kod üretir, geçen testler yazar ve makul açıklamalar sunar. Ancak her takım, AI’dan çok önce de bu tür kodlara sahipti:
if (user.country === "US" && order.total > 0) { enableManualReview = true; }Neden? Dolandırıcılık kuralı mı? Vergi kuralı mı? Eski bir iş gereksinimi mi? Geçici bir çözümün kalıcı hale gelmesi mi? Kimse bilmiyor.
Şimdi AI’yı ekleyin. Bir kodlama ajanı bu koşulu görür ve "sadeleştirmeye" çalışır. Bir inceleyici temiz bir diff görür. Testler geçer, çünkü kimse orijinal davranışı test etmemiştir ve PR birleştirilir. İki hafta sonra, birisi neden elle inceleme sürecine giren siparişlerin durduğunu sorar.
Davranış gerçekti. Kanıt ise yoktu.
Yeşil bir test seti, anlama kanıtı değildir
Testleri seviyorum, ancak testler sadece belgelemeye değer olduğunu düşündüklerimizi kanıtlayabilir. Bir test, bir fonksiyonun 200 yanıtı döndürdüğünü kanıtlayabilir. Ancak fonksiyonun yeniden deneme yapmasına izin verilip verilmediğini, yeniden denemenin idempotent olması gerektiğini ya da zaman aşımının mobil bir istemciye bağlı olduğunu kanıtlamayabilir.
Geçen bir test seti genellikle "yazdığımız kontroller hâlâ geçiyor" anlamına gelir — "kullanıcıların bağımlı olduğu davranışlar hâlâ korunuyor" anlamına gelmez.
Bu yüzden kanıt eksikliğinin bir sinyal olarak görülmesi gerekir, sadece bir rahatsızlık olarak değil. Bir PR ödeme mantığını değiştiriyor ve ödeme testlerinde hiçbir değişiklik yapılmadıysa, bu otomatik olarak PR’nin kötü olduğu anlamına gelmez — ancak bir sinyaldir. Bir özellik beş farklı uygulama, üç farklı adlandırma stili, dokümantasyon eksikliği ve sadece mutlu yol testlerini kapsayan testlere sahipse, gelecekteki bir değişiklik daha tehlikelidir. Kod deposu size sessizce şunu söylüyor: Çalışabilirim, ancak neden var olduğumu tam olarak açıklayamam.
Bu fark, kod üretiminin kolaylaştığı şu dönemde daha da önemli hale geliyor. Kod ucuzlaştıkça, anlama pahalılaşır.
Yeni kod inceleme sorusu
Geleneksel inceleme, kodun doğru, okunabilir, güvenli ve test edilmiş olup olmadığını sorar. Bu sorular hâlâ önemlidir. Ancak riskli bir PR incelenirken, bir soru daha sormalıyız:
Bu değişiklik hangi davranışı korumayı iddia ediyor ve kanıt nerede?
Bir PR fatura webhook’larını etkiliyor olsun. İnceleme sadece kodun iyi görünüp görünmediğini değil, şunları da sormalıdır: Bu değişiklik tekrar eden gönderimleri etkiliyor mu? Yeniden deneme davranışını, olay sırasını ya da iadeleri değiştiriyor mu? Ve her cevap için — kanıt var mı, yoksa sadece güven mi?
Bu bürokrasi eklemek değildir. Deponun kendini açıklayamadığı için güvenli görünen değişiklikleri birleştirmeyi reddetmektir.
"Dokümantasyon" yeterli değildir
Genellikle verilen yanıt: daha iyi dokümantasyon yazın. Kısmen katılıyorum. Dokümantasyon, sistemin yakınında kaldığında kullanışlıdır; sistemden uzaklaştığında tehlikelidir.
Bir README’nin "webhook’ların idempotent olduğunu" belirtmesi güzeldir. Ancak tekrar eden gönderimlerin güvenli olduğunu kanıtlayan bir test daha iyidir. Neden yeniden denemelerin bu şekilde çalıştığını açıklayan bir karar kaydı daha da iyidir. Ve iddianın kendisiyle, kanıtlarla, dosyalarla, testlerle ve yakın geçmişteki değişikliklerle bağlantı kuran bir aracın varlığıysa en iyisidir.
Yazılım bakımının geleceği daha fazla dokümantasyonda değil, kanıta dayalı dokümantasyondadır: İşte iddia, işte kanıt, işte hâlâ belirsiz olan şey. Bir kod deposunun "bilmiyorum" demesine izin verilmelidir — bu, hiçbir şey olmadığını iddia etmekten çok daha sağlıklıdır.
Belki de kod depolarının bir "anlama puanı"na ihtiyacı vardır
Test kapsamını, derleme süresini, bundle boyutunu, değişiklik sıklığını, güvenlik açıklarını ve bağımlılık riskini ölçüyoruz. Ancak nadiren bir kod deposunun kendi önemli davranışlarını açıklayabilme yeteneğini ölçüyoruz.
Bir kod deposunu açtığınızı ve şunu gördüğünüzü hayal edin:
| Alan | Kanıt Durumu | |------|-------------| | Kimlik Doğrulama | Güçlü | | Fatura Webhook’ları | Kısmi | | Dosya Yükleme | Zayıf | | Yönetici İzinleri | Belirsiz | | E-posta Gönderimi | Karar kaydı bulunamadı |
Bu puan mükemmel olsun diye değil, insan incelemesini de ortadan kaldırmak için değil — sistemin hangi bölümlerinde güvenin sahte olduğunu göstermek için. Ve sahte güvenlik pahalıdır.
Gerçek darboğaz
AI araçları sürekli gelişecek. Daha fazla kod yazacak, daha fazla PR açacak, daha fazla hatayı düzeltecek, daha fazla testi üretecek. Bu sorun değil. Asıl sorun, daha hızlı kod üretiminin otomatik olarak daha iyi sistem anlayışı yaratmamasıdır — bir takım daha fazla kodu yayınlarken, davranışları koruma anlayışından yoksun olabilir.
Darboğaz sentaks, boilerplate ya da inceleme hızı değil. Darboğaz kanıttır. Bu davranışın ne olduğunu, neden var olduğunu ve bu değişikliğin onu bozup bozmadığını kanıtlayabiliyor muyuz? Kod depoları bu soruları yanıtlayana kadar, güvenilere, folklora ve tahminlere bel bağlıyoruz.
Ve tahmin kanıt değildir.
Yapay zeka özeti
Kodunuzdaki en tehlikeli davranışlar, kanıtlanamayan fonksiyonlardan kaynaklanıyor. AI çağında bile, kodun neden var olduğunu açıklayabilmek kritik önem taşıyor.
