Dampak Gen AI pada Pekerjaan Berketerampilan Tinggi: Eksperimen dengan Pengembang Perangkat Lunak

Ringkasan

• Ikhtisar penelitian
  • Studi ini mengevaluasi dampak AI generatif terhadap produktivitas pengembang perangkat lunak melalui tiga eksperimen terkontrol acak yang dilakukan di Microsoft, Accenture, dan sebuah perusahaan manufaktur elektronik Fortune 100 anonim.
  • Eksperimen dilakukan sebagai bagian dari pekerjaan sehari-hari di masing-masing perusahaan, dengan pengembang yang dipilih secara acak diberi asisten coding berbasis AI, GitHub Copilot.
  • Studi yang melibatkan total 4.867 pengembang perangkat lunak ini menemukan bahwa jumlah tugas yang diselesaikan oleh pengembang yang menggunakan alat AI meningkat 26,08% (standard error: 10,3%).
  • Secara khusus, pengembang yang kurang berpengalaman menunjukkan tingkat adopsi dan peningkatan produktivitas yang lebih tinggi.

Ringkasan GN⁺

• Studi ini menunjukkan bahwa AI generatif dapat secara signifikan meningkatkan produktivitas pengembang perangkat lunak.
• Teknologi ini sangat berguna terutama bagi pengembang yang kurang berpengalaman, yang mengindikasikan bahwa alat AI dapat membantu mengurangi learning curve.
• Alat AI seperti GitHub Copilot dapat memainkan peran penting dalam meningkatkan efisiensi pengembangan perangkat lunak.
• Proyek lain dengan fungsi serupa antara lain TabNine dan Kite.

[GN⁺]

Komentar Hacker News

