Apakah Claude Menambah Bug di rsync?

 (alexispurslane.github.io)
2 poin oleh GN⁺ 2026-06-06 | 2 komentar | Bagikan ke WhatsApp
  • Rilis yang dibantu Claude hanya ada dua, rsync v3.4.2 dan v3.4.3, dan tidak ada bukti bahwa keduanya memiliki bug yang luar biasa banyak dibanding rilis historis jika diukur dengan bug berbobot keparahan per 10 commit
  • sev/10c adalah metrik utama yang menormalkan skor keparahan bug ke rentang 0–1, menjumlahkannya per rilis, lalu membaginya dengan jumlah commit dan mengonversinya menjadi nilai per 10 commit
  • v3.4.2 memiliki 50 commit, 9 commit Claude, 0 bug, dan 0.00 sev/10c, sedangkan v3.4.3 memiliki 34 commit, 28 commit Claude, 17 bug, dan 3.29 sev/10c; keduanya berada di sisi berlawanan dari IQR dan tidak satu pun merupakan outlier
  • Nilai p dari uji permutasi eksak adalah 46%, nilai p dari uji eksak Fisher adalah 74%, dan rasio odds adalah 1.06, sehingga hampir tidak ada sinyal bahwa rilis Claude lebih buruk daripada dua rilis acak atau lebih mungkin berada di atas median
  • v3.4.1 adalah rilis sebelum adopsi Claude, tetapi tetap menjadi nilai terburuk di seluruh data dengan 59 bug, 9 commit, dan 39.39 sev/10c; inti kontroversi rsync adalah mengaitkan satu regresi tunggal dengan Claude tanpa mempertimbangkan distribusi historis

Latar belakang dan pertanyaan

  • Pada akhir Mei 2026, kontroversi rsync dimulai dari sebuah postingan Mastodon yang menghubungkan regresi v3.4.3 dengan commit Claude di rilis tersebut, lalu menyebar ke Hacker News dan issue GitHub "Please Do Not Vibe Fuck Up This Software"; issue itu mengumpulkan lebih dari 300 komentar
  • Klaim inti yang berulang adalah bahwa pengembangan yang dibantu Claude memasukkan bug ke alat yang sebelumnya stabil, dan pertanyaan datanya adalah apakah rilis yang dibantu Claude memiliki bug jauh lebih banyak daripada rilis historis
  • Di Lobsters, ada permintaan untuk melihat jumlah regresi per rilis dalam bentuk grafik waktu, dan fokus analisisnya adalah satu pertanyaan: “Apakah rilis yang dibantu Claude memiliki bug yang luar biasa banyak?”

Cakupan data dan reproduksibilitas

  • Data mencakup 36 rilis dari v2.4.6 hingga v3.4.3 pada RsyncProject/rsync yang memiliki data bug, dan hanya ada dua rilis dengan commit Claude: v3.4.2 dan v3.4.3
  • Pemilihan metrik, metodologi, dan sumber data dilakukan langsung oleh manusia, dengan masukan dari pasangan penulis yang bergelar magister statistika
  • Pengumpulan data, pemuatan ke DuckDB, pembuatan view, dan skrip analisis statistik ditulis oleh GLM 5.1, tetapi semua angka, statistik, kartu, dan grafik dimasukkan otomatis oleh skrip Python yang menjalankan analisis statistik
  • Repositori reproduksi alexispurslane/rsync-analysis dapat menjalankan seluruh pipeline dari awal sampai akhir

Metrik dan cara atribusi bug

  • Metrik intinya adalah bug berbobot keparahan per 10 commit, yaitu sev/10c, dengan rumus sev/10c = (Σ severity/100 ÷ total_commits) × 10
  • Commit diurutkan berdasarkan committer date pada branch utama, dan rentang tiap rilis diambil dari tag sebelumnya hingga tag tersebut; tag pre dan rc dikecualikan sebagai batas dan diserap ke rilis final
  • Sumber bug berasal dari tiga tempat: issue GitHub, Bugzilla rsync, dan mailing list rsync; untuk issue GitHub dan bug dari mailing list, bug diatribusikan ke rilis terbaru yang sudah dirilis tepat sebelum waktu pelaporan
  • Entri Bugzilla memiliki field “Version” yang menyatakan rilis tempat bug dilaporkan, sehingga diatribusikan ke rilis tersebut
  • Alasan memilih analisis tingkat rilis adalah karena kritiknya sendiri berbentuk “seluruh rilis yang memiliki commit Claude menjadi lebih banyak bug”, dan sebagian besar bug tidak secara eksplisit menyebut berasal dari commit mana

Cara penilaian keparahan

  • Semua laporan bug dinilai oleh Qwen 3 35B dengan skor keparahan 0–100, menggunakan prompt yang memberinya peran senior reliability engineer dari sudut pandang dampak ke pengguna nyata
  • Skor 90–100 mencakup korupsi data senyap, kehilangan data, eksekusi kode jarak jauh, atau kerentanan keamanan dengan akses tidak sah; 70–89 mencakup crash, hang, kegagalan backup, dan kegagalan build; 50–69 mencakup regresi fungsional yang bisa diakali
  • Untuk Bugzilla dan mailing list, karena hanya ada judul tanpa isi, model menilai berdasarkan judul saja, dan bila informasinya tidak cukup, ia diarahkan agar cenderung ke rentang tengah 40–60
  • Output dibatasi ke integer severity saja melalui JSON schema dari structured output, dan temperature dikunci di 0 agar input yang sama menghasilkan skor yang sama
  • Issue yang mendapat skor 0, seperti permintaan fitur, spam, protes nonteknis terkait AI, atau kiriman kosong, dikeluarkan dari jumlah bug dasar

