- Alat AI awal 2025 diuji melalui eksperimen terkontrol acak untuk melihat dampaknya terhadap produktivitas nyata pengembang open source
- Hasil penelitian menunjukkan, dengan menggunakan alat AI, waktu penyelesaian tugas rata-rata justru 19% lebih lama
- Para pengembang memperkirakan AI akan membuat mereka 24% lebih cepat, tetapi berbeda dari persepsi mereka, justru terjadi perlambatan
- Kesenjangan antara kemampuan AI yang terlihat dalam benchmark dan pengalaman sehari-hari dengan efek nyatanya sangat mencolok
- Studi ini menekankan pentingnya memahami dampak produktivitas AI secara akurat dan menggunakan beragam metode evaluasi
Gambaran umum
- Studi ini melakukan eksperimen terkontrol acak (RCT) untuk memeriksa dampak alat AI awal 2025 (Early-2025) terhadap produktivitas pengembang open source berpengalaman
- Bertolak belakang dengan perkiraan, ditemukan bahwa pengembang membutuhkan waktu 19% lebih lama saat menggunakan alat AI
- Hasil ini dapat ditafsirkan sebagai salah satu contoh pengukuran dampak nyata otomatisasi riset AI terhadap pengembangan perangkat lunak
- Berdasarkan metodologi ini, peneliti menyatakan rencana untuk terus memperkirakan dampak realistis dari percepatan R&D AI
Motivasi penelitian
- Benchmark coding/agent yang ada memiliki keterbatasan karena tidak cukup merefleksikan situasi kerja nyata
- Karena struktur seperti pengujian mandiri, tugas sekali jalan tanpa konteks, dan penilaian otomatis, benchmark dapat melebih-lebihkan kemampuan AI
- Sebaliknya, bila tidak ada intervensi adaptif dari manusia, ada kemungkinan kinerja aktual model AI justru diremehkan
- Untuk melengkapi keterbatasan ini, studi mengukur dampak realistis AI dengan menguji pengaruhnya terhadap produktivitas nyata pengembang open source
Metode eksperimen
- 16 pengembang veteran open source direkrut, lalu dipilih 246 issue nyata dari repositori besar yang telah mereka kerjakan selama bertahun-tahun (rata-rata 22 ribu+ bintang, 1 juta+ baris kode)
- Untuk setiap issue, peserta diacak ke kelompok yang diizinkan atau dilarang menggunakan AI
- Saat AI diizinkan, pengembang bebas memakai Cursor Pro dan model terbaru seperti Claude 3.5/3.7 Sonnet; saat dilarang, mereka bekerja tanpa bantuan AI generatif
- Peserta merekam proses penyelesaian tiap issue (rata-rata memakan waktu 2 jam) dan melaporkan sendiri waktu yang dihabiskan
- Peserta eksperimen diberi kompensasi 150 dolar per jam
Hasil utama
- Saat menggunakan alat AI, waktu penyelesaian issue rata-rata menjadi 19% lebih lama
- Para pengembang memperkirakan AI akan benar-benar meningkatkan produktivitas sebesar 24%, dan bahkan setelah eksperimen mereka tetap melaporkan merasa sekitar 20% lebih cepat
- Dengan demikian, muncul kesenjangan besar antara persepsi dan hasil nyata
- Untuk mencegah kesalahpahaman tertentu, studi ini tidak memberikan bukti untuk hal-hal berikut:
- Generalisasi bahwa AI memperlambat semua pengembang atau seluruh pengembangan perangkat lunak
- Penetapan efek AI di bidang atau pengaturan lain
- Kepastian bahwa hasil yang sama akan terus bertahan dalam waktu dekat
- Klaim bahwa optimasi teknik LLM dan prompt yang ada tidak mungkin dilakukan
Analisis faktor yang memengaruhi
- Studi menganalisis 20 faktor yang dapat menjelaskan keterlambatan kerja, dan menilai 5 di antaranya benar-benar berpengaruh
- Dikonfirmasi bahwa variabel utama seperti kondisi eksperimen, model, tingkat kesulitan issue, dan kualitas PR tidak memberikan pengaruh yang berarti terhadap hasil eksperimen
- Fenomena perlambatan diamati secara konsisten pada berbagai subset data dan metode estimasi
- Rincian analisis lebih lengkap dapat dilihat di makalah aslinya
Interpretasi hasil dan pembahasan
Benturan bukti dan penyebabnya
- Perbedaan hasil antara skor benchmark AI/laporan kasus/eksperimen nyata terlihat jelas
- Benchmark mengukur kemampuan AI terutama pada masalah sempit yang bisa dinilai otomatis
- SWE-Bench: PR open source berbasis pengujian, RE-Bench: masalah yang bisa dievaluasi secara algoritmik
- Dalam RCT nyata, pada tugas kompleks dan realistis yang memakan waktu 20 menit hingga 4 jam, manusia justru menjadi lebih lambat
- Di sisi lain, di industri maupun komunitas terdapat banyak laporan kualitatif bahwa AI sangat berguna untuk pekerjaan berdurasi panjang
Kerangka interpretasi
- Masing-masing pendekatan memiliki karakteristik dalam mengukur “kemampuan nyata” dengan cara yang berbeda
- Pendekatan per kasus:
- Masalah underestimation pada RCT: bisa jadi ada kekhususan yang hanya berlaku pada setelan eksperimen ini
- Kemungkinan overestimation pada benchmark/kasus: ada jarak dari penyelesaian nyata, dan dasar self-report kurang dapat diandalkan
- Ketiga pendekatan bisa saja hanya cocok untuk sebagian submasalah nyata tertentu
- Kesenjangan antara berbagai sumber dan kemampuan nyata dapat ditafsirkan sebagai kesalahan/bias pengukuran (merah) dan perbedaan cakupan pengukuran (biru)
Implikasi tambahan dari eksperimen
- Hasil RCT mungkin tidak berlaku pada lingkungan yang melakukan sampling hasil AI ratusan atau ribuan kali
- Ada kemungkinan peningkatan efisiensi baru muncul setelah puluhan hingga ratusan jam menggunakan alat AI seperti Cursor
- Dalam lingkungan dengan kode berkualitas tinggi dan banyak persyaratan implisit (dokumentasi, pengujian, formatting, dll.), kemampuan AI bisa terbatas
- Karena cakupan masalah benchmark sempit, benchmark tidak dapat secara memadai mencerminkan tingkat kesulitan pekerjaan nyata
- Laporan persepsi kualitatif mungkin kurang dapat diandalkan karena efek overestimasi dan ilusi diri
- Karena tidak ada satu metode evaluasi pun yang sempurna, perlu menggunakannya secara saling melengkapi
Prospek ke depan
- Metodologi ini akan terus disempurnakan untuk melacak secara kuantitatif seberapa besar alat AI benar-benar mengubah produktivitas pengembang
- Jika alat AI secara signifikan meningkatkan efisiensi pengembang di lapangan, maka percepatan tajam R&D AI secara keseluruhan/kegagalan pengawasan/risiko konsentrasi kekuasaan juga bisa muncul bersamaan
- Pengembangan kerangka evaluasi yang sesuai dengan lingkungan nyata akan sangat penting bagi kemajuan AI dan industri secara keseluruhan
2 komentar
US$150 per jam? Bahkan kontrol variabelnya saja sudah bikin ngakak wkwk
Opini Hacker News
Komentar Simon Willison:
Makalah lengkapnya punya banyak detail yang tidak masuk ke ringkasan tautan makalah
Menurut saya pribadi, untuk mendapatkan peningkatan produktivitas yang nyata dari alat AI berbasis LLM, ada kurva belajar yang jauh lebih curam daripada yang orang bayangkan
Studi ini melibatkan 16 orang dengan tingkat pengalaman yang beragam dalam memakai alat AI, dan 56% baru pertama kali menggunakan Cursor, jadi ini pada dasarnya banyak meneliti Cursor
Setiap peserta menangani sekitar 15 issue secara total, dan untuk tiap issue ditetapkan secara acak apakah AI boleh digunakan atau tidak
Artinya, satu developer mengerjakan campuran tugas yang mengizinkan AI dan yang tidak
Hanya 1/4 peserta yang performanya meningkat, sementara 3/4 justru menurun
Pengguna AI yang berada di kelompok atas adalah orang yang telah memakai Cursor lebih dari 50 jam
Para peneliti juga mengakui bahwa developer yang cukup berpengalaman dengan Cursor memang mengalami peningkatan performa
Intuisi saya, makalah ini menunjukkan bahwa karena kurva belajar untuk pengembangan kolaboratif dengan AI itu tinggi, jika langsung dicampurkan ke workflow kerja yang sudah ada, performa justru bisa menurun
Tentang LLM, sering ada respons “itu karena kamu tidak bisa memakainya dengan benar”, tapi ini terasa seperti alasan yang terlalu membebankan tanggung jawab ke pengguna
Untuk sebagian besar produk teknologi, kalau pengguna tidak merasakan nilainya, saya cenderung menganggap desain produknya yang salah. Saya heran kenapa logika ini tidak diterapkan pada AI
Terima kasih kepada Simon, dan terima kasih sudah membaca makalahnya dengan saksama - saya penggemar proyek OS dan ingin menyoroti beberapa poin penting
1) Sejumlah riset sebelumnya menunjukkan peningkatan performa meski pengalaman dengan alatnya minim, jadi hasil kali ini tidak bisa dijelaskan hanya dengan teori “kurva belajar yang curam”
2) Sebelum studi, lebih dari 90% peserta sudah punya pengalaman melakukan prompting LLM, dan prompting dianggap sebagai keterampilan utama. Pandangan umum saat itu adalah jika Anda sudah terbiasa memakai VSCode, maka Cursor mudah dipakai
3) Jika semua orang sudah terbiasa dengan AI, mereka justru bisa lebih buruk saat bekerja tanpa AI (setidaknya saya bisa memahami itu), dan kalau begitu akan muncul efek pengurang yang malah membuat AI terlihat lebih baik
4) Informasi pengalaman dibagikan lebih dahulu kepada para ahli prediksi, namun para peramal tetap menetapkan ekspektasi peningkatan produktivitas yang terlalu tinggi
5) Bisa jadi memang ada keterampilan long-tail yang muncul dari ratusan jam penggunaan, dan studi ini sulit bicara sampai sejauh itu
Karena makalah ini memberi hasil yang mengejutkan, mudah bagi pembacanya untuk memilih satu faktor lalu menyimpulkan “ini penyebabnya!”
Padahal kenyataannya bisa jadi penyebabnya kompleks (setidaknya 5 hal, dan sebanyak 9 hal belum bisa dikesampingkan, lihat tabel di halaman 11)
Satu implikasi yang sangat penting: kepuasan yang dilaporkan sendiri oleh developer ternyata sangat jauh dari kenyataan, dan ini tidak bergantung pada jenis alat yang dipakai
Untuk mengukur produktivitas, data nyata di lapangan benar-benar dibutuhkan (lihat makalah bagian C.2.7: bagian “penggunaan alat AI di bawah rata-rata” membahas ini lebih rinci)
Ini bisa ditafsirkan sebagai: meski 75% peserta punya pengalaman LLM, kecepatan kerja mereka malah turun saat memakai AI. Salah satu tafsirnya adalah kurva belajar LLM memang sangat curam; tafsir lainnya adalah efisiensi aktual LLM sebagai alat bantu pemrograman saat ini terlalu dilebih-lebihkan. Orang-orang secara konsisten salah memperkirakan performa
Walaupun seseorang menjadi mahir memakai LLM, pemahamannya terhadap kode yang ia tulis sendiri bisa menurun
Developer makin lama biasanya makin paham terhadap basis kodenya, tetapi LLM justru bisa makin memburuk
Dengan LLM, kode bisa dihasilkan dengan cepat, tetapi jika tidak cukup diperhatikan, kemahiran terhadap kode itu sendiri tidak akan terakumulasi
Di awal memang terasa ringan dan cepat, tetapi di belakang layar pemahamannya kurang, dan LLM yang awalnya berguna juga makin lama tidak benar-benar membaik, sampai pada satu titik kode itu berubah menjadi kekacauan yang tidak bisa ditangani baik oleh LLM maupun penggunanya
Saya rasa kita harus menahan godaan itu, dengan tekun mengelola agar LLM menghasilkan kode yang lebih rapi, dan kita sendiri juga wajib mempelajari kodenya. Harus ada upaya sadar untuk benar-benar memahaminya
Terlihat ada orang yang produktivitasnya meningkat dengan alat AI dan ada juga yang tidak
Dugaan saya, orang yang bisa membaca teks atau kode panjang dengan cepat punya keuntungan besar
Kemampuan untuk cepat mengenali usulan yang tidak berguna dan terus mengiterasi sampai mendapat jawaban yang baik sangat penting
Kemampuan scanning yang cepat memang berkorelasi dengan pengalaman, tapi kadang ada juga junior yang ternyata cepat dalam hal ini
Orang yang jago mencari informasi bisa juga lebih unggul dalam memanfaatkan LLM, dalam konteks yang mirip dengan kemampuan googling
Ini mengingatkan lagi pada prinsip 80/20 - AI menyelesaikan 80% pekerjaan dalam 20% waktu, lalu 20% sisanya menghabiskan 80% waktu
Selalu ada kesan “hampir selesai”, jadi mudah terjebak pada sunk cost fallacy
Metode yang belakangan saya coba adalah memakai AI bukan sebagai “pemecah masalah”, melainkan “penghilang gesekan”
Saya tetap melakukan pemrogramannya sendiri, dan hanya menanyakan hal-hal kecil seperti sintaks yang sempat saya lupa untuk mempercepat kerja
Saya hampir tidak pernah melihat saran kode utuh secara langsung. Saya selalu menulis kode sambil berpikir sendiri, agar pemahaman dan kemampuan saya tidak menurun
Dulu itu semacam kebalikan Pareto: 80% pekerjaan butuh 80% usaha, lalu 20% sisanya juga butuh 80% usaha lagi
Saya setuju dengan penggunaan AI hanya untuk menyelesaikan “hambatan kecil”
Kemarin saya juga kesulitan gara-gara
ConcurrentOperationsExceptionsaat memprosesListdengan Java stream APISetelah menulis metodenya sendiri dan tetap buntu, saya minta AI membuat “metode konversi list yang thread-safe”, lalu AI memberi tahu bahwa API tersebut ternyata sudah punya metode bawaan
Untuk masalah kecil seperti ini AI memang yang terbaik - rumit, tetapi definisinya jelas
Sangat berguna terutama saat dipakai seperti Stack Overflow yang lebih kuat, ketika saya kurang lebih tahu apa yang harus saya lakukan tetapi tidak tahu detail cara menerapkannya sesuai lingkungan saya, dan juga membantu untuk debugging maupun rubber ducking
“20% terakhir menghabiskan 80% waktu” itu juga pengalaman saya sebelum AI hadir. Kalau AI bisa memangkas waktu di tahap awal saja itu sudah bagus. Penilaian terbaik tentang AI yang pernah saya dengar dari orang berpengalaman adalah “90% keterampilan saya jadi tidak bernilai, dan 10% sisanya jadi seribu kali lebih penting”; memang hiperbolis, tapi saya suka intinya
Ilusi bahwa “semuanya hampir jadi” justru membuat waktu terbuang. AI sangat ahli membuat sesuatu tampak berguna, jadi untuk menilai apakah itu benar-benar meningkatkan produktivitas dibutuhkan pemikiran kritis tingkat tinggi
Sangat berguna terutama saat menambahkan fitur ke codebase yang sudah ada, misalnya tugas seperti “tambahkan foo ke parameter pencarian yang sudah ada” atau “hapus kode yang terkait dengan x”
Untuk para pengguna HN, saya adalah penulis makalahnya - saya pengguna HN lama, dan hari ini saya berusaha menjawab sebanyak mungkin pertanyaan/masukan di komentar. Kalau tidak sempat membaca makalah lengkap, saya sarankan post blog pengantarnya atau thread presentasi di x.com
Metodologi makalah ini dan cara penulis berkomunikasi sangat profesional dan mengesankan, riset yang bagus
Menurut saya ini salah satu riset terbaik karena hasilnya disajikan dengan jujur tanpa clickbait, dan dirapikan dengan baik sehingga mudah dibaca
Apakah sudah dipertimbangkan apakah tiket yang dikerjakan dengan AI memang benar-benar jenis tugas yang cocok untuk AI? Pendekatan “coba kerjakan tiket ini dengan AI” memang realistis, tetapi bisa juga tidak efisien. Jika dipakai pada hal yang cocok, AI benar-benar bisa sangat membantu, tetapi dalam banyak kasus justru berefek sebaliknya. Jika peserta studi memang punya pengalaman AI yang cukup, mereka seharusnya mampu membedakan hal ini, tetapi saat membaca makalahnya saya merasa tidak terlalu jelas apakah itu benar terjadi
Saya penasaran apakah dataset mentah yang sudah dianonimkan mungkin akan dibuka, atau setidaknya apakah informasi waktu absolut yang dihabiskan per developer bisa ditambahkan ke makalah. Saya ingin tahu apakah peserta yang berpengalaman dengan Cursor memang lebih cepat daripada yang lain, atau justru pada dasarnya dia orang yang lambat sehingga mendapat peningkatan yang lebih besar dari AI. Senang bisa melihat evaluasi eksperimental yang sungguh bagus sampai mempertimbangkan Hawthorne effect (efek pengamat)
(Saya belum membaca makalahnya, hanya melihat post-nya) Saya penasaran apakah subjective fatigue diukur sebagai metrik untuk menjelaskan kenapa orang salah mengira AI itu lebih cepat. Sejak beralih dari developer ke manajer, saat otak saya lelah, AI terasa lebih nyaman dipakai
Hasil studi ini, khususnya bagian “developer memperkirakan AI akan meningkatkan kecepatan 24%, padahal sebenarnya mereka melambat, namun setelah mengalaminya mereka tetap percaya bahwa mereka menjadi 20% lebih cepat”, sangat menarik. Kenapa jarak antara kenyataan dan persepsi bisa sedrastis itu? Saya juga penasaran apakah otak mungkin keliru menganggap ‘upaya mental’ sebagai pengalaman waktu
Saya tidak punya dasar, tapi ada pikiran yang agak menyeramkan: apakah interaksi dengan AI saat coding menstimulasi otak dengan cara yang mirip dopamine loop media sosial (meski tentu tingkatnya berbeda)? Karena AI berulang kali menawarkan jawaban, otak terasa seperti menerima validasi positif, dan itu mungkin membuat developer menilai AI lebih positif daripada kenyataannya. Jika ini bahkan memicu kecanduan, bukankah itu bisa membuat orang melebih-lebihkan dampaknya terhadap produktivitas?
Fenomena ini juga bisa jadi merupakan hasil dari kampanye besar yang membuat banyak orang di pasar percaya bahwa alat AI jauh lebih hebat daripada kenyataannya. Kelompok ahli ekonomi dan ahli ML sendiri tumpang tindih dengan para pemangku kepentingan perusahaan AI, lalu eksekutif menerima narasi itu mentah-mentah dan menjanjikan hasil besar. Itu akhirnya menaikkan baseline ekspektasi secara menyeluruh, bahkan memengaruhi developer berpengalaman. Sulit dibuktikan secara empiris, tetapi mungkin itulah alasan ilusi kolektif tentang produktivitas AI menyebar luas
Saya juga bertanya-tanya apakah banyak penggemar AI di komentar HN terjebak dalam fenomena ini. Tanpa benar-benar mengukur performa sendiri, sulit yakin apakah AI sungguh meningkatkan produktivitas pribadi
Kadang saya malah mengalami kebalikannya. Hari ini saya mencoba membuat kode aplikasi demo contoh dengan Claude code, dan saat menontonnya memang terasa keren dan seperti fiksi ilmiah, tetapi setelah 15 menit saya justru merasa kosong dan bosan
Melihat pernyataan “developer berharap AI 24% lebih cepat, dan meski sebenarnya melambat mereka percaya diri merasa 20% lebih cepat”, saya merasa ada dua masalah di sini
Yang pertama, sulit membandingkan secara akurat waktu yang dibutuhkan oleh orang yang sama dalam konteks yang sama saat memakai AI versus saat tidak memakainya
Yang kedua, mudah sekali mengukur efisiensi AI dari metrik permukaan seperti waktu sampai PR dibuka/di-merge, padahal setelah AI dipakai justru lebih banyak waktu dialokasikan untuk pekerjaan lanjutan seperti refactoring, testing, dan penyelesaian issue
Melihat hanya “PR dibuka lebih cepat” membuat orang mudah salah mengira AI itu cepat, padahal kenaikan pekerjaan lanjutan sering terlewat
Sangat sulit mengukur dampak teknologi atau praktik tertentu terhadap produktivitas. Menarik kesimpulan hanya dari self-report atau anekdot itu berbahaya, karena siapa pun bisa dengan mudah terjebak dalam halusinasi diri. Studi ini sendiri juga mengakui keterbatasannya, jadi dalam diskusi soal produktivitas kita harus sadar bahwa margin of error-nya besar. AI adalah teknologi paling aneh yang pernah saya lihat seumur hidup; membaca hubungan kausal dari kasus-kasus potongan atau benchmark yang meragukan hampir seperti membaca ramalan
Di makalah itu, tidak terlihat penurunan kualitas PR antara kondisi AI diizinkan dan tidak diizinkan. Sebagian besar peserta sudah terbiasa dengan standar repositori dan bukan tipe yang “asal submit biar PR terbuka”. Waktu review median untuk PR dalam studi ini sekitar 1 menit. Seperti yang Anda bilang, cara waktu digunakan memang berubah total. Di halaman 10 makalah ada distribusi waktu antara penggunaan AI dan non-AI; dengan AI waktu coding berkurang, tetapi waktu untuk berinteraksi dengan AI meningkat
Menanggapi keberatan bahwa “mustahil mengetahui secara akurat selisih waktu yang dibutuhkan oleh orang yang sama dalam konteks yang sama saat bekerja dengan AI atau tanpa AI”, desain eksperimennya memisahkan efek kelompok AI dan non-AI melalui random assignment. Perbedaan individu, situasi, lingkungan, dan sebagainya dinetralkan lewat pengacakan. Jika ukuran sampel dan besaran efek cukup besar, perbedaan yang bermakna secara statistik bisa tetap diambil
Figure 21 menunjukkan implementasi awal itu sendiri (waktu hingga PR) juga meningkat, dan meski waktu setelah review PR juga bertambah, dampaknya secara keseluruhan tampaknya tidak besar. Seperti terlihat pada Figure 18, waktu coding murni memang berkurang, tetapi penghematan itu terkompensasi oleh waktu untuk menulis prompt, menunggu hasil, dan meninjau output. Untuk tugas sederhana di bawah 5 menit, mungkin justru lebih baik tidak memakai LLM
Saya ingin membandingkan isi PR di tiap workflow. Copilot cenderung menyarankan lebih banyak kode daripada jika saya mengerjakannya sendiri, dan sering kali kodenya jadi lebih panjang karena check yang tidak perlu, pengulangan, atau abstraksi yang sebenarnya tidak dibutuhkan. Hipotesis pribadi saya, saat melihat LLM menulis terlalu banyak kode, persepsi tentang berapa lama pemecahan masalah akan memakan waktu menjadi terdistorsi
Kesulitan nyata saat memakai LLM untuk bekerja pada codebase besar adalah mendeskripsikan dengan akurat pekerjaan yang harus dilakukan. Sering kali menjelaskan issue di tengah banyaknya interaksi kode justru memakan waktu lebih lama daripada menanganinya langsung secara manual; sebaliknya, untuk membuat boilerplate code pada proyek baru, LLM tampaknya paling cocok
Hanya untuk biaya rekrutmen developer peserta saja mereka menghabiskan 300 x 246 = sekitar 73K, tetapi makalah ini bahkan tidak dimuat di jurnal atau melalui peer review. Dari luar makalahnya terlihat rapi dan tidak terasa seperti hasil AI, tetapi saya penasaran bagaimana pendanaan sebesar ini bisa tersedia
Dukungan pendanaan terbesar datang dari The Audacious Project, dan bisa dicek lewat pengumuman resmi . Selain itu, sampai April 2025 mereka menyatakan tidak menerima kompensasi evaluasi dari perusahaan AI dalam catatan kaki situs web
Perusahaan memang sering mengeluarkan “whitepaper” seperti ini. Bentuknya campuran laporan teknis, usulan kebijakan, dan materi promosi
Menurut saya, hanya melihat apakah sesuatu dimuat di jurnal atau melalui peer review itu kurang bermakna. Dalam sains, yang penting bukan siapa yang menerbitkan, melainkan reproduksibilitas dan hasil yang berulang. Seperti dalam krisis replikasi psikologi, publikasi jurnal sendiri tidak menjamin reliabilitas
Di sebagian besar negara ada dana publik untuk riset. Amerika dulu mendanai lebih banyak, tetapi belakangan ini banyak dipotong
Jika melihat halaman tentang yayasan, tampaknya mereka menerima pendanaan dari berbagai pihak seperti perusahaan AI dan pemerintah
Dalam proyek OSS hobi, AI justru lebih banyak mengganggu. Pembuatan kode/scaffolding bukan kekhawatiran utama; yang lebih penting adalah code review dan pengelolaan komunitas. Hal-hal yang bisa dilakukan alat AI jelas ada batasnya. Tetapi seseorang menjalankan alat code review AI pada PR terbuka saya, dan bahkan untuk PR 30 baris alat itu memuntahkan ringkasan dua halaman lengkap dengan emoji dan bullet point rapi. Itu cuma menambah noise, dan sekarang saya malah harus menghapus atau menyembunyikan komentar-komentar seperti itu, sehingga waktu maintenance yang nyata justru makin berkurang
Begitu melewati kurva belajar, mungkin memang jadi lebih cepat (atau seperti kata seseorang, “sampai Anda lupa lagi bagaimana cara bekerja tanpa AI”), tetapi yang benar-benar perlu diukur adalah… saat alarm PagerDuty berbunyi pukul 3 pagi, berapa lama benar-benar dibutuhkan untuk men-debug kode itu. Saya juga penasaran seperti apa kualitas jangka panjang kode tersebut. Saya selama ini memperbaiki struktur kode dengan memindahkan business logic ke shared folder, menarik call chain ke atas agar API di bawah tetap bersih, memisahkan logic/API/display, melakukan enkapsulasi, dan seterusnya (mengurangi coupling lewat dependency injection, misalnya). Apakah kode dari AI dalam jangka panjang akan menghasilkan kualitas/portabilitas/ekstensibilitas yang lebih baik? Atau justru akan menumpuk sebagai kode berkualitas rendah yang makin lama makin jadi tempat sampah kusut, sehingga akhirnya setengah waktu habis hanya untuk memperbaiki bug?