• Kadang saya bertanya-tanya apakah alasan kualitas tenaga kerja TI menurun adalah karena perusahaan terus menimpakan semakin banyak peran ke satu orang demi mengurangi jumlah karyawan
  Dulu pengembangan, operasi, dan keamanan masing-masing adalah peran khusus, tetapi ketika DevOps muncul, sebagian perusahaan menafsirkannya bukan sebagai integrasi tim melainkan bahwa mereka cukup mempekerjakan 2/3 orang saja, lalu ketika DevSecOps muncul mereka menganggap cukup punya 1/3 dari peran semula dan pengembang bisa merangkap operasi serta keamanan aplikasi
  Ini bukan kritik terhadap shift-left atau model operasi terpadu itu sendiri, melainkan konsekuensi logis dari model seperti ini ketika para eksekutif berpikir mereka bisa mendapat bonus lebih besar dengan memangkas orang dan menurunkan biaya
  Sekarang pengembang junior masuk ke lingkungan n mikroservis yang rumitnya tidak masuk akal, sambil harus mempelajari codebase yang sudah ada, pipeline CI/CD yang terdiri dari 5 bagian, bahkan sampai peran DBA, sambil tetap memenuhi ritme rilis yang konsisten
  Jadi apakah benar-benar mengejutkan kalau mereka memakai ChatGPT untuk mengejar ketertinggalan? Ini akan terus berlanjut sampai perusahaan TI berhenti memangkas orang demi “menaikkan garis” alih-alih menjalankan strategi bisnis yang baik

  • Di startup, satu orang bisa mengerjakan pekerjaan tiga orang, dan memang itu sering terjadi
    Yang menurut saya dilewatkan para MBA adalah fenomena kendala berlebihan. Ketika peran umum “developer” dipecah menjadi “pengembangan, operasi, keamanan”, muncullah segala macam detail tentang bagaimana tiap peran harus dijalankan. Bahkan jika kemudian digabung lagi menjadi DevSecOps, semua detail itu tetap ada, sehingga satu orang bukan bekerja 3 kali lebih efisien, melainkan memikul 3 kali lebih banyak pekerjaan
    Untuk benar-benar membalikkannya, Anda harus melonggarkan kendala dan membiarkan satu orang itu memutuskan sendiri bagaimana pekerjaan dilakukan
    Kesimpulan yang mengikuti dari sini adalah ukuran organisasi tidak bisa mengecil, hanya bisa membesar. Semakin banyak pegawai, semakin terspesialisasi pekerjaan mereka, dan jika mereka dihilangkan, fungsi itu pada dasarnya tidak akan dijalankan. Pada tingkat spesialisasi seperti itu, sulit meminta pegawai yang tersisa untuk sekadar mengubah sedikit deskripsi pekerjaannya lalu menanggung tanggung jawab baru
    Pada akhirnya Anda harus membuang organisasi lama dan memulai lagi dengan organisasi baru yang lebih kecil, dan inilah alasan ekosistem private equity/venture capital/startup ada. Hukum Gall juga sejalan dengan ini: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
  • Saya rasa penurunan kualitas tenaga kerja TI sepenuhnya berkaitan dengan generasi yang masuk ke industri perangkat lunak karena bisa menghasilkan banyak uang. Bisa dimengerti, tetapi motivasi mereka sering kali lebih pada imbalan daripada gairah terhadap perangkat lunak, dan umumnya mereka orang-orang yang secara teknis biasa saja, lalu cenderung merekrut teknisi biasa lainnya
    Sebaliknya, kalau melihat startup baru yang bermunculan belakangan ini, tampaknya semakin banyak orang yang benar-benar berbakat. Dalam lingkungan pendanaan yang lebih ketat, untuk memulai perusahaan dibutuhkan orang yang benar-benar hebat, dan orang-orang seperti itu juga merekrut orang-orang hebat lainnya
    Industri teknologi saat ini terasa jauh lebih mirip dengan sekitar 2004~2008, ketika hampir semua orang yang tertarik pada startup masuk karena suka mengutak-atik masalah teknis
    Dari pengalaman saya memakai Cursor, alat itu sangat bagus untuk hal-hal yang bisa dilakukan insinyur biasa, tetapi buruk sekali untuk pekerjaan yang lebih tingkat lanjut, dan tetap membutuhkan kemampuan memahami kode orang lain dengan sangat cepat
    Kemungkinan ini akan membuat insinyur teknis tingkat lanjut yang tidak fokus pada frontend atau pengembangan web app tidak perlu lagi merekrut junior web developer sebanyak dulu. Mirip seperti webmaster yang menghilang setelah muncul framework dan alat yang bisa dengan cepat membuat HTML/CSS dasar untuk halaman web
  • Fenomena ini bukan hanya terjadi pada pekerja TI, melainkan di banyak bidang secara umum, dan menurut saya ini salah satu alasan utama peningkatan produktivitas yang dijanjikan teknologi tidak benar-benar terwujud
    Misalnya kalau staf “DevSecOps” melakukan 3 kali pekerjaan yang seharusnya, kita juga harus melihat apa lagi yang mereka kerjakan. Bisa jadi mereka juga memesan perjalanan dinas, mengurus penggantian biaya dan pelaporan, membagi jam kerja ke dalam kategori bisnis untuk dilaporkan, mengelola cuti, mengatur rapat, membuat materi presentasi dengan grafik buatan sendiri, bahkan mengerjakan sampai 80% persiapan pembelian vendor eksternal
    Hal-hal seperti ini tidak ada dalam deskripsi kerja, mengganggu pekerjaan sebenarnya, dan secara tidak seimbang menggerogoti kemampuan mereka melakukan pekerjaan utama. Dulu ada spesialis khusus untuk masing-masing tugas itu, dan mereka bisa mengerjakannya 10 kali lebih efisien dengan biaya jauh lebih murah
    Spesialis seperti sekretaris, departemen grafis internal, atau staf keuangan terlihat jelas di laporan keuangan. Menghapus peran-peran itu tidak membuat pekerjaannya hilang; semuanya hanya dipecah dan disebarkan ke semua orang dengan dalih software kantor swalayan meningkatkan “produktivitas”
    Akibatnya semua orang melambat secara tidak proporsional, tetapi orang yang hanya melihat angka cuma melihat penghematan dari gaji peran yang dihapus. Perlambatan itu muncul hanya sebagai rasa kabur akan turunnya produktivitas secara umum, seperti penyakit biaya misterius yang dialami semua orang
    Menurut saya itu bukan misterius; bukan ada peningkatan produktivitas, justru ada kerugian. Hanya saja biaya yang tadinya jelas dan terlihat diubah menjadi biaya yang tersebar dan sulit dihitung, sehingga orang mudah salah mengira bahwa mereka sedang menghemat uang
  • Perusahaan mulai sadar bahwa developer 10x itu ada, tetapi mereka mengira bisa mempekerjakan mereka dengan gaji developer 1x
    Kemampuan utama yang sering terlewat adalah memahami bisnis tempat perusahaan itu beroperasi. Bahkan kemampuan pengembangan yang biasa-biasa saja, jika dipadukan dengan pemahaman yang baik tentang tujuan bisnis, bisa tetap relevan di saat sebagian developer murni digantikan AI
  • Ini tidak akan berhenti. Para eksekutif puncak tipikal yang memegang kekuasaan nyata sama sekali tidak paham kompleksitas TI, dan memandang kita tidak lebih dari petugas kebersihan yang mahal. Itu kesalahan mereka, tetapi saat kesalahan itu sepenuhnya terlihat, kemungkinan besar mereka sudah pergi
    Selama 13 tahun di perusahaan sektor perbankan, saya melihat kompleksitas meningkat tajam, dan birokrasi yang tidak masuk akal ikut bertambah. Pekerjaan yang diperlukan sebenarnya masih bisa dilakukan, tetapi kami tidak punya akses. Dan memang tidak mungkin punya
    Tugas sederhana sekarang berubah menjadi harus melewati negosiasi 10 tahap dengan tim Pune entah-apa, lalu mengejar dan mengeskalasi 10 kali sampai mereka sadar memang ada pekerjaan yang harus dilakukan
    Prosesnya sudah begitu absurd sampai kalau Anda memulai sesuatu, Anda tidak tahu apakah itu akan selesai dalam 2 hari atau 3 bulan. Semua aplikasi akan cepat rusak jika tidak terus dipelihara, entah karena pekerjaan jaringan baru, pembaruan Unix yang belum tervalidasi, atau salah satu dari sekian banyak hal yang pasti akan terjadi
    Pada akhirnya para pengurus administrasi dan orang-orang yang juga cuma rata-rata dalam pekerjaan intinya tertanam jauh di dalam proses dan menang, sementara unit bisnis menerima TI berkualitas rendah, proyek terlambat, dan anggaran membengkak. Ini makin menguatkan citra TI sebagai “kejahatan yang buruk tapi harus ditoleransi”
    Sekarang saya sudah berhenti terlalu peduli, dan pekerjaan cukup menjadi sarana untuk hidup. Fokus dan pencapaian saya ada pada bagian “hidup” itu

