Melarang kode buatan LLM dalam dependensi

• git-annex telah diaudit selama sekitar 100 jam dalam sebulan terakhir agar dapat dibangun tanpa dependensi yang mengandung kode buatan LLM
• Pekerjaan ini menunjukkan kenyataan bahwa yang harus terus dilacak bukan hanya kode per bagian, melainkan seluruh pohon dependensi, sehingga beban pemeliharaan meningkat besar
• Selama audit, ditemukan contoh seperti pembatalan tanpa penjelasan atas perubahan besar buatan LLM, perubahan 10.000 baris pada codebase 26.000 LOC, serta pesan commit 1.489 baris yang tidak konsisten
• Sisi positifnya, ada tambahan informasi kualitas tentang dependensi, tetapi masih ada pandangan skeptis terhadap respons tingkat organisasi seperti Software Freedom Conservancy atau FSF
• Meski LLM bisa memudahkan penambahan konfigurasi atau perubahan formatting, commit seperti itu dapat menimbulkan biaya langsung terhadap kepercayaan kolaborasi dan partisipasi proyek

---

Audit dependensi git-annex

• git-annex diaudit selama sekitar 100 jam dalam kurang lebih satu bulan agar bisa dibangun tanpa dependensi yang menyertakan kode buatan LLM
• Hingga saat ini, target tersebut tampaknya telah tercapai
• Ada halaman terkait di git-annex no LLM code
• Inti masalahnya ada pada beban untuk terus meninjau seluruh pohon dependensi dari sebuah program

Kasus yang terungkap selama audit dan dampaknya

• Kasus-kasus yang terkonfirmasi menunjukkan bahwa ini bukan sekadar soal selera, melainkan masalah pemeliharaan dan kepercayaan
  • Perubahan besar buatan LLM dibatalkan tanpa penjelasan apa pun pada rilis berikutnya
  • Codebase 26.000 LOC menerima perubahan 10.000 baris, dan pesan commit-nya berisi 1.489 baris yang tidak konsisten
  • Ada prompt LLM yang menyuruh menyalin kode dari proyek lain, dan tampaknya pelanggaran hak cipta berhasil dihindari hanya karena beruntung
• Melalui pekerjaan ini, diperoleh informasi tambahan tentang kualitas dependensi, dan informasi ini bisa memengaruhi pilihan ke depan
• Software Freedom Conservancy tampak seperti melewatkan masalah tersebut dalam rekomendasi AI generatif berbasis LLM mereka, dan belum jelas apakah FSF akan berbuat lebih baik
• Di tengah perubahan seperti ini, ada pertimbangan ulang untuk terlibat dalam komunitas terkait, tetapi pekerjaan dan dukungan pengguna tetap berlanjut
• Memberi prompt seperti Add fourmolu config and restyled, neat, atau format a module kepada LLM lalu meng-commit hasilnya mungkin terlihat mudah, tetapi dampak luas dari tindakan itu perlu dipertimbangkan

[GN⁺]

Pendapat Lobste.rs

