Setiap Tahap Review Membuat Kecepatan 10 Kali Lebih Lambat

• Menjelaskan struktur di mana kecepatan penyelesaian kerja melambat secara eksponensial seiring bertambahnya tahap persetujuan dan review di dalam organisasi, serta memberi contoh bahwa tiap tahap persetujuan dalam praktiknya menyebabkan keterlambatan sekitar 10 kali lipat
• Meski alat coding AI secara dramatis meningkatkan kecepatan penulisan kode, latency pada pipeline review setelahnya tidak ikut berkurang, sehingga dampak perbaikan terhadap kecepatan total menjadi kecil
• Dengan menerapkan filosofi kualitas manufaktur dari W. E. Deming ke perangkat lunak, artikel ini menunjukkan bahwa menambahkan tahap QA justru memperburuk kualitas dan kecepatan sekaligus
• Review perlu dikurangi sambil digantikan dengan modularitas dan budaya kualitas berbasis kepercayaan, dan inti utamanya adalah perbaikan struktural yang membuat review itu sendiri menjadi tidak perlu
• Tim kecil lebih diuntungkan di era AI, dan organisasi serta sistem perlu didesain ulang dengan pendekatan menggabungkan komponen kecil yang indah

---

Hukum bahwa tahap review menciptakan keterlambatan 10 kali lipat

• Seperti hukum efek jaringan, ketika ukuran tim membesar akan muncul overhead koordinasi, sehingga menambah jumlah tim menjadi dua kali lipat tidak berarti kecepatannya juga menjadi dua kali lipat
• Ada aturan praktis yang ditemui beberapa dekade lalu: setiap tambahan satu tahap review membuat proses menjadi 10 kali lebih lambat
• Tidak ada dasar teoretisnya, tetapi fenomena ini berulang kali terlihat dalam kenyataan
• Waktu yang diukur di sini bukan effort, melainkan wall clock time, dan sebagian besar waktu tambahan itu adalah waktu tunggu
• Contoh konkret:
  • Coding perbaikan bug sederhana: 30 menit
  • Code review oleh rekan di meja sebelah: 300 menit (sekitar 5 jam, setengah hari)
  • Persetujuan dokumen desain oleh tim arsitek: 50 jam (sekitar 1 minggu)
  • Masuk ke jadwal tim lain (misalnya permintaan fitur pelanggan): 500 jam (12 minggu, 1 kuartal fiskal)
• Tahap berikutnya, yaitu 10 kuartal (sekitar 2,5 tahun), juga tidaklah tidak realistis; bahkan di perusahaan yang relatif kecil seperti Tailscale, perubahan arah produk bisa menimbulkan keterlambatan pada tingkat ini

AI tidak bisa menyelesaikan masalah ini

• Walaupun Claude bisa menyelesaikan coding 30 menit dalam 3 menit, 27 menit yang dihemat hanya akan dipakai untuk berulang kali mereview bersama AI atau untuk menyerahkan kode yang belum tervalidasi kepada reviewer
• Reviewer tetap membutuhkan 5 jam, dan jika Anda menyerahkan kode yang bahkan belum Anda baca sendiri, reviewer akan kesal
• Nilai sejati agentic coding sering dikatakan sebagai kemampuan menyelesaikan proyek besar yang biasanya 1 minggu hanya dalam beberapa jam, tetapi hasilnya terlalu besar untuk direview reviewer sekaligus
  • Harus dipecah menjadi unit-unit kecil, dan masing-masing memunculkan siklus review 5 jam
  • Karena tidak ada dokumen desain, juga tidak ada arsitektur yang disengaja, akhirnya bermuara pada rapat review desain
  • Akibatnya, proyek yang selesai dalam 2 jam kembali menjadi 1 minggu

Satu-satunya cara adalah mengurangi review

• Premis teori Singularity: sistem membuat sistem yang makin cerdas, dan bila waktu yang dibutuhkan per unit perbaikan mendekati nol, pertumbuhan eksplosif akan terjadi
• Alasan untuk tidak mempercayai teori ini: sebagian besar waktu untuk menyelesaikan sesuatu bukanlah waktu kerja nyata, melainkan wall clock time, yaitu waktu tunggu dan keterlambatan
• Latency tidak bisa diatasi dengan brute force

