Dua Belas Cara Keliru Menilai Coding Berbantuan AI

• Nilai coding berbantuan AI sulit direduksi ke angka-angka mudah seperti jumlah baris kode, jumlah tiket, atau kepuasan, dan kesimpulan bisa terdistorsi tergantung cara evaluasinya
• Jumlah baris kode serta jumlah commit, Pull Request, dan tiket hanyalah ukuran aktivitas; begitu dijadikan target, metrik ini mudah dimanipulasi dan tidak mampu membedakan kualitas
• Tingkat penerimaan dan tingkat adopsi hanyalah sinyal bahwa usulan tampak masuk akal atau alat telah diterapkan, bukan jaminan akurasi, keamanan, atau kemudahan pemeliharaan
• Tugas mainan, perbandingan sebelum-sesudah tanpa kelompok kontrol, perbandingan pengguna sukarela, dan baseline yang lemah membuat efek LLM sulit dipisahkan dari bias seleksi
• Untuk menilai produktivitas, dibutuhkan metrik tingkat sistem yang mencakup review, debugging, keamanan, utang teknis, bottleneck tim, dan perubahan jangka panjang

---

Objek evaluasi dan asumsi

• Saat mencoba membuktikan nilai alat coding berbantuan AI dibanding biaya langganannya, jumlah baris kode yang dihasilkan, jumlah tiket yang selesai, dan survei kepuasan pengembang masing-masing dapat menghasilkan kesimpulan yang keliru dengan cara yang berbeda
• Pokok persoalannya bukan nilai coding berbantuan LLM itu sendiri, melainkan seberapa mudah cara menilai dampaknya bisa meleset
• Kritik yang sama juga dapat diterapkan, dengan sedikit penyesuaian, pada klaim tentang pengembangan agile, test-driven development, dan praktik pengembangan perangkat lunak lainnya
• Ini mengarah pada kesimpulan bahwa jika rekayasa perangkat lunak benar-benar mengadopsi metode riset dari ilmu manusia, bidang ini akan jauh lebih maju dalam meneliti fenomena semacam ini

Metrik produktivitas yang keliru

• Menghitung jumlah baris kode yang dihasilkan

  • Jumlah baris kode telah lama digunakan sebagai metrik pengganti untuk produktivitas yang sulit diukur secara langsung
  • LLM dapat menghasilkan lebih banyak kode, tetapi itu tidak menjamin hasil yang lebih baik
  • Tim yang setelah mengadopsi LLM melihat jumlah baris kode per pengembang naik 40% mungkin sebenarnya mengukur kebertele-telean, bukan produktivitas
  • Perbaikan yang mengganti 2000 baris logika kusut menjadi 200 baris yang rapi akan tampak seperti kerugian dalam metrik jumlah baris kode
  • Lebih banyak kode berarti lebih banyak yang harus dibaca, dipelihara, dan di-debug, dan beban masa depan yang ditinggalkan AI tidak terlihat dalam hitungan jumlah baris

• Menghitung commit, Pull Request, dan tiket

  • Pada 2023, McKinsey mengusulkan cara mengukur produktivitas pengembang individu melalui jumlah aktivitas seperti commit, Pull Request, dan code review
  • Seperti hukum Goodhart, ketika suatu ukuran menjadi target, ia tidak lagi berfungsi sebagai ukuran yang baik
  • Jika jumlah commit dilacak, pengembang akan membuat commit yang lebih kecil dan lebih banyak; jika jumlah tiket dilacak, tiket akan dipecah-pecah
  • Angkanya bisa tampak membaik, sementara pekerjaan dasarnya belum tentu membaik
  • Aktivitas bukanlah output, dan output pun tidak otomatis menjadi nilai

• Menganggap tingkat penerimaan usulan sebagai sinyal kualitas

  • Tingkat penerimaan usulan yang tinggi pada coding assistant berbasis LLM sering diajukan sebagai bukti bahwa alat itu berguna
  • Tingkat penerimaan hanya mengukur apakah kode yang dihasilkan tampak cukup masuk akal sehingga pengembang menekan Tab, bukan mengukur akurasi, keamanan, atau kemudahan pemeliharaan
  • Pengembang yang berada di bawah tekanan waktu akan menerima lebih banyak usulan, termasuk usulan yang tidak aman
  • Studi perusahaan terhadap 400 pengembang menemukan tingkat penerimaan rata-rata 33% dan kepuasan pengembang yang tinggi, tetapi tidak melacak akurasi atau keamanan dari kode yang diterima
  • Metrik yang memberi penghargaan pada sesuatu yang tampak masuk akal bukanlah metrik yang memberi penghargaan pada sesuatu yang benar-benar baik

