- Whitepaper Coding on Copilot dari GitClear menganalisis, berdasarkan data perubahan kode, apakah kode berbantuan AI dapat meningkatkan produktivitas tetapi sekaligus membebani kualitas dan kemudahan pemeliharaan
- Code churn, yaitu kode yang dibatalkan atau diperbaiki dalam 2 minggu setelah ditulis, diperkirakan akan menjadi dua kali lipat pada 2024 dibandingkan baseline pra-AI tahun 2021
- Setelah Copilot meluas, proporsi kode yang ditambahkan dan kode salin/tempel meningkat, sementara penurunan kode yang dipindahkan mengisyaratkan melemahnya refactoring dan reuse
- Studi GitHub tahun 2022 melihat pengguna Copilot menyelesaikan tugas 55% lebih cepat, tetapi GitClear berfokus pada biaya pemeliharaan jangka panjang ketimbang produktivitas
- Analisis terhadap 153 juta baris perubahan kode yang ditulis dari Januari 2020 hingga Desember 2023 menunjukkan bahwa para pemimpin teknologi perlu menilai dampak adopsi AI dengan metrik kualitas kode
Karakter kode berbantuan AI menurut whitepaper GitClear
- Whitepaper Coding on Copilot meneliti perbedaan kode berbantuan AI dalam hal kualitas dan kemudahan pemeliharaan dibandingkan kode yang akan ditulis manusia
- Pertanyaan utamanya adalah apakah kode berbantuan AI lebih mirip kontribusi developer senior yang dipoles dengan cermat, atau pekerjaan terputus-putus dari kontraktor jangka pendek
- GitClear adalah perusahaan yang menjual alat code review berbasis cloud, dan riset ini berfokus pada bagaimana komposisi perubahan kode bergeser setelah penggunaan AI
Sinyal negatif pada kemudahan pemeliharaan
- GitClear menemukan tren yang mengkhawatirkan dari sisi kemudahan pemeliharaan
- Code churn adalah rasio baris kode yang dibatalkan atau diperbarui dalam 2 minggu setelah ditulis
- Rasio ini diperkirakan akan menjadi dua kali lipat pada 2024 dibandingkan baseline pra-AI tahun 2021
- Rasio kode yang ditambahkan dan kode salin/tempel meningkat dibandingkan kode yang diperbaiki, dihapus, atau dipindahkan
- Karena perubahan ini, kode yang dihasilkan AI dinilai menyerupai kontributor keliling yang mudah melanggar prinsip DRY pada repositori yang dikunjunginya
Tiga perubahan yang terkait dengan meluasnya Copilot
- GitClear menyebut churn, kode yang dipindahkan, dan kode salin/tempel sebagai perubahan penting setelah adopsi Copilot
-
Churn yang meningkat
- “Penggunaan Copilot” dianggap sangat berkorelasi dengan kode keliru yang di-push ke repositori
- Ini terkait dengan alur ketika kode berbantuan AI ditambahkan dengan cepat lalu dibatalkan atau diperbaiki dalam waktu singkat
-
Kode yang dipindahkan menurun
- Penurunan kode yang dipindahkan mengisyaratkan berkurangnya refactoring dan reuse
- Jika dilihat bersama peningkatan kode salin/tempel, implementasi AI assistant saat ini ditafsirkan belum cukup mendorong reuse kode
- Alih-alih membuat kode DRY lewat refactoring, AI memberi godaan untuk mengulang kode yang sudah ada hanya dengan satu tekanan tombol
-
Kode salin/tempel meningkat
- Kode salin/tempel dinilai sebagai faktor yang sangat membebani kemudahan pemeliharaan jangka panjang
- Ketika yang berulang adalah baris kode, bukan keyword, hal itu ditafsirkan sebagai sinyal bahwa tidak ada waktu untuk mengevaluasi implementasi sebelumnya
- Jika kode ditambahkan kembali tanpa reuse, maintainer berikutnya harus menggabungkan jalur kode paralel yang mengimplementasikan fungsi berulang
Kontras dengan studi produktivitas
- Studi GitHub tahun 2022 melihat developer yang menggunakan Copilot menyelesaikan tugas 55% lebih cepat dibandingkan developer yang tidak menggunakannya
- Studi yang sama juga mengukur efek positif di luar produktivitas, seperti kepuasan developer dan terjaganya energi mental
- Berbeda dari hasil produktivitas tersebut, whitepaper GitClear menganalisis perubahan komposisi perubahan kode dan aspek kemudahan pemeliharaan saat AI digunakan
Penilaian beragam dari riset terkait
- Exploring the Verifiability of Code Generated by GitHub Copilot: menemukan bukti yang sejalan dengan konsensus literatur sebelumnya bahwa Copilot adalah alat yang kuat, tetapi tidak boleh “menerbangkan pesawat” sendirian
- Assessing the Quality of GitHub Copilot's Code Generation: hasil analisis empiris menunjukkan Copilot adalah alat yang menjanjikan, tetapi ke depan diperlukan evaluasi yang lebih komprehensif
- Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle: seiring meningkatnya kemahiran dalam prompting AI generatif, terbentuk hubungan unik dan sulit dipisahkan antara manusia dan AI
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot: efek heterogen yang diamati menunjukkan kemungkinan bahwa AI pair programmer dapat membantu orang beralih ke karier pengembangan perangkat lunak
- Study of software developers' experience using the Github Copilot Tool in the software development process: pendapat developer terbelah; sikap mereka umumnya positif, tetapi tidak banyak yang berniat benar-benar menggunakannya, dan isu keamanan muncul sebagai kekhawatiran
Cakupan analisis dan pertanyaan yang tersisa
- GitClear mengumpulkan dan menganalisis 153 juta baris perubahan kode yang ditulis dari Januari 2020 hingga Desember 2023
- Mereka juga menyampaikan diagnosis bahwa, seiring popularitas AI yang melonjak, kita telah memasuki era ketika baris kode ditambahkan lebih cepat daripada sebelumnya
- Pertanyaan pada 2024 bukan lagi bagaimana Copilot akan mengubah makna menjadi developer, melainkan siapa yang akan menangani pekerjaan merapikan yang muncul setelahnya
1 komentar
Komentar Hacker News
Saya berhenti berlangganan setelah memakainya 2 bulan. Biaya mental untuk memperbaiki kesalahan dari muntahan kode yang terus mengalir terlalu besar, dan untuk pekerjaan yang tidak sepele atau terkait SQL, hampir tidak berguna meski seluruh skema dimasukkan lebih dulu
Karena saya tahu apa yang ingin saya tulis, menulisnya sendiri jauh lebih tidak melelahkan, dan memperbaiki kesalahan saya sendiri lebih mudah daripada kesalahan bot. Saya khawatir para junior akan tertimbun sampah ini
Saya memakai ChatGPT alih-alih Copilot, dan terkejut karena banyak hal yang bisa dilakukannya, tetapi tetap sulit menyebutnya “kode bagus”. Saya bisa membaca JavaScript, tetapi selama 14 tahun terakhir saya berspesialisasi di iOS sehingga tidak terlalu tahu praktik terbaik di sisi browser; karena itu saya memakainya, dan meski biasanya mendapat kode yang berjalan, pilihan buruk atau keanehan tetap terlihat
Menurut saya sikap yang tepat terhadap AI saat ini adalah menghindari dua ekstrem “semuanya sudah selesai” atau “ini bukan apa-apa”. Untuk kubu yang terakhir, perlu analogi seperti “seekor anjing bisa juggling, mengurus laporan pajak, dan memanggang kue, tetapi alih-alih kagum bahwa ia bisa melakukan itu, orang malah mengeluh karena bolanya jatuh, angkanya salah, dan resepnya kurang enak”
Copilot paling berguna sebagai alat autocomplete yang mengurangi pengetikan saat menulis kode berbasis konteks yang bisa diprediksi. Jika Anda menulis enum class di satu jendela, ia bisa meng-autocomplete bagian penggunaannya di jendela lain berdasarkan konteks, dan saat menulis sekumpulan unit test, satu Tab saja bisa membuat kerangka test case berikutnya
Terutama di bahasa dinamis, Copilot cukup baik melengkapi IntelliSense
Beberapa bulan lalu saya pernah menulis bahwa industri pengisi suara mau tidak mau akan terdorong keluar oleh model text-to-speech, disertai contoh typesetting, penjilidan, dan penyusunan notasi musik: https://news.ycombinator.com/item?id=38491203
Namun kalau pengembangan itu sendiri menjadi kosong seperti ini, saya tidak begitu tahu seperti apa kondisi akhirnya. Karena para developer jugalah yang mendorong berbagai penggantian di masa lalu. Bentuk kemunduran dan keruntuhan sosial tertentu tampaknya tidak sepenuhnya mustahil
“Parse JSON ini lalu masukkan field tersebut ke posisi yang sesuai di database” adalah use case yang sangat bagus untuk menulis SQL dengan Copilot. Bisa saja memakai plugin ORM atau middleware, tetapi untuk MVP atau mockup, itu optimasi dini yang berlebihan
Sebaliknya, saya sering memakai ChatGPT API dan itu cukup praktis. Saat saya menulis SQL update yang menyentuh jutaan baris, saya memintanya mengubahnya agar dipecah per batch dan mencetak log status setelah tiap batch; saat mendapat 401 ketika mengakses nuget feed di Azure DevOps, ia memberi bukan hanya penyebabnya tetapi juga yaml untuk memperbaikinya
Keduanya sebenarnya bisa saya lakukan sendiri dengan sedikit riset, tetapi sangat menyenangkan karena tidak perlu menghabiskan waktu untuk riset itu
Berkat GPT-4, efisiensi kerja saya meningkat pesat. Saya terutama membuat aplikasi PHP CRUD sederhana untuk menyelesaikan masalah pekerjaan sehari-hari, dan karena tidak memakai framework atau struktur MVC, kode yang dihasilkan GPT-4 berdasarkan instruksi yang jelas mudah dipahami dan biasanya langsung berjalan
Biasanya saya memintanya mengubah potongan kode sekitar 25 baris agar sesuai dengan fungsi pelaporan tertentu; misalnya jika saya memintanya mengelompokkan berdasarkan X dan menjumlahkan Y di halaman ini, ia merespons dengan tepat. Setelah QA dan pengujian cepat, selesai; untuk pekerjaan dengan kompleksitas rendah dan instruksi yang jelas, dampaknya benar-benar mengubah permainan
Proses ini mirip dengan cara programmer senior memecah pekerjaan menjadi komponen dasar lalu menyerahkannya kepada junior. Di sini GPT-4 berperan sebagai programmer junior seharga 20 dolar per bulan, dan karena menghemat waktu, saya rela membayarnya dari kantong sendiri
Namun seperti ketika waktu kecil saya bertanya mengapa harus belajar matematika kalau ada kalkulator, sekarang saya mengerti mengapa harus mempelajari dasar-dasarnya. Kalau tidak tahu dasar, kita tidak bisa menggunakannya secara efektif. Jika GPT-4 sudah ada saat saya belajar PHP, saya tidak akan memahami dasar-dasarnya sedalam sekarang. Saya diuntungkan karena belajar sebelum alat ini ada
Saya juga tidak merasa kualitas kodenya lebih rendah; malah kadang hasilnya lebih rapi
Menurut saya banyak kritik masih terlalu dini, dan ini lebih mirip kemajuan yang tersendat-sendat serta membutuhkan dukungan infrastruktur tambahan. Di mana integrasi linter yang mencegah hasil yang tidak bisa dikompilasi, dan di mana fitur yang otomatis menemukan serta memperbaiki kesalahan tingkat rendah?
Seperti apa seharusnya pengujian dalam lingkungan pengembangan AI generatif, dan bagaimana ia harus berubah, juga masih terbuka. Mungkin ada cara yang lebih baik untuk memaksimalkan manfaat sekaligus mengurangi biaya dari pendekatan prosedural seperti TDD atau BDD
Satu atau dua tahun terakhir adalah masa ketika perubahan teknologi besar begitu saja dilemparkan ke alur kerja yang sudah ada. Apa pun alatnya, hasil muncul dari gabungan kemampuan alat itu sendiri dan pengalaman orang yang memakainya
Industri perlu mengumpulkan jauh lebih banyak pengalaman dan kebijaksanaan dalam mengintegrasikan AI generatif ke pengembangan sebelum bisa merasakan nilai bersihnya yang sebenarnya. Menurut saya setidaknya masih perlu 2–3 tahun lagi, bukan karena adaptasi teknologinya, melainkan karena waktu yang dibutuhkan manusia untuk beradaptasi
Saya sudah melihat tim berusia 20-an menghasilkan segunung spaghetti full-stack di atas framework CRUD dasar yang saya buat. Jika bisa menghasilkan “MMO framework” dalam 60 detik, insentif untuk membuat aplikasi TODO dari nol akan berkurang
Ini mirip dengan saya yang memakai Firebase lebih dulu sebelum mempelajari dasar-dasar relasional 12 tahun lalu, dan butuh bertahun-tahun sampai akhirnya sampai ke dasar-dasar itu
Kita tidak bisa melihat masa depan secara tepat, tetapi saya percaya cara kita memandang kualitas akan berubah
Ada suasana bahwa teknologi akan menjadi penyelamat bagi berbagai masalah penting di semua bidang di sekitar kita, seperti kendaraan listrik, kesehatan, IT, keuangan, dan sebagainya. Pada saat yang sama, semakin jelas bahwa teknologi terutama dipakai untuk memperbesar pasar, pemerintah, negara, dan sejenisnya, serta bekerja dengan cara menambahkan lapisan lain di atas abstraksi yang sudah bocor. Rasanya lebih seperti mencoba mencairkan gejala daripada menyelesaikan masalah
Kualitas mencakup kelambatan, dan karena penanganan gejala memiliki batas, serta manusia tidak akan mampu menghadapi tantangan dengan terus menambahkan lebih banyak abstraksi, saya pikir kelambatan itu akan menjadi perlu
Saya pikir gagasan bahwa kita harus menjadi lebih cepat itu keliru. Saya percaya kualitas tidak akan muncul dari cara mencoba menyelesaikan sesuatu demi keuntungan dangkal tanpa memahami dasar tantangannya sebagai manusia
LLM adalah bencana bagi bidang kita. Sebab ia mengakomodasi kekeliruan manusia rata-rata yang ingin mencapai tujuan tanpa melakukan pekerjaan sungguhan. Pekerjaan sungguhan adalah menerapkan asumsi tentang kebenaran dan memahami apa yang sebenarnya ingin kita selesaikan
Untungnya, tidak semua orang berusaha bergerak lebih cepat; sebagian orang sedang mempelajari kembali dasar-dasar, menerapkan keputusan yang cermat, serta mengasah pemikiran dan alat mereka untuk menciptakan kualitas yang tahan lama
Pengalaman saya hampir kebalikannya. Alih-alih pekerjaan menelusuri API atau library yang berantakan menghalangi bagian yang sulit, LLM justru membuat sangat jelas, sampai terasa menyakitkan, ketika pemikiran saya belum kokoh dalam pekerjaan yang bermakna
Untuk melakukan sesuatu dengan LLM, kita harus menulis; dan untuk menulis, kita harus berpikir. Sering kali hal yang paling bermanfaat adalah saya bisa merumuskan dengan hati-hati apa yang ingin saya lakukan, ditusuk-tusuk oleh LLM, menemukan celah dalam pemikiran saya lewat proses itu, lalu melihat kembali riwayat chat yang sudah diperjelas
Khususnya pada tahap awal aplikasi saat membentuk arahnya, ini sangat berguna untuk melacak apa yang saat itu saya pikir perlu dilakukan dan kemudian meninjau kembali apakah hal itu masih benar
Mereka mendengar permainan profesional di klub lalu pulang dan mencoba menirunya, tetapi hasilnya hanya gumpalan kacau tanpa dasar. Ia menekankan bahwa kita harus puas melakukan hal-hal sederhana dan secara bertahap membangun dasar yang lebih kuat
Wawasan ini hampir sepenuhnya berlaku juga untuk penggunaan kode yang dihasilkan AI
Furnitur IKEA adalah contoh yang bagus. Jika Anda membuat furnitur sendiri, rasanya jauh lebih baik berada di sekitarnya dibandingkan barang IKEA yang seperti kardus. Namun dalam benak orang-orang, biaya, kecepatan, dan kenyamanan tampaknya menjadi hal terpenting
Model AI merampas pengalaman bawaan itu dan hanya memberi krim dari hasil akhirnya. Ini mirip seperti menonton porno alih-alih menjalin hubungan nyata hingga mencapai seks
Jika digunakan dengan cerdas, alat seperti Copilot membantu. Ia menangani boilerplate dan bagian-bagian membosankan sehingga manusia bisa fokus pada pemikiran berat
Selain itu, ini masih tahap awal. Terlalu dini untuk menghakimi, dan sepertinya juga tidak akan hilang
Metodologinya tampak membandingkan aktivitas commit tahun 2023 dengan tahun-tahun sebelumnya, lalu menafsirkan perubahan sebagai asumsi tanpa mengetahui seberapa besar Copilot terlibat di dalamnya. Ini pendekatan yang cukup goyah
Selain itu, tertulis bahwa “prediksi 2024 menjalankan regresi kuadratik pada data yang ada dengan Assistant gpt-4-1106-preview dari OpenAI”; saya jadi bertanya-tanya apakah mereka benar-benar menyuruh GPT melakukan regresi dengan empat data, alih-alih memakai alat regresi sederhana seperti sklearn, R, atau Excel. Bahkan jika dilakukan dengan benar, dengan hanya empat data ditambah kekhawatiran pertama tadi, daya yakinnya lemah
Disebut regresi kuadratik sehingga terdengar meyakinkan, tetapi dengan dua titik data, pada dasarnya itu hanya “memperpanjang garis apa adanya”. Jadi prediksi 2024 pada hakikatnya hampir tidak bermakna
Saya penulis studi aslinya. Senang melihat banyak orang memikirkan kualitas kode jangka panjang. Pada 2023, peningkatan churned code dan duplikasi—yakni kode hasil copy-paste—serta penurunan moved code bahkan lebih besar daripada perkiraan kami
Saya berharap tim pengembang dan pembuat AI Assistant mengadopsi metrik dan insentif yang mendorong kode yang digunakan kembali ketimbang kode yang baru ditambahkan. Tim yang berada di bawah manajer yang percaya bahwa LoC harus dimasukkan dalam evaluasi kinerja sangat berisiko. Menurut studi GitHub, kira-kira sepertiganya seperti itu, dan alat bantu kode generasi saat ini membuatnya terlalu mudah menekan Tab lalu commit, menanam utang teknis untuk masa depan. Seperti yang dikatakan Adam Tornhill di Twitter, “tantangan inti dalam pemrograman berbantuan AI adalah menjadi terlalu mudah untuk menghasilkan kode dalam jumlah besar yang sejak awal seharusnya tidak ditulis”
Namun, signifikansi studi saat ini terbatas karena tidak mengukur secara langsung kode yang ditulis AI. Kami hanya memetakan korelasi antara kualitas kode dan penyebaran AI Assistant selama 4 tahun terakhir. Saya berharap GitHub atau perusahaan AI Assistant lain mau bekerja sama dalam studi lanjutan agar kami dapat mengukur secara langsung perbedaan kualitas antara “kode yang sepenuhnya disarankan AI”, “kode saran AI yang dimodifikasi manusia”, dan “kode yang ditulis dari awal”
Dalam studi berikutnya, saya juga ingin mengukur secara langsung bagaimana frekuensi bug berubah sesuai penggunaan AI. Jika ada ide lain yang bagus untuk diukur, silakan usulkan. Saya berencana menerbitkan makalah riset baru kira-kira setiap 2 bulan
Penggunaan ulang kode bisa sangat kuat di dalam satu codebase, tetapi saya juga pernah melihatnya menciptakan kekacauan ketika melintasi codebase. Itu bisa berguna, bisa juga tidak tepat dan membingungkan, dan hasilnya umumnya bergantung pada penilaian
Menurut saya, lebih baik menilai developer berdasarkan hasil dari perangkat lunak. Misalnya dampak terhadap organisasi dibanding penggunaan sumber daya, atau error layanan yang tidak berasal dari layanan dependen maupun infrastruktur
Programmer modern bukan hanya orang yang bertanggung jawab atas kode, melainkan campuran yang disengaja antara quality engineer/tester, technical product manager, project manager, programmer, performance engineer, dan infrastructure engineer. Saya tidak bermaksud meremehkan risetnya; saya senang ada orang yang sangat peduli pada kualitas kode, dan menurut saya kita perlu memikirkan cara evaluasi secara berbeda
Saya juga penasaran apakah mereka mengontrol kemungkinan penjelasan lain, seperti perubahan ekonomi teknologi
Makalah ini membenchmark performa LLM paling populer pada tugas refactoring kode nyata, dan menyatakan bahwa AI hanya memberikan refactoring yang benar secara fungsional pada 37% kasus
Coding berbantuan AI memang berguna, tetapi kita harus tetap melibatkan manusia berpengalaman dalam loop dan menetapkan ekspektasi realistis di luar hype pemasaran
Alur kerja saya biasanya: membaca sekilas dokumentasi, membuat prototipe, sedikit merapikan kode, menambahkan test, memindahkan, memecahkan, mengerjakan ulang, mempelajari dokumentasi, melakukan refactoring lagi, lalu barulah cukup memahami masalah untuk membuang 80% kode dan membuat ulang dengan benar
Jika Copilot memberi kode yang cukup berfungsi pada tahap prototipe sehingga saya langsung lanjut ke tahap berikutnya, pemahaman saya tidak menjadi cukup dalam untuk menyusun keseluruhannya dengan benar. Ia memungkinkan saya melewati 90% alur kerja, tetapi ada harga yang harus dibayar. Tentu saja pada tahap akhir pengembangan, Copilot bisa sangat membantu
Jika hasil studi itu benar, saya tidak terkejut. Kode buruk berasal dari pemahaman yang kurang, dan Copilot tidak bisa memiliki pemahaman melebihi apa yang saya berikan. Ia mungkin bisa menulis kode lebih baik daripada programmer rata-rata, tetapi hasilnya tidak bisa lebih baik daripada inputnya. Orang-orang begitu fokus pada “prompt engineering”, jadi saya tidak mengerti mengapa mereka terkejut ketika “prompt” yang buruk di VSCode menghasilkan keluaran yang buruk
Dari pengalaman saya, Copilot sangat bagus untuk membantu memulai. Kodenya kadang bagus, kadang biasa saja atau benar-benar rusak
Meski begitu, ia berharga karena membuat saya mulai berpikir. Sebelum menggunakannya, saya jauh lebih banyak membuang waktu. Mungkin memang sirkuit otak saya yang tidak biasa
Saya masih junior dan memasang Codeium di VSCode, tetapi dalam kebanyakan kasus rasanya sangat mengganggu. Saya tidak begitu paham kenapa begitu banyak orang memakai alat bantu seperti ini.
Yang seperti Phind itu berguna. Saat ada sesuatu yang tidak saya pahami, sekitar 60% dari waktu ia membantu saya memahami masalahnya. Misalnya menemukan bug kecil yang terlewat karena saya lelah atau sedang tidak fokus.
Sebaliknya, Codeium mungkin berguna saat menghasilkan boilerplate untuk framework, tetapi dalam pengalaman kecil saya dengan scraper, pipeline data sederhana, dan JS+HTML/CSS murni, menelusuri sarannya sangat menyebalkan. Terutama karena sering kali tidak berjalan, dan meski alasannya sepele seperti ada satu argumen yang kurang, pada akhirnya tetap harus menghabiskan waktu untuk debugging.
Selain itu, di JavaScript ada gaya umum yang menyambung method dan fungsi anonim tanpa henti seperti daisy chain, dan itu benar-benar menyulitkan saya. Saya lebih suka memecah baris serta memberi nama pada fungsi dan variabel. Saran kode juga sering mengikuti gaya itu, mungkin karena data latihnya seperti itu. Codeium memang katanya mempelajari hal ini, dan kadang memang begitu.
Hal yang paling saya khawatirkan adalah, sebagai junior, bagaimana saya bisa belajar kalau menyerahkan kode ke alat bantu seperti ini. Memberi konteks dan pertanyaan ke Phind membantu saya belajar atau memberi arah untuk mencari sendiri di internet, tetapi saya tidak tahu bagaimana saya bisa belajar hanya dengan menekan Tab.
Beberapa hari lalu saya menyadari bahwa banyak orang, termasuk developer, memakai LLM bukan sebagai alat untuk menjadi lebih baik, melainkan sebagai pengganti usaha. Rasanya menakutkan, bukan hanya karena perusahaan mungkin akan menggantikan kita, tetapi juga sebagai persoalan refleksi diri.
Coding bukan passion hidup saya, tetapi saya menyukainya. Karena coding memungkinkan saya membuat sesuatu terjadi dan menangani kompleksitas. Jika tidak memahami apa yang terjadi, kita tidak bisa membuat sesuatu, dan juga tidak bisa menyadari kapan kompleksitas mulai memakan kita.
Teruskan saja seperti itu, jangan berubah, dan kamu akan menuju tempat yang baik. Kamu jelas berada di jalur yang benar.
Yang penting, selama karier saya sudah menulis terlalu banyak spesifikasi API secara manual, sehingga 1) saya bisa langsung melihat masalahnya dan 2) saya bisa memperbaikinya tanpa bantuan tambahan. Memperbaiki model secara manual lebih cepat daripada menyempurnakan prompt.
Di area yang saya kuasai, melihat sesuatu yang biasanya memakan waktu sepanjang pagi selesai dalam 30 detik itu mengagumkan. Namun saya tidak menyuruh AI melakukan hal yang tidak bisa saya lakukan sendiri. Sebagai gantinya, saya banyak berdiskusi dengan AI tentang trade-off, potensi isu keamanan, dan sebagainya terkait hal yang sedang saya kerjakan.
Rasanya seperti engineer junior yang punya gelar doktor dalam bahasa yang saya gunakan. Ia tidak memahami banyak hal, tetapi hal-hal yang ia pahami tampak dipahami secara mendalam.
Sebagian developer, terutama developer JS, menyukai chaining meski tidak ada manfaatnya selain membuatnya tetap dalam satu baris. Itu bukan manfaat. Teruskan seperti sekarang, dan jangan biarkan idiom bodoh ini menginfeksi pikiranmu.
Momen ketika teknologi ini terasa luar biasa adalah saat ia menyesuaikan dengan gaya dan preferensi saya. Misalnya memberi nama dengan cara yang saya inginkan, dan menggunakan method yang baru saja saya tulis dengan benar alih-alih mengimplementasikannya ulang.
Saya belum banyak mencobanya di proyek kosong atau kecil, tetapi jika ia tidak sangat condong pada cara yang sudah saya pakai berdasarkan konteks sekitar, rasanya pasti jauh kurang ideal.
Kegunaan terbesar alat bantu AI bagi saya adalah menulis test dan mempercepat perubahan berulang yang “mirip dengan ini, tetapi sedikit berbeda”. Di IntelliJ + GitHub, untuk pekerjaan ketika parameter baru harus diterapkan ke beberapa method dan file, setelah mengetik dua atau tiga variasi pertama sendiri, sisanya biasanya bisa ditangani dengan enter + tab. Konteks mengisi sisanya.
Codeium di VSCode tampaknya AI-nya sendiri kurang memadai, dan pluginnya juga terasa ditulis dengan cara yang sering membuat tombol saran dan penerimaan mengganggu. Masih membantu untuk pekerjaan berulang, tetapi kurang dalam hal menyarankan cara mencapai tujuan.
Saya memutuskan mencoba membuat klon Yourls berbasis Django/Python dengan ChatGPT. Saya memberi instruksi spesifik agar mengizinkan URL pendek kustom dan melacak traffic, tetapi ia tidak benar-benar mempertimbangkan itu dengan baik dalam logika maupun model datanya. Untuk memperbaikinya kemudian, saya harus kembali memberi instruksi spesifik.
Alat AI mirip developer junior yang mengerjakan sesuatu untuk kita. Hanya saja jauh lebih cepat.
Kalau tidak tahu apa yang sedang kita lakukan, ia hanya mempercepat laju kesalahan.
Baru-baru ini saya perlu menambahkan prefiks nama tabel pada alias kolom di pernyataan SELECT, tetapi tidak ada fitur seperti itu, jadi saya memberi ChatGPT definisi skema dan query, lalu memintanya menuliskan daftar pilihan sekitar 40 kolom secara panjang.
Saya tidak menemukan cara yang bagus untuk mengotomatiskan hal seperti ini di berbagai RDBMS, dan memang bisa dilakukan dengan regex atau manipulasi teks lain, tetapi cara menjelaskan masalah dan mendapatkan output yang dibutuhkan terasa sangat sederhana dan menyenangkan.
Selain itu, saya memakai LLM seperti autocomplete. Ada juga efek membuat saya memberi nama fungsi yang baik, karena dengan informasi sebanyak itu saja LLM sering bisa memberi titik awal yang masuk akal. Ini sangat berguna terutama pada API atau bahasa yang belum banyak saya pakai, ketika masalah yang saya hadapi sudah pernah diselesaikan ribuan kali. Saya juga jadi hampir tidak memakai StackOverflow.
Karena itu saya membeli Copilot dan juga banyak memakai ChatGPT. LLM adalah salah satu hal favorit saya, bersama autocomplete bagus seperti IntelliSense, pembuatan spesifikasi OpenAPI atau kode EF/JPA, migrasi DB/pembuatan tabel berbasis model ER, container, dan IDE pintar seperti JetBrains.
Perusahaan akan menginginkan lebih banyak kode dengan lebih cepat, dan dalam pusaran itu sepertinya akan semakin sedikit orang yang benar-benar tahu apa yang sedang mereka lakukan.
Makalah lengkapnya ada di sini: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...
Bahkan sebelum alat bantu “AI” masuk pasar, sudah ada reaksi balik terhadap kode DRY, dan sayangnya saat saya memakai Twitter pada 2019–2022, tren itu makin membesar
Sebagian developer muda punya sikap terhadap kode yang sangat berbeda dari yang saya pelajari. Mereka sangat meremehkan Gang of Four dan design pattern, dan tampaknya tidak sadar bahwa framework favorit mereka justru penuh dengan pattern tersebut. Mereka menyindir prinsip seperti DRY, terutama SOLID
Di tempat seperti Twitter, makin sinis dan makin menyerang pihak seberang suatu pernyataan, makin tinggi engagement-nya. Ini tren yang cukup mengkhawatirkan
Saya juga sangat meremehkan apa yang terjadi di codebase perusahaan. Apa pun kata para guru SOLID, membuat lapisan indirection bertumpuk-tumpuk dengan class itu tidak baik. Best practice, DRY, dan SOLID hanya dipakai sebagai alasan
Yang tidak bisa saya tahan adalah memperlakukan daftar prinsip arbitrer yang berasal dari cara berpikir OOP ala Java sebagai kebenaran dalam pemodelan perangkat lunak. Saya juga muak dengan diskusi kesekian kalinya tentang bagaimana seharusnya memahami SOLID
Orang tidak bertengkar seperti itu soal teorema CAP, karena itu bukan kumpulan ide arbitrer yang kebetulan membentuk akronim keren
DRY juga bisa disalahgunakan, dan reaksi baliknya hanya terhadap sikap orang-orang yang memperlakukannya seolah sempurna
Misalnya, prinsip penting DRY bukanlah jangan mengulang kode, melainkan jangan mengulang ide. Untuk konsep apa pun dalam sebuah sistem, idealnya harus ada satu sumber kebenaran, dan ketika menangani konsep itu, hanya ada satu tempat yang perlu dipahami atau diubah
Karena itu, menyalin-tempel cukup banyak kode sebagai pengganti abstraksi yang bermakna sering kali buruk. Pada saat yang sama, ini juga peringatan bahwa begitu sebuah ide diulang, muncul utang berkelanjutan untuk menyinkronkan berbagai representasinya. Ini berlaku pada migrasi DB yang mendefinisikan skema dan class ORM terpisah, API backend dan client frontend, nilai form dan state internal pada retained mode UI, serta invariant model data yang diekspresikan baik dalam tipe maupun unit test
Orang-orang yang menentang pemaksaan penggabungan ide berbeda hanya karena implementasinya kebetulan mirip tidaklah salah. Namun mereka sedang menyerang straw man yang bukan inti asli DRY
Masalahnya sekarang adalah di mana dan kapan developer baru mempelajari prinsip-prinsip ini dengan benar. Ada yang punya latar belakang jurusan terkait, tetapi tidak semua, dan program CS akademik juga tidak harus banyak mengajarkan keterampilan pengembangan praktis
Saat saya mulai dulu, para senior memberikan pelatihan nyata dan cukup banyak kepada junior, tetapi dalam budaya sering pindah kerja sekarang dan suasana yang enggan merekrut junior sebagai investasi jangka panjang, hal seperti itu tampaknya jauh berkurang. Kursus formal memang mahal bagi individu, tetapi bagi perusahaan biayanya hampir bukan apa-apa; meski begitu, kemungkinan sangat sedikit developer baru yang benar-benar dikirim perusahaan untuk ikut kursus
Ada juga buku-buku yang layak dibaca, tetapi saya tidak tahu apakah orang berusia 20-an pada 2024 mau berurusan dengan format usang berupa tinta yang dicetak di potongan pohon mati. Developer yang sedang bertumbuh saat ini tampaknya banyak mempelajari ide-ide seperti ini dari blog dan YouTube, dan di sana memang ada materi bagus, tetapi masalahnya selalu bagaimana menemukannya di antara sampah yang tidak dipahami dengan benar atau dikemas secara meragukan
Jadi ketika muncul alat ajaib yang dapat menghasilkan 12 baris kode yang sekadar berjalan dalam satu detak jantung, tidak mengherankan jika developer muda menganggap kode itu hebat tanpa banyak mengetahui masalah yang lebih dalam di baliknya. Sulit menyalahkan siapa pun, tetapi ini jelas masalah, dan alangkah baiknya jika kita tahu harus berbuat apa