• Apa yang diukur itu penting. Studi ini hanya melihat penggunaan Copilot.
  Saya engineer berpengalaman, dan bagi saya Copilot bukan cuma tidak berguna, tapi malah mengganggu. Sebagian besar waktu saya habis untuk memahami domain masalah, menangkap batasan dan kemungkinan di lingkungan tempat saya bekerja, serta memikirkan kode yang akan saya tulis.
  Saat benar-benar mulai mengetik kode, saya sudah tahu apa yang akan saya tulis, jadi autocomplete Copilot yang “membantu” malah hanya membuat saya terdistraksi. Alur kerja saya jadi jauh lebih buruk.
  Sebaliknya, untuk tahap-tahap sebelum benar-benar menulis kode, AI sangat berguna. Kadang, hanya dengan prompt yang disusun baik berdasarkan pemikiran yang sudah dilakukan sebelumnya, saya bisa mendapatkan draf awal; setelah itu, berpasangan dengan LLM sangat membantu untuk cepat mendapatkan jawaban atas masalah-masalah kecil tak terduga yang muncul.
  Jadi, berbeda dengan laporan ini, saya pikir jika developer berpengalaman menggunakan AI dengan baik, mereka justru bisa memperoleh keuntungan yang lebih besar daripada developer yang kurang berpengalaman.

  • Copilot sendiri tidak terlalu berguna. Paling bagus pun ia menghasilkan potongan kode kecil yang bisa benar atau bisa salah, dan jarang ada blok kode yang lebih besar yang langsung berjalan sejak awal.
    Tetapi jika memakai Claude Sonnet 3.5 bersama Cursor atau Continue.dev, hasilnya jauh lebih baik. Kita bisa mengendalikan konteks secara eksplisit, misalnya dengan memilih 6–7 file untuk disuntikkan, dan ditambah kemampuan Claude yang unggul, situasinya benar-benar berubah total.
    Tergantung pekerjaannya, saya bisa dengan mudah menjadi 2–5 kali lebih cepat. Pekerjaan yang biasanya bisa memakan setengah hari dapat menjadi 100 baris kode siap produksi lengkap dengan pengujiannya dalam satu jam.
    Saya mengatakan ini sebagai seseorang dengan 26 tahun pengalaman dan yang sudah memegang peran principal/staff/lead sejak 2012. Namun, saya tidak mengharapkan peningkatan yang sama pada pengalaman di bawah senior. Soalnya, kita harus menjelaskan apa yang sebenarnya diinginkan dengan cukup rinci, dan biasanya perlu menerima solusi awal yang cukup berjalan lalu menyempurnakannya sekitar enam kali hingga menjadi bentuk yang ideal dan terurai dengan baik.
  • Bagi saya, AI terasa seperti alat untuk mempercepat dokumentasi dan kemampuan pencarian. Saya tahu persis apa yang ingin saya lakukan, tetapi ada banyak hal kecil di mana saya tidak ingat sintaks atau cara pakainya.
    Misalnya, saat menulis IaC untuk AWS, ada banyak hal yang perlu dicari. Jika bertanya ke AI, saya bisa sangat cepat mendapatkan jawaban dan contoh. Jika saya sedang mempelajari IaC untuk layanan baru, saya akan melihat dokumentasi AWS, tetapi saat hanya butuh jawaban cepat atau penyegaran, AI jauh lebih cepat.
  • Dari sudut pandang sebaliknya, saya merasa Copilot memberi imbalan pada penulisan pola yang nantinya memungkinkan seluruh fungsi ditulis hanya dari method signature.
    Semakin kita mengandalkan pola fungsional—merancang monad, membatasi input/output hanya di boundary, dan memakai fluent programming—semakin besar efeknya.
    Sebagai catatan, ini pengalaman saya di Java. Saya sudah memakai Java selama 3,5 tahun dan sangat bergantung pada fitur Java 8+. Jika banyak menggunakan generic dalam kode library, ada ruang yang lebih besar bagi LLM untuk secara konsisten membuat pilihan yang benar.
    Dalam desain yang lebih cepat dan lebih seadanya, manfaat seperti ini tidak terlalu terlihat. Saya ingin lebih banyak mendengar dari pengguna functional programming sejati seperti Haskell, OCaml, F#, dan Scala.
  • Saya pernah mencoba versi uji coba Copilot, tetapi akhirnya saya menunggu dan menganalisis hasil yang diberikannya, lalu membuang sebagian besarnya dan membuat ulang dengan implementasi saya sendiri. Saya segera sadar itu buang-buang waktu.
    Itu memang berguna untuk menulis boilerplate unit test, terutama table-driven test, tetapi tidak sampai layak untuk mempertahankan langganan berbayar.
  • Pengalaman saya juga mirip. Saya punya akses lewat kantor, tetapi belakangan saya matikan karena terlalu berisik bagi konsentrasi.
    Itu sangat bernilai saat bekerja dengan bahasa yang belum familier, atau pada pekerjaan berulang di mana saya bisa dengan mudah menilai apakah kode yang dihasilkan cukup bagus.
    Sebaliknya, itu lemah ketika saya sangat jelas tentang apa yang ingin saya lakukan, dan pekerjaannya mirip implementasi standar tetapi sedikit lebih baru. Hal seperti ini sering terjadi pada “reduce” atau prosedur yang lebih ambigu.
    Saya seorang platform engineer, jadi sering berpindah-pindah antara Bash, Python, browser, pure JS, TS, Node, GitHub Actions, workflow Java di Jenkins, Docker, dan lainnya; saat berpindah domain, ini membantu memberi otak waktu istirahat dan pemanasan.

