AI: Ketidakmampuan yang Dipercepat

• Dalam rekayasa perangkat lunak, ketergantungan berlebihan pada LLM dengan cepat mendorong ketidakmampuan
• LLM memiliki keterbatasan sehingga tidak dapat menggantikan berpikir kritis dan kemampuan pemecahan masalah
• Penggunaan LLM disertai berbagai risiko seperti output yang salah, kesalahan input, penurunan kualitas kode, penurunan kemampuan pengembang, hilangnya kesenangan dalam berkarya
• LLM tidak dapat memberikan kemampuan pengembangan yang esensial seperti teori program dan entropi program
• Dalam jangka panjang, kemampuan teknis dan kemampuan berpikir mendalam menjadi lebih penting daripada sebelumnya

---

Pendahuluan

Sejak kemunculan AI dan LLM yang menarik perhatian publik pada akhir 2022, banyak diskusi terus bermunculan
Sebagai insinyur perangkat lunak berpengalaman, penulis membahas dua masalah utama yang diamati dari LLM

Sudut pandang "LLM adalah teman saya"

Para insinyur yang menganggap LLM sebagai alat terbaik cenderung menempatkan kecepatan sebagai nilai tertinggi
LLM memang dapat menghasilkan banyak kode dengan cepat, tetapi hal ini mengandung risiko jangka panjang

Risiko penggunaan LLM

• Risiko output yang salah: LLM menghasilkan kode yang jelas salah (tidak bisa dikompilasi) maupun kode yang memiliki kesalahan halus (seperti bug logika)
  • Ketika orang yang tidak memiliki kemampuan evaluasi meminta source code, kemungkinan menerima jawaban yang tidak tepat menjadi tinggi
• Risiko input yang salah: LLM tidak mengkritisi asumsi yang keliru atau prompt yang kekurangan konteks
  • LLM tidak bisa membedakan pertanyaan yang benar dan juga tidak memahami masalah XY (gagal mengidentifikasi akar penyebab)
• Penurunan kecepatan pengembangan di masa depan: Adopsi LLM dengan cepat meningkatkan utang teknis dan secara internal mengubah codebase menjadi membingungkan dan sulit dipelihara
• Risiko pematangan pengguna yang terhambat: Ketika kesempatan untuk memecahkan masalah dan mengembangkan daya pikir hilang, kemunduran kemampuan talenta pengembang akan semakin cepat
  • Pengembang senior tidak mendapatkan pengalaman pemecahan masalah yang lebih mendalam, sementara pengembang junior bahkan tidak sempat membangun kemampuan mereka
• Hilangnya kegembiraan berkarya: Penulisan kode berbasis LLM merampas kondisi flow dan kesenangan dalam berkarya, dan membaca serta mengubah kode buatan AI sering terasa menyakitkan

Kekhawatiran "Apakah saya akan kehilangan pekerjaan karena AI?"

Kemungkinannya sangat kecil
Ada dua kemampuan pengembangan yang tidak dapat digantikan oleh LLM: teori program dan entropi program

Teori program

• Seperti yang dikemukakan Peter Naur, “pemrograman adalah aktivitas membangun teori desain”
  • Source code bukanlah hasil akhir yang sesungguhnya; pemahaman kolektif (teori) jauh lebih penting
  • Jika dua tim dengan kemampuan yang sama diberi masalah yang sama dan hanya diberikan kodenya, tim yang membuatnya sendiri akan dapat menambahkan fitur dengan jauh lebih efektif
  • Produktivitas pada codebase yang belum familiar awalnya rendah, lalu meningkat secara bertahap seiring pemahaman atas teori desain internal

LLM dan teori program

• LLM hanya memiliki memori dalam konteks, sehingga tidak dapat menginternalisasi teori program yang sejati atau desain yang mendalam
  • Pada kenyataannya, esensi sejati coding (membangun desain dan teori) hanya dapat diperoleh oleh manusia

Entropi program

• Fred Brooks menyebut kompleksitas (entropi) sebagai kesulitan mendasar dalam pemrograman
  • Pemeliharaan program meningkatkan kompleksitas, dan bahkan pelaksanaan terbaik sekalipun dapat membawa sistem menuju penuaan yang tidak dapat dipulihkan

LLM dan entropi program

