TDD, Agen AI, dan Coding - Kent Beck

Perkenalan Kent Beck

• Pendiri Extreme Programming (XP)
• Salah satu penulis Agile Manifesto (penanda tangan pertama menurut urutan alfabet)
• Pelopor TDD (test-driven development)
• Legenda industri dengan 52 tahun pengalaman coding
• Saat ini sedang menulis "Tidy Together" (desain perangkat lunak dan kerja tim)
• Kini menghabiskan "masa pemrograman yang paling menyenangkan" sambil coding dengan alat AI selama 6-10+ jam per hari

---

1. Alat coding AI dan analogi 'jin'

Konsep inti: jin yang tak bisa diprediksi

• Mengibaratkan agen AI sebagai "jin yang tak bisa diprediksi"
• "Mereka tidak melakukan persis apa yang saya maksud"
• "Mereka punya agenda sendiri"

Pengalaman bekerja dengan AI

Sisi positif:

• Kadang menyelesaikan masalah desain besar seperti sihir yang menakjubkan
• Mengimplementasikan fitur berguna yang tak terduga (contoh: stress tester B+ tree)

Sisi negatif:

• Salah menafsirkan maksud pengguna
• Mencoba menghapus atau mengubah test
• Bertingkah usil dengan mencoba "menyelesaikan" masalah memakai lookup table

Pengalaman yang membuat ketagihan

• Imbalan intermiten seperti mesin slot
• "Saat lewat di depan komputer pada malam hari, saya berpikir, 'apa saya coba prompt sekali lagi?'"
• "Memulai prompt yang berlangsung satu jam lalu pergi keluar"

---

2. Perubahan keterampilan di era AI

Perombakan nilai keterampilan

"90% keterampilan kehilangan nilai, dan 10% keterampilan nilainya naik 1000 kali"

Keterampilan yang naik nilainya:

• Menetapkan visi
• Mengelola milestone
• Mengendalikan kompleksitas

Keterampilan yang turun nilainya:

• Detail spesifik tiap bahasa (posisi &, *, [] di Rust, dll.)

Perubahan sudut pandang terhadap bahasa pemrograman

Dulu: punya keterikatan emosional yang dalam dengan Smalltalk
Sekarang:

• "Sudah terlalu sering patah hati" sehingga keterikatan pada bahasa menghilang
• Lelah dengan pemisahan identitas seperti "developer Java" atau "developer Clojure"
• "Belajar lewat osmosis": berkat AI, tetap bisa memrogram tanpa mengetahui detail bahasa secara mendalam

Bahasa yang baru-baru ini dicoba: Swift, Go, Rust, Haskell, C++, JavaScript

Proyek ambisius saat ini: Server Smalltalk

• Persisten: bekerja seperti database
• Transaksional: bisa commit dan abort
• Paralelisme: pemrosesan paralel lintas multi-thread dan antar mesin
• Menangani data skala besar

---

3. Sejarah Agile Manifesto

Latar kemunculan (2001)

• Mencari alternatif untuk model waterfall
• Hasil dari workshop metodologi perangkat lunak selama bertahun-tahun
• Pertemuan persiapan untuk pelayaran di Norwegia → pertemuan final di Utah

Kontribusi Kent Beck

• Menambahkan kata "daily" ("berinteraksi setiap hari" dalam 12 prinsip)
• Penanda tangan pertama menurut urutan alfabet

Ketidakpuasan terhadap istilah "agile"

Masalahnya:

• Mengira istilah ini "terlalu menarik", sehingga akan disalahgunakan semua organisasi
• Dan memang muncul organisasi yang mengaku agile tanpa benar-benar mengikuti prinsipnya

Alternatif yang lebih disukai: "conversational"

• Menekankan komunikasi dua arah, bukan satu arah
• Tidak diadopsi karena kurang menarik

---

4. Extreme Programming (XP)

Latar pendirian

Pengalaman konsultasi awal:

• Awalnya konsultan teknis (tuning performa, manipulasi bit)
• Makin sering dimintai saran manajemen proyek
• Menemukan pentingnya lingkungan: hanya dengan mengubah tata letak tempat duduk saja bisa terjadi perbaikan dramatis

Proyek Chrysler:

• Mengubah proyek yang gagal menjadi sukses
• Mendorong semua praktik yang efektif ke "level tertinggi (hingga 11)"

Prinsip inti XP

Empat aktivitas dilakukan secara simultan/berurutan dalam irisan waktu kecil:

1. Menentukan apa yang akan dilakukan
2. Merancang struktur untuk melakukannya
3. Mengimplementasikan fungsi
4. Memastikan apakah hasilnya bekerja sesuai harapan

Pair programming