Hasil statistik untuk rilis Claude

  • v3.4.2 memiliki 9 commit Claude dari total 50 commit, 0 bug nyata, 0.00 sev/10c, dan berada di persentil 0
  • v3.4.3 memiliki 28 commit Claude dari total 34 commit, 17 bug, 3.29 sev/10c, dan berada di persentil 77
  • IQR historis adalah 0.29–2.59 sev/10c; v3.4.2 berada tepat di bawah IQR, sedangkan v3.4.3 tepat di atasnya, sehingga kedua rilis itu menjepit distribusi tengah dari sisi yang berlawanan
  • Uji permutasi eksak menghasilkan nilai p 46%, karena dari 595 kombinasi yang mungkin untuk dua rilis, ada 272 yang memiliki rata-rata grup Claude sebesar 1.65 sev/10c atau lebih tinggi
  • Uji eksak Fisher memeriksa apakah rilis Claude lebih sering berada di atas median 0.74 sev/10c, dan menghasilkan nilai p 74% serta rasio odds 1.06

Jumlah commit dan skala perubahan

  • Rata-rata rilis Claude memiliki 42 commit, sedangkan rilis tanpa Claude memiliki rata-rata 185 commit, dan peluang dua rilis acak memiliki jumlah commit setidaknya sebanyak itu adalah 88%
  • Berdasarkan GitHub compare API, rata-rata baris perubahan pada rilis Claude adalah 3.756 baris, sedangkan rilis tanpa Claude 696 baris, dan peluang dua rilis acak memiliki jumlah baris perubahan setidaknya sebanyak itu adalah 5%
  • Jumlah bug berbobot keparahan rata-rata pada rilis Claude adalah 5,6, sedangkan pada rilis tanpa Claude adalah 14,9, dan peluang dua rilis acak memiliki jumlah bug berbobot keparahan setidaknya sebanyak itu adalah 77%
  • Kesimpulannya, rilis Claude memang memiliki jauh lebih banyak baris perubahan, tetapi tidak memiliki lebih banyak commit atau lebih banyak bug berbobot keparahan

Sistem versi dan outlier yang sudah ada sebelumnya

  • Rata-rata rilis v2.x adalah 1.11 sev/10c, sedangkan rata-rata rilis v3.x adalah 4.23 sev/10c, sehingga v3.x menunjukkan tingkat bug yang lebih tinggi
  • Bahkan jika hanya membandingkan v3.x, rilis Claude tetap berada di kelompok tengah atau lebih baik; agar Claude terlihat seperti outlier, perbandingan harus dilakukan dengan era lama yang lebih tenang, sehingga perubahan yang sudah terjadi sebelum Claude justru dibebankan ke Claude
  • Wald–Wolfowitz runs test pada 35 rilis tanpa Claude menghasilkan 13 run teramati, nilai harapan acak 18,5 run, z=-1.88, p=0.060, yang tidak cukup kuat untuk menolak keacakan pada ambang 0,05
  • v3.4.1 adalah rilis sebelum Claude diadopsi, tetapi mencatat tingkat bug tertinggi di seluruh data dengan 59 bug, 9 commit, dan 39.39 sev/10c
  • v3.4.1 adalah rilis hotfix yang keluar sehari setelah v3.4.0, dan menunjukkan tingkat bug tertinggi yang melampaui semua rilis lain dengan selisih dua digit, pada masa ketika belum ada AI yang bisa disalahkan

Interpretasi dan keterbatasan

  • Interpretasi yang sesuai dengan data adalah bahwa “dua rilis Claude saat ini tidak dapat dibedakan secara statistik dari rilis historis”
  • v3.4.3 memang cukup tinggi pada 3.29 sev/10c dan berada di persentil 77, tetapi bukan nilai ekstrem, karena ada 8 rilis historis dengan skor lebih tinggi
  • Klaim bahwa “Claude jelas membuat keadaan lebih buruk” tidak didukung oleh distribusi rilis, uji permutasi, maupun uji Fisher
  • Sebaliknya, data ini juga tidak mendukung kesimpulan bahwa “commit Claude secara umum tidak akan membuat keadaan lebih buruk di masa depan”; datanya hanya menunjukkan bahwa dua rilis saat ini masih berada dalam rentang yang biasa
  • Metrik ini punya keterbatasan sebagai alat yang kasar karena tidak mengendalikan kompleksitas commit atau intensitas pekerjaan keamanan

Faktor perancu yang dibahas

  • Seorang pengguna di Hacker News berpendapat bahwa perbaikan keamanan untuk merespons CVE tampaknya mengungkap kesalahan pengkodean yang sudah ada dalam kode sejak 2007
  • Seorang pengguna di Lobsters mengusulkan rantai kausal “LLM → kenaikan issue keamanan yang diketahui → perlu lebih banyak perubahan daripada biasanya → lebih banyak regresi daripada biasanya”
  • Andrew Tridgell menjelaskan bahwa banjir laporan CVE buatan AI menuntut perubahan yang cepat dan luas pada permukaan serangan rsync
  • Jika faktor perancu ini juga diperhitungkan, maka masalahnya tampak lebih dekat ke meningkatnya pekerjaan keamanan dan volume perubahan yang mengikutinya, bukan ke Claude itu sendiri

Bacaan terkait