• Saya penasaran apakah studi ini mencakup utang teknis yang harus ditangani oleh pengembang yang lebih berpengalaman setelah pengembang yang kurang berpengalaman berkontribusi dengan AI. Saya pribadi sering mengalami hal seperti itu di salah satu perusahaan yang disebut dalam studi tersebut
  Saya juga melihat sendiri bahwa pengembang yang tidak terlalu tertarik pada teknologinya, tetapi sangat peduli pada penyampaian, menunjukkan minat yang lebih besar pada AI. PM menyukai orang-orang seperti itu, tetapi

  • Saya juga penasaran. Belakangan ini, di berbagai PR, saya harus me-review metode yang jelas-jelas telah dirombak total oleh AI tanpa alasan yang masuk akal. Saat ditanya kenapa diubah, mereka benar-benar diam, mengabaikan pertanyaan itu dan hanya berusaha menjelaskan pekerjaan yang sejak awal kami minta. Jelas mereka sendiri tidak tahu apa yang sebenarnya ada di dalam PR tersebut
    Yang kami minta hanyalah perubahan kecil sekitar 5 baris dan tes. Namun sekarang kami harus menanggung bukan hanya utang baru, tetapi juga kode yang tidak bisa dijelaskan siapa pun kenapa diubah total, sebagian di antaranya hanyalah perubahan demi perubahan, dan kode yang terasa sepenuhnya asing bagi orang-orang yang harus memeliharanya
    Saya terus melihat ini pada orang-orang yang memakai alat seperti ini dan bukan engineer senior. Akhirnya PR seperti itu saya tolak dan saya minta dikerjakan ulang, sehingga keuntungan waktu yang tadinya terasa didapat pun hilang
    Ini bukan berarti alat seperti ini tidak berguna, tetapi orang-orang memakainya tanpa memahami apa output-nya, dan juga tanpa memahami dampak jangka panjangnya terhadap codebase
  • Ungkapan “pengembang yang tidak terlalu tertarik pada teknologi tetapi sangat peduli pada penyampaian lebih tertarik pada AI” dengan tepat menggambarkan apa yang selama ini sulit saya jelaskan
    Hari ketika saya kehilangan sebagian jiwa saya adalah saat saya bertanya kepada seorang pengembang apakah saya boleh memberi masukan soal skema DB, dia bilang boleh, lalu beberapa menit kemudian memotong dengan berkata, “Ya, saya tidak terlalu tertarik pada X”
    Tidak tertarik? Saya, sebagai ahli di bidang itu, sedang memberi tahu apa yang bisa diperbaiki, bagaimana caranya, dan kenapa itu perlu dilakukan, lalu Anda bilang tidak tertarik
    Cloud adalah sebuah kesalahan. Itu menanamkan gagasan pada orang-orang bahwa karena kapan saja bisa scale up/out, maka tidak perlu mengejar efisiensi dan optimisasi. Saya bahkan bukan bicara soal microbenchmark, melainkan hal yang sangat sederhana seperti, “bukankah lebih baik memakai struktur data ini daripada yang itu?”
  • Saya nyatakan dulu bahwa saya bekerja di perusahaan yang menjual AI untuk coding
    Kami juga memakainya secara internal, dan saya melihat utang teknis sebagai ancaman besar yang skalanya belum benar-benar dipahami
    Ini sangat berguna untuk membombardir kode dengan API dan pola yang belum familiar, tetapi kalau tidak hati-hati akan menghasilkan duplikasi kode yang sangat besar dan boilerplate yang sulit ditangani
    Alasannya ada dua bias besar. Pertama, data pelatihan model berupa data contoh bergaya StackOverflow, jadi tidak mempertimbangkan konteks dan batasan. Kedua, model cenderung menyalin dan mengulang daripada melihat codebase yang ada lalu mengusulkan refactoring
    Yang pertama pada akhirnya bisa dikurangi kalau Anda benar-benar mengerjakan pekerjaan Anda sendiri, yaitu me-review dan mengedit apa yang dimuntahkan LLM
    Yang kedua baru bisa dikurangi jika diff dan riwayat commit masuk ke data pelatihan, tetapi dataset ini jauh lebih sulit untuk ditangani dan diberi tag. Sebagian perubahan memang bagus seperti refactoring, tetapi sebagian perubahan bisa jadi adalah bug yang lalu diperbaiki di commit berikutnya, dan commit message pada praktiknya sering bohong sehingga tidak ada pemisahan yang jelas. Tidak ada orang yang menulis “introduce bug”
    Belum lagi merge, rebase, dan squash yang mengubah makna riwayat, menghapusnya, atau menambah noise sehingga semuanya makin kabur
  • Di antara pengembang yang menyukai AI, hampir semua yang saya kenal adalah pengembang yang bahkan sebelum AI pun tidak terlalu saya hormati secara teknis. Mereka memang menyelesaikan pekerjaan sampai tingkat tertentu, tetapi tidak punya jiwa craftsmanship atau kualitas
  • Saya juga merasakan itu, tetapi saya juga melihat kebalikannya. Bahkan di HN sini pun ada orang-orang yang peduli pada teknologi yang menunjukkan penolakan yang nyaris refleks terhadap penggunaan AI
    Saya menyukai teknologi dan juga membuat software untuk bersenang-senang, tetapi secara objektif bekerja bersama AI jauh lebih menyenangkan. Produktivitas naik jauh lebih tinggi, dan yang paling penting, kebiasaan menunda hilang
    Saat saya buntu atau tidak ingin mulai bekerja, saya mulai berbicara dengan Aider, dan tahu-tahu satu tugas yang hari itu tidak akan saya kerjakan tanpa AI sudah selesai
    Berkat itu, proyek publik/pribadi yang dulu butuh beberapa bulan sampai beberapa tahun, sekarang bisa saya rilis setiap 2 minggu. Biaya untuk memiliki tim pengembang cepat dan berpengalaman yang duduk di sebelah saya paling mahal hanya beberapa dolar per hari