• Baru tahu hari ini bahwa git-annex ditulis dengan Haskell, keren juga

  Di kereta bawah tanah saat pulang tadi, orang di sebelah saya menonton YouTube Shorts dengan volume maksimal, dan di gerbong yang penuh serta sunyi itu rasanya benar-benar polusi suara, bikin kesal
  Yang lebih menjengkelkan lagi, video yang dia tonton adalah video murahan yang sepenuhnya dibuat AI

  Saya merasa kisah di tulisan ini tentang para penulis dependensi yang membuat perubahan sulit dipahami dengan LLM itu sangat mengena
  Bagian paling bikin frustrasi dari penyalahgunaan LLM adalah bagaimana itu merusak interaksi antarmanusia
  Dulu, bahkan saat harus meninjau usulan yang dipikirkan setengah matang di kantor, ide intinya tetap terlihat jelas sehingga mudah ditangkap dan dikomentari, tetapi sekarang siapa pun bisa memasukkan perubahan yang lemah ke LLM lalu mengubahnya menjadi hasil yang sekilas tampak rapi, padahal setelah ditinjau penuh lubang
  Demikian juga, sekarang orang bisa membuat kode buruk yang kelihatannya bagus

  Ini bukan keluhan baru, tetapi makin lama makin mengusik
  Rasanya seperti kita sedang kehilangan sebagian inti dari koneksi antarmanusia yang dulu membuat kerja dan hidup terasa menyenangkan dan bermakna

  • Saya menghargai rekan kerja yang jujur memberi tahu, “ini dikerjakan 🤖”, jadi saya bisa tahu dari awal tingkat peninjauan seperti apa yang diharapkan
    Biasanya itu berupa dokumentasi proses yang dipakai untuk mempelajari codebase lebih dalam, jadi saya bisa percaya bahwa rekan saya sudah membaca output LLM dan ingin memastikan apakah dia benar-benar memahaminya

  • Menurut saya, yang diubah LLM adalah harga relatif kualitas
    Kalau dianalogikan ke rumah, dulu rumah jelek model McMansion dengan atap bocor dan fondasi buruk harganya 1000X, sementara rumah bagus tanpa masalah tersembunyi harganya 2000X

    Sekarang, dengan teknologi LLM, pekerja terampil secara teori bisa menurunkan harga rumah bagus menjadi 1500X dengan menyerahkan sebagian pekerjaan mekanis yang mudah diverifikasi ke mesin
    Tetapi McMansion yang buruk itu turun menjadi 100X

    Jadi besar kemungkinan McMansion bermutu rendah akan menyingkirkan pekerjaan berkualitas dengan cara yang buruk
    Saya tidak ingin mengganggu para perajin yang bisa menurunkan harga rumah bagus dari 2000X ke 1500X, tetapi jika rumah jelek seharga 100X menyingkirkan yang lebih baik dari pasar dan menciptakan pasar lemon, pelanggan bisa menjadi jauh lebih curiga terhadap perangkat lunak secara keseluruhan
    Pasar lemon itu buruk karena pembeli tidak punya cara membedakan kualitas dari sampah
    Contoh paling terkenal di perangkat lunak adalah crash besar video game tahun 1983, ketika gelombang game sampah membuat banyak pelanggan kapok lalu berhenti membeli

• Saya rasa sikap ini cukup masuk akal
  Secara pribadi saya menduga pada akhirnya ini akan menjadi usaha yang sebagian besar sia-sia, dan untuk penggunaan perangkat lunak saya sendiri saya tidak terlalu memedulikannya, tetapi sebagai sudut pandang subjektif ini cukup valid dan menarik, dan saya juga senang orang ini melakukannya

  Seperti para optimis AI sering melebih-lebihkan, kubu anti-AI juga cenderung mendramatisasi sisi negatifnya secara berlebihan
  Tulisan ini sendiri justru termasuk pengecualian, tetapi menurut saya kalau generalisasi tergesa-gesa di paragraf terakhir dihapus, niat dan pesannya secara keseluruhan akan jadi jauh lebih kuat

  Meski begitu, saya suka membaca tulisan seperti ini dan mencari bagian menarik di dalam emosi yang dibawanya
  Akan menarik kalau ada basis data kode 100% non-LLM terakhir yang diketahui per proyek
  Basis data slop yang berpengaruh juga terdengar menarik, dan yang penting di sini “berpengaruh” mencakup sisi positif maupun negatif, sementara “slop” berarti output yang tidak ditinjau

  Memang orang bisa curang dengan sekadar mengambil arsip GitHub sekitar awal 2023, tetapi yang lebih menarik bukan snapshot pada satu titik waktu tertentu, melainkan snapshot commit terakhir per proyek
  Sepertinya akan ada banyak hasil menarik dari dataset seperti itu, dan ini juga membantu orang-orang yang, seperti penulis ini, ingin membangun ekosistem hanya dari perangkat lunak non-LLM

  Mungkin sudah bisa ditebak, saya sendiri pengguna LLM
  Meski begitu, saya rasa saya termasuk pihak yang masuk akal
  Kalau penasaran, silakan baca tulisan di situs web saya, tetapi saya berjanji isi postingan blog itu 100% ditulis manusia
  Saya merasa membaca pendapat yang berlawanan adalah salah satu cara terbaik untuk belajar dan berkembang, jadi saya senang ikut terlibat dalam upaya seperti ini

  • Ada proyek yang cukup dekat dengan gagasan melacak versi non-LLM terakhir per proyek
    Yaitu https://codeberg.org/ethical-foss/open-slopware yang dijalankan orang-orang anti-AI yang sangat bersemangat
    Untuk beberapa proyek ada “versi terakhir yang belum terkontaminasi atau ID commit”, tetapi tidak mencakup semua proyek

