Patch Emacs Ditolak Karena Mengungkap Vibecoding

• Patch kecil yang dibuat untuk meningkatkan performa Emacs di macOS diajukan ke emacs-devel, tetapi tidak diterima karena kebijakan GNU yang tidak menerima pekerjaan berbantuan LLM
• Pembuatnya mengungkapkan bahwa GLM 5.2 menemukan isu dan membuat draf, tetapi menyatakan bahwa ia sendiri menangani analisis akurasi dan dampak, perbaikan, pengujian manual, serta tanggung jawab pribadi
• Patch yang ditolak itu cakupannya sempit, hanya 92 baris, dan karena fakta penggunaan LLM sebenarnya bisa saja disembunyikan, ia mengkritik kebijakan tersebut karena membuat pengungkapan yang jujur menjadi merugikan dibanding penggunaan itu sendiri
• Kekhawatiran pihak GNU lebih terkait keterbukaan dan kelayakan hukum penggunaan keluaran LLM, tetapi ia tidak setuju dengan alasan model open-weight dan contoh penggunaan nyata di industri
• Ia mengatakan tidak akan lagi mengerjakan Emacs, dan hanya merilis sebagian patch peningkatan performa yang baru-baru ini ia verifikasi dari sekitar 40 patch yang ada di hard drive-nya

---

Pekerjaan peningkatan performa Emacs di macOS

• Przemysław Alexander Kamiński menghabiskan beberapa bulan untuk meningkatkan performa Emacs di macOS, termasuk meluangkan waktu membuat koneksi instrumentasi dan benchmark
• Ia memberikan codebase Emacs kepada beberapa LLM dan meminta mereka menemukan masalah tertentu, tetapi secara umum hasilnya kurang baik
  • Setelah patch dianalisis, sering kali dampaknya kecil atau masalahnya disalahpahami
• Penilaiannya saat itu tentang bottleneck performa adalah sebagai berikut
  • Di macOS, masalah utama adalah isu rendering dan memory thrashing akibat alokasi dan dealokasi cepat
  • Cara kerja malloc sistem di macOS, karena tidak adanya kompresi memori, menyebabkan pembengkakan memori virtual dan hilangnya lokalitas cache
  • Masalah performa juga masih tersisa di core Emacs
  • Pemrosesan regexp digunakan di banyak tempat, sehingga perbaikannya dapat memengaruhi performa keseluruhan

Patch yang ditemukan dengan GLM 5.2 dan proses pengajuannya

• Ia mendapat paket z.ai Max dari seorang teman sehingga bisa menggunakan GLM 5.2, dan menilai model ini cukup mumpuni untuk optimasi kode
• Berdasarkan pengetahuan yang sudah ia kumpulkan, ia mengajukan pertanyaan spesifik terkait Emacs dan menugaskan GLM 5.2 untuk mencari serta menganalisis isu
• Setelah sekitar 3 jam, ia menerima beberapa laporan, lalu meninjau usulan dan kodenya, menguji dampak tiap item, dan menjalankan benchmark
• Karena merapikan patch untuk diajukan membutuhkan waktu, ia memilih satu item yang paling menjanjikan untuk dikerjakan, lalu mengirimkannya ke mailing list emacs-devel dua hari sebelum menulis artikelnya
• Keesokan harinya ia mengetahui bahwa GNU memiliki kebijakan untuk tidak menerima pekerjaan berbantuan LLM, sehingga patch tersebut tidak diterima

Cakupan penggunaan LLM yang diungkapkan dalam email pengajuan

• Saat mengirim patch ke mailing list, ia mencantumkan fakta penggunaan LLM beserta cakupan peninjauannya sendiri
  • Penemuan isu dan penyusunan draf patch dilakukan oleh GLM 5.2, dan ia menyatakan GLM 5.2 adalah model open-weight dari Tiongkok
  • Ia sendiri menganalisis akurasi dan dampak laporan isu
  • Ia meninjau dan memperbaiki patch
  • Ia menguji patch secara manual
  • Untuk tujuan hukum, ia menyatakan authorship atas kiriman tersebut dan mengatakan siap berargumen bahwa kontribusinya lebih besar daripada LLM
  • Ia menyatakan akan memikul tanggung jawab pribadi penuh atas kiriman itu