• Sebelum mengambil kesimpulan, makalah ini perlu dilihat sedikit lebih dalam. Penelitian itu sendiri tampaknya juga bisa merangkum hasilnya dengan lebih baik
  Abstrak dan kesimpulan hanya menyajikan satu angka, yaitu kenaikan produktivitas 26,08%, dan jumlah angka di belakang komanya terasa berlebihan. Jika dilihat lebih jauh, muncul angka 27~39% untuk junior dan 8~13% untuk senior
  Jika ditelaah lebih dalam lagi, bukan hanya pengalaman, variasi antarperusahaan juga besar. Di Microsoft, selain pull request, indikator hasil lain seperti commit, build, dan tingkat keberhasilan build tampaknya tidak signifikan secara statistik. Kenaikan PR tampak signifikan di Microsoft, tetapi tampaknya tidak demikian di Accenture, dan bahkan itu pun mungkin hanya berlaku untuk junior
  Abstrak dan kesimpulan memang harus merangkum, tetapi hasilnya terlalu berubah-ubah tergantung variabelnya, jadi saya tidak yakin masuk akal memberi satu angka agregat sebagai ringkasan. Terutama karena signifikansi statistiknya terlihat tidak konsisten

  • Untuk melihat lebih jelas bagaimana hasil ini muncul, perlu dibaca seperti ini. Microsoft meneliti penggunaan produk internalnya sendiri dan ingin menunjukkan efektivitasnya. Hasilnya tidak sesukses yang diharapkan secara luas
    Accenture adalah perusahaan yang bekerja sama dengan organisasi besar seperti Microsoft dan melakukan pemasaran bersama. Kelompok sekitar 300 developer nyaris tidak menggeser keseluruhan sampel, dan karena mereka juga sedang membangun divisi pemasaran/konsultasi seputar workflow AI, sulit menganggapnya objektif
    Perusahaan anonim ketiga sebenarnya bukan eksperimen terkontrol acak, jadi sulit mengatakan bagaimana hasilnya harus digabungkan dengan RCT. Selain itu, di antara perusahaan teknologi besar kemungkinan ada tempat lain yang menjalankan eksperimen serupa dan ingin mengetahui efektivitasnya, jadi masuk akal mengasumsikan ada data lain selain yang dimasukkan ke hasil
    Mengapa perusahaan-perusahaan ini yang dipilih dari kumpulan sampel yang lebih besar? Mungkin karena Microsoft dan Accenture punya insentif untuk adopsi, dan perusahaan ketiga dipilih lewat p-hacking
    Terutama kalimat di abstrak, “masing-masing eksperimen individual berisik, tetapi ketika tiga eksperimen digabungkan,” adalah sinyal yang sangat buruk. Ini pada dasarnya pengakuan bahwa jika dilihat per perusahaan, tidak ada hasil yang signifikan secara statistik, tetapi jika tiga kelompok ini digabung, hasilnya menjadi signifikan. Ini bukan sains
  • Soal angka 26,08%, jika sebuah penelitian di bidang yang bukan seperti fisika menyajikan hasil sampai dua angka di belakang koma, saya langsung curiga
  • Secara pribadi, saya merasa sebagian perbedaan itu muncul karena developer senior menerapkan pengalaman code review dan pengujian pada kode yang dihasilkan. Jadi mereka meminta perubahan, menolak hasil generasi yang buruk, dan menghabiskan lebih banyak waktu untuk membuat pengujian guna memastikan kode baru atau refactoring bekerja sesuai harapan
    Developer junior mungkin mengerjakan tugas yang mudah ditebak LLM, atau membuat kesalahan dengan menerima draf pertama hanya karena terlihat seperti LGTM, sehingga throughput mereka bisa tampak lebih tinggi
    Menggunakan model kode generatif juga butuh keterampilan, dan keterampilan itu sama dengan yang diperlukan saat mendelegasikan pekerjaan kepada orang lain dan mengintegrasikan solusi dari banyak penulis menjadi satu sistem yang koheren