• Menganggap tingkat adopsi sebagai metrik keberhasilan

  • Pernyataan seperti “mencapai tingkat adopsi 90% untuk alat AI di seluruh organisasi engineering” adalah keberhasilan pembelian dan deployment, bukan keberhasilan produktivitas
  • Tingkat adopsi hanya mengukur apakah alat dipasang dan dibuka, bukan apakah usulannya berguna, apakah pengembang menerimanya tanpa berpikir kritis, atau apakah usulan yang diterima itu benar
  • Jika tingkat adopsi tinggi dipadukan dengan kualitas usulan yang rendah, pengembang bisa menghabiskan waktu untuk mengelola alat alih-alih memperoleh manfaat
  • Dalam studi IBM tentang AI coding assistant untuk perusahaan, alat tersebut sering menghasilkan kenaikan produktivitas bersih, tetapi manfaatnya tidak merata bagi seluruh pengguna
  • Tingkat adopsi lebih mudah diukur daripada manfaat, dan justru karena itu lebih mudah dilaporkan

Kesalahan desain eksperimen

• Mengukur waktu pada tugas buatan

  • Studi GitHub Copilot yang banyak dikutip menemukan bahwa pengguna menyelesaikan tugas 55% lebih cepat dibanding non-pengguna
  • Tugasnya adalah mengimplementasikan server HTTP dari nol dengan JavaScript, batas waktunya 90 menit, dan pengembang tidak memiliki kewajiban lain hari itu
  • Pengembangan perangkat lunak di dunia nyata mencakup menavigasi codebase besar yang tidak ditulis sendiri, memahami kebutuhan tiket yang ambigu, berkoordinasi dengan rekan kerja, dan menghadiri rapat
  • Kecepatan pada tugas mainan greenfield tidak dapat memprediksi kecepatan pada pekerjaan nyata semacam itu
  • Dalam uji acak terkontrol terhadap pengembang open source berpengalaman, bertentangan dengan perkiraan para peserta, pemberian akses ke alat AI justru meningkatkan waktu penyelesaian tugas sebesar 19%

• Perbandingan sebelum-sesudah tanpa kelompok kontrol

  • Jika mulai memakai LLM pada Januari dan pada Juni Pull Request dirilis lebih cepat, alat itu bisa tampak seolah efektif
  • Namun jika dalam periode yang sama perusahaan merekrut 12 engineer, merefaktor pipeline CI, dan mengganti cloud provider, penyebabnya tidak bisa dipisahkan
  • Tanpa kelompok yang tidak mengadopsi alat tersebut, sulit membedakan efek LLM dari efek perubahan lain yang terjadi bersamaan
  • Validitas internal membutuhkan counterfactual yang andal tentang apa yang akan terjadi jika alat itu tidak ada

• Membandingkan yang memilih ikut dan yang tidak

  • Jika membandingkan pengembang yang memilih menggunakan LLM dengan yang memilih tidak menggunakannya, yang dibandingkan bukan dua kondisi, melainkan dua kelompok orang yang berbeda
  • Early adopter lebih mungkin memiliki kemauan bereksperimen yang lebih kuat, lebih akrab dengan alat baru, dan sudah menjadi performer tinggi dibanding adopter belakangan atau non-adopter
  • Karena bias seleksi, perbedaan yang diamati bisa jadi merupakan sifat manusianya, bukan sifat alatnya
  • Cara ini berbiaya paling rendah untuk dijalankan, sehingga menjadi cacat desain yang umum dalam laporan produktivitas AI di industri
  • Dalam studi longitudinal yang melacak penggunaan Copilot selama dua tahun di organisasi TI besar, pengguna sudah secara konsisten lebih aktif daripada non-pengguna bahkan sebelum mengadopsi alat tersebut

