- Keyakinan bahwa alat coding AI benar-benar meningkatkan produktivitas pengembang adalah sebuah kekeliruan
- Alat-alat ini merusak kesenangan dalam pemrograman dan kedalaman pemahaman manusia
- AI berguna untuk pembuatan kode berulang, tetapi lemah dalam konteks, performa, dan nuance
- Ketergantungan berlebihan menurunkan kemauan belajar dan mengeksplorasi, serta kualitas kode pada pengembang
- Masalah bahwa hakikat profesi pemrograman perlahan menghilang karena kenyamanan AI makin membesar
Pendahuluan: Delusi tentang alat coding AI
- Artikel ini membahas realitas alat pembuat kode AI per Mei 2025
- Perdebatan tentang ketidakmampuan AI bisa mereda seiring waktu, tetapi masalah rusaknya hakikat dan kesenangan pemrograman justru diperkirakan akan makin serius
Bab 1: Rekan kerjaku, sang programmer
- Penulis memberi contoh pengalaman bekerja dengan pengembang nonprofesional yang sembarangan menyalin-tempel kode, sambil menekankan masalah penurunan performa/bom bug/pengabaian arsitektur yang ditinggalkan rekan seperti itu
- Rekan seperti ini terus mengubah kode tanpa pengujian, profiling, dan pemahaman konteks, dan pada akhirnya merampas motivasi serta keinginan belajar tim
- Melalui pengakuan berbalik ala "Captain Obvious", penulis mengungkap bahwa gambaran ini pada dasarnya adalah satire terhadap alat coding AI seperti GitHub Copilot, Claude Codex, dan sejenisnya
- Copilot pesawat sungguhan memahami keseluruhan sistem, berkolaborasi, dan punya rasa tanggung jawab. Sebaliknya, AI Copilot meninggalkan kode yang hanya tampak di permukaan tanpa pemahaman esensial
- Dengan hanya meminjam nama "Copilot", alat ini dipaksakan masuk ke IDE semua pengembang dengan kedok produktivitas dan inovasi
Bab 2: Kelebihan Copilot
- Alat coding AI juga bukan sesuatu yang sepenuhnya tidak berguna
- Alat ini berguna saat junior sekadar mempelajari sintaks rumit bahasa seperti C++, atau ketika ingin cepat merujuk suatu konsep
- Untuk brainstorming, merapikan konteks, dan template code yang berulang, alat ini lebih cepat dan lebih sedikit salah daripada intern manusia
- Namun, jelas ada risiko bahwa karena tidak punya pertimbangan performa/efisiensi sama sekali, bila dibiarkan tanpa pengawasan di sekitar kode produksi, hasilnya bisa menjadi bencana kualitas produksi
- Alat ini bisa cepat menyediakan scaffold/draf kode tanpa konteks, tetapi desain dan tuning yang utuh tetap menjadi bagian pengembang manusia
Bab 3: Diriku sebagai pengembang dan AI
- Penulis menekankan "kesenangan dari coding itu sendiri" dan rasa pencapaian saat membuat sesuatu secara langsung
- Jika kode berulang (boilerplate) diserahkan ke AI dan kita juga berhenti mengimplementasikan library/macro sendiri, pada akhirnya kreativitas dan motivasi intrinsik pengembang akan hilang
- Ketergantungan pada Copilot karena FOMO (takut tertinggal) memicu fenomena menuangkan kode yang kasar dan belum tervalidasi dengan cepat
- Ketergantungan pada AI merampas kesempatan untuk benar-benar belajar, serta memahami performa tingkat rendah, struktur, dan pengelolaan kualitas kode
- Nama "Copilot" bukanlah rekan setara, melainkan seperti fantasi seorang gamer berpengalaman singkat yang ingin menerbangkan pesawat
Bab 4: Komputer adalah mesin
- Kemampuan memahami wujud dan struktur mesin (hardware), serta karakteristik performanya hanya dimiliki manusia
- AI tidak memiliki intuisi atau pengalaman langsung tentang cache miss, memory layout, profiling, atau bottleneck performa yang nyata
- Jawaban yang diberikan AI terlepas dari konteks, dan tidak berguna di area yang membutuhkan optimisasi spesifik
- Bahkan saat membuat aplikasi CRUD yang biasa sekalipun, pengembang harus memiliki rasa hormat dan ketulusan terhadap pengguna dan sistem
- Profesionalisme dan jiwa craftsmanship terbentuk dari pengalaman langsung, rasa sakit, dan perbaikan yang berulang
Bab 5: Kesimpulan
- Alat coding AI dan aksesibilitasnya menyebabkan memudarnya semangat hacker
- Penulis mengkhawatirkan fenomena di mana hanya pengguna pasif yang tidak memiliki minat pada coding/struktur/performa yang sesungguhnya akan tersisa di industri
- Dulu, ada banyak rasa ingin tahu murni dan kreativitas lewat IRC semalaman, eksperimen hardware, dan eksplorasi tingkat rendah
- Kini yang tersisa adalah pekerjaan mekanis dan ketidakpedulian yang hanya mengulang "review patch AI"
- Penulis memperingatkan risiko bahwa pembuatan kode tanpa pemahaman konteks dan kemampuan nyata akan menjadi standar industri, sekaligus realitas tersingkirnya orang-orang yang benar-benar ahli
Riwayat penyuntingan isi
- Menambahkan disclaimer tentang tanggal penulisan
- Memperjelas posisi tentang cakupan kritik performa (sistem kompleks vs CRUD) dengan mencerminkan opini HN
- Menyesuaikan sebagian gaya kalimat dan penggunaan simbol demi kemudahan membaca
25 komentar
Tulisannya memang menarik, tetapi saya agak lelah karena terlalu banyak tulisan yang rasanya bisa diringkas menjadi “tidak memakai AI bukan berarti segalanya, tetapi mempercayainya begitu saja dan menjadi terlalu bergantung padanya juga bukan hal yang baik.”
LLM dan AI terus berkembang seiring waktu. Hanya beberapa bulan lalu, hampir mustahil mengharapkan hal-hal seperti konsistensi kode sesuai percakapan, tetapi sekarang jika Anda mengunggah ke AI file kode yang diminta pada konfigurasi awal dalam ruang kerja tersebut, lalu memberinya instruksi agar saat menulis kode baru selalu mengikuti gaya kode yang sudah ada, ternyata AI bisa menghasilkan kode yang cukup konsisten.
Saya membacanya sampai selesai, dan pada akhirnya saya pikir penulis punya sudut pandang yang agak bias karena hal ini.
Tentu saja, seperti isi artikel, apa yang disarankan itu hampir seperti nasihat yang sangat baku, jadi memang benar.
Namun, saya rasa AI sudah cukup bagus untuk CRUD dan frontend, yang punya banyak materi untuk dipelajari.
Sepertinya kita perlu memanfaatkannya semaksimal mungkin di dalam domain kita sendiri.
Saya rasa ada sedikit kesalahpahaman dalam memahami maksud yang ingin disampaikan penulis.
Penulis berfokus pada performa proyek yang ia kelola, stabilitas, serta arsitektur yang mudah dipelihara dan konsistensi kode, dan khususnya arsitektur serta konsistensi kode adalah salah satu bidang yang memang sangat tidak dikuasai LLM saat ini.
Khususnya di web, karena arus masuk developer sangat besar dan pola pikir "yang penting jalan" sangat kuat, ada sangat banyak kode berkualitas rendah yang terlanjur dipublikasikan. Dan karena LLM dilatih berdasarkan hal-hal seperti itu, kualitas hasil keluarannya jatuh sampai tingkat yang absurd.
Coba saja minta ke GPT,
tolong implementasikan algoritma quicksort dalam js, buat dipakai di web front-end. Kalau Anda tidak bisa menemukan masalah pada hasil keluarannya, saya rasa percakapan ini tidak akan terlalu bermakna.Halo. Karena penasaran, saya mencoba mengatakan, "Ini akan dipakai di front-end web, jadi tolong implementasikan algoritma quicksort dengan JavaScript." Namun, menurut saya cukup sulit untuk memahami apa masalahnya. Jika Anda bisa memberi tahu saya, itu akan sangat membantu. Terima kasih sebelumnya. https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd
Sepertinya tautannya tidak berfungsi dengan baik, jadi saya coba lagi. https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e
quickSortInPlace()kedua yang Anda lampirkan ini juga merupakan implementasi yang lambat.Coba jalankan kode di bawah ini.
function quickSortInPlace(arr, left = 0, right = arr.length - 1) {
if (left >= right) return;
const pivotIndex = partition(arr, left, right);
quickSortInPlace(arr, left, pivotIndex - 1);
quickSortInPlace(arr, pivotIndex + 1, right);
}
function partition(arr, left, right) {
const pivot = arr[right];
let i = left;
for (let j = left; j < right; j++) {
if (arr[j] < pivot) {
[arr[i], arr[j]] = [arr[j], arr[i]];
i++;
}
}
[arr[i], arr[right]] = [arr[right], arr[i]];
return i;
}
function quickSort(arr) {
if (arr.length <= 1) return arr;
const pivot = arr[arr.length - 1];
const left = [];
const right = [];
for (let i = 0; i < arr.length - 1; i++) {
if (arr[i] < pivot) {
left.push(arr[i]);
} else {
right.push(arr[i]);
}
}
return [...quickSort(left), pivot, ...quickSort(right)];
}
const repeat = 100;
const arrLength = 10000;
const unsortedArray = new Array<number>();
for(let i = 0; i < arrLength; i++)
unsortedArray.push(Math.round(Math.random() * arrLength));
let sorted: Array<number>;
const qb = performance.now();
for(let i = 0; i < repeat; i++)
sorted = quickSort(unsortedArray);
const qe = performance.now();
const rqb = performance.now();
for(let i = 0; i < repeat; i++) {
let copied = [...unsortedArray];
quickSortInPlace(copied);
}
const rqe = performance.now();
console.log(
q: ${qe - qb} ::: rq: ${rqe - rqb});Pada dasarnya, ini bisa dianggap sebagai kode yang sama sekali tidak memahami beban dalam pembuatan, pengelolaan, dan penggabungan collection. Dalam kasus C++, sekitar 10 tahun lalu saja sudah ada usulan/implementasi untuk Move Constructor, dan bersikap sangat sensitif terhadap beban yang terkait dengan penyalinan memori adalah hal yang paling mendasar. Quick sort, secara mekanisme, adalah algoritme yang dapat menetapkan index semua nilai, dan sebaiknya setiap field mendukung random access.
Bahkan tanpa optimasi yang terlalu maniak, hanya dengan menerapkan hal-hal di atas saja sudah menghasilkan perbedaan performa lebih dari 2x dibanding cara pada tautan yang Anda berikan.
Saya sudah menjalankannya langsung, dan memang cenderung sedikit lebih lambat, tetapi sepertinya tidak sampai 2 kali lipat.
===
node q.js
Using geekNews quicksort implementation.
Quicksort: 29.55 ms, In-place: 9.94 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 28.42 ms, In-place: 9.07 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 26.91 ms, In-place: 9.15 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 28.73 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 26.87 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.97 ms, In-place: 9.30 ms
node --version
v22.14.0
bun q.js
Using geekNews quicksort implementation.
Quicksort: 32.05 ms, In-place: 17.39 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 30.97 ms, In-place: 17.82 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 29.73 ms, In-place: 16.14 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 30.61 ms, In-place: 12.63 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 31.09 ms, In-place: 12.76 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 33.24 ms, In-place: 12.75 ms
bun --version
1.2.14
deno q.js
Using geekNews quicksort implementation.
Quicksort: 32.30 ms, In-place: 6.79 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.79 ms, In-place: 6.86 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.09 ms, In-place: 6.85 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.18 ms, In-place: 7.92 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.34 ms, In-place: 8.12 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.39 ms, In-place: 8.09 ms
deno --version
deno 2.3.3 (stable, release, x86_64-pc-windows-msvc)
v8 13.7.152.6-rusty
typescript 5.8.3
Ah.. sekarang saya paham maksud Anda. Rupanya Anda tidak memahami apa yang harus dibandingkan dengan apa.... algoritma quick sort itu bukan berarti ada dua cara implementasi, yaitu quicksort dan in-place......
Sejak awal, yang saya persoalkan adalah bagian ketika
quickSortGPT()danquickSort()pada kode di atas (keduanya adalah kode yang dihasilkan GPT), yang sudah menyertakan penggabungan Array bawaan, ditulis lalu disediakan kepada pengguna AI.Dalam jawaban GPT ada
quickSortdanquicSortInPlace, dan karena di komentar Anda menyoroti bagian[...,quickSort(left), ...equal, ...quickSort(right)], saya memahaminya sebagai bahwaquickSortharus dibandingkan dengan sesamaquickSort, danquickSortInPlacedengan sesamaquickSortInPlace, tetapi tampaknya bukan begitu.Ungkapan "quickSort itu sesama quickSort" membuat saya memegangi tengkuk saking kesalnya.
Saat membaca tulisan ini, pastikan untuk memeriksa konteksnya.
Saya tidak sedang membanggakan kemampuan coding saya. Yang saya tunjukkan adalah bagian di mana kode buruk seperti
quickSort()yang digunakan sebagai contoh sekarang justru muncul dengan prioritas tinggi dari GPT.Kalau Anda mencoba pencarian GPT beberapa kali, sering kali ia memberikan hasil fungsi
quickSort()secara tunggal, dan sekali lagi,quickSort()hanyalah salah satu contoh. Jika meminta kode ke GPT untuk tujuan pekerjaan, sering kali keluar kode dengan kualitas yang sangat rendah (ini berdasarkan pengalaman pengguna berbayar). Saya sampai pada konteks ini karena setuju dengan pendapat penulis artikel bahwa jika developer sendiri tidak punya kemampuan untuk membedakan hal seperti ini, besar kemungkinan proyek akan berjalan ke arah yang merusak.Di sekitar saya sendiri, proyek-proyek yang dipenuhi kode buruk seperti ini sudah terus bertambah.
Tentu saja, perbandingannya harus membandingkan performa dua fungsi
quickSort()danquickSortInPlace()........Lalu, membagikan hasil yang menunjukkan perbedaan output lebih dari 2 kali sampai 3–4 kali, tetapi kemudian mengatakan rasanya tidak sampai 2 kali itu maksudnya apa?
return [...quickSort(left), ...equal, ...quickSort(right)];
Coba pikirkan baik-baik bagian kode ini.
Saya belajar banyak.
Terima kasih atas jawabannya!
Pertama, dalam konteks "memanfaatkan AI di dalam domain" yang saya sebutkan, tentu saja perancangan dan koordinasi dilakukan oleh manusia...
Sebenarnya, kalau dulu mungkin lain ceritanya, tetapi sekarang ketika semua orang sudah mengetahui keterbatasan LLM, ini sudah menjadi hal yang terlalu wajar sampai rasanya tidak perlu disebutkan lagi.
Berikutnya, soal orang awam yang tidak punya pengetahuan pengembangan menggunakan LLM,
sepertinya baik artikel utamanya, Hacker News, maupun saya sendiri tidak pernah mengatakan hal itu, tetapi bagaimanapun juga, bahkan dalam kasus ini pun kualitasnya sudah mencapai tingkat yang cukup memuaskan bagi para pengguna.
Kalau bukan begitu, rasanya Bolt.new, v0, dan Cursor tidak akan mendapat penilaian seperti sekarang.
Ringkasnya,
Penulis: pengembang harus meningkatkan dan mempertahankan kemampuannya sendiri. Bahkan AI pun tidak terlalu berhasil.
crawler: Hah? Saya sih berhasil dengan baik?
superscv: Banyak masalah...
crawler: Harus dipakai dengan penyesuaian yang tepat
superscv: Sepertinya ini sudah terlalu jauh dari pesan yang sejak awal ingin disampaikan penulis..
Sepertinya Anda belum benar-benar memahami alasan saya menyebut bidang si penulis dan apa yang dimaksud dengan domain sendiri.
Mendelegasikan semua keputusan kepada AI tanpa pemikiran sendiri memang terlihat bodoh,
tapi saya juga kurang paham dengan orang-orang yang berada di sisi sebaliknya.
Terakhir, yang ingin saya tanyakan adalah, saya penasaran menurut superscv bagaimana sebaiknya LLM digunakan untuk coding.
Saya biasanya tidak terlalu sering menulis komentar, tetapi alasan saya meninggalkan komentar pada tulisan ini adalah karena saya sangat sependapat dengan pemikiran penulis. Yang penting bukanlah AI atau LLM, melainkan saya harus siap sebagai seorang developer dalam lingkungan apa pun yang datang.
Karena karakteristik sumber yang dipelajari LLM, ia terutama memberikan data yang berada di sekitar nilai rata-rata dari data online yang tersebar di seluruh dunia. (Sebelumnya, quicksort di js membuktikan hal ini.) Karena itu, biasanya saya banyak menggunakannya untuk menanyakan apakah dari sisi gagasan/desain ada penyimpangan dari sudut pandang yang umum dan sampai sejauh mana hal itu bisa dipahami, atau untuk hal-hal yang selama ini agak sulit ditentukan harus ditanyakan ke mana.
Saya kurang paham apa makna dari melanjutkan percakapan ini lebih jauh.
Kalau sejak awal maksudnya adalah bahwa kode yang dihasilkan AI bisa saja memiliki sejumlah risiko, jadi sebaiknya disaring dengan baik lalu dimanfaatkan secara tepat, rasanya Anda cukup menjelaskan bagian mana dari tulisan penulis yang menurut Anda menunjukkan pemikiran penulis yang bias. Bahkan di ringkasannya juga ada isi dengan makna serupa, yaitu bahwa AI dapat dengan cepat menyediakan kode scaffold/draf tanpa konteks, tetapi desain dan tuning yang utuh tetap menjadi tanggung jawab pengembang manusia.
Meski pesan penulis cenderung terasa agak keras, jika dibaca baik-baik, ini bukan berarti "jangan gunakan AI". Ada usulan tentang bagaimana memanfaatkannya, dan intinya adalah bahwa pengembang sendiri tidak boleh kekurangan kemampuan.
Kalau dilihat kenapa pesan penulis terasa kuat, itu karena pesannya dibentuk sebagai sudut pandang yang menanggapi pandangan bahwa pengembangan akan menjadi mungkin dengan copilot (nuansa ketergantungan pengembangan yang tinggi pada copilot). Karena itu, pesannya digiring dalam bentuk "jangan mengambil posisi yang merusak nilai keberadaan kalian sendiri" kepada para pengembang.
Karena penulis juga bukan menyampaikan pesan "jangan gunakan AI", pada akhirnya jika AI dimanfaatkan, kemungkinan akan jatuh pada suatu titik kompromi di antaranya, jadi secara garis besar pesan Anda barusan tampaknya menjadi mirip dengan pesan itu.
Namun, di antara isi yang Anda tulis pada awalnya, saya sulit setuju dengan bagian yang menyebutnya sebagai 'sudut pandang yang bias', jadi saya menjawab terlebih dahulu.
Komentar Hacker News
Jika Anda ingin membuat perangkat lunak yang harus benar-benar tangguh, seperti software untuk alat pacu jantung, sistem pemandu misil, atau tank M1, maka singkirkan agen coding AI dan belajarlah sendiri.
Tapi kebanyakan dari kita tidak membuat hal seperti itu, melainkan menghasilkan aplikasi CRUD dengan kebutuhan yang nyaris sama, hanya skemanya sedikit berbeda dan cara integrasinya sedikit berbeda.
Praktis tidak ada hal baru dalam software yang dibuat sebagian besar dari kita.
Sering kali yang terbaik adalah mendaur ulang pengetahuan yang sudah ada.
Bagi saya, agen coding adalah versi luar biasa besar dari daur ulang kode di masa lalu.
Tambahan lagi, ironisnya, tulisan ini sendiri terasa seperti tulisan yang dibuat AI.
Saya memang dari awal tidak ingin menulis kode low-level yang mission-critical.
Saya juga tidak menganggap tool AI semata-mata berguna seperti penulisnya, tapi saya sudah muak dengan argumen gaya “kalau tidak melakukan system programming dalam C, kamu bukan programmer sungguhan”.
Saya suka mengerjakan frontend.
Saya juga tidak ingin membuat sendiri library grafis low-level.
Saya bukan tipe yang tiba-tiba tercerahkan lalu ngoding semalaman, tapi saya punya gairah dan kebanggaan terhadap pekerjaan saya.
Saya tidak merasa semua orang harus punya sikap ekstrem seperti penulisnya.
Menurut saya pasar software memang harus beragam.
Tidak masalah membantah argumen penulis, tapi mengatakan tulisan ini sendiri dibuat AI itu keterlaluan.
Penulisnya menuangkan gaya khasnya ke seluruh tulisan lewat ungkapan yang hidup, metafora yang kuat, dan humor yang benar-benar lucu.
Untuk saat ini, sangat sulit membayangkan LLM bisa menulis seperti ini.
Ini bukan tulisan AI, ini tulisan yang bagus.
Setuju atau tidak dengan argumennya, kualitas tulisannya patut diakui.
Ada juga bagian seperti ini di artikel aslinya.
“Kemungkinan besar Anda tidak akan menulis kode yang membuat pesawat terbang, atau kode yang langsung berkaitan dengan nyawa manusia. Kebanyakan orang memang tidak. Tapi bahkan jika Anda bekerja di perusahaan yang hanya menambal-nambal aplikasi CRUD sederhana, Anda tetap punya tanggung jawab untuk menjaga rasa hormat dan martabat bagi pengguna.”
Ini menekankan bahwa bahkan software yang sederhana pun tetap butuh rasa tanggung jawab minimum.
Sebenarnya penulis juga mengakui beberapa kasus di mana AI berguna.
Masalah utama yang ia angkat adalah kita menyebut AI sebagai “copilot”, sehingga pemula bisa terlalu mempercayainya.
Copilot yang sesungguhnya seharusnya adalah rekan yang terampil, sementara AI saat ini masih seperti rekan payah dengan peluang 50 persen.
“Saat ini kita menaruh rasa ingin tahu dan inisiatif di luar sistem. Orang-orang berbakat yang seharusnya tumbuh malah kehilangan semangat karena hanya meninjau patchset AI. Terminal berubah menjadi spreadsheet, debugger menjadi peti mati.”
Namun AI pada akhirnya hanyalah salah satu bentuk abstraksi.
Seperti orang khawatir bahwa ketika otomatisasi menjadi sewajarnya GC (garbage collector), kemampuan dasar akan terabaikan, ada juga kekhawatiran bahwa AI pada akhirnya bisa mengikis kemampuan pemrograman dan belajar yang sangat mendasar.
Developer web bisa membuat situs yang bagus berkat abstraksi tanpa harus memahami struktur terdalam dari stack.
Tapi AI adalah abstraksi yang penuh lubang, sehingga seseorang bisa membuat sesuatu yang cukup berjalan tanpa benar-benar memahami dasar-dasarnya.
Masalahnya, pada titik tertentu kita akan menemukan bug serius yang tersembunyi, dan kemampuan debugging, pemecahan masalah, dan belajar sendiri adalah hal yang tidak bisa digantikan AI.
Karena itu ada kekhawatiran bahwa jika belajar jadi terlalu mudah berkat AI, kemampuan dasar yang penting akan terlewatkan.
Pada akhirnya, pertumbuhan sejati datang dari pengulangan dan dari benar-benar berhadapan langsung dengan masalah.
Jika AI mengabstraksikan proses “belajar” itu sendiri, kemampuan developer dalam jangka panjang bisa melemah.
Tentu bukan berarti semua orang yang memakai AI akan jadi bodoh, dan orang yang belajar secara aktif akan tetap ada.
Tapi secara keseluruhan kemungkinan proporsi mereka akan menurun.
Karena pengalaman “membuat sambil berpikir sendiri” bagi pemula bisa saja menghilang.
Dan abstraksi bernama AI ini pada akhirnya memang penuh celah.
Dari sudut pandang pemula, AI terlihat seolah melakukan semuanya, tapi pada akhirnya kemampuan inti pemrograman dan debugging tetap dibutuhkan.
Jadi kalau ingin benar-benar bisa menangani isu pada kode buatan AI, tetap wajib membangun keterampilan sendiri.
Saya sendiri cukup memanfaatkan bantuan coding AI.
Tapi karena ada kekurangannya, saya rasa kita tidak boleh melihatnya seolah semuanya hanya positif.
Saya sempat membuat video komedi pendek sendiri dengan Google Whisk lalu mengunggahnya ke TikTok, dan ketika saya masuk, isinya penuh dengan konten buatan AI atau video orang yang saling meniru.
Saya pikir mungkin ada sesuatu yang nyata dalam “kreasi orisinal”, tapi ternyata kita ini terlalu mudah direproduksi.
Bahkan kalau kita mengunggah video coding harian ke TikTok, yang muncul tetap aplikasi-aplikasi serupa tanpa akhir.
Seperti kata Elon Musk, rasanya sekarang yang tersisa cuma benar-benar pergi ke Mars.
Dua tahun lalu saya juga pernah bilang bahwa LLM tidak terlalu sering “berhalusinasi”, dan sampai sekarang orang masih percaya manusia pasti dibutuhkan, tapi saya ingin bilang bahwa semakin lama itu semakin tidak benar.
Saya ingin mengingatkan percakapan ini lagi dua tahun dari sekarang.
“Mesin itu nyata. Silikon nyata, DRAM nyata, L1 cache dan false sharing nyata, branch predictor yang melempar koin pun nyata. Kalau Anda tertarik, semuanya bisa dipahami.”
Sudah lama sekali saya tidak merasa sebuah kalimat seindah ini.
Penulisnya menulis dengan gaya yang jenaka seperti Dave Barry, dan saya tertawa berkali-kali saat membacanya.
Saya suka bagaimana ia mengekspresikan pemikiran yang relatable tentang Copilot dengan humor yang sangat baik.
Dalam diskusi pengembangan software, yang sering terlewat adalah bahwa bukan hanya “hasil akhir dari menulis kode” yang penting.
Perjalanan mencapai hasil itu, melalui begitu banyak trade-off, juga sangat penting.
Coba saja membuat satu fitur bersama junior di codebase yang agak kompleks, Anda langsung bisa merasakan trade-off seperti apa yang secara tidak sadar dibuat oleh engineer berpengalaman.
AI juga punya semacam konsep trade-off ini, tapi sebagian besar hanya pada level belajar dari observasi.
Memang benar AI membantu “menulis kode dengan baik”, tapi pada akhirnya yang menilai dan berpikir tetap manusia.
LLM tidak “berpikir”.
Dan semakin AI berkembang, semakin besar risikonya manusia jadi makin jarang berpikir.
Bagi saya, kelebihan dan kekurangan Copilot sama-sama terasa nyata.
Tapi tidak seperti gambaran hacker atau “jiwa pengrajin” masa kecil itu, engineer memang sejak dulu selalu engineer.
Alasan teknologi inti masa kini lahir dengan susah payah adalah karena pada saat itu hambatan tersebut memang harus dipecahkan bagaimanapun caranya.
Jika sejarah dramatis seperti itu digeneralisasi sebagai “dulu memang begitulah caranya”, ada risiko sudut pandangnya jadi bias.
Update CRUD yang sederhana memang repetitif dan membosankan, tapi sesekali ada tantangan yang benar-benar bikin berpikir keras, atau momen memakai lagi pengetahuan yang dulu dipelajari di kampus, atau kasus-kasus langka seperti algoritma rekursif; semua itu adalah permata dalam karier.
Saya berharap software engineer yang dipandu AI di masa depan juga semakin menghargai pengalaman seperti itu.
AI mungkin bisa memberikan jawaban yang terdengar logis, tapi kadang bisa benar-benar salah dan bahkan berbahaya, jadi tetap harus ada orang yang tahu apa yang sebenarnya perlu dilakukan.
Saat AI “berhalusinasi” atau kekurangan konteks, akan selalu ada situasi di mana manusia pada akhirnya harus menyelesaikan masalah.
Bagi saya pembandingnya bukan pair programming, melainkan developer outsourcing di luar negeri.
Sejujurnya Copilot, Cursor, dan tool AI lain terasa jauh lebih baik karena saya tidak perlu lagi membuang waktu di Zoom call akibat komunikasi yang ambigu, hambatan bahasa, dan perbedaan pemahaman.
Misalnya situasi yang sering muncul dalam outsourcing seperti “ada fungsi
isChild(mengembalikan boolean) yang ditambahkan terkait root node, tapi ternyata tidak ada hubungannya dengan pengecekan keberadaan parent” atau “parameter API tiba-tiba tidak bisa lagi menerima array”.Saat bekerja dengan AI, kalau masalah seperti ini muncul, saya bisa langsung bilang itu salah dan menjelaskan alasannya, lalu biasanya cepat diperbaiki.
Hampir tidak ada komunikasi berlarut-larut, salah paham, atau waktu terbuang seperti saat bekerja dengan manusia.
Begitu AI nantinya mudah terhubung dengan tiket Jira, sekitar 80% pekerjaan development akan berubah menjadi penulisan tiket dan peran supervisi.
Tentu bukan berarti peran engineer hilang—divisi Biz juga tidak akan bisa menulis tiket yang bagus, dan pada akhirnya seseorang tetap harus bertanggung jawab penuh.
Meski begitu, banyak organisasi kemungkinan akan melupakan hal ini, dan dari situ bisa timbul kecelakaan besar.
Bagian utama yang saya tangkap dari tulisan ini adalah
“Kita akan memuja realitas software saat ini yang mundur, gemuk, dan terlalu diabstraksikan sebagai bentuk terbaik. Budaya memeras performa sampai batas, atau membangun sistem yang ramping, tajam, dan jernih, hanya akan tersisa sebagai cerita masa lalu.”
Ada kekhawatiran bahwa library atau pola arsitektur yang dibuat sebelum 2023 ke depan akan membeku menjadi inti data pelatihan LLM.
Alih-alih terus berinovasi, ketergantungan dan kode berantakan yang terakumulasi selama 30 tahun terakhir bisa terus hidup selamanya.
Saya khawatir hal seperti Javascript juga akan bertahan selamanya.
Belakangan ini saya benar-benar merasakan tekanan dari pimpinan yang setiap hari berkata, “kita tidak cukup memakai AI” atau “kalau adopsi AI, jadwal yang ada bisa dipotong setengah”.
Kami dipaksa mengadopsi tool AI baru demi memenuhi KPI, dan kalau tidak bisa menyesuaikan diri, pengurangan anggota tim pun mulai disebut-sebut.
Rasanya dunia ini sudah benar-benar gila.
AI selalu dibungkus sebagai “alat untuk menggantikan pekerjaan orang lain”.
Padahal alasan AI tampak hebat justru sering kali hanya karena kita menilai pekerjaan orang lain tanpa benar-benar memahami pekerjaan itu dengan cukup baik.
Rasanya para eksekutif sedang memegang palu bernama AI dan mencoba memaku semua hal di dunia ini.
Saya benar-benar berpikir kita perlu mencari cara untuk memangkas struktur manajemen dan menghabiskan lebih banyak waktu untuk pekerjaan yang sungguh produktif.
Saya berharap ada budaya yang lebih fokus pada pekerjaan nyata dan delivery dibanding sekadar pemanfaatan AI.
Ini sebenarnya hanya pola biasa dari
hype cycleindustri AI.Setelah keadaan mereda, yang tersisa hanyalah tool dan teknologi yang benar-benar berguna, sementara sebagian besar akan hilang.
Menurut saya, jalan untuk tetap bertahan adalah memahami dengan bijak apa yang benar-benar akan tersisa, dan kalau bisa memengaruhi perubahan itu, kita harus berusaha ke arah sana.
Paksaan “adopsi secepat mungkin” saat ini justru bertolak belakang dengan esensi engineering, desain, dan kerja teknis seperti yang saya kenal.
Dulu pendekatan yang benar adalah meninjau dengan cermat apakah tool, bahasa, atau layanan tertentu memang layak diadopsi, lalu menyiapkan dasar alasan mengapa itu cocok untuk kasus kita serta apa kelebihan dan kekurangannya.
Proses pengambilan keputusan yang sehat adalah bertanya, “kenapa ini dibutuhkan, dan kenapa layanan ini lebih masuk akal?”
Dulu juga ada proses untuk menguji apakah teknologi itu memang layak diadopsi, lalu mengevaluasi hasil serta efisiensi adopsinya setelah diterapkan.
Perusahaan-perusahaan saat ini sedang menjauh dari cara sehat seperti itu.
Fantasi bahwa “AI selalu bisa menggantikan pekerjaan orang lain” sudah terlalu merajalela.
Memang banyak pekerjaan berisi tugas berulang yang sederhana, tapi untuk melakukannya dengan baik, kebanyakan pekerjaan memerlukan nuansa dan kehalusan yang unik, dan semua itu berisiko hilang dalam proses otomatisasi.
Saya tidak setuju dengan ucapan “cukup 80% saja dengan AI”.
Kesalahan bisa berdampak ke seluruh sistem, dan orang yang menilai hasilnya pasti akan kekurangan pengalaman lapangan.
Saya rasa tidak lama lagi justru jabatan manajerial yang akan hilang lebih cepat.
Sampai saat itu tiba, semangat untuk kita semua.
Penulisnya jelas terdengar seperti developer C++.
Memang dalam praktiknya asisten coding AI jarang benar-benar bekerja baik untuk C++, sementara orang yang memakainya dengan efektif kebanyakan ada di bahasa scripting atau aplikasi CRUD.
Pengetahuan dan materi pengembangan game belum dipelajari LLM dalam jumlah besar, jadi tidak seperti kasus aplikasi CRUD, penulis artikel ini tampaknya lebih jelas merasakan keterbatasan LLM.
Sebagian tulisan ini terasa seperti dibaca dengan suara karakter ‘Bertram Gilfoyle’ dari acara TV Silicon Valley.
Saya penasaran apakah saya saja yang merasa begitu.
Intinya adalah selalu punya kemampuan “teleskop”.
Berkat agen coding, tidak masalah jika kita hanya mengerjakan hal-hal level tinggi, tapi demi keamanan kita harus tetap bisa kapan saja masuk jauh ke dalam kode, memahaminya sendiri, dan memperbaikinya langsung bila perlu.