Penulis Clean Code Berhenti Membaca Kode AI

Robert C. Martin, penulis buku Clean Code, mengaku tidak lagi membaca kode yang ditulis AI agennya. Sebagai gantinya, ia memakai pengujian dan ukuran kualitas: uji unit, uji penerimaan, mutation testing, cakupan pengujian, serta batas kompleksitas dan ketergantungan modul. Pendekatan ini memindahkan sebagian pemeriksaan kualitas ke proses otomatis.

Pernyataan tersebut menarik perhatian karena Martin dikenal menekankan keterbacaan kode. Ia tetap memasang batas kualitas, tetapi menggunakan pemeriksaan otomatis untuk menegakkan sebagian aturan itu.

Apa yang sebenarnya dikatakan Uncle Bob?

Perdebatannya mulai April 2026. Martin menulis bahwa ia tidak meninjau kode agen. Yang ia ukur: "test coverage, dependency structure, cyclomatic complexity, module sizes, mutation testing".

Tanggal 23 Juli 2026 ia mengulanginya lewat unggahan di X yang dapat sekitar 15.000 tanda suka. Dalam unggahan tersebut, ia menjelaskan telah menulis kode sejak akhir 1960-an. Strateginya kini adalah tidak membaca kode agen agar manfaat produktivitasnya dapat digunakan sepenuhnya. Ini ringkasan pernyataannya, bukan kutipan langsung.

Alasannya, seperti dikutip Startup Fortune: manusia lambat kalau berurusan dengan kode. Supaya produktif, manusia harus mundur selangkah dan mengelola dari level yang lebih tinggi. Ia juga mengaku, dua tahun lalu ia tidak percaya AI bisa secakap sekarang.

Yang sering hilang dari judul berita: apa yang ia kerjakan sebagai gantinya.

Pemeriksaan apa yang menggantikan pembacaan kode?

Martin menjelaskan beberapa lapisan pemeriksaan yang dapat diterapkan pada kode agen:

• Uji unit, yaitu pengujian bagian kecil kode, yang ditulis oleh agen.
• Uji penerimaan dengan Gherkin, yaitu skenario dalam bahasa biasa, misalnya "Tamu punya booking. Ketika ia check-out, status kamar jadi kotor." Bagian inilah yang masih dibaca Martin.
• Mutation testing: alat sengaja mengubah kode, misalnya mengganti > jadi >= atau menghapus satu baris, lalu mengecek apakah ada test yang gagal. Jika pengujian tetap lulus, perubahan tersebut tidak terdeteksi; daya tangkap pengujiannya perlu diperiksa.
• Cakupan pengujian (coverage) dan skor CRAP: CRAP (Change Risk Anti-Patterns) menggabungkan kompleksitas fungsi dengan bagian yang telah diuji. Fungsi yang rumit dan sedikit diuji memerlukan perhatian lebih.
• Batas kompleksitas dan ukuran modul: jumlah cabang (if, loop) per fungsi dan panjang file dibatasi keras.
• Analisis ketergantungan modul: modul mana boleh memanggil modul mana, supaya agen tidak diam-diam menyambung lapisan basis data langsung ke UI.
• Prosedur penjaminan kualitas (QA) dan pengujian manual berkala oleh Martin sendiri.

Martin juga jujur bahwa semua lapisan itu tidak selalu sepadan. Menurut rangkuman ExplainX, untuk banyak pekerjaannya ia cukup pakai unit test plus metrik CRAP.

Keterbacaan kode tetap memengaruhi pekerjaan agen

Nama yang jelas, fungsi kecil, dan batas modul masih membantu manusia maupun agen memahami kode.

Martin sendiri menjelaskan mengapa ia membatasi ukuran dan kompleksitas: kode berantakan membuat agennya lambat. Ia pernah melihat agen berputar-putar di kekacauan buatannya sendiri tanpa pernah beres. Agen yang bekerja di file 2.000 baris dengan ketergantungan modul yang rumit akan menghabiskan konteks, melewatkan efek samping, dan menambal bug yang sama di tiga tempat.

Fungsi kecil, nama yang jelas, dan batas modul yang ditegakkan dapat membantu agen memahami serta menyelesaikan tugas. Ketiganya tidak menjamin tugas selesai dalam satu percobaan.

Aturan tahun 2008 tetap berlaku. Yang berganti adalah penjaganya. Dulu peninjau menangkap fungsi 200 baris dengan mata. Sekarang linter menolaknya sebelum ada yang sempat melihat. Standarnya sama, ongkosnya lebih murah, dan penjaganya tidak pernah capek.