• Ini hanya intuisi saya, tetapi saya melihat coding berbantuan LLM sebagai sesuatu yang merugikan pertumbuhan menjadi developer. Mungkin ini bisa menaikkan produktivitas sampai tingkat tertentu, tetapi tingkat itu bisa jadi sekadar pengulangan membosankan bagi senior, sementara bagi junior itu justru bagian dari proses pembentukan
  Dalam pengalaman saya, LLM tidak hanya dipakai untuk boilerplate sederhana, tetapi dipanggil saat developer junior menghadapi tugas yang cukup umum namun belum benar-benar mereka pahami. Proses bereksperimen, belajar, dan memahami sebagian besar digantikan oleh LLM, dan keterampilan yang sebenarnya menjadi sekadar menyesuaikan prompt sampai terlihat seperti berhasil

  • Bagi saya, ini adalah alat belajar yang nyaris terlalu bagus untuk dipercaya. Dengan memakai alat chat, saya belajar lebih luas dan lebih dalam. Ia menjadi partner percakapan yang hebat untuk mengeksplorasi topik dan mencari materi tambahan
    Tadi malam saya pertama kali menyiapkan Linux RAID. Itu bukan hal yang sangat sulit, tetapi membutuhkan berbagai alat seperti mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs, dan di tengah proses bisa menyimpang dari langkah persis di panduan, jadi hanya melihat tutorial atau dokumentasi tidak terlalu membantu
    Saya mengajukan puluhan pertanyaan tentang tiap alat dan langkah, dan di masa lalu saya mungkin hanya akan menyalin-tempel lalu berdoa
    Dua hari lalu saya juga berhasil memulihkan semua data dari SSD yang rusak sambil belajar melalui ChatGPT. Meski mungkin 20% salah, sangat menyenangkan menangani keterampilan yang benar-benar baru dengan “panduan” yang jauh lebih baik daripada rata-rata internet terbuka
    Bagi orang yang suka belajar, ini terasa seperti lompatan besar dibanding terus-menerus mengais sampah internet tanpa akhir. Tentu saja, seperti semua hal lain di internet, apa yang dikatakan AI juga harus diragukan, tetapi ini sangat mengurangi kerepotan
  • Saya sangat berharap penelitian ini membahas bagian itu. Kenyataannya, penelitian ini hanya melihat kenaikan produktivitas jangka pendek, mengabaikan utang keterampilan jangka panjang, dan sepenuhnya mengabaikan dampaknya pada pertumbuhan software developer
    Saya juga punya intuisi yang sama, bahkan saya ingin menyebutnya opini kuat yang berlandaskan alasan. Menurut saya, beberapa tahun lagi industri akan membayar harganya
    Jalur pasokan “junior software developer yang punya insting” akan mengering drastis, lalu digantikan banjir “junior software developer yang bergantung pada AI”. Di antara dua kategori itu ada jurang yang dalam
    Tentu saja ini akan menimbulkan efek berantai pada jumlah developer menengah yang punya insting dan developer senior yang punya insting
  • Menurut saya ini benar-benar sangat bergantung pada penggunanya. Dulu pun orang yang hanya menyalin-tempel kode StackOverflow sampai terlihat berjalan lalu selesai, akan menyalahgunakan LLM juga
    Sebaliknya, orang yang ingin memahami semua kode yang mereka tulis kemungkinan besar akan menyelidiki bagian yang tidak mereka kenal dari keluaran LLM
    Setidaknya saya memakainya seperti itu. Dan sebagai bantahan terhadap hipotesis tadi, kadang LLM menggunakan fungsi atau komponen library yang belum saya kenal, jadi sangat menghemat waktu saat mempelajari bahasa atau toolkit baru. Bagi saya, ini mempercepat pembelajaran, bukan memperlambatnya
  • Seperti hal-hal lain, ini bisa disalahgunakan. Sama seperti menyalin-tempel dari StackOverflow lalu berhenti kalau kebetulan berjalan
    Tetapi bagi orang yang memang akan berhasil bagaimanapun, ini benar-benar hadiah besar, seperti bisa melempar pertanyaan ke StackOverflow dan langsung mendapat jawaban tanpa celaan
    Memang tidak selalu benar, tetapi StackOverflow juga begitu. Pada akhirnya, seperti biasa, semuanya kembali ke individunya
  • Melihat kemajuan LLM selama 2 tahun terakhir, saya jadi bertanya apakah memilih untuk tidak benar-benar mendalaminya itu taruhan yang buruk
    Lima puluh tahun lalu, bahasa mesin pada dasarnya wajib dikuasai untuk membuat sesuatu, tetapi berapa banyak developer saat ini yang benar-benar bisa menggunakannya
    Mungkin LLM sedang berubah dari sekadar kruk abstraksi lain menjadi pilar abstraksi yang kokoh