• LLM hanya melakukan prediksi token pada tingkat teks, dan tidak mampu melakukan pemikiran semantik pada tingkat ide, rancangan, atau kebutuhan
  • Semakin panjang percakapan atau semakin besar potongan kode yang ditangani, LLM berulang kali membuat perubahan yang tidak perlu atau aneh, sehingga hanya menambah kompleksitas
  • Pekerjaan untuk mengurangi atau melawan kompleksitas hanya dapat dilakukan oleh manusia

Kesimpulan

Berdasarkan wawasan dari dua pelopor, artikel ini menegaskan kembali hakikat desain perangkat lunak dan kompleksitas
Jika Anda berharap AI akan meningkatkan karier pengembangan Anda, justru ada risiko ketidakmampuan dipercepat
Sebagai pengembang dengan pengalaman kaya dan keahlian matang, kita perlu menyadari bahwa LLM tidak dapat menggantikan insinyur manusia
Daya tarik bisnis dari adopsi AI adalah pengurangan biaya, tetapi pada kenyataannya hal itu menimbulkan risiko baru, dan jika digunakan berlebihan akan menumpuk biaya tambahan jangka panjang serta risiko organisasi
Pentingnya kemampuan teknis dan kemampuan berpikir mendalam tidak akan berubah dalam jangka panjang; AI harus digunakan sebagai alat, dan kita perlu terus berinvestasi pada kemampuan esensial yang sudah penting bahkan pada 2019

Pratinjau tulisan berikutnya

Pada pos berikutnya, penulis berencana membahas solusi konkret untuk masing-masing risiko

Referensi

• Leading Question: https://en.wikipedia.org/wiki/Leading_question
• The XY Problem: https://en.wikipedia.org/wiki/XY_problem
• ThoughtWorks Technology Radar Volume 32: https://thoughtworks.com/content/dam/…
• Coding as Craft: Going Back to the Old Gym: https://cekrem.github.io/posts/…
• Thoughts on Thinking: https://dcurt.is/thinking
• The Hidden Cost of AI Coding: https://terriblesoftware.org/2025/04/23/the-hidden-cost-of-ai-coding/
• "I wonder if I'll become redundant": https://reddit.com/r/ExperiencedDevs/…
• Programming as Theory Building: https://pablo.rauzy.name/dev/naur1985programming.pdf
• Grug on Complexity: https://grugbrain.dev/#grug-on-complexity
• Gartner Hype Cycle: https://en.wikipedia.org/wiki/Gartner_hype_cycle

[GN⁺]

Pendapat Hacker News

• Berbagi pengalaman bahwa terkadang diskusi tentang AI coding terasa mencerminkan perbedaan antara software engineer dan data scientist/machine learning engineer
  Software engineer selalu dituntut membuat software yang dapat diprediksi dan lolos pengujian, dan tooling-nya juga jauh lebih matang
  Sebaliknya, bagi machine learning engineer, bekerja dengan model probabilistik adalah hal yang wajar sehari-hari, dan pengujian pun biasanya lebih berpusat pada metrik daripada output tertentu
  Karena itu mereka lebih terbiasa dengan fakta bahwa AI tidak selalu dapat diandalkan
  Coding assistant pun didekati dengan pola pikir bahwa meski hanya memberi jawaban benar 80%, 20% sisanya bisa saya tangkap sendiri
• Dalam pengalaman saya juga, sekitar setengahnya terasa serupa
  Saat bekerja di Amazon, solusi berbasis ML sangat berguna untuk masalah yang tidak punya pendekatan klasik
  Namun di sebuah startup, tanpa pemahaman dasar tentang filtering atau mapping, mereka bersikeras hanya memakai pendekatan berbasis pembelajaran dan terus menghasilkan hasil konyol untuk estimasi pose pesawat yang diam
  Kesenjangan antara ML dan software engineering ini terasa jelas, dan ada harapan agar ada cara untuk menampakkannya lebih baik dalam proses rekrutmen
• Dalam suasana saat ini, terasa seolah mindset MLE dipaksakan juga ke kelompok lain
  Di perusahaan yang menjual produk di mana akurasi dan kebenaran adalah hal utama, tim ML berargumen bahwa 80~90% sudah cukup, dan terlihat ketidakpuasan arsitek terhadap hal itu
  Mengingatkan pada contoh diskusi fatalitas 1% saat pandemi, bahwa persentase kecil pun bisa memberi dampak besar