• Kiriman tersebut memiliki cakupan implementasi yang sangat sempit dan ukurannya juga kecil
  • Patch yang ia publikasikan berisi 92 baris, dengan alasan keberadaannya tercantum di dalam komentar
• Ia tidak menganggap patch ini bisa diklasifikasikan sebagai “slop”, tetapi menambahkan bahwa orang lain bebas menilainya sendiri

Sanggahan terhadap kebijakan GNU

• Ia menghormati kebijakan GNU, tetapi tidak setuju dengannya dan menilai kebijakan itu tidak memiliki dasar yang memadai
• Ia sebenarnya bisa saja menyembunyikan fakta penggunaan LLM, tetapi memilih mengungkapkannya secara eksplisit, dan menilai akibatnya pengajuan tersebut menjadi dirugikan
  • Karena itu, ia mengkritik kebijakan tersebut sebagai kebijakan yang menghukum pengungkapan yang jujur, bukan penggunaan LLM itu sendiri
  • Karena ia sama sekali tidak memercayai LLM, ia berpandangan bahwa pekerjaan berbantuan LLM membutuhkan lebih banyak peninjauan dan perhatian, bukan lebih sedikit
• Konteks lengkap kebijakan itu dibahas di milis internal GNU sehingga tidak dapat ia ketahui, dan ia merangkum bahwa keraguan yang ia temui dalam percakapan sebelumnya lebih terkait apakah kontribusi LLM cukup terbuka dan apakah dapat digunakan secara legal
• Ia tidak setuju dengan logika yang mempersoalkan keterbukaan model open-weight
  • Misalnya, ia menilai absurd jika penggunaan Qwen 3.6 di lingkungan lokal dianggap boleh, tetapi penggunaan melalui OpenRouter dianggap tidak boleh
  • GLM 5.2 adalah model open-weight, dan ia mengatakan bahwa dengan RAM 256GB dan VRAM 24GB, model itu bisa dijalankan secara lokal untuk menghindari argumen bahwa “SaaS itu tertutup”
  • Ia juga mempertanyakan, karena internet berisi banyak konten tidak bebas, apakah dengan logika yang sama akses internet saat membuat kiriman juga harus dilarang
• Ia juga tidak setuju dengan kekhawatiran hukum
  • Ia mengatakan perusahaan gim lebih sensitif terhadap IP dan LLM tetapi tetap terlihat menggunakan LLM, ChatGPT memiliki 1 miliar pengguna aktif, dan ratusan ribu hingga jutaan organisasi menggunakan keluaran LLM setiap hari
  • Dengan catatan bahwa ia bukan pengacara AS, ia memahami bahwa masalah pendaftaran hak cipta berada pada pihak yang membubuhkan pernyataan hak cipta
  • Ia tidak setuju dengan sikap GNU yang meyakini bahwa pendapat mereka dan pengacara mereka sendiri memiliki bobot paling besar

Berhenti mengerjakan Emacs dan patch yang dirilis

• Ia mengatakan GNU bebas mengambil keputusan sendiri dan ia juga bebas mengkritiknya
• Ia mengkritik cara pembahasan kebijakan secara internal yang tidak transparan bagi pengguna sebagai tidak lebih terbuka daripada cara Meta menentukan arah Facebook secara internal
• Akibatnya, ia menyatakan tidak akan lagi mengerjakan Emacs
  • Ia mengatakan tidak suka berada dalam situasi pekerjaan sukarela di mana ia diberi tahu bahwa ia “memegang tongkat dari ujung yang salah”