2 komentar

 
GN⁺ 2026-06-06
Komentar Hacker News

  • Saat melihat commit, saya menemukan commit asli dan commit pembatalannya: https://github.com/RsyncProject/rsync/commit/d046525de39315d...
    Bahkan jalur yang seharusnya memakai malloc ikut diubah menjadi calloc, seolah-olah semua alokasi dipaksa menganggap calloc adalah superset yang ketat dan kompatibel ke atas. Pada alokasi besar atau alokasi rekursif, biayanya bisa cukup besar. Ini tampak seperti contoh bagus bagaimana hal seperti ini bisa lolos dari pengawasan pada kode yang ditulis dengan Claude. Pembatalannya ada di https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721..., dan bahkan kalau hanya membaca separuh penjelasan pembatalannya, terasa sekali nuansa tulisan LLM. Saya paham perasaan orang yang memposting tulisan aslinya

    • Jumlah commit-nya sendiri juga mencurigakan. Dalam dua bulan terakhir, jumlah commit yang masuk ke rsync hampir setara dengan dua tahun sebelumnya, dan sebagian besar adalah commit yang ditulis dengan Claude. Melihat perubahan seperti ini ikut masuk, rasanya seperti pola klasik ketika orang terlalu bersemangat memakai AI lalu makin ceroboh
    • “Ditulis dengan Claude” tidak tepat. Commit pembatalan itu merujuk ke https://github.com/RsyncProject/rsync/issues/959, dan di issue tersebut penulisnya sendiri menjelaskan bahwa “perubahan untuk membuat memori menjadi 0 adalah ide saya dan perubahan saya sendiri”
      Dalam laporan keamanan disebutkan ada penggunaan elemen di luar akhir array, dan ia menilai bahwa jika alokasi diinisialisasi ke 0, maka walaupun bug serupa muncul lagi nanti, kemungkinan besar dampaknya berhenti pada dereferensi pointer null alih-alih pointer valid. Claude hanya dipakai untuk merapikan kumpulan commit, dan karena sistemnya memberi tag co-authored bahkan untuk sedikit revisi, itu tidak berarti Claude yang menulis perubahannya. Ia menyatakan bahwa kode sebenarnya ditulis olehnya sendiri
    • Saya tidak akan langsung menyimpulkan bahwa Claude yang membuat keputusan itu. Ini bukan perubahan sampingan yang diam-diam menyusup di antara commit besar; dari pesan commit saja sudah dimulai dengan “menginisialisasi semua memori yang baru dialokasikan ke 0”, dan memang itulah yang dilakukan. Saya juga tidak tahu prompt seperti apa yang dibayangkan orang
      Sangat mungkin seorang manusia awalnya menganggap itu perbaikan, lalu berubah pikiran setelah melihat regresi RSS. Dan juga tidak ada hukum alam yang mengharuskan perubahan ini pasti menambah RSS. calloc bisa saja diperlakukan khusus karena sistem operasi tahu bahwa pemetaan memori baru yang baru diterima sudah diinisialisasi ke 0. Jika mau menyalahkan AI di sini, artinya lebih dekat ke: AI memicu lonjakan laporan kerentanan, itu memicu lonjakan perbaikan mendesak, dan perbaikan mendesak kadang memang menimbulkan masalah lain
    • Luar biasa, kita hidup di zaman AI dikalikan Linux overcommit. Buat saya pribadi, 10.8GB sekarang bukan angka yang istimewa, dan buffer sprintf mungkin malah lebih besar dari itu. Kalau belum, seharusnya begitu; kalau tidak, sudah waktunya mulai memakai snprintf

  • Sebelum ikut berkomentar, saya sarankan membaca tulisan yang ditautkan oleh penulis rsync: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
    Sebagai keterbukaan, saya sudah beberapa tahun tidak berkomunikasi dengan Tridge, tetapi dulu lama menjadi rekan kerja sekaligus mentor saya. Ada baiknya mempertimbangkan sudut pandangnya sebelum ikut dalam gerakan mengecam

    • Ini seharusnya jadi komentar teratas. Cukup menyedihkan bahwa ia sampai harus menulis posting seperti ini. Terlalu banyak orang menghakimi padahal mereka juga bukan yang membayar tagihannya
    • Saya tidak sepenuhnya paham bagian “saya pikir lebih baik membangun struktur inti dari test suite baru secara terbuka di master terlebih dahulu”. Kalau dia hanya memperbarui test atau hanya push ke master, orang-orang tidak akan marah
      Tetapi dia juga mendorong perubahan yang merusak ke release branch. Merusak workflow yang sudah berjalan selama bertahun-tahun adalah cara paling pasti membuat orang marah, dan ketika commit-nya juga menampilkan “Claude”, itu seperti menyiram bensin ke api
    • Menurut saya responsnya benar-benar ditulis dengan baik

  • Saya tidak punya kepentingan langsung dalam perdebatan ini, tetapi ada beberapa bagian yang tampak mencurigakan. Rilis yang dikaitkan dengan bug terbanyak adalah rilis Januari, tepat sebelum rilis pertama yang memasukkan commit co-author Claude, jadi saya penasaran apakah mungkin ada commit yang ditulis LLM tanpa penanda atribusi yang masuk ke rilis ini
    Metodologi atribusi rilisnya juga kurang bagus. Bug yang diperkenalkan dalam pembaruan minor cenderung diatribusikan ke rilis patch tempat bug itu bertahan paling lama dalam versi minor tersebut. Sulit percaya bahwa 3.4.1 benar-benar memperkenalkan banyak bug; karena dirilis sehari setelah 3.4.0, kemungkinan besar bug yang muncul di rilis itu tercatat sebagai milik 3.4.1. Selain itu, karena rilis yang lebih baru punya lebih sedikit waktu untuk dilaporkan bugnya, bisa ada bias yang membuat rilis terbaru tampak seolah punya lebih sedikit bug

    • Setuju. Ungkapan di tulisan itu, “rilis terburuk dalam sejarah rsync terjadi sebelum Claude diperkenalkan, dan tidak ada yang menyadarinya,” memberi kesan bukan bahwa penulis tidak punya kepentingan dalam perdebatan ini, melainkan bahwa ia membungkus opini dengan istilah statistik yang mencolok
      “Sangat jelas sekali”? Cukup gambar satu grafik. Dan v3.4.1 bertanggal 2025-01-16, jadi secara teknis sudah berada dalam era coding berbantuan AI, dan itu sebelum penanda atribusi menjadi praktik standar
    • Mengingat rilisnya cukup jarang, saya juga mulai melihat bagian yang sama. Untuk menghindari masalah commit buatan LLM tanpa penanda atribusi, menurut saya analisisnya harus mencakup perbandingan tingkat keparahan bug sebelum dan sesudah v3.3.0. Tanggalnya 6 April 2024
    • LLM bisa dipakai dengan berbagai cara. Mulai dari manusia yang terlibat sangat langsung dan hanya meminta perubahan lokal, sampai benar-benar menyerahkan semuanya
      Saya sudah melihat banyak kode yang dibuat LLM tetapi tidak diberi co-author di pesan commit. Biasanya tag seperti itu tampaknya hanya muncul kalau antarmuka ke codebase dilakukan sepenuhnya lewat alat seperti Claude/Codex, dan commit semacam itu biasanya paling bertele-tele namun hampir tidak menjelaskan kenapa perubahan dilakukan, hanya merangkum perubahan kodenya. Sebaliknya, saya juga melihat developer yang memakai Claude sebagai alat. Mereka bolak-balik antara VSCode dan terminal Claude, memverifikasi sendiri kode yang benar, lalu menyerahkan pekerjaan plumbing ke Claude. Mungkin penulis juga memulai dari kecil lalu pemakaiannya membesar seiring waktu
    • Poin pertama dan kedua tampak saling bertentangan. Jika semua bug di 3.4.1 seharusnya diatribusikan ke 3.4.0, maka waktu ketika commit LLM tanpa atribusi harus masuk ke proyek menjadi lebih awal lagi, dan makin ke awal, hipotesis itu makin tidak masuk akal
      Masalah yang lebih besar adalah, sama sekali tidak ada bukti yang mendukung hipotesis bahwa commit LLM diam-diam masuk ke rilis sebelumnya dan karena itu tingkat bugnya tinggi. Tidak ada dasar untuk itu kecuali jika sejak awal diasumsikan bahwa jumlah bug yang tinggi otomatis berarti ada campur tangan AI, dan itu adalah penalaran melingkar. Poin ketiga masuk akal. Saya sudah menganalisis biasanya butuh berapa lama untuk menemukan bug dan tiap versi berada di bagian mana dalam siklus rilis; kalau mau, saya bisa unggah
    • Kalau mulai dari kesalahan yang paling gamblang dan mengejutkan, statistik Claude itu berasal dari total 2 data point

  • Ada ironi penting di tingkat meta di sini. Tulisan aslinya membela penggunaan AI, tetapi tampaknya juga jelas memakai AI untuk menganalisis data dan menyajikan hasilnya
    Dalam prosesnya, penulis menggunakan statistik dengan cara yang jelas tidak ia pahami dengan baik, dan sampai pada beberapa kesimpulan yang salah. Diskusi terkait bisa dilihat di https://news.ycombinator.com/item?id=48417626. Singkatnya, studi ini tidak punya daya uji statistik yang memadai, dan membuat klaim “tidak ada perbedaan” yang tidak terjustifikasi. Pada akhirnya, ia menafsirkan data dengan LLM lalu melakukan jenis kesalahan yang sama seperti yang ingin diselidiki studi ini, yaitu dengan yakin menyatakan sesuatu yang salah

    • AI itu terlalu mirip agama. Apa pun yang Anda katakan kepada orang yang percaya, tidak akan membuat mereka meragukan keyakinannya. Lebih umum lagi, Anda tidak bisa meyakinkan seseorang dengan nalar untuk melepaskan sesuatu yang memang ingin ia percayai

  • Menurut saya, satu-satunya hasil dari orang-orang yang marah soal ini dan menekan maintainer rsync adalah membuat orang lain tidak mau mengungkapkan penggunaan AI secara bertanggung jawab. Demi menghindari kontroversi, mereka akan mematikan penanda atribusi Claude di commit

    • Saya tidak terlalu peduli pada pengungkapan penggunaan AI. Kalau bukan dari orang yang saya kenal langsung, saya tidak percaya bahwa kode buatan manusia pasti lebih baik daripada kode buatan AI
      Bagaimanapun, manusialah yang harus bertanggung jawab atas kode yang di-commit dan di-push. Itu tidak pernah berubah. Mau ditulis dengan tangan, dihasilkan karena kucing berjalan di atas keyboard, atau dibuat oleh AI, saya tidak terlalu peduli. Kualitas kode sebuah proyek bisa menurun karena banyak alasan, dan terpaku hanya pada apakah AI yang membuatnya atau tidak itu tidak produktif. Kalau ada yang ingin mencari alasan untuk mengkritik AI, dan ada yang lain ingin membelanya, silakan saja, tetapi itu bukan cara yang tepat untuk menilai kualitas kode proyek
    • Terlepas dari kontroversinya, mematikan penanda seperti itu memang benar. Tidak ada alasan memberi iklan gratis kepada perusahaan bernilai triliunan. Trailer seperti Generated-by hanya relevan saat berkontribusi ke proyek pihak ketiga, dan dalam konteks itu mengungkapkannya adalah bentuk sopan santun
    • Kedengarannya seperti, “Jangan marah karena seseorang melakukan hal yang tidak etis atau tidak bermoral, kalau tidak mereka akan melakukan hal yang lebih tidak etis atau lebih tidak bermoral!”
      Mematikan penanda atribusi untuk kode hasil LLM itu penipuan. Karena itu sama saja dengan mengatakan bahwa Anda yang menulis kodenya. Tentu saja itu juga sangat cocok dengan menghasilkan kode lewat LLM sejak awal. Dalam praktiknya, itu hanya memuntahkan kembali input sambil menghapus lisensi dan pemberitahuan hak cipta
    • Saya tidak yakin itu hal yang buruk. Dari sudut pandang divisi marketing Anthropic, mungkin iya, tetapi kalau agen itu hanya alat lain di kotak perkakas developer, penanda atribusi terasa agak aneh. Pada akhirnya, tanggung jawab commit tetap ada pada developer
    • Logika ini selalu muncul, tetapi tidak meyakinkan. Memang benar bahwa ketika masalah disorot secara terbuka, muncul insentif untuk menyembunyikannya, tetapi lalu apa? Saya tidak paham kesimpulan apa yang diharapkan dari situ
      Mengesampingkan dulu perdebatan apakah AI itu buruk, analoginya begini: penggelapan pajak itu buruk dan tidak etis, dan kalau terlihat harus ditegur. Fakta bahwa itu menciptakan insentif untuk menyembunyikannya tidak berarti kesimpulannya adalah kita tidak boleh menegurnya dan harus diam saja

  • Saya berterima kasih atas kerja Andrew membuat dan memelihara rsync, tetapi karena saya sangat bergantung pada rsync untuk backup file antar mesin di jaringan rumah, saya meluangkan waktu untuk mencari cara mengunci versi rsync Homebrew ke 3.4.1
    Setelah itu, bug di dua versi berikutnya benar-benar menakutkan, begitu juga laporan asli yang memicu semua ini. Prosedurnya ternyata jauh lebih rumit daripada yang saya kira, dan saya merangkumnya di sini: https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

  • Tulisan ini meninggalkan lebih banyak pertanyaan daripada jawaban, jadi sulit menarik kesimpulan. Saya tidak mengerti kenapa v3.4.1 tepat sebelum commit Claude punya bug paling banyak, dan kenapa “tidak ada yang menyadarinya”. Terlalu aneh kalau cuma dianggap kesalahan manusia
    Lalu kenapa v3.4.2 punya 0 bug atau skor bug 0 juga patut dipertanyakan. Juga aneh bahwa outlier seperti ini, yang tampaknya tidak ada pada commit lain, dibiarkan bercampur dalam statistik agregat sehingga menurunkan skor “Claude membuat bug?”. Sejujurnya saya tidak paham kenapa ini bukan tanda bahaya dalam analisis penulis. Rasanya seperti analisis setengah matang disajikan sebagai hasil jadi yang sangat kompleks hanya karena memakai statistik tingkat lanjut

    • Saya tidak tahu alasan apa untuk menganggap v3.4.1 bukan kesalahan manusia, selain asumsi awal bahwa itu tidak mungkin
      Untuk v3.4.2 juga, dalam metrik aslinya ada 4 bug sebelum permintaan fitur dan pertanyaan disaring, dan sebelumnya malah lebih tinggi, tetapi itu tidak membuat perbedaan besar pada keseluruhan analisis. Nilainya masih masuk dalam rentang interkuartil, bahkan di sisi bawah. Dalam situasi ketika rilis Claude cuma ada dua, menghapus satu outlier hanya karena terlihat lucu menurut saya justru lebih buruk dan lebih sewenang-wenang

  • Kalau argumennya seperti, “Kompleksitas commit, fokus keamanan, dan tingkat keparahan bug tidak dikendalikan. Ini alat tumpul yang tidak membedakan typo satu baris dari patch CVE. Tapi karena tuduhan para pengkritik bahwa ‘Claude memperburuk keadaan’ juga alat tumpul, maka alat tumpul adalah respons yang paling adil,” saya sulit setuju
    Dari sudut pandang pengguna, kita perlu memahami apakah sifat bug-nya menjadi lebih buruk. Walaupun proporsinya tetap sama, kalau kualitas perangkat lunak yang dirasakan menurun, terutama bagi maintainer proyek, mereka akan menganggapnya memburuk. Saya tidak mau sepenuhnya mengabaikan analisis ini, tetapi pertanyaan seperti ini menurut saya sulit dijawab hanya dengan analisis kuantitatif

    • Meski begitu, menurut saya ini tetap adil. Sampai sekarang saya belum melihat siapa pun menganalisis kode lalu mengatakan ada berapa regresi dengan tingkat keparahan tertentu. Yang ada cuma, “bug bertambah karena LLM”
      Analisis ini bisa diverifikasi sendiri kalau mau, dan menyatakan bahwa “meskipun ada LLM, jumlah bug masih cukup rata-rata”. Itu berarti klaim tersebut sudah ditanggapi secara langsung. Kalau ingin analisis yang lebih bernuansa, lakukan sendiri dan bagikan hasilnya
    • Klaim yang diajukan tanpa bukti bisa ditolak tanpa bukti. Analisis ini punya lebih banyak bukti dan ketelitian yang lebih tinggi daripada yang dipakai untuk klaim awal. Bagi saya itu sudah cukup. Akan bagus kalau ada yang benar-benar mendukung klaim awal dengan bukti yang lebih baik, dan saya ingin melihatnya. Sampai saat itu, saya tidak akan mengkhawatirkan isu ini
    • Bukankah beban pembuktian ada pada pihak yang membuat klaim?

  • Saya sudah ngoding lebih dari 20 tahun, mencintai ngoding, dan kemungkinan besar akan terus begitu. Sampai beberapa bulan lalu saya skeptis terhadap AI, tetapi Claude dan Codex telah mengubah cara saya mengembangkan dan kecepatan kerja saya dengan cara yang dulu tidak pernah saya bayangkan
    Hasilnya, saya membuat lebih banyak kode dan juga menemukan lebih banyak bug. Karena itu saya cukup terkejut melihat kebencian ekstrem di komentar HN terhadap apa pun yang dibuat dengan AI. Hanya karena AI membantu atau bahkan menghasilkan semuanya bukan berarti sebuah proyek tiba-tiba menjadi vibe coding, dan istilah itu juga tidak seharusnya menjadi hinaan yang diarahkan pada pengguna LLM. Ini sangat mengingatkan saya pada banyak ungkapan merendahkan yang dulu diarahkan pada “developer India” ketika outsourcing ke luar negeri meningkat sejak pertengahan 1990-an. Sekarang di pertengahan 2020-an, ucapan serupa muncul terhadap AI. Saya tidak memahaminya. Yang jelas, terlepas dari para penentangnya, semakin banyak kode akan dihasilkan dengan AI

    • Saya juga skeptis terhadap AI dengan cara yang mirip tiga tahun lalu. Saat GPT-4 masih dianggap state of the art, saya kira semuanya akan segera stagnan karena batas ukuran konteks. Saya ingat masa ketika memakai konteks 32K saja butuh biaya yang tidak masuk akal
      Tahun lalu untuk pertama kalinya saya melihat agen AI men-debug dan memperbaiki bug yang tidak sepele dengan memuaskan. Bahkan saat itu pun jelas bahwa kalau dipakai untuk pekerjaan besar, kemampuannya belum sampai level bisa dilempari seluruh issue tracker. Sekarang saya sudah beberapa bulan mengerjakan proyek yang tidak sepele dengan Codex. Karena alasan library, saya membuat purwarupa dalam C++, versi awalnya saya tulis dalam Haskell, dan belakangan saya port ke Rust untuk menekan penggunaan memori di mobile. Ini bukan alat tanpa masalah, tetapi kecepatan kemajuannya dalam setahun terakhir sangat mengejutkan. Skeptisisme itu bagus, tetapi skeptisisme yang sehat seharusnya mundur ketika berhadapan dengan bukti konkret
    • Dalam topik apa pun yang melibatkan alat, selalu ada orang yang menyukai alatnya sendiri dan ada yang suka melakukan sesuatu yang lain dengan alat itu. Dalam pemrograman, saya termasuk yang kedua. Pemrograman adalah alat yang memungkinkan saya melakukan hal yang benar-benar saya sukai: memecahkan masalah, berpikir di level sistem, dan memberikan solusi keren lewat perangkat lunak
      Karena itu saya sangat menikmati AI yang membantu bagian-bagian membosankan, dan juga sangat senang melihat rekan kerja non-programmer bersemangat ketika ide vibe coded mereka menjadi kenyataan. Saya sungguh penasaran dengan sudut pandang anti-AI dari orang yang bekerja di industri perangkat lunak. Apakah karena takut pada akhir karier yang sudah dekat atau karena pergeseran teknologi?
    • Kalau memang ada ungkapan merendahkan terhadap “developer India” saat outsourcing ke luar negeri meningkat pada pertengahan 1990-an, apa pemicunya?
    • Saya terus-menerus berurusan dengan kode outsourcing, dan tanpa kecuali rasanya seperti kebakaran ban. Barusan saya menghabiskan seminggu membersihkan codebase tempat seorang developer meng-commit flag yang melewati pemeriksaan autentikasi dalam keadaan aktif secara default karena dia tidak tahu cara menyiapkan lingkungan kerja lokal
      Masalah “jalan pintas” yang sama juga dilaporkan pada AI vibe coding, dan saya sendiri mendapati bahwa bahkan ketika memakai model terdepan dengan level reasoning sampai 11, hampir semua kode yang dihasilkan AI tetap harus saya tulis ulang. Meski begitu, AI sangat berguna untuk aktivitas lain seperti review PR, analisis kerentanan keamanan, mencari typo, dan rekayasa balik. Mungkin saya bahkan perlu naik ke paket langganan berikutnya, tetapi pada saat yang sama, kode yang dihasilkan AI tetap tidak bisa dipakai. Kalau dalam satu orang saja bisa ada dua pandangan sekaligus—“sangat berguna sampai saya perlu bayar lebih” dan “kualitas output kodenya tetap tidak berguna”—maka wajar kalau di seluruh basis pengguna muncul beragam pendapat
    • LLM bagus untuk pengambilan konteks dan keluaran berbasis templat. Tetapi yang dijamin hanyalah jawaban menonjol dengan penyebut bersama terendah, hasil yang tidak bisa dilindungi hak cipta, dan potensi risiko hukum akibat kebocoran hak cipta
      Saat ini adalah masa keemasan Napster untuk plagiarisme homolog

  • Saya benar-benar bingung ini apaan. Yang sebenarnya penting hanyalah apakah setelah kode yang ditulis AI diizinkan masuk ke codebase, bug benar-benar bertambah banyak. Semua orang sudah tahu jawabannya. Tetap saja, selalu menarik melihat bagaimana “data” bisa dipakai untuk membangun kesimpulan yang dibutuhkan
 