• Disebutkan perbedaan antara perilaku deterministik (Deterministic) dan probabilistik (Probabilistic)
  Tulisan ini berfokus pada kegelisahan meta tentang AI dan software engineering, yakni pengelolaan entropy program
  Pengelolaan entropy adalah bagian yang sangat besar dalam membangun produk software, dan AI mungkin suatu hari bisa mempermudah bagian ini, tetapi saat ini justru sering memperburuk entropy
• Saat ini sedang mengambil program master AI, terutama ML, sambil membangun otot baru sebagai SWE
  Memandang MLE dari perspektif SWE yang lebih luas, dan perlu memahami keseluruhan seperti membangun pipeline yang robust, integrasi model, deployment, dan sebagainya
  Namun kebanyakan lulusan murni MLE kekurangan sudut pandang SWE, dan sering kali hanya memahami ML tanpa intuisi komputasional
  Untuk benar-benar menjadi full-stack, memahami sistem level rendah, arsitektur, deployment, hingga MLE adalah hal yang esensial
  Tetapi pasar kerja kebanyakan hanya mencari SWE atau PhD MLE, sehingga muncul semangat untuk meminta imbalan bagi orang seperti saya yang memahami semuanya
• Software engineer juga sebenarnya banyak menerapkan pemikiran probabilistik
  Misalnya saat mendesain ulang race condition, memprediksi p99 dari panggilan DB, atau A/B test
• Secara umum setuju dengan argumen artikel, tetapi juga menemukan perubahan positif dari penggunaan LLM
  Sebagai developer senior dengan pengalaman 30 tahun, keharusan membaca kode yang dihasilkan AI berarti pengembangan bergeser ke alur yang berpusat pada code review
  Ini membantu developer individu juga belajar rasa tanggung jawab tingkat tim dan pengalaman membaca kode
  Selain itu, untuk menggunakan LLM dengan benar, pemahaman tentang struktur hierarkis masalah adalah hal yang wajib
  Mendesain secara rinci per bagian sebelum implementasi secara alami membantu mendefinisikan antarmuka dan batasan
  LLM adalah katalis yang mempercepat pertumbuhan junior menjadi senior dan membantu mereka merasakan pembelajaran dari developer berpengalaman
  AI tidak akan menggantikan developer dan pada akhirnya akan menyatu sebagai alat
  • Saya selalu berpikir jumlah kode yang dibaca harus lebih banyak daripada yang ditulis
    Kode hasil LLM mungkin monoton, tetapi itu pun tetap peluang belajar
    Dari kode yang dihasilkan LLM saya banyak mengetahui idiom baru/pemanggilan library baru, dan sebagainya
    Semakin senior seseorang, semakin baik prompt yang bisa ia berikan, sehingga LLM menjadi katalis yang lebih kuat
  • AI sangat bagus untuk sekadar membuat kode di tingkat prototipe yang bisa di-copy-paste, tetapi tidak untuk langsung direview dan di-commit
  • Dari sudut pandang perusahaan, AI bukan membantu junior, melainkan menjadi alasan untuk menghapus perekrutan junior dan menuntut produktivitas 10x dari senior dengan AI
    Baik big tech, mid tech, maupun small tech sama-sama terus melakukan pengurangan karyawan
• Perdebatan tentang AI dibandingkan dengan dulu orang bertanya apakah 3D printing akan menggantikan seluruh manufaktur
  Argumennya, AI lebih dekat ke perubahan realistis seperti itu daripada ke singularity
  • 3D printing memang teknologi yang sangat keren dan inovatif, tetapi injection molding masih tetap ada
  • 3D printing mungkin tidak memicu singularity, tetapi di lingkungan kerja pengetahuan seperti pendidikan universitas, AI sudah memberi dampak besar
    Dibagikan kenyataan bahwa cara kuliah/tugas/kelas yang dulu dianggap wajar kini berubah cepat di seluruh dunia sejak munculnya LLM
  • 3D printing adalah contoh yang membawa perubahan dan inovasi besar di banyak industri seperti dirgantara dan antariksa
    Tanpa SpaceX, banyak wilayah yang secara praktis tidak mungkin dicapai
  • Ini juga mirip dengan harapan bahwa Bitcoin akan menggantikan bank
    Pada akhirnya hasilnya justru bank menjual produk finansial berbasis Bitcoin
  • 3D printing dan AI memiliki kurva pertumbuhan yang sama sekali berbeda
    3D printing tidak dipandang sebagai pengganti manufaktur lama, dan tetap lebih banyak dipakai untuk prototipe/mockup/PoC