Bukankah review tidak mungkin dihilangkan?

• Banyak orang menyadari gejalanya: tahap pertama pipeline (kode hasil AI) sudah menjadi cepat, tetapi tahap review setelahnya adalah bottleneck
• Solusi intuitifnya: hentikan review → meski hasilnya kasar, jika 100 kali lebih murah maka cukup memberi 1% nilai saja untuk impas
• Di balik logika ini ada asumsi yang cukup bodoh
• AI Developer's Descent Into Madness:
  1. Membuat prototipe dengan kecepatan mengejutkan → terasa seperti punya kekuatan super
  2. Muncul bug pada prototipe → minta AI memperbaikinya
  3. Setiap kali memperbaiki sesuatu, muncul bug baru sebanyak yang diperbaiki
  4. Salah kaprah mengira jika agen AI melakukan code review atas kodenya sendiri, ia akan menemukan bug-nya sendiri
  5. Menyadari diri sendiri mulai mengoper data langsung antaragen
  6. Menyadari perlunya framework agen
  7. Menulis framework agen dengan agen
  8. Kembali ke langkah 1
• Karena Claude Code baru menjadi cukup layak dipakai beberapa bulan lalu, siklus ini pun baru mulai belakangan ini, dan banyak rekan serta orang yang dihormati sedang terjebak dalam siklus ini

Mengapa kita melakukan review

• Saat perusahaan tumbuh, tahap kolaborasi, review, dan manajemen bertambah → tujuannya mencegah kesalahan, karena makin besar skala, biaya kesalahan makin tinggi
• Akan datang titik ketika rata-rata nilai tambah fitur baru lebih rendah daripada rata-rata kerugian dari bug baru yang ditimbulkannya
• Karena tidak ada cara untuk menaikkan nilai fitur, organisasi bergerak ke arah mengurangi kerugian
• Jika pemeriksaan dan kontrol ditambah, kecepatan melambat tetapi kualitas tampak meningkat secara monoton → terlihat seperti landasan perbaikan berkelanjutan
• Namun, "lebih banyak pemeriksaan dan kontrol" bukanlah satu-satunya cara untuk meningkatkan kualitas, dan justru merupakan cara yang berbahaya

"Quality Assurance (QA)" justru menurunkan kualitas

• Mengacu pada filosofi kualitas yang dipopulerkan W. E. Deming dalam industri manufaktur mobil Jepang
• Masalah tahap QA di pabrik: membuat widget → inspeksi/QA → buang yang gagal → lalu demi mencegah kelolosan, ditambahkan QA tahap kedua
• Dalam model matematika sederhana hal ini tampak masuk akal (jika tiap tahap QA menangkap 90% cacat, maka dengan 2 tahap hasilnya berkurang 100 kali lipat)
• Tetapi dalam lingkungan manusia agentic yang otonom, insentif menjadi terdistorsi:
  • Tim QA kedua berperan menilai tim QA pertama → mereka tidak punya insentif untuk rajin mencari hasil yang bisa membuat rekan mereka dipecat
  • Tim QA pertama berharap tim kedua akan menangkap sisanya sehingga mengurangi upaya mereka sendiri
  • Tim pembuat widget juga jadi lalai melakukan pemeriksaan mandiri karena ada tim QA → dibanding sistem melambat 20%, tingkat scrap 10% terasa lebih baik
  • Redesain engineering menyeluruh demi menaikkan kualitas dianggap terlalu mahal sehingga dihindari
• Toyota Production System menghapus tahap QA sepenuhnya dan memberi semua orang tombol "stop the line"
• Pabrikan mobil Amerika memasang tombol yang sama, tetapi tak ada yang menekannya → takut dipecat

Kepercayaan

• Perbedaan antara keberhasilan sistem Jepang dan kegagalan sistem Amerika adalah kepercayaan
• Kepercayaan antarindividu: keyakinan bahwa atasan benar-benar ingin mengetahui semua cacat dan bahwa lini harus dihentikan saat cacat ditemukan
• Kepercayaan antarmanager: keyakinan bahwa manajemen sungguh serius soal kualitas
• Kepercayaan di tingkat eksekutif: keyakinan bahwa dengan sistem dan insentif yang tepat, individu akan menghasilkan pekerjaan berkualitas tinggi dan menemukan cacatnya sendiri
• Syarat tambahannya: ada kepercayaan bahwa sistem itu benar-benar bekerja → maka terlebih dahulu harus ada sistem yang memang bekerja