• Alasan saya mengirim tulisan ini adalah karena saya suka penulisnya benar-benar mencari commit tertentu yang mengindikasikan penggunaan LLM dalam dependensi, lalu membuat halaman yang merangkum temuannya

  Secara pribadi saya tidak yakin tulisan ini seharusnya diberi tag vibecoding, karena menurut saya isinya lebih tentang komunitas dan praktik daripada vibe coding

• Ada bagian yang berbunyi, “Saya tahu bahwa pada titik ini saya mungkin sedang mencoba menahan arus yang datang”

  Kalau kompiler yang diandalkan proyek ikut terdampak, permainan selesai
  Saya juga sedang membatasi dampaknya, tetapi pada akhirnya akan datang saat ketika bertahan pada alternatif justru lebih buruk, jadi mau tak mau harus mengalah

• Ini masalah yang rumit
  Sekalipun dianalisis sebaik mungkin, kemungkinan besar tetap sulit menghindari kode LLM
  Misalnya, kode yang masuk lewat pelengkapan otomatis tidak akan terdeteksi

• Menurut saya, titik rusaknya kepercayaan bukan ketika pustaka-pustaka ini mulai memakai LLM, melainkan ketika mereka menerima dan menggabungkan perubahan besar sambil menempelkan pesan commit yang sulit dibaca dan tidak berguna

  Ini adalah kegagalan rekayasa perangkat lunak yang terpisah dari soal apakah LLM dipakai atau tidak

  Sebagai catatan, saya menyukai Joey Hess dan perangkat lunaknya, dan saya cenderung berpikir kontribusi kode harus dinilai berdasarkan mutu hasilnya, apa pun alat yang dipakai untuk membuatnya

• Cara penjelasannya agak mengecewakan
  Commit persistent sepertinya bukan ditulis LLM
  Saya berharap orang-orang tidak menyebut semua commit yang punya “Co-authored-by” sebagai hasil buatan LLM

  Tautan yesod pertama adalah perubahan CI, jadi menurut saya itu sulit dianggap sebagai kode dependensi
  Saat saya membaca “commit buatan LLM dengan pesan commit 1489 baris”, saya kira commit-nya akan benar-benar kacau, tetapi ternyata itu squash merge yang masuk akal, hanya saja diff-nya memang sangat besar

  Commit cabal disebut hanya memakai LLM untuk membuat test, dan bahkan untuk itu pun saya masih ragu apakah itu harus dianggap sebagai kode yang saya andalkan
  Commit git juga cuma CI

  Saya tidak meragukan bahwa sebagian dependensi ini memang memakai LLM, tetapi menurut saya bukti yang diajukan tidak cukup kuat untuk menopang klaimnya
  Di sisi lain, ini jelas usaha yang jauh lebih besar daripada yang saya bayangkan, dan bagus juga ada sesuatu yang konkret untuk ditunjuk sebagai alasan spesifik mengapa seseorang memilih tidak memakai dependensi tertentu