- Produktivitas meningkat ketika para developer menggunakan alat AI coding secara luas, tetapi muncul biaya kognitif dan organisasional yang tidak terlihat
- Dari alat bantu awal seperti Copilot dan Cursor, kini berkembang menjadi agen otonom, mengubah struktur kerja sehingga manusialah yang membantu AI
- Namun, penggunaan berbasis delegasi penuh memicu utang kognitif (cognitive debt) dan penurunan kemampuan debugging, sehingga kemampuan pemecahan masalah dan pemahaman kode developer melemah
- Struktur di mana manusia hanya meninjau kode yang ditulis AI menyebabkan runtuhnya jalur pembinaan senior dan hilangnya flow kreatif, sehingga kemampuan teknis organisasi terkikis dalam jangka panjang
- Pemanfaatan AI memang penting, tetapi perlu menetapkan sendiri 'ambang penggunaan yang tepat' dan menyesuaikannya agar pemahaman serta pembelajaran manusia tetap terjaga
Evolusi adopsi AI coding
- Copilot, Cursor, dan alat sejenis yang muncul pada 2022~2023 mengindeks codebase untuk menyediakan autocomplete dan chat berbasis konteks
- Kebutuhan untuk googling atau mencari di StackOverflow berkurang, dan lingkungan IDE dengan AI bawaan makin menyebar
- Setelah itu, workflow berbasis agen mengubah pola dari bantuan untuk manusia menjadi pengembangan yang dipimpin AI
- Namun, agen menimbulkan masalah keandalan seperti loop, halusinasi, dan error dependensi
- Sejak Opus 4.5, tingkat otomatisasi meningkat, dan di beberapa perusahaan mulai muncul kasus developer tidak lagi menulis kode secara langsung
- Contoh: Co-CEO Spotify menyebut engineer dapat memberi perintah ke Claude di Slack untuk memperbaiki fitur hingga deployment
Utang kognitif dan degradasi keterampilan
- Mengutip konsep ‘Digital Dementia’ dari Manfred Spitzer dan ‘Cognitive Debt’ dari Margaret-Anne Storey
- Jika pemikiran berulang didelegasikan ke AI, jalur otak melemah dan kemampuan memahami kode menurun
- Riset Shen·Tamkin (2026): dari 52 developer, kelompok yang dibantu AI mendapat skor 17% lebih rendah dalam pemahaman konsep, debugging, dan membaca kode
- Penurunan kemampuan debugging tampak paling menonjol, dan hanya 1 jam penggunaan AI secara pasif sudah memunculkan erosi keterampilan yang dapat diukur
- Ketika AI menangani tantangan menggantikan manusia, yang muncul bukan 'flow' sejati melainkan 'dark flow', sehingga ketergantungan menguat tanpa pembelajaran
Paradoks code review dan runtuhnya senior
- Jika AI menulis kode dan manusia hanya meninjaunya, muncul paradoks bahwa sumber kemampuan review itu sendiri menghilang
- Developer yang sepenuhnya bergantung pada AI bekerja cepat, tetapi skor evaluasinya justru paling rendah
- Storey menyarankan bahwa “perubahan yang dihasilkan AI harus sepenuhnya dipahami manusia sebelum deployment”
- AI dapat memberi output setingkat senior kepada pemula, tetapi itu hanya replikasi tanpa pemahaman
- Senior kehilangan kedalaman karena tidak lagi menulis kode langsung, sementara junior tidak berkembang karena tidak melalui trial and error
- Akibatnya, pipeline pembinaan senior runtuh
Salah baca manajemen dan dampak organisasional
- Eksekutif di Microsoft, Anthropic, Google dan lainnya memprediksi AI akan menggantikan engineer dalam beberapa bulan
- Google melaporkan pada akhir 2024 bahwa 50% kode baru dihasilkan AI
- Namun, angka seperti ini merupakan pembesaran untuk penjualan AI dan penguatan harga saham, sehingga tidak bisa diterapkan pada organisasi pada umumnya
- Beberapa perusahaan bahkan mengukur penggunaan AI sebagai KPI dan memaksakannya kepada developer
- Kasus Reddit: developer memanipulasi angka penggunaan AI dengan perintah yang tidak bermakna
- Akibatnya, Hukum Goodhart bekerja, dan yang tersisa bukan peningkatan produktivitas melainkan kepatuhan formal
Biaya manusiawi dan hilangnya kreativitas
- Menulis kode memberi kesenangan dari fokus mendalam dan kreativitas, tetapi meninjau kode AI justru memicu kelelahan mental
- Ketika imbalan dopamin dari proses mencipta hilang, burnout makin cepat
- Pengembangan berubah menjadi quality assurance (QA), dan kepuasan kreatif menguap
- Ini dianalogikan dengan situasi ketika AI mengerjakan seluruh seni sementara manusia hanya melipat cucian
Ambang penggunaan AI yang tepat
- AI adalah alat yang kuat, tetapi lebih banyak atau lebih sedikit penggunaan tidak otomatis lebih baik
- Dalam riset Shen·Tamkin, dari 6 pola interaksi AI,
- delegasi penuh, ketergantungan bertahap, dan penyerahan debugging menghambat pembelajaran
- meminta penjelasan, mengajukan pertanyaan konsep, dan melakukan coding mandiri lalu memverifikasi membantu menjaga pembelajaran
- Kuncinya adalah mempertahankan keterlibatan kognitif, jadi yang penting bukan sekadar memakai atau tidak memakai AI, melainkan cara menggunakannya
- Jika sama sekali tidak memakai AI, kita kehilangan efisiensi pencarian, boilerplate, dan eksplorasi,
tetapi jika terlalu banyak memakainya, pemahaman, pembinaan senior, deteksi bug, dan rasa flow akan rusak
Kemunduran yang senyap
- Di permukaan, metrik seperti jumlah PR, jumlah fitur, dan cycle time membaik,
tetapi kemampuan teknis batin, fokus, dan daya pemecahan masalah perlahan melemah
- Developer berubah menjadi ‘butter robot’ yang hanya mengklik approve tanpa memahami struktur yang dibuat AI
- Simon Willison juga menyebut bahwa karena tidak meninjau fitur yang dibuat AI dalam proyeknya,
ia “tidak lagi memahami cara kerja internalnya dengan jelas”
- Pada akhirnya, yang mengalami degradasi bukan alatnya melainkan manusianya, dan perubahan ini tidak terukur maupun tidak terkelola
- Ketergantungan pada AI berkembang seperti adiksi dan berisiko berujung pada kemerosotan keterampilan yang senyap tetapi nyata
1 komentar
Komentar Hacker News
Saya masih merasa menulis kode sendiri dan membayangkan strukturnya di kepala adalah salah satu kesenangan dalam pekerjaan saya
Bahkan refactoring yang repetitif atau merepotkan pun tetap bermakna bagi saya
Momen-momen berat seperti ini menjadi bahan pembelajaran yang membantu saya menemukan cara yang lebih baik berikutnya
Ini tersisa sebagai harapan bahwa suatu hari arus ini akan berbalik lagi
Saya percaya suatu saat nilai orang-orang yang tetap menjaga kemampuan untuk memilih dan menilai sendiri akan kembali diakui
Kalau kodenya sulit diuji, berarti abstraksi atau interface-nya yang harus diubah
Test adalah bentuk penggunaan ulang pertama dari kode, jadi kalau terasa tidak nyaman di test, kemungkinan juga akan tidak nyaman dalam penggunaan nyata
Semakin banyak kode yang saya tulis sendiri, semakin mudah membayangkan di kepala titik munculnya masalah
LLM tidak bisa menggantikan intuisi seperti ini, sebanyak apa pun log yang Anda lemparkan
Tapi saya khawatir ini justru menghilangkan motivasi untuk memperbaiki ekosistem frontend
Bahkan pekerjaan yang ingin diserahkan orang ke LLM pun tetap menyenangkan jika saya kerjakan langsung
Sedih melihat perusahaan perlahan-lahan merampas kesenangan kecil seperti ini
Selama setahun terakhir saya banyak menggunakan Claude Code, dan belakangan saya merasakan perubahan emosi di antara rekan-rekan soal penggunaan AI
Saya menulis tentang biaya tersembunyi yang muncul saat AI digunakan secara berlebihan, dan mencoba mengumpulkan data dari berbagai sumber
Datanya memang belum jelas, tapi tampaknya banyak developer merasakan hal yang sama
Namun, ungkapan “software hanyalah alat” selalu terdengar aneh bagi saya
Jika alat bisa menggantikan proses berpikir, apakah itu masih pantas disebut “alat”?
Saya suka ungkapan jujur “kecanduan prompt”. Tapi akan menarik juga jika aspek kecanduan perilaku turut dieksplorasi
Terasa cepat dan seolah terkendali, tapi perlahan kita justru kehilangan kendali
Hal yang benar-benar sulit adalah menemukan “seberapa cepat penggunaan yang tetap berkelanjutan”
Saya juga menulis posting blog tentang topik serupa,
tapi dari sudut pandang pemimpin yang membantu organisasi menemukan keseimbangan yang berkelanjutan
Saya mencari paper tentang pengaruh working memory dan sistem reward terhadap pembelajaran dan fokus
Misalnya, paper Nature mengatakan bahwa working memory memiliki responsivitas dopamin
Lalu artikel Scientific American menyebut menulis dengan tangan mengaktifkan lebih banyak area otak
Pada akhirnya, kesimpulannya adalah bahwa pada pekerjaan pasif dengan reward rendah, manfaat kognitif seperti ini hampir tidak ada
Karena itu saya pikir standar penggunaan AI sebaiknya didasarkan pada “seberapa menyakitkan dan rendah reward-nya suatu tugas”
Saya masih tetap menulis kode sendiri dan memahami hasilnya sepenuhnya
Saya tidak peduli soal peningkatan kecepatan. Yang penting adalah rasa memiliki bahwa ini kode saya
Dari dulu saya juga bisa saja meng-outsourcing-kan pekerjaan, tapi itu berarti menjadi orang yang hanya membaca kode
Saya dan sebagian besar developer di sekitar saya merasakan tekanan seperti itu
Menggunakan keyboard tidak membuat kita lupa tulisan tangan, dan membeli kopi tidak membuat kita lupa cara menyeduh kopi
Pada awal 80-an saya belajar coding dengan assembly LSI-11 dan menghafal semua opcode oktal
Tapi begitu belajar FORTRAN 83, produktivitas saya naik 10 kali lipat, dan saya sama sekali tidak menyesal walau keterampilan saat itu menurun
Suatu hari nanti bahasa seperti C++ atau Java juga akan menjadi keterampilan yang tidak lagi dibutuhkan
Kemampuan berpikir logis yang dibangun saat bergelut dengan opcode justru membuat pembelajaran bahasa berikutnya jadi lebih mudah
Cara berpikir untuk menangani formal language seperti ini jauh lebih dalam secara kognitif dibanding menulis prompt untuk LLM
sedangkan kolaborasi dengan AI adalah proses menyampaikan niat lewat bahasa alami yang ambigu
Kecuali Anda menulis pseudocode dalam bahasa Inggris, presisinya tetap lebih rendah
Ditambah lagi kali ini ada ketakutan bahwa kita bisa tergantikan
Jika menjaga tiga pola penggunaan AI yang tepat, kita bisa mendapatkan produktivitas sekaligus pembelajaran
Tapi jika mengikuti anti-pattern, hasilnya adalah ketergantungan pada alat, kecemasan, menurunnya kemampuan debugging, dan kecanduan pada reward instan
Pada akhirnya akan terbentuk lingkaran setan penurunan kognitif
Saya baru bergabung dengan perusahaan yang berpusat pada AI, dan suasananya hampir melarang coding manual
Saya meminta Claude membaca dokumentasi API dan membuat wrapper, hasilnya memang sempurna,
tapi saya sendiri jadi sama sekali tidak memahami rasa maupun struktur API tersebut
Keadaan “bisa melakukan banyak hal tapi tidak benar-benar paham apa pun” seperti ini terasa tidak nyaman dan hampa
Tidak ada memori refleks yang terbentuk. Karena itu saya sangat berempati dengan isi tulisan ini
Saya sedang mengerjakan beberapa side project yang ditulis AI
Namun tetap ada perasaan aneh seperti “menurut saya ini bagus, tapi saya tidak yakin”
Kesimpulannya, bahkan saat membuat sesuatu bersama AI, kita tetap perlu meninggalkan jejak diri sendiri agar bisa merasakan pencapaian
Saya baru coding selama 8 bulan, dan belajar berkat AI
Tapi ketika Claude menuliskan kode, saya hanya memahami sekitar 70%-nya, sisanya begitu saja saya lewati
Rasa cepat itu adiktif, tapi kemampuan mempertahankan struktur keseluruhan di kepala jadi menurun
Meski begitu, tanpa AI saya tidak akan bisa membuat hasil seperti sekarang, jadi saya mengakui trade-off ini
Misalnya, terlalu sering menambahkan fallback code yang tidak perlu
Kalau belum berpengalaman, kita bisa tidak sadar bahwa itu keliru
Tingkat LLM saat ini kira-kira setara developer intern hingga junior
Bottleneck-nya bukan model, melainkan kemampuan verifikasi kita
Saya ragu apakah kita benar-benar perlu memakai LLM untuk otomatisasi boilerplate
Bukankah metaprogramming atau script yang sudah ada juga cukup untuk itu?
Selain itu, menolak AI secara prinsip pun bisa menjadi semacam pilihan yang memberi kepuasan
Dasar-dasar seperti penggunaan mouse dan keyboard, penelusuran file, atau pencarian perintah masih lemah
Karena itu godaan untuk berkata “tanya saja ke LLM” jadi besar
Tapi solusi yang sebenarnya adalah meningkatkan keterampilan alat dan mempelajari template engine
AI memang bisa menyebabkan penurunan keterampilan,
tapi saya rasa itu tidak masalah jika terjadi di area yang memang tidak ingin saya fokuskan
Misalnya, saya tidak perlu sampai memahami optimisasi internal compiler
Untuk memahami interaksi antar-sistem, kita tetap perlu tahu sampai taraf tertentu prinsip kerja compiler
Bagian yang tidak ingin terlalu dipikirkan diserahkan ke LLM,
lalu sumber daya otak difokuskan pada masalah yang benar-benar penting