GN⁺ 2026-06-06
Opini di Lobste.rs

  • Menurut saya, tiap orang boleh memutuskan sendiri apakah akan terus memakai proyek FOSS yang ke depannya dikembangkan dengan vibe coding. Namun, kemarahan yang ditunjukkan komunitas setelah maintainer beralih ke alat vibe coding cukup mengejutkan, dan data empiris dalam tulisan itu setidaknya membantu memberi konteks yang lebih baik terhadap perubahan praktik tersebut
    Apakah kepercayaan akan tetap terjaga atau justru makin runtuh setelah maintainer mengadopsi cara coding ini, baru akan terlihat seiring waktu

    • Saya penasaran, dari orang-orang yang marah soal peralihan ini, berapa banyak yang benar-benar berkontribusi secara berarti ke rsync atau menyumbang dana

  • Analisis ini persis seperti yang saya harapkan, bahkan lebih. Saya terutama suka bagian “semua metrik, metodologi, dan sumber data saya pilih sendiri setelah berkonsultasi dengan istri saya yang bergelar master statistika dari Penn State University”, dan keterlibatan ahli statistik sungguhan serta cara penyajiannya yang mudah dibaca sangat bagus
    Katanya dipakai satu metrik tunggal, yaitu “jumlah bug per 10 commit”, padahal ini kesempatan yang terlewat untuk memakai prefiks SI dan menyebutnya decibugs per commit

    • Setuju. Ini bukan tulisan saya, tetapi saya suka karena ada orang yang melampaui perdebatan panas pro-kontra dan menunjukkan dampaknya pada kualitas kode dengan data

  • Keberhasilan proyek open source terlalu dipengaruhi persepsi sampai-sampai orang membeli bintang GitHub dengan uang. Sayangnya, masalah persepsi kali ini sudah lepas kendali dan menjadi sebuah talking point, dan data apa pun akan sulit mengubahnya
    Ke depannya, kalimat seperti “maintainer rsync memakai LLM lalu semuanya rusak” akan dipakai skeptikus AI bersama talking point seperti “pusat data membuang 500 ribu galon air bersih per hari” dan “riset METR mengatakan LLM menurunkan produktivitas”
    Saya tidak sedang bilang apakah saya seorang skeptikus AI atau bukan, hanya bahwa perdebatan soal topik ini biasanya berjalan seperti itu

    • Kenapa itu disebut “talking point”, bukankah itu cuma fakta?
    • Saya tidak yakin penulis berusaha meyakinkan seseorang dengan data. Saya melihat tulisan ini sebagai upaya memberi konteks berbasis data pada perdebatan sengit soal adopsi alat oleh rsync
      Namun memang benar bahwa unsur-unsur nonkuantitatif lain sepenuhnya tidak dibahas dalam tulisan itu, dan mungkin itu sengaja karena kebisingan dari pihak evangelis maupun skeptis sudah lebih dari cukup

  • Sangat penting, dan juga sesuai dugaan, bahwa rilis terburuk dalam sejarah rsync terjadi sebelum Claude diadopsi, dengan 39,39 bug per 10 commit
    Jika proses seperti pengujian dan quality assurance antara pengguna dan pengembang tidak mampu menjamin ketepatan perangkat lunak, maka bug tetap akan dirilis baik ada LLM maupun tidak. LLM bisa merugikan proses ini, tapi juga bisa membantu

    • Setuju. Tulisan terbaru cURL tampaknya menunjukkan contoh dari sisi sebaliknya
      Berkat praktik rekayasa perangkat lunak yang kuat dan sudah mapan selama bertahun-tahun, nilai penggunaan alat AI serupa untuk menemukan bug secara keseluruhan menjadi lebih rendah
    • Saya punya beberapa kekhawatiran soal masa depan rsync. Masalah terbesarnya adalah rsync pada dasarnya sudah menjadi proyek yang selesai selama beberapa tahun, tetapi setelah memakai AI mereka mencabut kode pengujian lama dan menggantinya dengan test suite Python, serta tidak menjalankan pengujian lama secara paralel untuk memverifikasi ketepatan selama periode yang cukup lama
      Menurut standar saya, itu tidak bertanggung jawab. Terutama karena tujuan utama rsync adalah memindahkan data berharga, dan integritas data tersebut mutlak penting

  • Saya berharap retorika seperti “seperti khas pengguna anti-AI, pada akhirnya ini meningkat menjadi fantasi kekerasan” dihindari. Itu bukan cuma menggeneralisasi sebagian orang yang tidak disetujui penulis, tetapi juga membuat pembaca yang sejak awal tidak setuju jadi semakin antipati, sehingga justru orang-orang yang paling perlu membaca tulisan itu malah tidak membacanya
    Terlepas dari itu, saya tidak terlalu peduli apakah bug-nya lebih banyak atau lebih sedikit dibanding versi sebelumnya. Yang penting bagi saya adalah bahwa ini dikembangkan dengan cara yang tidak sejalan dengan pandangan saya tentang bagaimana perangkat lunak seharusnya dibuat. Jika tidak ada pemahaman dasar bahwa ada masalah selain efisiensi, saya tidak berharap bisa meyakinkan orang bahwa posisi ini masuk akal
    Untungnya, kalau saya tidak mau, saya tidak perlu memakai versi rsync ini, dan saya akan memilih alternatif yang bercabang dari sebelum penggunaan LLM

    • Tulisan ini terlalu penuh amarah, jadi saya tidak bisa membacanya lama-lama dan akhirnya menyerah. Akan lebih baik kalau penulis berusaha adil, atau setidaknya terlihat begitu
      Mengulang meme yang sebenarnya sudah lama dibantah—yaitu bahwa laporan bug pertama adalah issue tempat orang-orang berbondong-bondong masuk—juga tidak membantu. Laporan bug pertama yang sebenarnya adalah yang lain

  • Menurut saya, tulisan yang sekarang ini jujur lebih baik. Hanya saja, bagian “metrik ini tidak bisa mengendalikan kompleksitas commit, sensitivitas keamanan, atau tingkat keparahan bug. Ini alat tumpul yang tidak bisa membedakan perbaikan typo satu baris dengan patch CVE” itu, dari posisi saya yang ada di kubu LLM itu buruk, justru meleset dari kritik utamanya
    Kritik yang saya dan orang lain ajukan adalah bahwa AI mendorong orang membanjiri repositori dengan commit yang lebih besar, lebih sulit dipahami, dan menambah kompleksitas. Para pendukung LLM juga sering mengatakan hal serupa, lalu menggeser tiang gawang dari praktik “membaca PR” yang sudah teruji puluhan tahun menjadi “LLM seharusnya bisa menguji semuanya”. Tetapi masalah bahwa kompleksitas kode adalah utang teknis tidak hilang
    Dalam kasus ini, tingkat keparahan bug-nya sangat tinggi. Karena workflow backup benar-benar rusak. rsync dipakai luas untuk backup, dan orang sudah lama mempercayainya sebagai alat yang “teruji di medan tempur”, sampai-sampai hampir tak terpikir bahwa update patch bisa merusak skrip backup
    Bisa saja dibilang bahwa LLM membuat software yang bug-nya hanya karena kebetulan, atau bahwa maintainer perlu mengubah alur kerja LLM dan meningkatkan cakupan pengujian. Memang maintainer juga mengatakan begitu. Tetapi inti kemarahannya adalah bahwa alat ini merusak kepercayaan tersebut
    Bahkan sekarang ada jenis baru programmer LLM yang berkata mereka “sama sekali tidak membaca kode”. Alasannya, membaca kode terlalu memakan waktu dan lebih rumit dipahami dibanding kode programmer biasa. Membaca kode itu berarti mempelajari model mental orang lain, tetapi alat LLM tidak bisa memberikan satu model mental yang konsisten
    Terpisah dari itu, aksesibilitas situs juga perlu dicek. Penglihatan saya cukup bagus dan saya masih di akhir usia 20-an, tetapi teks abu-abu terang di atas latar krem/kuning benar-benar menyakitkan untuk dibaca

    • Bagian yang dikutip ini membingungkan. Metrik yang dipakai di tulisan itu tampaknya memberi bobot tingkat keparahan pada jumlah bug per 10 commit; apakah penulisnya sedang bertentangan dengan dirinya sendiri? Atau saya yang salah baca?
    • Bagi orang-orang yang bilang workflow-nya rusak, saya rasa ini kesempatan bagus untuk belajar apa itu perangkat lunak open source dan lisensi GPL, serta jaminan apa yang sebenarnya diberikan
      Saya rasa orang tidak akan menemukan bug itu sendiri. Dugaan saya, lebih dari 90% pengguna rsync masih memakai versi lama yang belum memiliki bug itu. Saya juga termasuk salah satunya 
      $ uname -a  
Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64

