Menurut Working Paper NBER 35275, AI coding agent menaikkan jumlah commit sampai 180 persen di level tugas, tetapi rilis software yang benar-benar sampai ke pengguna hanya bertambah 20 sampai 30 persen. Kesenjangan itu muncul konsisten di tiga generasi alat, dari autocomplete sampai agent asinkron, dan bertahan saat diuji pada empat panel app marketplace. Artinya, mempercepat penulisan kode tidak otomatis mempercepat software yang dikirim. Studi ini ditulis Mert Demirer, Leon Musolff, dan Liyuan Yang, dan diterbitkan pada Mei 2026.
TL;DR
- Working Paper NBER 35275 mencatat kenaikan commit sampai 180 persen di level tugas, tetapi rilis hanya naik 20 sampai 30 persen.
- Elastisitas substitusi antara AI dan kerja manusia diperkirakan sekitar 0,25, jadi keduanya lebih sering saling melengkapi.
- Datanya berasal dari studi peristiwa berpasangan atas lebih dari 100.000 developer GitHub plus empat panel app marketplace.
- Di marketplace, rilis aplikasi baru memang naik, tetapi pemakaian oleh pengguna akhir tidak ikut naik.
- Bottleneck bergeser dari menulis kode ke tinjauan kode, pengujian, dan koordinasi rilis.
Apa temuan utama Working Paper NBER 35275?
Temuan utamanya adalah pola atenuasi: keuntungan produktivitas yang besar di satu tahap menyusut tajam saat merambat naik ke keluaran akhir. Di level tugas, penulis mencatat kenaikan commit hingga 180 persen. Namun ketika diukur pada keluaran yang benar-benar dirilis, angkanya hanya 20 sampai 30 persen lebih banyak. Dua angka itu berasal dari kertas yang sama, bukan dari dua studi berbeda.
Penulis membandingkan tiga generasi alat secara berurutan. Generasi pertama adalah autocomplete, yang menyarankan baris berikutnya saat developer mengetik. Generasi kedua adalah agent sinkron, yang menunggu developer di terminal dan mengerjakan satu tugas dalam satu sesi. Generasi ketiga adalah agent asinkron, yang bisa menerima tugas, bekerja di latar belakang, lalu menyerahkan hasil dalam bentuk pull request. Pola atenuasinya sama di ketiganya, meski besaran kenaikannya berbeda.
Yang membuat temuan ini kuat adalah kombinasinya. Penulis memakai studi peristiwa berpasangan atas lebih dari 100.000 developer GitHub, lalu menambahkan model produksi hierarkis untuk menjelaskan mengapa atenuasi itu terjadi. Mereka juga menguji pola yang sama di tingkat agregat lewat aktivitas GitHub dan empat panel app marketplace. Ketika pola yang sama muncul di tiga tingkat pengukuran berbeda, penjelasan sesederhana salah ukur menjadi lemah.
Mengapa kenaikan commit tidak berubah jadi rilis?
Karena AI dan tenaga manusia di tahap hilir bersifat komplementer, bukan substitusi. Penulis memperkirakan elastisitas substitusi sekitar 0,25. Angka itu jauh di bawah satu, yang berarti menambah kapasitas di satu tahap tidak menggantikan kebutuhan di tahap lain. Kode yang dihasilkan lebih cepat tetap harus ditinjau, diuji, digabungkan, dan dirilis oleh manusia dengan kecepatan yang belum ikut naik.
Dalam kerangka ini, menulis kode bukan lagi tahap yang paling menahan laju. Tahap yang menahan laju justru tinjauan pull request, pengujian, dan koordinasi rilis. Penulis menyebut ini sebagai orchestration tax: semakin banyak kode yang masuk, semakin besar pula beban mengoordinasikannya. Kalau jumlah reviewer tetap dan jumlah pull request naik, antrean tinjauan otomatis memanjang, dan kecepatan rilis ditentukan oleh antrean itu, bukan oleh kecepatan menulis.
Ada juga efek kualitas yang tidak langsung terlihat. Kode yang dihasilkan model cenderung lebih banyak barisnya untuk fungsi yang sama, sehingga beban membaca dan menilai ikut bertambah. Seorang reviewer yang harus memahami perubahan lebih besar dalam waktu yang sama akan melewatkan lebih banyak detail, dan itu justru menaikkan risiko cacat yang lolos ke produksi. Jadi menambah volume kode tanpa menambah kapasitas tinjauan bukan hanya tidak menambah keluaran, tetapi juga menambah risiko.
| Tahap | Kenaikan yang terukur | Sifat pekerjaan |
|---|---|---|
| Menulis kode (commit) | Sampai 180 persen lebih banyak | Paling mudah dipercepat model |
| Rilis ke pengguna | 20 sampai 30 persen lebih banyak | Dibatasi tinjauan dan pengujian manusia |
| Pemakaian pengguna akhir | Tidak terlihat naik | Ditentukan kualitas dan relevansi produk |
Tabel di atas merangkum tiga tingkat pengukuran yang dipakai penulis, dari yang paling dekat dengan model sampai yang paling dekat dengan pengguna. Semakin jauh dari penulisan kode, semakin kecil dampak yang terlihat.
Kapan AI coding agent tetap layak dipakai?
Tetap layak, terutama untuk pekerjaan yang tidak menumpuk di antrean tinjauan. Menulis pengujian, membuat kode boilerplate, memigrasikan pola yang sudah baku, dan menelusuri bug di kode yang belum dikenal adalah contoh pekerjaan yang tidak menambah beban review secara proporsional. Di situ kecepatan model langsung menjadi keluaran, bukan sekadar tumpukan kode yang menunggu ditinjau.
Sebaliknya, untuk perubahan yang menyentuh logika inti, keamanan, atau data pengguna, menambah kecepatan menulis justru memindahkan beban ke reviewer. Di kasus seperti ini, nilai AI lebih besar pada tahap verifikasi: memeriksa perubahan, mencari kasus batas yang belum diuji, dan menjelaskan dampak perubahan. Itu pekerjaan yang mengurangi antrean, bukan menambahnya.
Kesimpulan praktisnya bukan mengurangi pemakaian AI, tetapi menyeimbangkan kapasitas. Kalau tim memakai agent asinkron untuk menghasilkan pull request, kapasitas tinjauan dan pengujian harus direncanakan dengan asumsi volume yang lebih tinggi. Tanpa itu, keuntungan di hulu akan hilang di antrean yang sama.
Apa artinya untuk tim developer di Indonesia?
Untuk tim kecil, temuan ini berguna sebagai pengingat bahwa menambah alat bukan strategi yang cukup. Sebuah tim berisi tiga orang yang mulai memakai agent asinkron akan mendapat pull request lebih cepat, tetapi jumlah orang yang bisa meninjau tetap tiga. Kalau tidak ada perubahan proses, antrean tinjauan akan jadi titik macet baru dalam beberapa minggu.
Langkah yang masuk akal adalah memperkuat pagar otomatis lebih dulu: pengujian yang berjalan sendiri, pemeriksaan gaya kode, dan analisis statis. Pekerjaan yang bisa diperiksa mesin tidak perlu mengantre di mata manusia. Setelah itu, tinjauan manusia bisa difokuskan pada hal yang memang butuh pertimbangan, seperti desain antarmuka, dampak keamanan, dan keputusan produk.
Perlu dicatat juga bahwa data studi ini berasal dari developer dan marketplace di luar Indonesia. Penulis tidak memisahkan hasil per negara, jadi angka 180 persen dan 20 sampai 30 persen itu berlaku sebagai gambaran umum, bukan patokan yang pasti sama untuk konteks lokal. Untuk tim yang ingin tahu dampaknya sendiri, pengukuran internal tetap diperlukan.
Bagaimana pola ini terlihat di data agregat?
Di tingkat agregat, penulis menguji apakah pola yang sama muncul di luar sampel developer individual. Aktivitas GitHub secara keseluruhan menunjukkan kenaikan volume kode yang sejalan dengan lonjakan adopsi alat AI, tetapi laju rilis tidak bergerak secepat itu. Ini penting karena kalau atenuasi hanya muncul di satu kelompok developer, penjelasannya bisa jadi soal kemampuan orangnya, bukan soal struktur kerjanya. Munculnya pola yang sama di tingkat agregat mengarah pada penjelasan struktural.
Pengujian berikutnya memakai empat panel app marketplace. Di sana, jumlah aplikasi baru yang dirilis memang bertambah, tetapi pemakaian oleh pengguna akhir tidak ikut bertambah pada laju yang sama. Artinya, bertambahnya pasokan aplikasi tidak otomatis menciptakan permintaan. Bagi pembuat produk, ini pengingat bahwa biaya produksi yang turun hanya bernilai kalau ada orang yang mau memakai hasilnya.
Kombinasi tiga tingkat pengukuran ini yang membuat kesimpulan penulis sulit dibantah dengan argumen metodologis sederhana. Kalau hanya satu tingkat yang menunjukkan atenuasi, kritik soal definisi commit atau soal pemilihan sampel akan relevan. Ketika tiga tingkat yang berbeda menunjukkan arah yang sama, penjelasan paling hemat adalah bahwa hambatannya memang ada di tahap hilir, bukan di alat ukurnya.
Ada satu implikasi yang sering terlewat: kalau hambatan utama ada di tinjauan dan rilis, maka investasi yang paling menguntungkan bukan membeli langganan alat AI yang lebih mahal, melainkan memperbaiki jalur dari pull request ke produksi. Otomatisasi pengujian, perubahan yang lebih kecil, dan keputusan tinjauan yang lebih cepat adalah tiga hal yang langsung menyerang titik macet yang sama.
Cara mengukur dampak AI coding di tim
Ukur keluaran, bukan aktivitas. Jumlah commit dan jumlah baris kode adalah metrik aktivitas yang justru naik paling banyak dan paling menipu. Yang lebih berguna adalah waktu dari pull request dibuka sampai digabungkan, jumlah perubahan yang harus diperbaiki setelah tinjauan, dan jumlah rilis ke produksi per periode. Tiga angka itu lebih dekat ke keluaran yang dilihat pengguna.
Selain itu, catat kapasitas tinjauan secara eksplisit. Kalau satu reviewer bisa menangani sejumlah perubahan per minggu, itu batas nyata tim. Setelah batas itu terukur, keputusan apakah perlu menambah reviewer, memecah perubahan jadi lebih kecil, atau mengurangi pemakaian agent menjadi keputusan berbasis angka, bukan kesan.
Apa batasan dan kritik atas studi ini?
Kertas kerja ini belum melalui tinjauan sejawat penuh, jadi angkanya sebaiknya dibaca sebagai temuan awal, bukan angka final. Metode studi peristiwa berpasangan berusaha membandingkan developer atau tim yang mulai memakai alat AI dengan yang belum, lalu menyesuaikan perbedaan awal. Cara ini kuat, tetapi tetap bergantung pada asumsi bahwa kelompok pembanding tidak berubah karena alasan lain pada periode yang sama.
Kedua, definisi keluaran perlu dibaca hati-hati. Commit, pull request, dan rilis adalah proksi yang mudah dihitung, bukan ukuran langsung nilai yang sampai ke pengguna. Sebuah rilis bisa berisi perbaikan kecil atau fitur besar, dan model tidak membedakan keduanya. Karena itu, kesimpulan bahwa kenaikan rilis hanya 20 sampai 30 persen harus dibaca sebagai perkiraan arah, bukan angka presisi.
Ketiga, konteksnya adalah developer dan marketplace di luar Indonesia. Perbedaan struktur tim, ukuran perusahaan, dan jenis produk bisa membuat besarannya berbeda di tempat lain. Yang kemungkinan besar tetap berlaku adalah polanya, yaitu hambatan di tahap hilir, bukan besaran angkanya. Untuk keputusan internal, pola itu yang lebih berguna dijadikan acuan.
Keempat, studi ini mengukur periode ketika alat AI masih berkembang cepat. Generasi alat berikutnya bisa mengubah sebagian kesimpulan, terutama kalau model mulai ikut menangani pengujian dan tinjauan, bukan hanya penulisan kode. Karena itu, temuan ini paling tepat dipakai sebagai potret satu periode, bukan sebagai hukum tetap.
Sumber dan bacaan lanjutan
Artikel ini merujuk pada kertas kerja asli dan ringkasan dari beberapa media. Berikut tautan ke sumbernya.
- Working Paper NBER 35275, halaman resmi kertas kerja
- Kolom VoxEU dari penulis tentang hasil studi
- Liputan Ars Technica atas temuan studi
- Ringkasan Quartz soal celah kode dan rilis
FAQ
Apakah studi ini menyimpulkan AI coding agent tidak berguna?
Tidak. Studi ini menemukan bahwa keuntungannya nyata di level tugas, tetapi menyusut saat diukur pada keluaran akhir. Manfaatnya tetap ada, hanya tidak sebesar yang terlihat dari jumlah kode yang dihasilkan.
Berapa banyak developer yang datanya dianalisis?
Studi memakai data lebih dari 100.000 developer GitHub dalam studi peristiwa berpasangan, ditambah empat panel app marketplace untuk menguji pola di tingkat yang lebih agregat.
Apa arti elastisitas substitusi 0,25 dalam konteks ini?
Angka itu mengukur seberapa mudah AI menggantikan kerja manusia di tahap berikutnya. Nilai 0,25 berarti keduanya sulit saling menggantikan, sehingga menambah AI di satu tahap tidak menghapus kebutuhan tenaga manusia di tahap lain.
Mengapa pemakaian pengguna akhir tidak ikut naik?
Karena jumlah aplikasi baru yang dirilis bertambah, tetapi jumlah pengguna yang memakainya tidak bertambah dengan laju yang sama. Bertambahnya pasokan aplikasi tidak otomatis menciptakan permintaan.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