• Di hard drive-nya ada sekitar 40 patch peningkatan performa, sebagian saling tumpang tindih dan sebagian lainnya belum terbukti memiliki dampak nyata
• Ia hanya merilis sebagian patch yang baru-baru ini ia verifikasi berfungsi dan menunjukkan dampak bermakna, dan mengatakan patch-patch tersebut benar-benar membuat perbedaan

[GN⁺]

Pendapat di Lobste.rs

• Sepertinya penulis salah paham tentang arti open dalam "open weight"
  Fakta bahwa kumpulan matriks finalnya dipublikasikan dan bisa di-fine-tune sampai tingkat tertentu tidak berarti data pelatihan yang dipakai untuk membuatnya juga open source. OSI seems to agree tampaknya melihatnya dengan cara yang mirip, dan kalau begitu, masalah hak cipta sama sekali belum terselesaikan
  Saya bisa bersimpati dengan orang yang ingin berkontribusi dengan niat baik tanpa imbalan, tetapi GNU sudah menuliskan aturannya dengan jelas, jadi kalau datang ke sana sambil berkata, "Saya cuma sedikit melanggar, dan ini patch-nya," tidak aneh kalau ditolak. Alasan penolakannya bukan kejujuran, melainkan karena melakukan sesuatu yang secara eksplisit dilarang

  • Kalau begitu, apakah driver yang ditulis berdasarkan datasheet yang terikat perjanjian kerahasiaan juga semuanya bukan perangkat lunak bebas? Lalu bagaimana kalau pegawai pabrikan menulis driver dengan memanfaatkan dokumen internal dan pengetahuan ahli?
  • Saya kurang paham kenapa data pelatihan dianggap relevan. Kalau hasilnya bisa dipakai, didistribusikan ulang, dan dimodifikasi secara bebas, menurut saya itu sudah cukup dekat dengan open

• Semoga hari ini penulis belajar bahwa miliaran orang pun bisa salah. Normalization of deviance tidak membenarkan penyimpangan, melainkan hanya menjelaskan bagaimana penyimpangan itu terus menyebar
  Salah satu pola yang terlihat dalam chatbot psychosis adalah menganggap manusia yang tidak setuju atau punya pendapat berbeda sebagai musuh. Narremes yang dipelajari chatbot mencakup sudut pandang bahwa pengguna adalah protagonis, dengan kamera over-the-shoulder dan narasi personal yang mudah dibaca. Narasi preferensi chatbot yang sudah diproses ulang kemudian memengaruhi pengguna secara langsung dengan memperkuat rasa bahwa dirinya tokoh utama, dan ketika pengguna sudah cukup terionisasi, mereka bahkan tidak bisa menerima posisi yang netral
  Dalam kasus ini, saya menyarankan membaca diskusi aslinya, yang tidak ditautkan atau dikutip oleh penulis. Komunitas Emacs bersikap ramah, terbuka, bertanya, menunjukkan minat, dan menerima penulis. Bahkan saat menolak patch, mereka berbicara dengan lembut dan lebih menekankan kebijakan GNU daripada menyalahkan penulis

  • Jujur saja, tidak menaruh tautan ke diskusi yang sebenarnya di artikelnya itu tanda bahaya besar. Sulit dipercaya saya sempat tidak menyadarinya
  • Artikel Wikipedia tentang narremes cuma terdiri dari satu paragraf dan diberi tag [incomprehensible]
    Meski begitu, dari konteksnya saya paham maksudnya, dan di sini itu tampak seperti konsep yang berguna dan cocok