• Membandingkan AI dengan ‘tidak ada apa-apa’

  • Membandingkan pengembang berbantuan AI dengan kelompok kontrol yang tidak menggunakan alat apa pun berarti memilih baseline yang tidak ada dalam pekerjaan nyata
  • Pengembang tanpa assistant LLM pun tetap menggunakan dokumentasi, rekan kerja, dan waktu untuk memikirkan masalah sendiri
  • Pertanyaan pentingnya adalah apakah alat LLM lebih baik daripada alternatif yang sudah dimiliki pengembang, dan perbandingan seperti ini jarang dilakukan
  • Jika memilih baseline yang lemah, alat apa pun akan tampak bagus, tetapi itu tidak berarti benar-benar berguna

Cakupan pengukuran yang terlewat

• Hanya mengukur separuh yang mudah

  • LLM membuat pembuatan kode lebih cepat, dan bagian ini mudah diukur
  • Separuh yang lebih sulit adalah waktu untuk meninjau kode buatan LLM, waktu debugging yang hilang karena usulan yang salah tapi terdengar meyakinkan, kerentanan keamanan dari kode yang tampak masuk akal tetapi tidak aman, serta utang teknis dari solusi dadakan yang mengabaikan desain sekitarnya
  • Dalam studi kode GitHub Copilot, sebagian besar kode yang dihasilkan mengandung kerentanan keamanan, dan pengembang yang berada di bawah tekanan waktu menerima usulan tidak aman dengan tingkat yang lebih tinggi
  • Dalam evaluasi tahun 2025 terhadap 5 LLM utama, tidak satu pun model mampu menghasilkan kode aplikasi web yang memenuhi standar keamanan industri
  • Analisis skala besar atas lebih dari 300 ribu commit yang ditulis AI menemukan bahwa lebih dari 15% memperkenalkan setidaknya satu masalah kualitas, dan hampir seperempat di antaranya tetap bertahan dalam codebase dalam jangka panjang
  • Jika hanya mengukur kenaikan output sambil mengabaikan kenaikan biaya yang menyertainya, itu bukan pengukuran melainkan pemasaran

• Yang harus diukur adalah sistem, bukan individu

  • Kecepatan coding individu adalah yang paling mudah diukur, sehingga paling sering diukur
  • Bahkan jika alat AI membuat pengembang menulis kode 30% lebih cepat, jika lead time tiket-ke-produksi tim tidak berubah, berarti bottleneck-nya bukan pada penulisan kode
  • Jika kode yang dihasilkan bertambah, kode yang harus direview juga bertambah; bila AI hanya menambah volume kode tanpa menambah kapasitas review, cycle time bisa memburuk
  • Dalam studi empiris pada pengembang profesional, alat AI memang meningkatkan output kontributor yang kurang berpengalaman, tetapi pada pengembang senior produktivitas justru turun 19% karena beban code review dari kode buatan AI naik 6,5%
  • Mengoptimalkan hanya satu tahap dalam pipeline sambil mengabaikan sisanya adalah kegagalan berpikir sistem yang menyamar sebagai riset produktivitas

Distorsi efek dari waktu ke waktu

• Menanyakan kepada pengembang apakah produktivitasnya naik

  • Hasil survei seperti “87% pengembang merasa lebih produktif dengan alat AI” sering dikutip sebagai bukti bahwa alat itu bekerja
  • Laporan diri dapat menimbulkan salah paham sistematis karena tiga alasan
  • Karena efek Hawthorne, orang bekerja berbeda ketika tahu bahwa mereka sedang diamati atau dievaluasi
  • Alat baru terasa lebih cepat hanya karena baru, menciptakan efek kebaruan, dan perasaan ini biasanya hilang dalam beberapa minggu
  • Karena bias keinginan sosial, responden cenderung memberikan jawaban yang mereka yakini ingin didengar survei, terutama ketika manajemen yang memilih alat tersebut

• Hanya mengukur selama masa efek kebaruan

  • Jika studi 4 minggu menemukan peningkatan produktivitas, itu hanya menemukan peningkatan produktivitas selama 4 minggu
  • Pengembang cenderung lebih terlibat dengan alat baru pada periode awal, sehingga hasil yang diamati bisa membesar dibanding baseline jangka panjang
  • Efek yang benar-benar penting muncul dalam hitungan bulan, bukan minggu
  • Degradasi keterampilan pada pekerjaan yang didelegasikan ke AI, utang teknis yang menumpuk dari usulan keliru, dan perubahan cara tim berkolaborasi memerlukan pengamatan jangka panjang
  • Studi yang dirancang untuk mendeteksi keuntungan jangka pendek tidak memberi tahu apa yang terjadi setelah penelitian berakhir
  • Analisis terhadap 807 repositori open source yang mengadopsi Cursor menunjukkan bahwa setelah adopsi, kecepatan pengembangan meningkat tajam tetapi sementara, sementara kompleksitas kode dan peringatan analisis statis meningkat secara signifikan dan bertahan lama