Fallibility

• AI coder sering menulis kode buruk, dan dalam hal ini sama saja dengan programmer manusia
• Dalam pendekatan Deming tidak ada solusi ajaib → engineer harus merancang kualitas ke dalam seluruh sistem dari bawah ke atas
• Setiap kali terjadi masalah, pertanyaannya adalah "bagaimana ini bisa terjadi?" dan akar penyebab harus ditemukan lalu diperbaiki dengan postmortem dan Five Whys
• "Coder melakukan kesalahan" bukan akar penyebab melainkan gejala → yang harus dicari adalah penyebab struktural yang memungkinkan coder melakukan kesalahan itu
• Peran sejati code reviewer bukanlah melakukan code review, melainkan membuat komentar review mereka sendiri menjadi tidak perlu
  • Memperbaiki sistem agar jenis komentar itu tidak muncul lagi di masa depan
  • Targetnya haruslah keadaan di mana review tidak lagi diperlukan
• Contoh: orang-orang yang membuat go fmt → menghapus komentar review soal spasi secara permanen → inilah engineering yang sesungguhnya
• Saat review menemukan kesalahan, kesalahan itu sebenarnya sudah terlanjur terjadi → akar penyebabnya sudah lewat

Modularitas

• Pipeline review (tahap QA) tidak bekerja, memperlambat kecepatan, dan menyembunyikan akar penyebab → sehingga penyelesaiannya menjadi lebih sulit
• Daya tarik coding AI: tahap pertama pipeline menjadi sangat cepat → terasa seperti kekuatan super
• Bisa jadi kini ada motivasi yang cukup untuk menyelesaikan masalah-masalah yang tersembunyi selama 20 tahun budaya code review, lalu menggantinya dengan budaya kualitas yang sesungguhnya
• Kaum optimis benar setengahnya: tahap review memang perlu diperkecil, tetapi jika diperkecil tanpa pengganti, hasilnya akan berakhir seperti Ford Pinto atau pesawat Boeing belakangan ini
• Seperti yang dibawa Deming ke manufaktur, dibutuhkan pergantian paket secara total (table flip) → sistem "total quality" tidak bisa diadopsi setengah-setengah
• Saat menghapus review, kita juga harus sekaligus membuatnya tidak perlu
• Sistem baru bisa diadopsi sepenuhnya dalam unit kecil:
  • Diibaratkan seperti pabrikan mobil Amerika lama yang membeli komponen berkualitas tinggi dari pemasok Jepang
  • Jika komponennya dibuat dengan baik, tahap QA di tempat lain bisa dihapus → kompleksitas pekerjaan "merakit komponen" turun drastis
• Hal-hal kecil yang indah bisa digabungkan menjadi sesuatu yang besar dan indah
• Tim kecil yang saling percaya membuat komponen masing-masing sambil memahami apa arti kualitas bagi mereka
• Tim pelanggan menjelaskan dengan jelas apa arti kualitas bagi mereka → kualitas lalu menyebar dari bawah ke atas

Tim kecil dan desain organisasi di era AI

• Startup kecil mungkin lebih diuntungkan di dunia baru ini → karena orangnya sedikit, tahap review dari awal memang lebih sedikit
• Sebagian startup akan menemukan cara memproduksi komponen berkualitas tinggi dengan cepat, yang lain gagal → kualitas melalui seleksi alam
• Perusahaan besar sudah terlanjur terkunci dalam sistem review yang lambat, sehingga jika dihapus bisa menimbulkan kekacauan total
• Terlepas dari ukuran perusahaan, tim engineering bisa dibuat lebih kecil dan antarmuka antar tim bisa didefinisikan lebih jelas
• Mungkin saja ada model di mana beberapa tim dalam satu perusahaan mengembangkan komponen yang sama secara kompetitif
  • Tiap tim terdiri dari sedikit orang dan bot coding
  • Mencoba 100 cara lalu memilih yang terbaik → kualitas melalui evolusi
  • Kode itu murah, tetapi ide yang bagus tetap mahal → ide baru bisa diuji lebih cepat daripada sebelumnya