• GNU Project perlu mempertimbangkan kekhawatiran hak cipta di seluruh dunia, bukan cuma masalah hak cipta di AS. Hukum AS sendiri juga belum sepenuhnya jelas
  GNU ingin yakin bahwa mereka memegang 100% hak cipta atas kontribusi penting. Tafsir hukum penulis tidak penting di sini; GNU Project sedang memilih jalan yang aman. Kekhawatiran lain yang mungkin mereka miliki terhadap LLM pun bahkan belum dihitung

  • Jujur saja, kalau melihat preseden hukum saat ini, pemahaman penulis tentang hukum AS juga salah[1]. Berdasarkan preseden yang ada, kode yang dihasilkan LLM tidak bisa mendapat perlindungan hak cipta, sehingga tidak bisa diberi lisensi dan otomatis menjadi domain publik
    Selain itu, jika ada kode hasil LLM di dalam repositori dan kode itu tidak dibedakan atau ditandai dengan jelas, seluruh repositori bisa dianggap tidak dapat dilindungi hak cipta maupun diberi lisensi
    Dengan kata lain, kalau penulis berbohong sehingga kodenya sampai dikomit, efektivitas lisensi seluruh codebase Emacs bisa ikut terancam
    Semua ini terpisah dari sikap congkak yang nyaris delusional seperti "Saya bukan pengacara, tapi para pengacara jelas salah." Ia hanya melihat sebagian pasal hukum terkait, sambil pada saat yang sama menuduh para pengacara arogan
    [1] Ini berdasarkan percakapan saya dengan tim legal perusahaan sekitar dua bulan lalu, jadi setidaknya cukup mutakhir

• Saya kurang yakin bahwa argumen "kalau berbohong pasti diterima" itu benar-benar bermakna

  • Logika yang sama bisa diterapkan ke lisensi juga. Kalau seseorang menyalin sesuatu dari codebase proprietari lalu berbohong bahwa ia menulisnya sendiri, patch itu bisa saja diterima. Tapi kalau jujur, pasti ditolak. Jadi kesimpulannya lisensi itu buruk?
  • Betul. Untuk kebijakan no-LLM, saya sering mendengar argumen, "Kalau begitu orang-orang tinggal bohong saja"
    Bukankah itu sama sekali bukan hal yang baik untuk dikatakan tentang orang-orang tersebut?
    Menurut saya juga tidak ada gunanya menyusahkan para maintainer hanya karena kebijakan pro atau kontra LLM. Mereka sedang bekerja, dan mereka berhak memilih kontribusi mana yang akan dievaluasi, diterima, atau ditolak
    Tentu saja mengeluh tidak masalah. Orang ini sedang menyatakan posisinya di blog, dan begitulah diskusi dibingkai. Hanya saja saya tidak setuju dengan framing-nya. Masalahnya di sini bukan "kejujuran". Jika kebijakan no-LLM sudah diumumkan, maka tanggung jawab atas waktu yang dihabiskan untuk mencoba berkontribusi ke proyek yang memang tidak menginginkan kontribusi berbantuan LLM ada pada dirinya sendiri
    Ini tidak berbeda dari memberi makanan berisi daging atau keju kepada seorang vegan, lalu mengeluh karena mereka tidak mau memakannya setelah Anda "jujur" menyebut bahan-bahannya. "Kalau saya tidak bilang, mereka tidak akan tahu ada produk susu di dalamnya" tidak terdengar baik, dan "kalau saya tidak bilang, mereka tidak akan tahu saya memakai LLM" juga sama saja
  • Setuju. Saya mengusulkan judul baru: Vibecoding gets Emacs patch rejected. Kejujuran dalam mengakui vibe coding mirip dengan kejujuran dalam mengakui pelanggaran hak cipta. Akar penolakannya bukanlah kejujuran
  • Menurut saya, memakai LLM dan mengungkapkannya dengan jujur memang cukup menjadi alasan patch ditolak. Memakai LLM lalu berbohong bukan hanya alasan untuk menolak patch, tetapi juga alasan untuk melarang upaya kontribusi berikutnya