Kesimpulan untuk interpretasi yang lebih baik

• Pengukuran produktivitas sulit direduksi menjadi satu angka atau metrik pengganti yang mudah
• Untuk menilai dampak coding berbantuan LLM, yang perlu dilihat bukan hanya kecepatan menulis kode, tetapi juga review, debugging, keamanan, pemeliharaan, utang teknis, bottleneck tim, dan perubahan jangka panjang
• Tanpa kelompok kontrol, baseline yang realistis, pengendalian bias seleksi, pengamatan jangka panjang, dan metrik tingkat sistem, sulit membedakan efek alat AI dari efek perubahan lain
• Nilai yang mudah diukur memang mudah dilaporkan, tetapi nilai yang mudah tidak otomatis mewakili nilai yang penting
• Untuk menilai praktik pengembangan perangkat lunak, perlu ada penerimaan yang lebih serius terhadap metode riset dari ilmu manusia

Sumber utama yang dikutip

• Kent Beck, “Measuring Developer Productivity: Real-World Examples”: contoh realistis pengukuran produktivitas pengembang
• Catherine M. Hicks, Carol Lee, Kristen Foster-Marks, “The New Developer: AI Skill Threat, Identity Change & Developer Thriving in the Transition to AI-Assisted Software Development”: membahas ancaman keterampilan, perubahan identitas, dan keberlangsungan pengembang dalam transisi ke pengembangan berbantuan AI
• McKinsey, “Yes, You Can Measure Software Developer Productivity”: usulan pengukuran produktivitas berbasis aktivitas seperti commit, Pull Request, dan code review
• Peng2023: studi yang menyatakan pengguna GitHub Copilot menyelesaikan tugas implementasi server HTTP 55% lebih cepat
• Becker2025: studi yang menyatakan waktu penyelesaian tugas meningkat 19% ketika pengembang open source berpengalaman diberi akses ke alat AI
• Pearce2022: studi yang mengevaluasi kerentanan keamanan pada kode yang dihasilkan GitHub Copilot dan peningkatan penerimaan usulan tidak aman saat berada di bawah tekanan waktu
• He2026: studi yang menemukan peningkatan kecepatan pengembangan jangka pendek dan peningkatan kompleksitas kode serta peringatan analisis statis jangka panjang setelah adopsi Cursor
• Xu2025: studi yang membahas bahwa pemrograman berbantuan AI dapat meningkatkan beban review dan pemeliharaan bagi pengembang berpengalaman sehingga menurunkan produktivitas

[GN⁺]

Pendapat di Lobste.rs

• Penulisnya adalah salah satu pendiri Software Carpentry, jadi dia adalah orang yang sudah memikirkan cara yang lebih baik untuk mengukur produktivitas perangkat lunak jauh sebelum LLM muncul
  Riset METR yang dikutip lebih menarik daripada alasan yang biasanya dibicarakan. Bagi banyak orang, tajuk utamanya adalah “AI membuat orang lebih lambat”, dan ini bisa dibantah dengan mengatakan bahwa LLM model 2025 terus membaik
  Tetapi hasil yang lebih menarik adalah bahwa perkiraan mereka sendiri setelah kejadian ternyata bahkan tidak sesuai arah dengan kenyataan. Tampaknya ada faktor di sini yang diabaikan sebagian besar perusahaan, yang menciptakan kesulitan mendasar dalam pengukuran apa pun
  Bahkan perasaan samar bahwa alat membuat orang lebih produktif pun tidak bisa dipercaya. Orang-orang sendiri tidak tahu
  Studi lanjutan yang menyusul pada dasarnya gagal karena bias seleksi

  The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
  Fakta bahwa para developer menolak bekerja tanpa AI bisa berarti alat itu memang bekerja dengan baik, atau bisa juga berarti mereka makin bergantung pada alat tersebut sampai kemampuan mereka untuk menangani tugas yang lebih sulit benar-benar mengalami kemunduran

  • Hipotesis saya adalah bahwa orang cenderung lebih mengandalkan LLM untuk bagian pekerjaan yang sebenarnya tidak ingin mereka lakukan, dan saat melakukan pekerjaan yang tidak mereka sukai, waktu selalu terasa berjalan jauh lebih lambat