• Dalam kontinuum monolit-microservice, mungkin akan muncul titik optimum baru
  • Microservice mendapat reputasi buruk karena terlalu kecil, tetapi dalam istilah aslinya layanan "micro" berukuran pas untuk dibangun dan dijalankan oleh "tim dua pizza"
  • Di era AI, ukurannya mungkin menjadi "satu pizza dan sedikit token"
• Dengan coding baru yang cepat, batas modul itu sendiri bisa dieksperimenkan lebih cepat
  • Feature tetap sulit, tetapi refactoring dan automated integration test adalah area yang dikuasai AI
  • Modul yang dulu terlalu menakutkan untuk dipisahkan kini bisa dicoba dipisahkan → jumlah baris kode memang bertambah, tetapi itu murah dibanding overhead koordinasi ketika tim besar harus memelihara kedua sisi
• Setiap tim punya monolit yang terlalu besar dan terlalu banyak tahap review
• Walau mungkin tidak sampai Singularity, kita tetap bisa merekayasa dunia yang jauh lebih baik → masalah ini bisa diselesaikan
• Kuncinya adalah kepercayaan

[bbulbum]

Saat pertama kali melihat go fmt: kenapa formatnya tidak bisa sesuai seleraku..!

Sekarang: buat apa format butuh selera?

[GN⁺]

Komentar Hacker News

• Mungkin saja tidak perlu review sama sekali
  Jika review digeser ke kiri dan diubah menjadi sesi desain kode, masalah diangkat saat daily, dan bagian sulit diselesaikan dengan pair programming, maka sebagian besar tujuan review hilang
  Sisa 10% seperti nama variabel, spasi, dan pola bisa diotomatisasi dengan linter
  Pada akhirnya yang penting adalah membangun budaya tim berbasis kepercayaan agar orang bisa menulis dan memercayai kode yang telah disepakati tim

  • Seperti pepatah “beberapa jam untuk perencanaan bisa menghemat beberapa menit saat coding”, tidak semua arsitektur bisa dirancang di papan tulis
    Justru saat implementasi nyata biasanya masalah baru terlihat
    Hampir tidak pernah semuanya berjalan persis sesuai rencana. Pada akhirnya dibutuhkan rapat arsitektur yang berulang, tetapi itu juga bisa berubah menjadi rawa rapat mingguan
  • Saya melihat para engineer yang saya hormati meninggalkan pendekatan ini sambil memakai coding agent untuk membuat PR secara otomatis
    Saat orang bahkan tidak lagi me-review kode yang ia tulis sendiri, kepercayaan yang dibangun bisa runtuh seketika
  • Inti tulisan ini pada akhirnya adalah sistem kepercayaan
    Seperti Toyota Production System, untuk menghilangkan tahap QA dibutuhkan kepercayaan agar setiap anggota bisa langsung menghentikan proses saat menemukan cacat
    Pipeline review hanya menyembunyikan masalah dan memperlambat laju
  • “Geser review ke kiri, sebut itu sesi desain, angkat masalah di daily, selesaikan dengan pair programming”
    Kalimat ini sendiri terasa seperti definisi neraka
  • Saya bilang ke orang baru, “Kami memercayai Anda. Tapi kami tahu nomor telepon Anda”
    Ternyata ini cukup berhasil. Orang-orang menulis tes sendiri dan juga melakukan verifikasi manual
    Kami juga membangun jaring pengaman untuk rollback dalam 10 menit jika ada deploy yang salah

• Code review adalah dilema relawan
  Karena “mereview banyak PR” tidak dihargai sebesar “merilis banyak fitur”
  Akhirnya orang hanya aktif mereview bila itu berdampak langsung pada pekerjaannya sendiri
  Namun karena kode bersifat lentur, merge cepat lalu diperbaiki belakangan justru bisa menghasilkan konvergensi yang lebih cepat

  • Ada juga reviewer yang, seperti team lead, merasa bertanggung jawab atas hasil tim
    Terutama karena mereka ingin menemukan bug lebih awal untuk mengurangi stres on-call
  • Untuk junior, saya sarankan review semua PR
    Walau tidak paham semuanya, meninggalkan pertanyaan tetap sangat membantu proses belajar
    Jika ingin menjadi pemimpin, Anda perlu banyak mereview kode dan dokumen desain
  • Menariknya, dua hal yang dianggap paling penting oleh banyak developer — code review dan menghapus kode — justru tidak mendapat imbalan

