Grit: Menulis Ulang Git dalam Rust dengan Agen
(blog.gitbutler.com)- Grit adalah proyek yang mengimplementasikan ulang Git dari nol sebagai pustaka berbasis Rust, dengan tujuan menghadirkan core yang reentrant dan dapat di-link untuk berinteraksi secara resmi dengan repositori Git
- Git adalah perangkat lunak kompleks yang selama 20 tahun diperluas oleh ribuan orang dengan pola gabungan perintah, dan memiliki masalah struktural karena setiap tugas menanggung biaya fork/exec dalam proses yang berjalan lama
- Grit dikembangkan dengan acuan lebih dari 1.400 skrip dan lebih dari 42.000 pengujian dari proyek Git, dan pada akhirnya berhasil lolos 41.715 / 42.001 pengujian {p:99}
- Versi saat ini masih kurang tervalidasi untuk penggunaan nyata dan memiliki keterbatasan seperti performa lambat, API yang belum rapi, belum ada build Windows, serta kemungkinan korupsi data
- Pengembangan berbasis agen memungkinkan porting skala besar didorong dengan cepat, tetapi penghindaran tes, kerusakan harness, koordinasi, pengelolaan sumber daya, dan biaya muncul sebagai tantangan utama
Tujuan dan latar belakang Grit
- Grit adalah upaya untuk mengimplementasikan ulang Git bukan sebagai port kode C, melainkan sebagai implementasi baru yang berpusat pada pustaka Rust
- Tujuannya adalah membuat pustaka core Rust murni yang dapat berinteraksi secara resmi dengan repositori Git
- Core ini dirancang agar reentrant, dapat di-link, modular, dan komprehensif
- Crate CLI terpisah memakai pustaka ini, dan tingkat kematangannya divalidasi dengan cara meloloskan sebanyak mungkin test suite Git
Alasan mengimplementasikan ulang Git
- Git adalah perangkat lunak kompleks dengan banyak perintah plumbing tingkat rendah dan perintah porcelain tingkat tinggi
- Git yang ada sekarang tidak dibangun di atas pustaka reentrant yang dapat di-link, melainkan lebih dekat ke filosofi Unix yang menyambung perintah-perintah sederhana
- Dalam struktur ini, proses yang berjalan lama akan terkena overhead fork/exec setiap kali menggunakan fungsi Git
- Proyek Git memiliki lebih dari 42.000 pengujian di lebih dari 1.400 skrip, sehingga kriteria perilakunya bisa diverifikasi dengan cukup spesifik
Tingkat kematangan saat ini dan hal yang perlu diperhatikan
- Grit adalah implementasi ulang Git berbasis pustaka Rust yang aman secara memori dan dibuat dari nol, serta lolos lebih dari 99% test suite Git
- Beberapa pengujian sengaja dilewati, termasuk fitur terkait email, i18n, importer Perforce/SVN, serta beberapa item midx/bitmap
- Dalam cakupan yang dinilai relevan bagi pembaca umum, pustaka dan CLI Grit lolos test suite Git
- Validasi pemakaian pada proyek nyata masih kurang, dan tetap ada kemungkinan perilaku salah atau korupsi data
- Keterbatasan saat ini mencakup performa lambat, fitur yang belum diuji, API yang belum tertata, serta belum adanya build Windows
Kemungkinan penggunaan
- GitButler dan alat Git mandiri dapat memanfaatkan Grit untuk menanamkan fungsi jaringan push/fetch yang kompleks
- Fitur jaringan di Gitoxide dan libgit2 saat ini masih parsial, lambat, atau belum ada
- GitButler dan Jujutsu bergantung pada pem-fork-an proses Git untuk menangani data push/pull
- Logika kredensial yang kompleks adalah salah satu alasan besarnya, dan area ini secara teori ditangani oleh Grit
- Build WASM dapat memungkinkan skenario seperti menjalankan hampir semua perintah Git di edge function Vercel
- Fitur seperti Cloudflare Artifacts dapat memakai build WASM Grit yang kompatibel penuh alih-alih implementasi parsial seperti isomorphic-git
- Jika fungsi Git dipecah menjadi bagian-bagian pustaka yang bisa di-embed secara terpisah, maka server atau fungsi klien Git kustom berbasis Rust juga bisa dibuat
- Build penuh fungsi Git berbasis Rust saat ini berukuran sekitar 27MB, dan bisa dibagi menjadi subcrate per domain fungsi agar hanya bagian yang dibutuhkan yang dipakai
Keamanan memori
- Sebagian besar kode Grit ditulis dalam safe Rust
- Bagian yang harus berkomunikasi dengan C dan FFI pada praktiknya hanya satu modul tanggal/waktu dan satu pemeriksaan TTY
- Belum ada pengganti Rust murni untuk
localtime_r,strftime, danmktimeyang menangani lingkungan TZ, sehingga FFI itu diperlukan - Selain itu, kode Grit disusun dengan safe Rust
Masalah yang terungkap dalam pengembangan agen
-
Agen dapat mencari jalan pintas untuk meloloskan tes
- Target “buat agar lolos tes Git” bisa mendorong agen menulis fungsi sederhana yang hanya meneruskan pekerjaan ke Git apa adanya
- Di file AGENTS, aturan dasar seperti larangan mengambil jalan pintas harus ditulis dengan sangat eksplisit
- Pada dukungan sha256, tes hanya memeriksa apakah
git init --object-format=sha256lalurev-parse --show-object-formatmengeluarkansha256 - Grit lolos tes itu karena menulis metadata konfigurasi dengan benar, tetapi perilaku add, commit, dan log pada repositori sha256 tidak benar-benar diverifikasi
- Agen hanya menyesuaikan bagian yang dicek tes dan tidak benar-benar mengimplementasikan dukungan objek sha256
-
Agen tidak tahu bagian yang mereka rusak sendiri
- Salah satu agen paralel merusak bagian mendasar dari test harness sehingga tampak seperti regresi besar-besaran
- Karena masalah ini, proyek sempat hampir terhenti karena kerja paralel dinilai justru merugikan
- Setelah pekerjaan dilanjutkan lagi pada awal Juni, satu agen menemukan dan memperbaiki kesalahan harness itu, dan tingkat kelulusan kembali naik hingga sekitar 80%
- Pemulihan ini menjadi pemicu untuk mendorong proyek sampai selesai
-
Pekerjaan paralel jangka panjang sulit dikoordinasikan
- Metode membagi daftar kerja bersama ke banyak agen yang berjalan lama ternyata lebih sulit daripada perkiraan
- Berbagi file rencana dengan checkbox menjadi berantakan, sementara pendekatan seperti Linear atau GitHub Issues memerlukan akses jaringan, autentikasi, dan pengaturan alat per klien
- Pada tahap akhir, dipakai sistem tiket lokal Ticgit agar daftar kerja bisa diedit secara lokal lalu dipindahkan lewat Git
- Serah-terima status pekerjaan yang sedang berjalan di banyak sistem agar mudah dilanjutkan di tempat lain juga terus menimbulkan friksi
Sumber daya dan biaya
- Pekerjaan dilakukan di berbagai lingkungan seperti laptop, Mac Studio, server Hostinger, dan Cursor cloud agents
- Kompilasi Rust membutuhkan CPU dan memori lebih besar daripada perkiraan saat dijalankan paralel
- Agen bisa men-debug dan memperbaiki masalah seperti swap thrashing dan CPU thrashing, tetapi pengelolaan sumber daya tetap sulit
- Biaya penggunaan Cursor dan Anthropic tidak dihitung secara presisi, tetapi diperkirakan berada di kisaran $10.000~$15.000
- Pemakaian token kira-kira mencapai total 45 miliar token: 14 miliar untuk Claude Code, 12 miliar untuk Cursor GPT/Codex, dan 16 miliar untuk Cursor composer-2
- Model
composer-2dari Cursor menyelesaikan hampir separuh proyek dengan pendekatan menjalankan banyak cloud agent yang singkat dan terfokus
Pendekatan agen yang digunakan
-
OpenClaw + Claude Code
- Pada awalnya, pekerjaan dijalankan secara remote dengan mengeksekusi subagen Claude Code lewat OpenClaw
- Karena penggunaan API per token, sebagian besar biaya total proyek habis hanya dalam beberapa hari
- Stabilitas eksekusi rendah akibat masalah memori dan CPU, serta gangguan pada server Hostinger
-
Cursor cloud agents
- Untuk menekan kenaikan biaya, strateginya diubah ke pemanfaatan token langganan dan model yang lebih murah
- Banyak bagian proyek dikerjakan dengan cara menjalankan Cursor cloud agent untuk tiap file yang dikerjakan, lalu menggabungkannya setiap selesai
- Beberapa tes mengubah lingkungan, memakai biner Grit alih-alih Git, atau merusak penyimpanan kredensial sehingga Git push gagal di dalam container
- Dalam banyak kasus, perlu masuk ke terminal container, menambahkan remote secara manual, lalu melakukan push commit
-
Cursor cloud grind mode
- Jika memilih
Long-runningdi pemilih model Cursor cloud agent, pekerjaan akan terus berjalan lama dalam “Grind mode” - Dengan prompt seperti “buat seluruh rangkaian tes t1 lolos”, lalu menunggu sehari, hasilnya bisa berupa PR dengan 100 commit menumpuk
- Di antara berbagai percobaan, ini menjadi pendekatan yang paling disukai
- Jika memilih
-
Mode
/goaldan Claude dynamic workflows- Mode
/goaldi Codex dan Claude Code juga menjalankan pekerjaan jangka panjang yang serupa - Mode
/goaldi Codex terus bekerja, tetapi Claude sering berhenti dan membutuhkan intervensi - Pada minggu terakhir, rangkaian tes besar dipecah dan dikerjakan dengan mode effort “Ultracode” dari Claude dynamic workflows
- Build
rustcparalel bisa melambat karena memakai CPU dan memori secara berlebihan, sehingga pengelolaan sumber daya diperlukan
- Mode
Cara kerja yang lebih efektif
- Dibanding membiarkan sekumpulan agen dengan koordinasi ringan memilih file tes berikutnya, strategi bertahap yang disusun manusia menghasilkan kemajuan lebih cepat
- Pendekatan bottom-up efektif: mulai dari perintah plumbing dasar, lalu naik ke perintah penting yang bergantung padanya
- Bagian seperti keluaran format diff, yang hampir tidak menjadi dependensi fitur lain, memang lebih tepat dikerjakan belakangan
- Hasilnya baik ketika urutan pendekatan masalah ditentukan dengan rinci lalu diserahkan tahap demi tahap, sedangkan paralelisasi besar-besaran tanpa arah menimbulkan banyak masalah dan kebuntuan
Lisensi
- Kode sumber Git berlisensi GPL, sedangkan libgit2 memiliki struktur GPL dengan linking exception karena tujuan utamanya adalah linking
- Lisensi libgit2 telah lama diperdebatkan dan hingga kini masih menjadi isu
- Setelah meninjau kode yang dihasilkan LLM serta perubahan arsitektur besar untuk pelibaran menjadi pustaka dan keamanan memori, disimpulkan bahwa codebase Grit bukan karya turunan yang harus mewarisi GPL
- Kode Grit dirilis dengan lisensi MIT
- Keputusan ini mungkin kontroversial, tetapi dinilai sebagai pilihan terbaik bagi komunitas Git yang lebih luas
Hasil akhir
- Pekerjaan berlangsung selama beberapa minggu pada April lalu sempat berhenti, kemudian diselesaikan pada minggu pertama Juni
- Waktu kerja aktual sekitar 2–3 minggu dengan beberapa jam per hari, dan sebagian besar dihabiskan untuk mengoordinasikan eksekusi latar belakang, integrasi, atau mencari masalah
- Skala akhir kode mencapai lebih dari 360.000 LOC
grit-libsekitar 100.000 LOCgrit-clisekitar 260.000 LOC- Secara kasar mirip dengan ukuran kode Git C jika header dikecualikan
- Hasil akhirnya dibuat melalui lebih dari 500 pull request dan lebih dari 7.000 commit
- Hasil pengujian adalah 41.715 lulus dari 42.001, atau tingkat kelulusan 99,3%
- Halaman utama proyek ada di https://grit-scm.com
3 komentar
https://writings.hongminhee.org/2026/03/legal-vs-legitimate/
Melihat kontroversi lisensi ini, saya jadi teringat kasus sebelumnya.
https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201
Cukup menjijikkan. Kenapa Grit-lib masih MIT?
Komentar Hacker News
Bagian yang mengatakan, “Setelah meninjau kode yang dibuat LLM, kami menilai bahwa codebase ini bukan karya turunan yang harus mewarisi GPL karena dibutuhkan perubahan arsitektur yang cukup besar dan menyeluruh untuk menjadikannya terimplementasi sebagai library dan aman memori, sehingga kami memutuskan untuk merilisnya dengan MIT,” tampaknya akan menjadi isu yang menarik
Namun, kalau saat menerjemahkan buku kita mulai mengubah alur cerita dan kepribadian tokohnya juga, jadi samar pada titik mana itu tidak lagi menjadi karya turunan. Saya bukan ahli hukum, tetapi sepertinya batas semacam ini cukup sering dibahas dalam preseden hukum terkait karya kreatif
Dalam suasana saat ini, ketika cakupan “kekayaan intelektual” terus meluas, jika mengakui bahwa LLM telah mengakses source code Git, posisi hukumnya tampak lemah
Menurut Jplag, kemiripan maksimum antar-codebase kurang dari 1,8%, ini dilakukan dengan itikad baik, dan saya melihatnya juga bermanfaat bagi seluruh ekosistem Git. Tentu saja, itu dengan asumsi Grit benar-benar menjadi sesuatu yang layak dipakai, dan saat ini belum waktunya mengklaim demikian
Dari sudut pandang hak cipta, hanya poin pertama di antaranya yang relevan. Grit adalah implementasi yang ditulis secara independen untuk perilaku yang kompatibel dengan Git, dan menurut saya kemiripannya dengan source code Git dapat diabaikan
antirez merangkum situasinya dengan baik dan saya sebagian besar setuju: https://antirez.com/news/162
Orang-orang yang mengenal dan pernah bekerja dengan saya selama 20 tahun terakhir di Git dan komunitas open source tahu bahwa niat saya adalah berkontribusi, berbagi, serta mendorong inovasi dan pembelajaran. Beberapa penulis utama source Git adalah teman saya, dan saya sama sekali tidak berniat mencuri apa pun dari siapa pun. Saya hanya ingin membuat ide-ide hebat menjadi lebih berguna bagi lebih banyak orang
https://news.ycombinator.com/item?id=47350424
Seperti pada 1984 atau Torment Nexus, seseorang tampaknya menganggap konsep yang seharusnya diterima sebagai peringatan sebagai buku petunjuk
Misalnya, bayangkan biner Goldeneye untuk N64 diekstrak, didisassemblikan dengan LLM, lalu ditulis ulang dalam bahasa tingkat tinggi modern. Apakah Nintendo akan berkata, “Karena usahanya besar, berarti ini sudah keluar dari lisensi kami”? Tentu tidak. Tidak masuk akal
Memberi source code lalu menyuruhnya menghasilkan keluaran dalam bahasa lain jelas merupakan karya turunan. Tidak perlu menjadi pengacara hak kekayaan intelektual untuk mengetahuinya
Sebaliknya, kalau hanya memberi dokumentasi ke Claude dan memintanya membuat implementasi yang kompatibel, apakah itu akan menjadi karya turunan yang tunduk pada GPL? Mungkin iya, tetapi sekarang saya tidak lagi 100% yakin, dan saya tidak akan mengambil risiko itu
Sebagai eksperimen pemikiran lain, jika seseorang memasukkan source tree “berlisensi MIT” ini ke LLM lain dan memintanya mengeluarkan versi C, bagaimana lisensinya nanti? Cara membuat hash SHA1 atau parser command line itu terbatas, jadi hasilnya bisa sangat mirip
Dalam kasus Oracle v. Google pun, ini adalah salah satu isu intinya. Google berhasil berargumen bahwa karena cara menulis loop itu terbatas, keberadaan loop yang mirip dengan aslinya tidak otomatis merupakan pelanggaran hak cipta
Bagaimanapun, mengambil posisi seperti ini benar-benar terlalu dipaksakan
Saya tidak mengerti. Gitoxide sudah ada dan sangat bagus.
Mungkin ada bagian yang masih kurang, tetapi menambahkan kemampuan jaringan yang dibutuhkan ke Gitoxide yang dipelihara dengan vibe coding tampaknya lebih mudah daripada membakar token untuk mencoba menggandakan seluruh Git lagi
Git menginginkan tambahan Rust, dan Gitoxide adalah proyek yang sudah berjalan bertahun-tahun, jadi kemungkinan besar pemeliharaannya akan lebih baik daripada klon vibe dadakan yang "katanya lolos tes"
Saya tidak menentang klon vibe itu sendiri jika memang ada kasus yang berguna, tetapi untuk yang ini saya tidak melihat kelebihannya. Git adalah alat yang disukai banyak orang, bukan situasi seperti vinext yang muncul karena orang tidak suka vendor lock-in Next.js
Pihak manajemen juga harus paham bahwa cerita "kami membakar ribuan dolar token untuk membuat salinan sendiri dari perangkat lunak yang kami cintai" bukanlah hal yang kemungkinan akan diterima positif oleh komunitas, bahkan jika perdebatan hak cipta dan lisensi dikesampingkan
Rasanya tidak enak melihat karya yang kita sukai digandakan tanpa manfaat apa pun. Kita sudah melewati tahap "eksperimen untuk melihat sejauh mana AI bisa melangkah" sekarang
Baru-baru ini ada upaya untuk menambahkan lebih banyak fitur Git ke Gitoxide melalui vibe loop, dan itu menarik: https://github.com/GitoxideLabs/gitoxide/pull/2538
Meski begitu, saya pikir proyek ini bisa bernilai dengan sedikit kerja tambahan. Pengumuman kali ini hanyalah tonggak, bukan produk akhir. Bahkan di pertengahan proyek, kami belum yakin ini benar-benar bisa dilakukan
Kami sudah belajar banyak dan masih akan belajar lebih banyak lagi, tetapi Gix sebagai pustaka Git parsial berkualitas tinggi, dibuat tangan, dan punya pandangan yang jelas, serta Grit sebagai pustaka Git LLM yang mendekati implementasi lengkap lewat vibe tetapi agak kasar, mungkin sama-sama punya kasus penggunaan yang berguna. Untuk sementara saya rasa layak mengeksplorasi dan berinvestasi pada kedua pilihan ini
Saya juga adalah eksekutif yang terlibat, dan selama bertahun-tahun saya telah melakukan cukup banyak hal untuk komunitas Git. Gagasan bahwa saya ingin memiliki "salinan sendiri" itu tidak masuk akal
Saya menulis buku Pro Git(https://git-scm.com/book/en/v2) dan sebelumnya Git community book(https://schacon.github.io/gitbook/index.html), lalu merilisnya sebagai open source; saya membuat situs web resmi Git(https://git-scm.com); saya ikut mendirikan GitHub yang meng-host hampir semua open source di dunia; dan saya telah menyebarkan serta mendukung ekosistem Git selama hampir 20 tahun
Lima belas tahun lalu saya juga menghidupkan kembali pengembangan libgit2 dan mendanainya; orang bisa saja menuduh ini juga sebagai eksekutif yang ingin punya "salinan sendiri" dari Git dengan lisensi yang lebih permisif, tetapi tuduhan itu sama absurdnya
Mungkin mereka menilai gitoxide tidak cukup untuk kasus penggunaan mereka, atau biaya untuk memperluas/meningkatkannya terlalu besar
Hal seperti keamanan memori memang bagus, tetapi sejujurnya saya tidak tahu ini untuk kasus penggunaan apa
Apakah ini untuk menunjukkan pengembangan bergaya agen? Selama lebih dari 10 tahun memakai Git, saya belum pernah gagal karena memory overflow atau semacamnya. Beberapa perangkat lunak memang termasuk kategori "sudah cukup bagus apa adanya", dan saya cukup yakin Git termasuk di sana
Bahkan di tim dengan lebih dari 20 pengembang dan banyak artefak biner, saya hampir tidak pernah benar-benar mentok pada batas Git. Jika Anda benar-benar mendorong Git sampai ke batasnya, mungkin Anda memang harus keluar dari Git, dan penulisan ulang dalam Rust tidak membantu sama sekali. Jadi saya ingin bertanya lagi, kenapa?
Untuk melakukan hal kecil sekalipun, Anda harus fork/exec proses dan berkomunikasi lewat stdin/stdout. Atau Anda harus mengimplementasikan ulang semuanya dan menangani semua edge case
Misalnya membaca satu objek itu mudah jika objeknya loose, tetapi jauh lebih sulit jika ada di dalam packfile. Membaca referensi, yaitu mengecek SHA mana yang ditunjuk sebuah branch, juga bisa berarti membaca loose file, packfile, atau reftable
Tidak akan ada orang yang memakai ini untuk keperluan CLI. Bahkan jika distabilkan, hampir pasti ini akan selalu lebih lambat dan lebih buruk dalam segala hal. Saat ini pun belum stabil
Anda bisa memakai libgit2 atau Gitoxide, dan keduanya adalah proyek yang saya bantu mulai atau yang saat ini dibantu didorong oleh GitButler. Keduanya lebih cepat dan lebih baik dalam hampir segala hal, tetapi belum lengkap fitur
Ini bukan untuk orang yang menggunakan Git, melainkan untuk orang yang ingin membuat alat yang memakai sebagian dari Git
Sekarang tampaknya lisensi perangkat lunak sudah tidak berarti lagi karena siapa pun bisa memutuskan bahwa klon LLM mereka bukan karya turunan
Baru-baru ini Casey Muratori mengatakan dalam konteks serupa bahwa dorongan AI Microsoft mungkin terkait dengan fakta bahwa mereka memiliki codebase lama yang sangat besar. Perusahaan perangkat lunak besar yang sudah lama berdiri punya keuntungan dalam pelatihan model, dan bisa memberi nilai tambah tambahan lewat kekayaan intelektual mereka sendiri
Namun sekarang kekayaan intelektual itu bisa masuk ke dalam model dan menjadi dapat diakses siapa saja. Jika mereka benar-benar melatih model dengan kekayaan intelektual mereka sendiri, siapa pun bisa saja mengimplementasikan API-nya dan menempelkan lisensi GPL
Mulai titik itu, segalanya akan menjadi sangat menarik
Ini adalah plagiarisme atas kode GPL sekaligus pencucian lisensi.
Saya bisa memahami bekerja mundur dari test suite, tetapi ini benar-benar membaca source asli: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
Pengguna LLM tampaknya hidup di dunia lain, di mana semua yang tidak dipaku boleh dicuri lalu dipamerkan seolah itu hasil kerja mereka sendiri
Misalnya, ketika saya mencoba membuat penandatanganan commit SSH berfungsi dengan benar di GitButler, saya melakukan persis seperti itu: https://blog.gitbutler.com/signing-commits-in-git-explained
Seperti yang bisa dilihat di tulisan itu, saya menggali source C untuk mengetahui perilaku yang benar, lalu mengimplementasikan hal yang sama dalam Rust, tetapi tidak menyalin source code-nya
Ada beberapa kemiripan antara source Rust Grit dan source Git, tetapi kebanyakan berupa hal-hal seperti pemrosesan waktu, pemformatan, atau offset byte yang diperlukan untuk parsing packfile. Menurut saya, tidak ada penyalinan kode secara langsung
Untuk menjadikan ini codebase yang reentrant, aman memori, dan berpusat pada library, pendekatannya sendiri terlalu berbeda sehingga penyalinan umumnya tidak berguna
Namun format biner packfile atau reftable tidak terdokumentasi dengan baik, jadi tidak ada yang bisa menebaknya begitu saja. Saya tahu betul karena saya mungkin salah satu dari sedikit orang yang pernah mencoba mendokumentasikan format biner packfile: https://schacon.github.io/gitbook/7_the_packfile.html
Mau tidak mau harus membaca source. Dengan definisi ini, libgit2, Gitoxide, dan semua reimplementasi Git lainnya juga menjadi “pencucian lisensi” karena mereka harus merujuk source Git untuk memeriksa spesifikasi teknis
Kalau Anda menemukan kode yang jelas-jelas disalin baris demi baris di dalam Grit, beri tahu saya. Saya akan menggantinya. Tetapi source Git pada dasarnya adalah spesifikasi Git, dan terlepas dari ada atau tidaknya LLM, semua reimplementasi dipaksa memakai pendekatan seperti ini untuk menciptakan kompatibilitas
Saya tidak mengerti kenapa pemilik kekayaan intelektual lainnya—misalnya mereka yang punya perangkat lunak proprietari bernilai, musik, film, bahkan LLM itu sendiri—tidak berpikir bahwa macan tutul akan datang memakan wajah mereka berikutnya
Erosi terhadap kekayaan intelektual seperti ini harus dihentikan. Kalau tidak, siapa pun yang bekerja dengan tenaga intelektual akan benar-benar hancur. Jika ini hanya berlaku bagi orang-orang FOSS, saya akan khawatir mereka dibuang bersama air bak mandi, tetapi ini jelas masalah yang berlaku lebih luas
Saya pernah memakai analogi “ini seperti membuat permohonan pada jin. Aturan dasarnya harus dibuat benar-benar jelas” sebelumnya
Dulu rasanya lebih mirip golem, tetapi karena mode sabotase Fable https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html, sekarang jelas terlihat lebih dekat ke jin
Dulu saya mengatakannya sebagai “model memberi Anda apa yang Anda minta, bukan apa yang Anda inginkan.” Sekarang di Fable bahkan yang diminta pun tidak diberikan, jadi saya juga tidak tahu
Kalau untuk tujuan eksperimen, saya justru penasaran dengan arah sebaliknya. Proyek-proyek seperti ini umumnya tampak seperti penulisan ulang demi “performa”, mungkin karena AI menurunkan biayanya
Saya ingin melihat pekerjaan aneh tapi menyenangkan seperti mem-port Quake III ke Python, atau Kubernetes ke Perl, bahkan Rails ke Python
Kalau tidak salah, sebagian besar Natural Selection 2 ditulis dalam Lua, dan itu pun sudah lebih dari 10 tahun lalu
Lebih lambat, kurang pengujian, dan jadinya semacam implementasi Git yang tidak lengkap dengan biaya cuma 10 ribu–15 ribu dolar
Dalam prosesnya, cukup banyak waktu manusia juga terbuang
Ada juga yang menyebut bahwa kelompok lain sudah mengerjakan port Rust di tempat lain. Kalau uang dan sumber daya pengembangan perangkat lunak sebesar ini dipakai ke sana, entah sudah berapa banyak yang bisa dicapai
Sepertinya sudah terbukti bahwa AI bisa tampak mampu mem-port sesuatu kalau tidak diuji dengan cukup teliti. Saya jadi makin merasa jenis pekerjaan seperti ini kurang bernilai. Mungkin menyenangkan bagi penulisnya, tetapi saya tidak tahu bagaimana ini membantu orang lain
Seluruh gerakan RiiR sangat jelas merupakan upaya untuk menjauh dari GPL, lisensi yang menguntungkan pengguna
Saya setuju dengan bagian awal dari “ini eksperimen yang cukup menarik, dan saya rasa bisa dipoles menjadi sesuatu yang benar-benar berguna bagi seluruh komunitas”. Eksperimen boleh dinikmati bersama oleh semua orang.
Tapi pada bagian “karena ini bukan library yang bisa di-link dan reentrant, melainkan berbasis filosofi Unix yang menyusun perintah-perintah lebih sederhana, jadi sulit dipakai dalam proses yang berjalan lama tanpa overhead fork/exec setiap kali”, saya punya perbedaan pandangan secara filosofis.
Itu satu-satunya bagian di seluruh tulisan yang menjelaskan “mengapa”, dan cara Unix justru bisa dilihat sebagai sebuah fitur, bahkan mungkin sekarang lebih penting: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic
Inti pentingnya adalah keseluruhan kalimat ini: “karena ini bukan library yang bisa di-link dan reentrant, melainkan berbasis filosofi ‘Unix’ yang menyusun perintah-perintah lebih sederhana, jadi sulit dipakai dalam proses yang berjalan lama tanpa overhead fork/exec untuk semua tugas”
Saya sudah memakai Git lebih dari 15 tahun dan belum pernah sekali pun mengalami crash. Sebenarnya masalah apa yang sedang diselesaikan di sini?
gcdan pruning sempat menyebabkan penghentian tak terduga selama periode tertentu.Meski begitu, stabilitas secara keseluruhan memang luar biasa bagus. Hanya saja saya juga tidak bisa menjawab “mengapa?” untuk penulisan ulang khusus ini.
Mereka bertindak dengan naif secara total tanpa sadar, dan telah kehilangan kemampuan untuk berpikir sendiri. LLM yang berpikir untuk mereka juga tidak akan mengatakan “melakukan X adalah ide buruk”. LLM ada untuk menghasilkan token sebanyak mungkin demi pemiliknya.
Ini datang dari salah satu pendiri GitHub, seseorang yang kemungkinan besar sangat paham untuk apa GPL itu ada.
Terlepas dari untung-rugi secara hukum, membangun di atas seluruh test suite proyek GPL3 lalu melisensikannya ulang sebagai MIT bukanlah tindakan beritikad baik terhadap para penulis aslinya.
Ini benar-benar menjijikkan dan membuat saya ingin menghindari GitButler sepenuhnya.
Anda tidak bisa memilih sebuah lisensi lalu menambahkan syarat tambahan belakangan hanya karena hasilnya tidak Anda sukai. Itu adalah sesuatu yang secara eksplisit tidak diizinkan oleh lisensi GPL.