$ port info rsync  
rsync @3.4.1 (net)  
[...]
      Kalau soal kenapa ini menarik perhatian, tidak perlu jadi Steven Pinker untuk paham bahwa cukup banyak komunitas sedang berada dalam kebingungan sekarang. Fakta bahwa LLM lebih baik daripada manusia dalam pemrograman bukanlah hal yang mudah diterima
      Orang-orang yang menaruh identitas dan harga diri mereka pada kemampuan atau profesi pemrograman kini menghadapi dua krisis sekaligus: ketidakpastian soal nafkah/nilai pasar masa depan, dan krisis identitas
      Ketakutan, ketidakpastian, dan keraguan sulit ditangani, dan perusahaan LLM sedang berusaha sekuat tenaga memperbesar efek itu demi menaikkan harga saham. Jika pasar terkoreksi tajam setelah Oktober, saya kira alat penguat seperti ini juga bisa melemah
      Dari seluruh programmer di dunia, hanya sebagian sangat kecil—yaitu mereka yang memandang kode sebagai bentuk seni—yang mungkin akan memakai LLM untuk berlatih dan meningkatkan keterampilan

  • Tulisan ini banyak mengutip komentar yang menyebut regresi, tetapi analisisnya sendiri tidak mengukur regresi, melainkan hanya laporan bug. Ia mengaitkan bug ke rilis saat bug itu dilaporkan, bukan ke rilis saat bug itu diperkenalkan, dan mengukur tingkat keparahan rilis berdasarkan jumlah commit sambil mengabaikan faktor-faktor yang jelas seperti durasi rilis atau adopsi distribusi
    Saya tidak paham bagaimana ini bisa masuk akal

  • Secara pribadi saya menghindari proyek yang memakai LLM. Bukan karena ada alasan praktis yang kuat, melainkan karena rasanya sangat menjijikkan, mirip seperti ketika seseorang memakai kata-kata seperti “kek” atau “fren” dan saya langsung menganggap itu sinyal bahwa saya tidak ingin berinteraksi lagi, bahkan tanpa alasan khusus
    Penjelasan yang sekarang muncul untuk membenci penggunaan LLM terasa seperti rasionalisasi yang ditempel belakangan. Kekhawatiran saat ini soal etika, kualitas, dan sebagainya memang valid, tetapi meskipun masalah-masalah itu diselesaikan, saya rasa orang seperti saya yang cenderung anti-AI tidak akan tiba-tiba merasa baik-baik saja
    Karena itu saya menghindari proyek dengan AGENTS.md, commit yang ditulis bersama Claude, dan semacamnya tanpa alasan yang spesifik. Rasanya saja tidak enak dan tidak sesuai selera saya, ada bug atau tidak pun tidak penting. Saya rasa ada orang lain yang merasakan hal serupa

  • Untuk penulisnya, pertama, fantasi itu adalah ujaran. Secara praktis Anda sedang mengklaim bahwa itu berhenti pada ujaran, atau setidaknya Anda tidak sedang mengklaim ada eskalasi nonverbal
    Kedua, kalau mau membuat klaim seperti ini, Anda perlu bertanya kepada ahli statistik terdekat bagaimana cara mendukungnya. Hanya karena beberapa orang membuat postingan seperti itu bukan berarti itu secara bermakna mendukung klaim bahwa hal tersebut “tipikal”
    Pengamatan anekdotal saya yang juga tidak didukung statistik adalah bahwa pengguna “anti-AI” cenderung tidak merasa bahwa masuknya LLM ke tempat yang tidak membantu itu sebagai sesuatu yang brutal, melainkan lebih dekat ke rasa sedih

    • Kadang saya melihat tulisan yang sangat panjang dan rinci yang mencoba membantah sebagian penentang LLM, biasanya mereka yang bereaksi secara emosional dan sosial terhadap LLM. Sulit menjelaskan alasannya dengan jelas, tetapi tulisan seperti itu terasa sangat tidak tulus dan seperti memukul pihak yang lebih lemah
      Terlalu rinci sehingga sulit dibantah dari sudut pandang emosional, dan pada akhirnya terkesan berujung pada “LLM bukan masalahnya; kalau dipakai dengan benar itu hanya alat penguat. Penentang AI tidak mengerti apa-apa dan cuma takut tertinggal”
      Saya juga tidak ingin mereduksi pekerjaan para maintainer rsync menjadi sekadar bahan debat, jadi saya tidak tahu bagaimana saya bisa menyusun sanggahan yang meyakinkan
      Statistik di sini mungkin menarik dari sudut pandang pemeliharaan open source, tetapi kesimpulannya terasa condong aneh ke satu sisi, dan meninggalkan kesan bahwa open source ala GitHub bukanlah bentuk kontribusi yang ingin saya lakukan
      Meski begitu, saya tetap berpikir bahwa tindakan beramai-ramai menyerbu maintainer di repositori rsync jelas tidak baik
    • Menyebut fantasi kekerasan publik sebagai sesuatu yang tidak bisa diterima itu benar. Itu bukan sesuatu yang layak dituju sebagai peradaban. Hanya saja saya terganggu ketika penulis menyebutnya “tipikal”, karena itu generalisasi
      Soal pengamatan anekdotal, rasanya komik ini benar. Saya suka melihat klaim yang konkret dan terukur, sebagian karena saya suka angka, dan juga karena itu membantu membuat diskusi online sedikit lebih dekat ke dunia ideal pada panel terakhir

  • Terima kasih atas analisisnya, tetapi saya belum yakin dengan metodologinya. Saya penasaran dengan metrik seperti jumlah bug per unit perubahan yang mengalikan jumlah baris perubahan pada kode inti di setiap commit, yakni perubahan pada kode selain pengujian atau dokumentasi, serta analisis tentang waktu yang dibutuhkan untuk mencapai jumlah bug tertentu setelah rilis.
    Namun, karena rilis kali ini kemungkinan mendapat perhatian jauh lebih besar dibanding rilis lain sehingga lebih banyak bug dilaporkan, tampaknya sulit membuat metrik yang benar-benar meyakinkan. Pertanyaan seperti “apakah ini tergolong tipikal berdasarkan jumlah minggu setelah rilis?” juga mungkin tidak terlalu berguna.