• Tulisan ini berhasil merapikan intuisi dan pengalaman saya dengan sangat jelas
  Saya memang sudah suka produk Tailscale, tapi sekarang rasanya saya juga akan jadi penggemar CEO-nya
  Terima kasih kepada Avery yang menulis ini; saya akan membagikannya seluas mungkin

• Valve adalah salah satu dari sedikit perusahaan yang memahami batas bandwidth komunikasi
  Semakin besar organisasi, beban komunikasi meningkat secara eksponensial

  • Saya rasa orang pertama yang benar-benar menyadari ini adalah Jeff Bezos
    Mestinya perusahaan lain sekarang juga sudah paham, tapi ternyata belum

• Mengejutkan bahwa review bisa selesai dalam 5 jam
  Di kebanyakan tempat, prosesnya berjalan dalam hitungan hari
  Tetapi jika ada budaya di mana semua developer bisa langsung menghentikan proses saat menemukan bug, mungkin review memang tidak diperlukan
  Kenyataannya, struktur insentif sering membuat orang dirugikan secara pribadi jika target rilis tidak tercapai

  • Di perusahaan lama, review butuh beberapa hari tetapi kualitas kodenya lumayan baik
    Di perusahaan sekarang, review selesai dalam hitungan menit tetapi utang teknis meledak
  • Di tim FAANG, SLA review adalah 4 jam
    Setelah melewati batas waktu tertentu, otomatis muncul pesan “menunggu review”
    Semuanya diukur, dan tekanan kinerja sangat tinggi
  • Pada titik tertentu saya sadar review adalah bottleneck, lalu mulai menangani code review tim seketika itu juga
    Selama ukuran tim masih masuk akal, kebiasaan ini bisa dipelajari dan ditularkan
  • Saya baru sadar di bagian bawah halaman bahwa penulisnya adalah CEO Tailscale
  • Sampai sekarang saya belum pernah melihat proyek yang benar-benar memperlakukan review dengan serius
    Baik pihak bisnis maupun developer tidak terlalu peduli

• Rasio nilai terhadap usaha dalam review sering diabaikan
  Jika review tidak benar-benar meningkatkan kualitas, maka waktu itu terbuang sia-sia
  Daripada berdebat soal detail kecil, lebih efisien memastikan “apakah ini bekerja” lalu cepat merge
  Perbaikan bisa dilakukan lewat commit berikutnya
  Review seharusnya menjadi checkpoint singkat untuk memastikan arah

• Saya sepenuhnya setuju dengan kalimat, “tugas reviewer adalah menghilangkan kebutuhan akan review”

• Tulisan ini mengasumsikan proses yang terserialisasi, padahal kenyataannya berjalan paralel
  Jika beberapa bug ditangani bersamaan, keterlambatan review bukan masalah besar
  Intinya adalah mengatur jumlah pekerjaan simultan (N)

  • Untuk itu saya pernah membuat kalkulator teori antrean
    tautan
    Semakin lambat kecepatan review PR, semakin besar biaya context switching
    Hasil perhitungannya menunjukkan bahwa mempercepat review bisa sangat meningkatkan produktivitas

• Saya setuju dengan gagasan bahwa “tujuan reviewer adalah membuat review menjadi tidak perlu”,
  tetapi ceritanya berubah saat cakupan kepercayaan meluas ke luar perusahaan
  Misalnya, jika npm update menyebarkan kode berbahaya, respons setelah kejadian sudah terlambat
  Bahkan dalam sistem berbasis kepercayaan, tetap ada titik tertentu yang memerlukan verifikasi manusia

• Para manajer menekankan produktivitas, tetapi pada saat yang sama tetap mempertahankan proses yang memperlambat laju
  Ini masalah yang kompleks, jadi sulit dibilang sekadar baik atau buruk

  • Ini mengingatkan saya pada Rule 9 dari “How complex systems fail”
    Operator harus bertanggung jawab sekaligus atas produktivitas dan keselamatan
    Sebelum insiden, yang ditekankan adalah produktivitas; setelah insiden, yang ditekankan adalah keselamatan
    Orang luar sering tidak memahami keseimbangan peran ganda ini dengan baik
    tautan terkait