• LLM sangat unggul dalam menulis kode, tetapi tidak bisa menjadi subjek yang memikul 'tanggung jawab'
  Kode yang diterima tanpa dipahami akan dibayar mahal nanti saat pemeliharaan dalam bentuk technical debt
  Seperti ilusi kecepatan gratis, padahal sebenarnya technical debt menumpuk seolah dengan bunga tahunan sekitar 40%
  AI hanya mengotomatisasi pengetikan; berpikir tetap harus dilakukan manusia
  • Karena LLM tidak benar-benar 'memahami', comprehension yang sesungguhnya hanya terjadi ketika manusia memahami konteks codebase dan sistem
  • Diajukan cara menurunkan suku bunga itu, yakni lewat testing dan penataan subsistem terisolasi (tdd, microservices, dan sebagainya)
    Ada yang berpendapat bahwa tdd dan microservices, yang mungkin dulu tidak terlalu diperlukan dalam pengembangan tradisional, justru jadi lebih bernilai di era LLM
  • Bergantung pada tugasnya, AI kadang juga sangat buruk bahkan untuk menulis kode
• Pengalaman bahwa input risk adalah titik sakit terbesar
  Hanya karena sedikit ambiguitas dalam prompt, hasil bisa melenceng total, dan ketika itu baru disadari, sangat sulit memperbaikinya
  Karena ambiguitas bahasa manusia, pada akhirnya lahirlah bahasa formal yang jelas
  Secara pribadi, saat memakai tooling AI terasa kemampuan saya menurun drastis, bahkan ada kasus di mana justru menghabiskan lebih banyak waktu dan energi
  AI memang berguna, tetapi tampaknya ada dua kubu: satu kubu yang melihat bagaimana kesalahan kecil terakumulasi dalam masalah kompleks, dan kubu manajer/nonteknis yang hanya melihat hasil lalu mengklaim 'penggantian peran'
  [Pengalaman lebih detail: komentar sebelumnya]
  • Disarankan memakai AI sebagai asisten saya, sementara saya sendiri tetap bertanggung jawab penuh atas kualitas dan maintenance
    Seperti kalkulator menurunkan kemampuan berhitung mental manusia, AI juga bisa menurunkan kemampuan menulis, berkomunikasi, dan memecahkan masalah
  • Dibagikan pengalaman bahwa memasukkan kata yang ambigu membuat LLM menghasilkan hasil yang tidak logis
    Karena itu LLM hanya dipakai untuk tugas kecil dan jelas, atau masalah yang biasanya dicari di StackOverflow
    Jawabannya diperlakukan bukan sebagai kebenaran mutlak, melainkan panduan
  • AI memang membantu menyelesaikan beberapa masalah lebih cepat, tetapi tidak mampu menyelesaikan masalah yang dibuat lebih rumit dari yang perlu
    Kemampuan manusia memahami cetak biru keseluruhan adalah inti dari perlawanan terhadap entropy
  • Metode yang sering dipakai: pertama meminta LLM, "tolong ajukan 5 pertanyaan yang jelas selama 3 ronde"
    Dengan begitu topik dan konteks bisa diperjelas lebih baik
    Semoga tip ini juga membantu orang lain
  • Ada firasat bahwa setelah era hype ini, pentingnya quality control pada akhirnya akan ditemukan kembali
    Contoh: perang lama Coke vs Pepsi
• Sulit setuju dengan klaim bahwa LLM tidak menangani ide, diagram, dan spesifikasi secara konseptual
  Jika ditanyai tentang maksud desain, misalnya dengan meminta 'kode yang disederhanakan', LLM cukup mampu memberi second opinion yang baik
  Jika tidak ditanya, memang tidak akan ada jawaban, dan pengaturan default pun adalah pilihan kita sendiri, sehingga ini terasa bukan argumen yang berkaitan dengan hakikat teknologi dasarnya
  • Ada kasus-kasus yang sudah menunjukkan secara empiris melalui berbagai cara bahwa LLM bisa melakukan pekerjaan konseptual
    Di dunia nyata, tidak ada seorang pun yang bisa memahami sepenuhnya program raksasa di dalam kepala, sehingga alat dan bahasa berkembang berdasarkan pemahaman parsial
    LLM juga berbagi keterbatasan itu, sehingga dalam kerangka ini manusia dan LLM memiliki batasan yang mirip
  • Saat me-review kode junior, sering terasa masalahnya lebih pada arah daripada kualitas kode itu sendiri
    Sayangnya LLM sulit memiliki kemampuan untuk bertanya, 'kenapa dilakukan seperti itu?' terhadap arah tersebut
  • Ditanyakan apakah ada yang memakai alat otomatis untuk konversi kode→diagram, atau membuatnya sendiri