• Pernyataan bahwa “alat baru terasa lebih cepat karena masih baru, dan perasaan itu biasanya hilang dalam beberapa minggu” terasa terbalik
  Alat baru selalu membuat saya lebih lambat karena saya belum terbiasa dengannya. Tentu, saya bisa melihat potensinya untuk menjadi lebih cepat, tetapi saya belum bisa memakainya secara efektif

  • Ada satu efek terkait lagi. Terutama orang-orang yang secara sukarela mencoba alat baru biasanya antusias, jadi mereka juga bekerja lebih banyak di luar jam kerja untuk menutupi kekurangannya
    Untuk sementara terlihat mengesankan, tetapi pada akhirnya itu memudar secara alami ketika mereka kembali ke pola kerja normal

• Pengukuran itu sulit. Dalam arti tertentu, mencoba mengukur coding berbantuan AI itu sendiri mungkin merupakan sebuah kekeliruan
  Jelas ada tugas-tugas yang dibuat lebih cepat olehnya, dan hampir pasti ada cara menggunakan alat itu agar benar-benar mempercepat
  Pertanyaan yang lebih penting adalah apa cara itu, dan apa yang hilang dalam prosesnya

  • Produktivitas dan peningkatan kecepatan kerja itu berbeda. Meski suatu tugas menjadi lebih cepat, kalau tugas itu bukan bottleneck atau jika peningkatan kecepatan itu memiliki biaya, dampaknya belum tentu positif terhadap produktivitas
    Teks aslinya juga membahas ini sebagai “mengukur hanya separuh yang mudah”

• Soal pertanyaan, “Kalau minggu depan manajer meminta Anda menunjukkan bahwa alat coding AI yang dibayar perusahaan memang sepadan dengan biaya langganannya, apakah Anda akan mengukur jumlah baris kode yang dihasilkan, atau jumlah tiket yang ditutup?”, Claude sudah mengukur jumlah baris kode, tingkat penerimaan, dan penggunaan token dari catatan penagihan
  Jumlah tiket yang ditutup adalah kecepatan tim, tetapi output AI hanyalah salah satu faktor di dalamnya, dan Jira mengukur velocity sprint
  Bagaimanapun juga, pertanyaan ini mudah dimanipulasi tergantung apa yang Anda anggap sebagai output yang diinginkan manajer, dan sangat mungkin itu memang sudah terjadi

• Rasanya penulis melewatkan pertanyaan yang sangat penting. Yaitu, “Kerugian apa yang ditimbulkan oleh penggunaan AI?”
  Menurut saya, pertanyaan ini lebih mendasar daripada yang lain. Kerugiannya jauh lebih mudah diukur. Cukup jalankan satu Git forge dan lihat crawler berdatangan seperti hiu yang mencium bau darah
  Fakta bahwa scraper melakukan DDoS terhadap seluruh internet adalah masalah yang bisa diukur, dan bagi orang yang melakukan self-hosting, itu adalah kenyataan yang mereka rasakan sendiri
  Apakah apa yang disebut manfaat AI itu—yang bahkan sulit kita ukur dengan baik—cukup bernilai untuk menanggung kerugian yang sangat nyata akibat crawler?
  Bagaimana kalau ditambah energi yang dibutuhkan untuk menjalankan crawler dan memproses request itu, biaya pelatihan, biaya inferensi, sampai kebutuhan akan data center yang terus membesar?
  Menanyakan apakah apa yang disebut manfaat AI itu layak mengorbankan semua ini menurut saya adalah pertanyaan yang jauh lebih penting

  • Yang selalu membuat frustrasi dalam isu model “kita seharusnya membicarakan X” seperti ini adalah bahwa saya pernah melihat klaim yang persis kebalikannya dalam tulisan tentang kerusakan ekologis
    Misalnya, “bahkan jika ini tidak memakai energi, tetap saja menghasilkan kode buruk, jadi itu yang jauh lebih penting untuk dibicarakan”, atau “kenapa bicara soal coding, kerugian yang sebenarnya adalah penggunaannya untuk pengawasan”, dan seterusnya