Cuma akşamı saat 18:42. Deploy her zamanki gibi akıp gidiyordu—pipeline yeşil, testler geçmiş, checklist tamam. Slack’e düşen “✅ Production deploy edildi” mesajıyla herkes rahatladı. Hafta sonu resmen başlamıştı.

Pazartesi sabahıysa tablo değişti. İlk alarm geldi. Dashboardlar tuhaf görünüyordu. Kullanıcı davranışı kaymış, tahminler tutarsızlaşmıştı. Sistem… sanki eski bir versiyona geri dönmüş gibiydi.

İlk tepkiler tanıdık: “Cache mi?”, “Rollback mi oldu?”, “Data mı değişti?” Loglara girildi ve gerçek ortaya çıktı. Sorun karmaşık değildi—yanlış model deploy edilmişti.

Dosyalar yan yana duruyordu:
model_v3_final.pkl
model_v3_final_updated.pkl
Pipeline aslında doğru çalışmıştı. Hiçbir şey bozulmamıştı. Sadece yanlış dosya seçilmişti—o kadar.

Deploy sırasında iki geliştirici aynı ekrana baktı. İkisi de dosya adını gördü ama kimse şu basit soruyu sormadı: “Deploy ettiğimiz modelin adı ne?”

Kod review yapılmıştı. Checklist işaretlenmişti. Pipeline kusursuzdu. Ama kimse gerçekten teyit etmemişti. Sorun sistemde değil, kontrolün kendisindeydi.

Kod review ekiplerinin en çok güvendiği mekanizmalardan biri. Ama çoğu zaman süreç şöyle işliyor: hızlı bir scroll, “LGTM”, sonra merge. Review yapılıyor ama derinlemesine incelenmiyor. Çünkü amaç çoğu zaman doğrulamak değil, ilerlemek oluyor.

Buradaki asıl sınır görsel kontrol. Diff’e bakıyoruz, satırları inceliyoruz ama beynimiz tanıdık şeyleri otomatik olarak “doğru” kabul ediyor. Benzer dosya isimleri mi? “Muhtemelen doğru.” Küçük farklar mı? “Önemsizdir.” Hatalar tam da burada saklanıyor.

Japon demiryollarında kullanılan Shisa Kanko yöntemini düşün. Makinist sadece bakmaz—işaret eder ve yüksek sesle söyler: “Bu sinyal yeşil.” Bu basit hareket, pasif bakışı aktif doğrulamaya çevirir. Yazılımda karşılığı net: “Deploy edilen dosya: model_v3_final_updated.pkl” ya da “Bu değişiklik sadece logging’i etkiliyor.” Söylemek zihni gerçekten kontrol etmeye zorlar.

Peki ya iki kişi kuralı? Çoğu ekip buna güvenir ama gerçek şu: iki kişi bakmak, iki kişinin gerçekten kontrol ettiği anlamına gelmez. Süreç pasifse herkes varsayar, hızlı geçer ve aynı hatayı birlikte kaçırır. Shisa Kanko’nun farkı burada—herkes aktif olmak zorunda. Biri söyler, diğeri gerçekten duyar ve doğrular.

Pair programming’in gücü de buradan gelir. Mesele sadece birlikte kod yazmak değil; sürekli konuşmak, anında teyit etmek. “Burada null check yapıyorum.” “Bu fonksiyon şu değeri döndürüyor.” Bu küçük cümleler hataları daha oluşmadan yakalar. Asıl farkı yaratan şey iki kişi değil, sürekli doğrulama döngüsüdür.

İyi haber şu: büyük değişikliklere gerek yok. Kod review sürecine birkaç küçük alışkanlık eklemek yeterli—kritik satırları sesli okumak, deploy edilecek artefact’ı adıyla teyit etmek, “Bu değişiklik ne yapıyor?” sorusunu gerçekten sormak. Küçük gibi görünen bu adımlar büyük hataları engeller.

Çoğu ekip hataların sebebini hızda arar. Ama sorun genelde hız değil, yüzeyselliktir. Yavaş ama yüzeysel bir review de aynı hatayı kaçırır. Hızlı ama dikkatli bir süreç ise yakalayabilir. Farkı yaratan şey basit: aktif doğrulama.

Ve cuma akşamına dönersek—aslında hiçbir şey yanlış gitmedi. Sistem çalıştı, süreç işledi, araçlar görevini yaptı. Eksik olan tek şey şuydu: Biri durup gerçekten kontrol etmedi.

Bazen en büyük hata,
hiç kimsenin hata aramamasıdır.

İki kişi baktı. Ama kimse sormadı.