• GNU dan FSF berinvestasi cukup besar untuk mendapatkan nasihat hukum profesional. Namun calon kontributor ini pada dasarnya menyarankan agar mereka mengabaikan nasihat profesional itu berdasarkan omongan seseorang di internet
  Jika sudah membayar nasihat profesional, masuk akal untuk mengikutinya, dan jika tidak setuju, seharusnya mencari profesional lain. Mengabaikannya karena saran komentator internet acak bukan "hampir satir", melainkan sekadar bodoh

  • Berkontribusi ke sebuah proyek berarti membuka diri dan menempatkan diri pada posisi yang rentan. Terutama jika "kodenya berfungsi" dan menyelesaikan ketidaknyamanan pribadi, penolakan bisa terasa lebih sulit
    Terlepas dari penolakan ini, sepertinya ke depan akan muncul beberapa kasus pengadilan yang cukup menarik. Penyedia model besar bisa saja menawarkan bentuk indemnifikasi tertentu dan berkata "itu adalah kode yang kami bantu buat, jadi Anda bebas mengklaim hak cipta sesuka Anda", atau sebaliknya mendorong persoalan ini dan menyatakan bahwa merekalah pemiliknya dan lisensi diperlukan untuk penggunaan tertentu. Claude saat ini memang memberikan kode itu kepada pengguna, tetapi saya tidak tahu indemnifikasi apa yang mereka berikan. Untuk model lain juga saya kurang tahu

• Tahukah Anda bahwa kejahatan itu ilegal hanya kalau ketahuan

• Saya sama sekali bukan penggemar fanatik GNU, tetapi bukankah alat coding LLM berada di sisi yang sepenuhnya berlawanan dengan filosofi GNU? Rasanya seperti membawa anjing ke kafe kucing lalu marah karena diusir

• Menurut saya, mengubah judul dari "Honesty gets Emacs patch rejected" menjadi Vibecoding gets Emacs patch rejected itu sangat tidak jujur
  Meski penulis seperti menerima bantuan dari alat AI, jika ia benar-benar mencurahkan waktu dan pemahaman sebanyak itu pada kodenya, itu jelas bukan vibe coding. Kalau ia hanya melempar "buat Emacs lebih cepat" ke AI lalu mengirim hasilnya tanpa meninjau, itu baru vibe coding, tetapi dari tulisannya jelas bukan itu yang terjadi

  • Judul "honesty" juga tidak jujur. Patch itu ditolak bukan karena kejujuran, melainkan karena pelanggaran kebijakan
  • Saya setuju dengan penafsiran tentang istilah "vibe coding", tetapi melihat betapa beragamnya orang memakai istilah itu, saya tidak menganggapnya sampai sebegitu tidak jujur
    Kalau saya, mungkin akan memilih judul seperti "Breaking contribution policy gets Emacs patch rejected". Tetap bernada menyindir, tetapi lebih sulit untuk dibantah

• Yang menonjol di sini adalah penulis mengklaim telah mengerjakannya secara konsisten selama dua bulan, sambil menjelaskan bahwa model yang dipakai untuk menemukan dan menyelesaikan masalah itu dirilis 12 hari lalu
  Saya paham penulis cukup marah, tetapi pada akhirnya open source menurut saya bukan memberi hak tertentu, melainkan lebih seperti hak istimewa untuk memakai kode yang sudah dibuat. Kalau memang ada manfaatnya, mungkin ada, dan hal yang ia tulis tentang macOS pada umumnya benar, jadi mungkin pengembang Emacs akan meluangkan waktu untuk meninjaunya. Hanya saja, sepertinya macOS bukan fokus utama mereka

• Ada solusi mudah untuk membuktikan betapa bodohnya kebijakan ini. Tampilkan diff PR berbantuan LLM di monitor kedua, lalu tulis ulang perubahan itu dengan tangan dari awal di monitor utama. Ganti juga nama variabel dan isi komentar sedikit
  Sekarang itu menjadi kode yang ditulis manusia, jadi bisa di-merge

  • Melihat isu hak cipta dan persoalan hukum seputar keluaran LLM di berbagai yurisdiksi dunia, itu pandangan yang sangat naif