• Disebutkan kemiripan dengan klaim bahwa software peta seperti Google/Apple Maps membuat kemampuan navigasi manusia merosot
  Ada benarnya, tetapi menurut saya kebanyakan orang memang dari awal tidak pandai mencari jalan, dan justru teknologi peta meningkatkan kemampuan rata-rata untuk berpindah dari A→B
  Bahkan bagi sedikit orang yang terampil pun, teknologi lebih berperan sebagai bantuan daripada pengganti kemampuan mereka
  AI kemungkinan akan membawa perubahan serupa pada skala yang lebih besar; ada titik-titik di mana kemampuan berkurang dan hilang, tetapi juga banyak yang didapat
  • Dari sisi keandalan, peta tidak bisa dibandingkan dengan LLM
    Peta hampir selalu memberi nilai yang diharapkan, sedangkan hasil LLM berubah bahkan untuk prompt yang sama sehingga sulit dipercaya
    Seperti orang yang sampai tercebur ke danau karena terlalu percaya peta, kepercayaan buta pada LLM bisa memicu masalah yang lebih besar
  • Secara pribadi, memakai software peta justru membantu memori spasial
    Saya bisa bebas tersesat lalu menangkap rute saat dibutuhkan, sehingga pengalaman malah terasa diperkuat
  • Google Maps lebih dari 90% lebih akurat daripada sopir taksi
    Sementara AI kadang bahkan kalah dari orang biasa yang baru beberapa hari mencoba bidang itu
  • Diragukan apakah ada bukti untuk klaim 'peningkatan kemampuan rata-rata'
• Tidak setuju dengan klaim penulis bahwa '[AI] tidak bisa bekerja pada level konseptual'
  LLM belakangan ini jelas bisa bekerja pada level konseptual, misalnya menerjemahkan atau menerapkan konsep
  Bahkan diklaim memahami konsep yang belum pernah dialami manusia itu sendiri secara pribadi
  • LLM memodelkan konsep melalui cluster token
    Misalnya, kata 'dog' dikelilingi kata-kata terkait
    Namun ia tidak bisa memodelkan kombinasi, niat, atau logika kontrafaktual
    Untuk pertanyaan yang mirip dengan data latih, model menunjukkan kekuatan
    Di domain seperti software engineering, di mana konseptualisasi relatif terdefinisi baik, ini berguna
  • Ditambahkan contoh bahwa manusia pun bisa memahami konsep yang tidak pernah mereka alami langsung
• Secara realistis, 70% karyawan bekerja asal-asalan, dan kadang AI justru lebih baik
  Pada akhirnya orang yang memang tidak serius bekerja akan tetap sama walaupun memakai AI, sementara hanya orang yang benar-benar belajar yang akan tumbuh bersama AI
  • Ditunjukkan keterbatasan narasi yang berpusat pada diri sendiri, yakni merasa dirinya termasuk 30% yang berbeda
  • Orang yang mencoba menyerahkan pekerjaan seadanya ke AI justru memperbesar risiko dirinya dipecat
    Jika AI mengerjakan pekerjaan lebih baik, itu hanya menjadi alasan untuk menggantikan pelakunya
  • Dalam standar perusahaan besar, argumen ini terasa paling realistis sehingga disetujui
    Bahkan FSD pun jauh lebih baik daripada pengemudi biasa yang bukan ahli
• Dibagikan situasi baru-baru ini yang membuat merasa perlu membangun kembali 90s.dev sebagai komunitas non-AI, ruang untuk craftsmanship software
  Sedang memikirkan bentuk seperti forum, mailing list, atau multi-blog
  Mailing list sementara
  • Dibanding struktur yang bisa diikuti siapa saja, menurut saya komunitas berbasis undangan dengan struktur pohon kepercayaan dari pemberi rekomendasi lebih cocok untuk keberlangsungan jangka panjang
    Sudah ada contoh yang berhasil di komunitas tertentu
  • Menggunakan software forum klasik era dulu dengan desain bergaya retro juga terdengar seperti ide yang bagus