• Pendekatan eksperimental, bukan kewajiban
• Pengalaman tim awal: semua bug yang ditemukan setelah development berasal dari kode yang dikerjakan sendirian
• "Nol defect produksi saat pair programming"

Strategi penamaan

• Alasan memilih "Extreme": nama provokatif yang tidak akan dipakai pesaingnya (Grady Booch)
• Kebetulan sejalan dengan tren olahraga ekstrem saat itu
• "Atlet ekstrem siap sebaik mungkin atau mati" - metafora yang bagus

Faktor keberhasilan

• Pada masa bubble dot-com, ini menarik bagi developer yang frustrasi dengan pendekatan waterfall 18 bulan
• Menjanjikan hasil yang lebih cepat dan lebih bisa diprediksi

---

5. Test-Driven Development (TDD)

Asal-usul dan inspirasi (1970-an)

Sistem tape-to-tape:

• Konsep yang ditemui dari buku pemrograman milik ayahnya
• Input nyata → ketik manual output yang diharapkan → tulis kode → bandingkan dengan output aktual
• Dibaca saat usia 8-12 tahun, tetapi tidak dipahami

Pengembangan S-Unit:

• Dibuat untuk membantu klien menulis test
• Mencoba ide yang "konyol" yaitu "memasukkan nilai yang diharapkan sebelum menulis kode"

Pengalaman TDD pertama: implementasi stack

Kepribadian yang cemas:

• "Saya orang yang cemas. Saya banyak khawatir"
• "Pemrograman adalah sumber kecemasan yang terus-menerus" (apa yang saya lupa? apa yang saya rusak?)

Hasil penerapan TDD:

• "Rasa cemas itu hilang sepenuhnya"
• "Saya yakin ini bekerja"
• Mengubah pengalaman emosional dalam pemrograman

Nilai TDD

Keunggulan teknis:

• Menurunkan kepadatan defect
• Umpan balik cepat terhadap pilihan API
• Memungkinkan evolusi desain implementasi

Keunggulan emosional:

• "Layak hanya dari penghematan biaya obat anti-kecemasan teknis saja"

Sanggahan soal desain

Kritik John Osterhout: "TDD tidak membantu desain dan hanya fokus pada detail"

Jawaban Kent Beck:

• "Ini soal pilihan"
• Praktisi nyata terus berpindah di antara level abstraksi saat membuat keputusan desain
• Momen "pelepasan ketegangan" dalam siklus Red-Green memberi kebebasan lebih besar untuk berpikir desain pada level yang lebih tinggi

---

6. Agen AI dan TDD

Penerapan dalam praktik

Selalu menulis test lebih dulu:

• Menyampaikan hal-hal yang terlewat oleh AI melalui test
• Mencegah AI mencoba mengubah/menghapus test

Perbaikan yang dibutuhkan:

• Perlu "immutable annotation"
• "Ini benar. Jika kau mengubahnya, kau akan terjaga selamanya dalam kegelapan"

Keterbatasan AI

• Kurang mampu menurunkan coupling/meningkatkan cohesion
• Kurang punya sense desain
• Cenderung membuat keputusan yang menimbulkan efek riak jarak jauh

Strategi penanganan

• Test suite besar yang berjalan dalam 300 milidetik
• Mendeteksi secara real-time kerusakan kode tak disengaja dari AI

---

7. Pengalaman di Facebook (2011-2017)

Kejutan saat bergabung pada 2011

Peserta kelas TDD: nol:

• Keterampilan Excel tingkat lanjut: penuh + daftar tunggu
• Tango Argentina: penuh + daftar tunggu
• TDD: tidak ada peserta

Strategi respons:

• "Melupakan semua pengetahuan rekayasa perangkat lunak"
• Memutuskan untuk "melihat monyet lalu menirunya"

Lingkungan development Facebook yang unik

Rasa tanggung jawab yang kuat:

• Programmer mendapat giliran on-call malam hari
• "Merasakan sendiri rasa sakit akibat kesalahannya"

Loop umpan balik berlapis:

• Server development cepat (langsung bisa mengecek setelah perubahan blue→green)
• Code review
• Deploy internal (dipakai karyawan untuk penggunaan pribadi/kerja)
• Rollout bertahap (harian/mingguan)
• Observabilitas yang luar biasa

Budaya organisasi:

• "Di Facebook, tidak ada satu pun yang menjadi masalah orang lain"
• Bahkan jika ada nenek yang datang soal cucunya dirisak, "itu juga masalah Anda"

Mengapa TDD tidak cocok

Area masalah yang sebenarnya:

• Masalah konfigurasi
• Relasi antar subsistem
• Hal-hal yang sulit ditangkap dengan test

Keunggulan khas Facebook:

• Pengujian langsung skala besar dengan basis jutaan pengguna
• Observabilitas yang luar biasa
• Feature flag
• Lingkungan yang sulit diwujudkan di perusahaan biasa

Contoh konkret:

• Mengimplementasikan fitur status hubungan (menambah civil union/cohabitation ke single/married)
• Memakai TDD, tetapi "buang-buang waktu"
• Muncul masalah akibat coupling implisit di kode notifikasi → diperbaiki cepat oleh orang lain

Perubahan dari waktu ke waktu

2011 (2.000 orang):

• Kemungkinan, skala, dan rasa memiliki berada di puncaknya
• Para manajer menengah berpikir dalam kerangka optimisasi global
• Kolaborasi yang mempertimbangkan "siapa yang benar-benar membutuhkan bantuan"

2017 (15.000 orang):

• Politik, pola pikir zero-sum, dan mikro-optimalisasi
• Makin sulit melihat gambaran besar
• Konflik kepentingan antardivisi (misalnya tim tulisan panjang vs tim optimasi like/komentar)

Pengalaman soal skala

• Messenger API: 1 kuadriliun panggilan per minggu
• Kelompok eksperimen seukuran "Selandia Baru" (satu juta orang)
• 1 kuadriliun = satu juta × satu miliar

---

8. Masa depan pengembangan perangkat lunak di era AI

Pergeseran paradigma

Perombakan total struktur biaya:

• "Batas antara yang murah dan yang mahal berubah total"
• Hal-hal yang dulu dianggap mahal menjadi "sangat murah"

Tantangan adaptasi organisasi

Membuang lebih banyak kode:

• Bisa menghasilkan 10 kali lebih banyak artefak
• Tetap saja hanya satu yang bernilai
• Perlu sistem penghargaan untuk "membuang eksperimen yang sudah selesai"

Peningkatan kuantitas eksperimen:

• Jumlah ide yang dieksplorasi menjadi keunggulan kompetitif
• Ini adalah era ketika kita "harus mencoba semuanya sebagai eksperimen"

Perubahan pribadi

• Coding kembali menyenangkan
• Bisa punya ambisi yang lebih besar
• "Gagasan yang sangat ambisius" menjadi mungkin diwujudkan

---

9. Q&A singkat

Preferensi pribadi

• Bahasa favorit: Smalltalk
• Bahasa kedua: JavaScript (mirip dengan Smalltalk)
• Alat AI saat ini: Claude (engine internal Cursor, Augment)
• Buku rekomendasi: "The Timeless Way of Building" oleh Christopher Alexander

---

Wawasan utama

1. Pentingnya konteks secara mutlak

• Metodologi yang sama pun efektivitasnya bisa sangat berbeda tergantung lingkungannya
• Lingkungan skala besar Facebook vs lingkungan transaksi kecil di bank

2. Hubungan antara emosi dan teknologi

• Nilai sejati TDD adalah "menghilangkan kecemasan"
• Perubahan emosional lebih penting daripada logika teknis

3. Pola pikir baru di era AI

• Kemampuan visi dan desain muncul sebagai keterampilan inti
• Detail bahasa tidak lagi penting
• Peningkatan kuantitas eksperimen menjadi keunggulan kompetitif

4. Kekuatan budaya organisasi

• Rasa memiliki bahwa "tidak ada satu pun yang menjadi masalah orang lain"
• Perbedaan antara optimisasi global vs optimisasi pribadi
• Pentingnya penyelarasan insentif

[mse9000]

Lingkungan pengembangan Facebook yang unik
Rasa tanggung jawab yang kuat:
programmer menjadi pihak yang menerima panggilan darurat malam hari
"merasakan langsung penderitaan akibat kesalahannya sendiri"

Bukankah ini tidak jauh berbeda dari lingkungan pengembangan ala K-...?

[helloppfm]

Masih ada ya.

Dulu saya pernah mengadakan seminar tentang TDD di sebuah perusahaan manufaktur, dan saya masih tidak bisa melupakan tatapan semua orang yang seolah berkata, "Apa ini?"

Saya pikir TDD itu bagus, tetapi ternyata lebih sulit dijalankan daripada yang saya kira...
Saya jadi melakukan integration test seperti TDD. Tentu saja, ini bukan TDD. ^^

[kandk]

Masih ada pertarungan antara penganut buta TDD vs kubu yang menganggapnya tidak berguna,
rasanya akan bagus kalau dirilis versi 2 TDD yang disesuaikan lagi dengan situasi industri saat ini.
Belakangan ini hal-hal yang kecil mudah ditangani AI, jadi misalnya bagaimana memanfaatkannya ketika dibutuhkan context dalam jumlah besar..

[codemasterkimc]

Tulisan yang bagus.