TDD, AI Agents and Coding - Kent Beck

Kent Beck’e Giriş

• Extreme Programming (XP) kurucusu
• Agile Manifesto’nun ortak yazarı (alfabetik sırada ilk imzacı)
• TDD’nin (test güdümlü geliştirme) öncüsü
• 52 yıllık kodlama deneyimine sahip sektör efsanesi
• Şu anda "Tidy Together" (yazılım tasarımı ve ekip çalışması) üzerinde yazıyor
• Günde 6-10 saatten fazla AI araçlarıyla kod yazarak "programlamanın en keyifli dönemini" yaşıyor

---

1. AI kodlama araçları ve 'cin' benzetmesi

Temel kavram: öngörülemez cin

• AI ajanlarını "öngörülemez bir cin" olarak benzetiyor
• "Ne demek istediğimi tam olarak yapmıyor"
• "Kendilerine ait bir gündemleri var"

AI ile çalışma deneyimi

Olumlu tarafları:

• Bazen şaşırtıcı bir sihir gibi büyük tasarım problemlerini çözüyor
• Beklenmedik şekilde faydalı özellikler geliştiriyor (ör. B+ tree stress tester)

Olumsuz tarafları:

• Kullanıcı niyetini yanlış yorumluyor
• Testleri silmeye ya da değiştirmeye çalışıyor
• Problemi lookup table ile "çözmeye" çalışan yaramaz davranışlar sergiliyor

Bağımlılık yaratan deneyim

• Slot makinesi benzeri aralıklı ödül
• "Gece bilgisayarın önünden geçerken 'bir prompt daha mı versem?' diye düşünmek"
• "Bir saatlik bir prompt başlatıp dışarı çıkmak"

---

2. AI çağında becerilerin değişimi

Beceri değerlerinin yeniden dağılımı

"Becerilerin %90’ı değer kaybediyor, %10’u ise 1000 kat değer kazanıyor"

Değeri artan beceriler:

• Vizyon belirleme
• Kilometre taşı yönetimi
• Karmaşıklığı kontrol etme

Değeri azalan beceriler:

• Dile özgü ayrıntılar (Rust’taki &, *, [] konumları gibi)

Programlama dillerine bakışın değişmesi

Geçmişte: Smalltalk’a güçlü duygusal bağlılık
Bugün:

• "Kalbi çok kez kırıldığı için" dillere bağlılığı kalmamış
• "Java geliştiricisi", "Clojure geliştiricisi" gibi kimlik ayrımlarından yorulmuş
• "Ozmozla öğrenme": AI sayesinde dil ayrıntılarını bilmeden de programlayabilmek

Son dönemde denediği diller: Swift, Go, Rust, Haskell, C++, JavaScript

Şu anki iddialı proje: Server Smalltalk

• Kalıcı (persistent): veritabanı gibi çalışıyor
• İşlemsel: commit ve abort yapılabiliyor
• Paralellik: çoklu thread ve makineler arası paralel işleme
• Büyük veri işleme

---

3. Agile Manifesto’nun tarihi

Ortaya çıkış arka planı (2001)

• Şelale modeline alternatif arayışı
• Yıllarca süren yazılım metodolojisi atölyelerinin sonucu
• Norveç kruvaziyeri hazırlık toplantısı → Utah’taki nihai toplantı

Kent Beck’in katkısı

• "daily" kelimesini ekledi (12 ilke içindeki "günlük etkileşim")
• Alfabetik sıradaki ilk imzacı

"Agile" terimine yönelik memnuniyetsizlik

Sorunlar:

• "Fazla çekici" olduğu için tüm organizasyonlar tarafından kötüye kullanılacağını öngördü
• Gerçekte ilkelere uymadan kendine agile diyen organizasyonlar ortaya çıktı

Tercih ettiği alternatif: "conversational (diyaloğa dayalı)"

• Tek yönlü değil, çift yönlü iletişimi vurguluyor
• Yeterince çekici bulunmadığı için benimsenmedi

---

4. Extreme Programming (XP)

Ortaya çıkış arka planı

İlk danışmanlık deneyimi:

• Başlangıçta teknik danışmandı (performans tuning, bit manipülasyonu)
• Zamanla daha fazla proje yönetimi tavsiyesi istenmeye başlandı
• Ortamın önemini keşfetti: sadece oturma düzenini değiştirerek bile dramatik iyileşme

Chrysler projesi:

• Başarısız giden bir projeyi başarıya çevirdi
• Etkili olan tüm pratikleri "en üst seviyeye (11’e)" çıkardı

XP’nin temel ilkesi

Dört etkinliği zamanı küçük parçalara bölerek eşzamanlı/sıralı yürütmek:

1. Ne yapılacağını belirlemek
2. Hangi yapıyla yapılacağını tasarlamak
3. İşlevi uygulamak
4. Beklendiği gibi çalışıp çalışmadığını doğrulamak

Pair programming