• Hal paling menarik dari studi ini adalah, ketika dibagi berdasarkan tingkat pengalaman, pengembang dengan masa kerja di atas median tidak menunjukkan peningkatan yang signifikan secara statistik pada proksi buruk yang disebut “produktivitas” itu. Interval kepercayaan 95% bahkan turun cukup dalam ke sisi negatif pada semua metrik, hanya sedikit saja condong ke sisi positif
  Ini juga sesuai dengan pengalaman saya. Copilot bagus untuk mengurangi sebagian pekerjaan membosankan dan membiarkan otak dipakai untuk pertanyaan yang lebih dalam, tetapi tidak sampai level mengubah dunia seperti yang sering dikatakan para pengembang junior
  Selain itu, ia juga sering salah secara halus, dengan cara yang mungkin terlewat oleh pengembang yang kurang berpengalaman. Saya harus berhenti dan menyesuaikan sebagian besar hasil yang dihasilkannya, dan pengembang yang kurang terampil kemungkinan besar tidak tahu bagaimana harus melakukan penyesuaian itu
  Setelah memakainya selama beberapa tahun, sekarang saya sudah cukup paham kapan Copilot sebaiknya dipakai dan kapan tidak, jadi saya rasa efek bersihnya positif, tetapi tidak selalu begitu
  Saya juga penasaran apakah sebagian alasan mengapa “produktivitas” pengembang senior tampak menurun adalah karena produktivitas para junior di perusahaan meningkat. Jika junior membuat lebih banyak PR dan lebih banyak kesalahan di dalamnya sehingga waktu review bertambah, peningkatan produktivitas senior bisa berkurang secara proporsional

• Peningkatan produktivitas 26% secara umum juga sesuai dengan pengalaman saya. Dimensi lain yang layak dilihat adalah apakah yang dikerjakan itu teknologi baru atau teknologi yang sudah familier. AI jauh lebih membantu pada bahasa atau framework yang sedang saya pelajari

  • Saya ingin memperluasnya ke “bahasa/framework yang memang tidak berniat saya pelajari dengan benar”
    Saya tidak terlalu ingat kekhasan dan jebakan bahasa pendukung, seperti mantra tanda kutip seperti apa yang tepat untuk menulis kondisional di Bash. Karena itu, dulu saya hampir tidak pernah menulis skrip Bash untuk otomasi, dan hanya mau berusaha jika pekerjaannya cukup sering dilakukan. Hal yang sama berlaku untuk memproses JSON dengan jq atau parsing dengan AWK
    Sekarang, berkat LLM, saya jauh lebih sering membuat skrip Bash, dan karena jadi terlalu mudah, saya juga lebih sering memakainya untuk dokumentasi proses. Sesuatu yang dulu berupa README statis langkah demi langkah kini disertai skrip Bash interaktif yang menerima input pengguna
  • Copilot cukup bagus untuk mengurangi kebosanan. Misalnya, ia umumnya menulis docstring dengan baik. Tapi ia tidak mengurangi beban mental nyata dari rekayasa perangkat lunak
  • Bisa jadi begitu. Mungkin ini juga hasil dari seberapa fleksibel seseorang pada tiap tahap karier
    Secara umum saya lebih sering melihat programmer senior membahas kenapa alat AI tidak bekerja. Para junior memakainya begitu saja tanpa prasangka
  • Dalam pengembangan produk utama, ini tidak terlalu berguna. Memang berbasis Python, tetapi karena memakai framework internal, CoPilot tidak punya banyak kode rujukan dan malah menyarankan metode serta argumen yang tidak ada, sehingga pekerjaan justru bertambah
    Ada empat area tempat ini berguna. Pertama, untuk pertanyaan tentang framework/bahasa seperti Qt atau CSS yang tidak sering saya pakai tetapi punya banyak contoh konten
    Kedua, untuk pertanyaan yang sangat spesifik yang sebelumnya akan saya cari lewat Google Search atau StackOverflow. Misalnya, untuk pertanyaan seperti “cara paling efisien mendapatkan penggunaan CPU dan RAM Windows dengan Python”, alih-alih langsung membuat kode untuk disalin-tempel, ia menunjuk ke library atau contoh
    Ketiga, untuk boilerplate yang sebenarnya sudah saya tahu cara menulisnya, tetapi bisa menghemat sedikit waktu dan mengurangi salah ketik. Saat memakai plugin CoPilot untuk PyCharm, saya menulis niat saya sebagai komentar di file lalu ia melengkapi beberapa baris berikutnya. Lagi-lagi, hasilnya paling bagus jika sangat pendek dan spesifik. Kalau sudah panjang, saya harus terlalu banyak bolak-balik dengan CoPilot sehingga tidak lagi sepadan
    Keempat, sebagai cara cepat menelusuri dokumentasi
    Ada juga yang bilang ini bagus untuk menulis unit test, tetapi saya tidak merasa begitu. Setidaknya bukan untuk jenis unit test yang saya inginkan
    Kalau harus dikuantifikasi, saya melihat peningkatan produktivitasnya sekitar 5~10%. Jauh lebih kecil dibanding memakai IDE penuh seperti PyCharm alih-alih Notepad, atau memakai klien git yang bagus alih-alih mengetik langsung perintah git di CLI. Jadi ini hanya salah satu dari banyak alat produktivitas, dan saya tidak akan menyebutnya “revolusioner”
  • Kesan saya juga mirip
    Saya mencoba Cursor sekitar 10 hari pada proyek Ruby on Rails yang sangat besar, dan saya sudah memakai stack ini lebih dari 13 tahun
    Saya tidak mendapatkan peningkatan produktivitas tambahan di luar yang sudah diberikan GitHub Copilot. Peningkatan dari Copilot sendiri saya perkirakan sekitar 25%
    Tetapi untuk pertama kali membuat proyek baru dari folder kosong, misalnya dengan Node.js, ini terasa sangat kuat sampai agak aneh. Hanya dengan prompt, dalam sekitar 5 menit ia bisa membuat API yang menangani request dari skema OpenAPI dan menyajikan skema OpenAPI dengan swagger
    Namun memulai proyek baru dari nol adalah hal yang jarang bagi saya, jadi saya mungkin akan kembali ke Copilot dan VSCode standar