Batas pemeriksaan otomatis

Grady Booch, salah satu pencipta UML, menjawab Martin langsung. Booch membaca semua kode buatan agennya. Menurutnya, angka coverage dan kompleksitas hanya membuktikan kode melakukan apa yang diminta test. Angka itu "no confidence whatsoever" soal celah keamanan, kode mati, atau struktur yang nanti menyusahkan performa.

Riset mendukung kekhawatirannya. Studi Juli 2026 terhadap 4.022 usulan perubahan kode (pull request) dari agen pemrograman otonom, Trust but Verify? Uncovering the Security Debt of Autonomous Coding Agents (diterima di workshop KDD 2026), menemukan pola rawan keamanan di hampir dua dari lima PR agen. Kredensial yang ditulis langsung dalam kode menyumbang 99,6% temuan tingkat kritis. Lebih dari empat dari lima kebocoran kredensial lolos dari mekanisme peninjauan yang ada.

Daftar pemeriksaan yang dibahas tidak menyebut pemindaian kunci API yang bocor. Mutation testing menguji kemampuan pengujian menangkap perubahan kode, bukan mencari kata sandi dalam berkas konfigurasi. Karena itu, pemeriksaan rahasia dan keamanan perlu menjadi langkah tersendiri.

Batas kedua lebih ke soal orang. Martin sudah menulis perangkat lunak hampir enam dekade. Ia tahu batasan mana yang penting karena pernah melihat akibatnya kalau batasan itu tidak ada. Tim yang meniru "jangan baca kodenya" tanpa bekal itu dapat kecepatannya, tetapi tidak dapat pengamannya.

Pemeriksaan yang perlu diminta saat memesan perangkat lunak

Jika vendor menggunakan agen AI, tanyakan pemeriksaan yang diterapkan serta bagian yang tetap ditinjau manusia. Daftar berikut membantu memperjelas bukti yang perlu ditunjukkan:

1. Dapatkah vendor menunjukkan skenario penerimaan? Spesifikasi bahasa biasa yang bisa Anda baca dan setujui. Itu kontrak Anda dengan kodenya. Kalau tidak ada yang bisa menunjukkan perilaku apa yang dispesifikasikan, berarti tidak ada yang mengeceknya.
2. Ada mutation testing, atau minimal batas cakupan pengujian yang mencegah penggabungan kode? Coverage mudah diakali dengan test yang tidak mengecek apa-apa. Mutation testing membantu menguji daya tangkap test, tetapi hasilnya tetap bergantung pada jenis mutasi, pengecualian, dan kualitas skenario. Skor tinggi bukan bukti bebas bug atau celah keamanan.
3. Batas kompleksitas dan ukuran file dijalankan dalam integrasi berkelanjutan (CI), bukan hanya ditulis di panduan gaya kode?
4. Apakah setiap usulan perubahan kode (PR) melalui pemindaian rahasia dan pemeriksaan komponen? Pemeriksaan ini menangani kebocoran kredensial dan masalah dependensi yang diketahui, tetapi belum menjawab semua persoalan keamanan atau rancangan yang dikemukakan Booch. Kaitannya dengan mengapa pilot AI coding mandek.
5. Siapa yang membaca perubahan di bagian sensitif? Login, pembayaran, cek hak akses. Pembagian yang masuk akal: kode rutin dijaga metrik, jalur yang satu kesalahannya mahal tetap dibaca manusia, seperti API pembayaran yang idempoten.
6. Apakah pengujian ikut diberikan saat serah terima? Kode yang tidak pernah dibaca orang hanya bisa dirawat kalau gerbangnya ikut pindah tangan. Masukkan rangkaian pengujian dan konfigurasi CI ke checklist serah terima.

Logika yang sama berlaku untuk produk yang memanggil LLM saat berjalan. Anda juga tidak bisa membaca setiap keluarannya, jadi butuh eval, bukan assertion.

Tentukan siapa yang menjaga bagian sensitif

Pendekatan Martin menunjukkan cara mengotomatisasi sebagian pemeriksaan kualitas. Tim kecil dapat menjalankan aturan tersebut pada setiap perubahan kode, sambil tetap meninjau keamanan dan alur yang berdampak besar.

Tetapkan orang yang merancang pemeriksaan, memelihara pengujian, dan membaca perubahan sensitif. Hasil otomatis perlu dinilai bersama konteks yang tidak tercakup oleh metrik.