• Zorunluluk değil, deneysel bir yaklaşım
• İlk ekip deneyimi: geliştirme sonrası bulunan tüm hatalar tek başına yazılan koddan çıktı
• "Pair programming sırasında production hatası sıfırdı"

İsimlendirme stratejisi

• "Extreme" seçiminin nedeni: rakibin (Grady Booch) kullanmayacağı kadar provokatif bir isim olması
• Extreme sporların popüler olduğu döneme denk geldi
• "Aşırı sporcular ya en iyi şekilde hazırlanır ya da ölür" - iyi bir metafor

Başarı faktörleri

• Dot-com balonu döneminde 18 aylık şelale süreçlerinden bunalan geliştiricilere hitap etti
• Daha hızlı ve daha öngörülebilir sonuçlar vaat etti

---

5. Test güdümlü geliştirme (TDD)

Kökeni ve ilhamı (1970’ler)

Tape-to-tape sistemler:

• Babasının programlama kitabında gördüğü bir kavram
• Gerçek girdiyi alma → beklenen çıktıyı elle yazma → kodu yazma → gerçek çıktı ile karşılaştırma
• 8-12 yaşlarındayken okudu ama anlayamadı

S-Unit geliştirme:

• Müşterinin test yazmasına yardımcı olmak için geliştirdi
• "Kodu yazmadan önce beklenen değeri girmek" gibi "saçma" bir fikri denedi

İlk TDD deneyimi: stack implementasyonu

Kaygılı kişilik:

• "Ben kaygılı biriyim. Çok endişelenirim"
• "Programlama sürekli bir kaygı kaynağıdır" (Neyi unuttum? Neyi bozdum?)

TDD sonucu:

• "Kaygı tamamen ortadan kalktı"
• "Bunun çalıştığından eminim"
• Programlamanın duygusal deneyimi değişti

TDD’nin değeri

Teknik faydalar:

• Hata yoğunluğunu azaltma
• API seçimi hakkında hızlı geri bildirim
• Uygulama tasarımının evrimine olanak tanıma

Duygusal faydalar:

• "Sadece teknik kaygı bozukluğunun ilacı olarak bile yeterince değerli"

Tasarıma yönelik itiraza yanıt

John Osterhout’un eleştirisi: "TDD tasarıma yardımcı olmaz, sadece ayrıntılara odaklanır"

Kent Beck’in yanıtı:

• "Bu bir tercih meselesi"
• Uygulayıcılar tasarım kararları verirken soyutlama seviyeleri arasında sürekli gidip gelir
• Red-Green döngüsündeki "gerilim boşalması" anı, daha büyük tasarım düşüncesi için özgürlük sağlar

---

6. AI ajanları ve TDD

Pratikte uygulama

Her zaman önce test yazmak:

• AI’nin kaçırdığı noktaları testlerle iletmek
• AI’nin testleri değiştirme/silme girişimlerini engellemek

Gerekli iyileştirmeler:

• "Immutable annotation" gerekli
• "Bu doğru. Bunu değiştirirsen sonsuza dek karanlıkta uyanacaksın"

AI’nin sınırlamaları

• Bağlılığı azaltma / uyumu artırma becerisi zayıf
• Tasarım sezgisi eksik
• Uzak etkiler yaratan kararlar alma eğiliminde

Karşı strateji

• 300 milisaniyede çalışan büyük bir test paketi
• AI’nin istemeden kodu bozmasını gerçek zamanlı tespit etmek

---

7. Facebook deneyimi (2011-2017)

2011’de katıldığında yaşadığı şok

TDD dersine sıfır katılımcı:

• İleri Excel teknikleri: tam dolu + bekleme listesi
• Arjantin tangosu: tam dolu + bekleme listesi
• TDD: katılımcı yok

Uyum stratejisi:

• "Yazılım mühendisliği hakkında bildiğim her şeyi unutmak"
• "Maymunu gör, maymunu yap" yaklaşımını seçmek

Facebook’un benzersiz geliştirme ortamı

Güçlü sorumluluk duygusu:

• Programcılar gece çağrılarında sorumlu kişilerdi
• "Kendi hatalarının acısını doğrudan hissediyorlardı"

Çok katmanlı geri bildirim döngüsü:

• Hızlı geliştirme sunucusu (mavi→yeşil değişiklikten hemen sonra doğrulama)
• Code review
• İç dağıtım (çalışanlar kişisel/iş amaçlı kullanıyor)
• Kademeli rollout (günlük/haftalık)
• Mükemmel gözlemlenebilirlik

Organizasyon kültürü:

• "Facebook’ta hiçbir şey başkasının problemi değildir"
• Bir büyükanne torununa zorbalık yapıldığı şikayetiyle gelse bile "bu da senin problemin"

TDD’nin neden uygun olmadığı

Gerçek problem alanları:

• Konfigürasyon sorunları
• Alt sistemler arası ilişkiler
• Testlerle yakalanması zor konular

Facebook’a özgü avantajlar:

• Milyonlarca kullanıcı üzerinde canlı büyük ölçekli test
• Mükemmel gözlemlenebilirlik
• Feature flag
• Normal şirketlerde kurulması zor bir ortam

Somut örnek:

• İlişki durumu özelliğinin geliştirilmesi (bekâr/evli’ye civil union/birlikte yaşama eklenmesi)
• TDD kullandı ama "zaman kaybıydı"
• Bildirim kodundaki örtük bağlılık sorun yarattı → başka biri hotfix yaptı

Zaman içindeki değişim

2011 (2.000 kişi):

• Olasılık, ölçek ve sahiplenme duygusu zirvedeydi
• Global optimizasyon düşünen orta kademe yöneticiler vardı
• "Kimin gerçekten yardıma ihtiyacı var" diye düşünen bir iş birliği kültürü

2017 (15.000 kişi):

• Politika, sıfır toplamlı düşünme ve mikro optimizasyon öne çıktı
• Büyük resmi çizmek zorlaştı
• Ekipler arası çıkar çatışmaları arttı (ör. uzun yazılar vs beğeni/yorum optimizasyon ekibi)

Ölçeğin deneyimi

• Messenger API: haftada 1 quadrillion çağrı
• Deney grubu "Yeni Zelanda" ölçeğinde (bir milyon kişi)
• 1 quadrillion = bir milyon × bir milyar

---

8. AI çağında yazılım geliştirmenin geleceği

Paradigma değişimi

Maliyet yapısının tamamen yeniden kurulması:

• "Ucuz ve pahalı arasındaki sınır tamamen değişiyor"
• Eskiden pahalı sayılan şeyler "akıl almaz derecede ucuz" hale geliyor

Organizasyonların uyum zorluğu

Daha fazla kodu çöpe atmak:

• 10 kat daha fazla artifact üretmek mümkün
• Buna rağmen hâlâ yalnızca biri değerli
• "Tamamlanmış deneyleri atmayı" ödüllendiren sistemlere ihtiyaç var

Deneylerin niceliksel artışı:

• Keşfedilen fikirlerin miktarı rekabet avantajı haline geliyor
• "Her şeyi denemek zorundayız" dönemi

Kişisel değişim

• Kod yazmak yeniden eğlenceli hale geldi
• Daha büyük hedefler kurabilir oldu
• "İnanılmaz derecede iddialı fikirleri" hayata geçirmek mümkün hale geldi

---

9. Hızlı Soru-Cevap

Kişisel tercihler

• En sevdiği dil: Smalltalk
• İkinci dil: JavaScript (Smalltalk’a benzer)
• Şu an kullandığı AI aracı: Claude (Cursor, Augment’in iç motoru)
• Önerdiği kitap: Christopher Alexander’dan "The Timeless Way of Building"

---

Temel içgörüler

1. Bağlamın mutlak önemi

• Aynı metodoloji bile ortama göre tamamen farklı etki yaratır
• Facebook’un büyük ölçekli ortamı vs bir bankanın küçük ölçekli işlem ortamı

2. Duygu ile teknoloji arasındaki ilişki

• TDD’nin gerçek değeri "kaygıyı gidermesi"
• Teknik mantıktan çok duygusal dönüşüm daha önemli

3. AI çağında yeni düşünme biçimi

• Vizyon ve tasarım becerileri temel beceriler olarak öne çıkıyor
• Dil ayrıntıları artık eskisi kadar önemli değil
• Deney sayısındaki artış rekabet avantajı sağlıyor

4. Organizasyon kültürünün gücü

• "Hiçbir şey başkasının problemi değildir" anlayışındaki sahiplenme
• Global optimizasyon vs bireysel optimizasyon farkı
• Teşviklerin hizalanmasının önemi

[mse9000]

Facebook'un kendine özgü geliştirme ortamı
Güçlü sorumluluk duygusu:
programcılar gece çağrılarının muhatabı
"Kendi hatalarının acısını doğrudan hissediyorlar"

k-geliştirme ortamından çok da farklı değil mi...?

[helloppfm]

Hâlâ buralardasınız.

Eskiden TDD hakkında bir makine şirketinde seminer vermiştim; herkesin "Bu da ne?" der gibi baktığı o bakışları hâlâ unutamıyorum.

TDD'nin iyi olduğunu düşünüyorum ama düşündüğüm kadar iyi yürümediği için...
Entegre testleri TDD gibi yapıyorum. Tabii ki bu TDD değil. ^^

[kandk]

Hâlâ TDD mutlak savunucuları ile gereksiz olduğunu söyleyenler tartışıyor,
mevcut sektör koşullarına yeniden uygun bir TDD v2 sürümü çıkarsa iyi olur.
Bugünlerde küçük işleri yapay zeka kolayca hallediyor; bu yüzden büyük miktarda bağlam gerektiren durumlarda bunun nasıl kullanılacağı gibi konular da dahil edilmeli..

[codemasterkimc]

Güzel bir yazı.