• Ini memungkinkan orang membuat lebih banyak PR. Wah, hebat sekali. Siapa peduli
  Apakah jumlah item yang lolos QA meningkat? Apakah hal-hal yang dibuat dengan bantuan AI memiliki lebih sedikit bug yang ditemukan setelah QA? Apakah lebih mudah diperluas atau dimodifikasi nantinya, atau justru desainnya kaku dan tidak fleksibel?
  Alat yang mengubah pengembang menjadi monyet kode dengan kualitas kode yang tidak diketahui bukanlah yang saya cari. Saya ingin alat yang membantu pengembang menemukan bug atau cacat desain dalam pekerjaan mereka, atau alat yang membantu mereka menulis test yang dirancang dengan baik
  Hanya menghitung jumlah PR tidak mengatakan hal berguna apa pun. Malah, jika jumlah kode per satuan waktu meningkat, itu menyentuh intuisi saya bahwa kualitas rata-rata justru menurun

  • Pengembang: “Copilot, tolong pecah commit ini menjadi 5 commit”
    Copilot: “Baik, saya kerjakan! Ini commit-commit barunya!”
    Pengembang senior: “Kenapa? Perubahannya sudah atomik. Kalau manajemen kembali mengangkat metrik bodoh seperti jumlah perubahan bulanan, saya akan bilang dengan sopan agar mereka enyah”

• Ini kemungkinan besar adalah Copilot berbasis GPT-3.5
  Microsoft: September 2022~3 Mei 2023
  Accenture: Juli 2023~Desember 2023
  Perusahaan anonim: Oktober 2023~?
  Pembaruan GPT-4 untuk Copilot Chat terjadi pada 30 November 2023: https://github.blog/changelog/label/copilot/

  • Poin yang bagus. Saya sangat penasaran seperti apa hasilnya jika memakai hal seperti Cursor atau langsung memakai Claude. Sekarang saya terkejut melihat betapa mudahnya memulai skrip kecil yang sederhana dengan Claude

• Bagi saya, AI telah menghidupkan kembali dokumentasi. Framework baru terlalu minim dokumentasi. Dokumentasi bagus terakhir yang saya ingat adalah buku-buku DOS. Rasanya pengembang zaman sekarang bahkan tidak punya gambaran seperti apa dokumentasi yang bagus
  Meski begitu, karena AI bisa memberi saran berbeda setiap kali, penilaian tetap harus dilakukan oleh pengembang berpengalaman. Pada akhirnya AI menggantikan dokumentasi dan pengetikan

  • Menurut saya, AI justru membuat nilai dokumentasi makin tinggi
    Untuk proyek terbuka, dokumentasi menjadi bagian dari data pelatihan LLM, jadi jauh lebih penting agar dokumentasinya menyeluruh dan akurat. Karena banyak pengembang akan mendapatkan jawaban dari sistem itu
    Untuk proyek tertutup, dokumentasi bisa dimasukkan ke dataset fine-tuning atau sistem RAG untuk mendapatkan efek yang sama
  • Kadang di HN muncul diskusi seperti “bagaimana kalian mengelola dokumentasi internal”, dan kebanyakan menulis dengan nada “dokumentasi cepat usang jadi tidak ada gunanya menulisnya”. Bahkan dalam beberapa hari terakhir saja ada dua thread seperti itu
    Itu mungkin menjelaskan kenapa tidak ada apa pun yang didokumentasikan
  • Betul. AI juga bisa membantu menulis dokumentasi, dan hasilnya lebih baik kalau dimulai dari dokumentasi terlebih dahulu. Misalnya, jika kita lebih dulu menulis komentar yang menjelaskan apa yang dilakukan sebuah fungsi, AI akan membantu menulis fungsinya jauh lebih baik
    Jadi ada efek nyata yang mendorong pengembang untuk mendokumentasikan kode mereka dengan lebih baik
  • Saya benar-benar suka menulis dokumentasi yang bagus. Tentu saya tidak selalu punya kesempatan untuk melakukannya, tetapi bisakah Anda memberi tahu satu dokumentasi yang menurut Anda luar biasa
    Tidak harus dokumentasi live modern, apa pun boleh. Saya ingin melihat apa yang dulu begitu hebat namun kini kita hilangkan, lalu mencoba menerapkan sebagian darinya ke dokumentasi saya