Kode Menjadi Lebih Murah

• Biaya menulis kode turun drastis seiring meluasnya alat coding AI, tetapi kenyataannya biaya untuk memahami kode yang dihasilkan justru makin besar
• LLM bersifat nondeterministik, tidak menyimpan source asli, dan cakupan outputnya meluas ke seluruh perangkat lunak umum, sehingga tidak bisa disamakan dengan output compiler
• LLM menghasilkan kode jauh lebih cepat daripada kecepatan manusia untuk memahaminya, sehingga disarankan penggunaan bertahap (incremental) agar perubahan besar yang tidak dipahami siapa pun bisa dicegah
• Risiko utama saat kode menjadi murah adalah kompleksitas (complexity), yang setidaknya meningkat secara geometris sesuai skala sistem, sementara LLM adalah pembuat kode produktif tanpa rasa takut terhadap kompleksitas
• Sebagai solusi, diajukan insinyur pengurang (subtractive engineer) yang menghapus dan menyederhanakan alih-alih menambah kode, sambil menekankan pentingnya menjaga seni pemrograman komputer

---

Era ketika kode menjadi murah

• Dalam setahun terakhir, AI mampu menghasilkan kode dengan kualitas yang cukup baik dalam jumlah besar dan sangat cepat, sehingga biaya pembuatan kode turun besar-besaran
• Terhadap klaim bahwa "coding sejak awal bukanlah masalah", penulis membantah bahwa coding juga merupakan bagian dari masalah, dan bagian itu telah banyak dikurangi oleh alat coding AI
• Bagi pengembang yang dulu bangga pada kemampuan coding mereka, ini menimbulkan pertanyaan tentang arti dari menurunnya pentingnya coding murni

Biaya pemahaman meningkat (Understanding is Expensive(er))

• Ketika kode tidak lagi lahir susah payah dari tangan programmer melainkan diproduksi massal, pemahaman atas kode itu sendiri tidak otomatis ada
  • Jika pemahaman diperlukan, maka itu harus diperoleh dengan membaca kode setelah kode ditulis
  • Secara umum, membaca kode yang ditulis orang lain dianggap lebih sulit daripada menulis kode sendiri
• Pembela AI yang berkata "bukankah kita juga tidak memahami output compiler" dinilai melakukan kesalahan kategori (category error)
  • Compiler bersifat deterministik, sedangkan LLM secara desain bersifat nondeterministik
  • Alur kerja compiler mempertahankan source code asli, sedangkan alur kerja LLM umumnya tidak
  • Output compiler terbatas pada domain sempit berupa bahasa mesin, sedangkan output LLM tidak terbatas pada perangkat lunak umum
• Dalam banyak kasus, khususnya pada perangkat lunak mission-critical, pengembang tetap harus memahami kode dasar meskipun kode itu dihasilkan LLM
• LLM dapat memproduksi kode dengan kecepatan yang tidak mungkin dikejar siapa pun, sehingga ada risiko melampaui kecepatan pemahaman
  • Karena itu, disarankan penggunaan bertahap alih-alih menghasilkan daftar perubahan besar sekaligus
  • Ini mungkin cocok untuk refactoring mekanis, tetapi sangat berbahaya saat memperkenalkan makna baru (semantics) ke dalam codebase

Jebakan murid penyihir (The Sorcerer's Apprentice Trap)

• Adegan "The Sorcerer's Apprentice" dari film Disney Fantasia diajukan sebagai metafora yang tepat untuk era AI
  • Murid itu merapal mantra pada sapu untuk meringankan kerja berat membersihkan, tetapi sapu itu membersihkan makin agresif hingga situasi lepas kendali
  • Pada akhirnya sang penyihir (Sorcerer) muncul kembali, mengambil alih situasi, menegur kebodohan muridnya, dan membereskan kekacauan
• Pelajaran dari metafora ini adalah bahwa kita harus menjadi penyihir, bukan muridnya, dan penyihir harus memahami kodenya

Kompleksitas tetap buruk (Complexity: Still Bad)

• Manusia tidak pandai memahami kurva geometris dan eksponensial, serta memperlakukan hal seperti bunga majemuk (compound interest) seolah dongeng
• Risiko utama saat kode menjadi murah adalah kompleksitas (complexity), yang menurut penulis meningkat setidaknya secara geometris, dan sering secara eksponensial, seiring skala sistem
• Bahkan sebelum LLM, sudah ada pembuat kode produktif (prolific coder)
  • Pembuat kode produktif yang tidak takut pada kompleksitas terus menumpuk kode di atas masalah yang sudah ada, hingga sistem runtuh ke dalam keadaan macet yang tak bisa diperbaiki, di mana setiap perubahan menghasilkan bug sebanyak yang diperbaiki
• Karena LLM tidak memiliki rasa takut terhadap kompleksitas sekaligus sangat produktif, maka ia berbahaya

Insinyur yang mengurangi dan membatasi (The Subtractive, Constraining Engineer)

• Untuk menghadapi risiko kode hasil LLM, diajukan insinyur yang mengurangi dan membatasi (subtractive, constraining engineer)
  • Insinyur ini berkata "tidak", meninjau output LLM dengan cermat, mengusulkan penyederhanaan, dan dengan tegas menjaga kendali
  • Ia bangga bukan pada kode yang ia tambahkan, melainkan pada kode (dan layer) yang ia hapus dari sistem atau cegah agar tidak masuk
  • Sikap ini lebih dekat pada pemahat (sculptor) daripada pembangun (builder)
• Sikap sebagai pembangun (builder) tetap valid pada tingkat desain sistem
  • Insinyur yang baik harus mampu menyusun sistem dengan menggabungkan komponen secara efektif
  • Namun bahkan pada tingkat ini, cara berpikir yang mengurangi juga berguna untuk menyederhanakan deployment dan interaksi dengan menghapus komponen yang tidak perlu serta batas antarsistem
• Insinyur pengurang adalah tipe yang berbeda dari kebanyakan coder masa lalu, dan selaras dengan sikap yang lebih suka merapikan sistem yang ada daripada sekadar pandai mengatakan "tidak" atau melakukan penulisan ulang heroik
• Pendekatan ini mengakui kenyataan ganda bahwa kode telah menjadi murah dan kompleksitas tetap predator puncak (apex predator), sekaligus menjadi cara produktif untuk menjaga seni pemrograman komputer

[GN⁺]

Komentar Lobste.rs

• Tulisan Peter Naur tahun 1985, Programming as Theory Building, tampaknya layak dibaca ulang beberapa kali belakangan ini

• Saya rasa ungkapan “LLM tidak bisa takut pada kompleksitas” lebih mendekati hiperbola
  Pola kegagalannya memang nyata. Jika instruksinya dibuat luas, LLM akan menambahkan lapisan, menciptakan abstraksi, dan sering menghasilkan kode yang berlebihan dibanding masalahnya. Namun perilaku itu mudah diamati, mudah direview, dan ternyata cukup mudah pula diarahkan ulang. Cukup sesuaikan gaya software yang diinginkan lewat file AGENTS/CLAUDE.md
  Minta perubahan sekecil mungkin, tanyakan apa yang bisa dihapus, dan tanyakan apakah abstraksi itu benar-benar sepadan. Tanyakan juga invariant, titik coupling, dan beban kognitif, lalu minta pass kedua untuk menghilangkan hal-hal yang terlalu pintar; biasanya model akan mengikuti tekanan itu. Jika dimasukkan ke prompt, model bahkan bisa dibuat menghindarinya sejak awal
  Risikonya bukan karena LLM sama sekali tidak bisa menghormati kompleksitas, melainkan karena ia dengan senang hati menghasilkan bentuk kode yang dihargai oleh proses di sekitarnya. Tim yang memberi penghargaan pada kuantitas akan mendapatkan kuantitas, dan tim yang menghargai kesederhanaan umumnya juga bisa mendapatkannya
  Model-model saat ini lebih baik daripada kebanyakan manusia dan akan terus membaik. Kalau kodenya jelek, kita perlu menekan lab AI lewat feedback. Misalnya, menurut saya lini GPT sangat buruk dalam menulis dokumentasi yang baik

  • Benar dan tidak juga. Intinya tampaknya lebih dekat ke cara pelatihan dan tujuannya daripada kemampuan semata. Yang sedang ngetren sekarang adalah gaya “seluruh proyek saya vibe coding”, dan LLM sangat lemah dalam mengubah kode yang sudah ada dibanding membuat sesuatu dari nol. Kemungkinan besar ini karena cara pelatihannya, dan sepertinya juga ada bias statistik. Kode dari codebase besar dan kompleks jauh lebih banyak daripada proyek kecil dan sederhana, jadi kemungkinan porsinya lebih besar dalam pelatihan
    Jadi, kata “mustahil” mungkin bukan pilihan terbaik, tetapi saya memang melihat ada banyak bias yang secara default condong ke arah kompleksitas
    Ada juga bias untuk melakukan sesuatu daripada tidak melakukan apa-apa. Programmer yang baik memakai jauh lebih banyak konteks daripada manajer yang sekadar melempar permintaan tertentu, dan mereka juga mengusulkan alternatif. LLM mungkin bisa melakukan itu, tetapi saat ini LLM belum mahir mengajukan pertanyaan yang tepat, bahkan jika sudah ada kode untuk “bertanya saat perencanaan” atau mendeteksi pengulangan. Mungkin data pelatihan untuk hal seperti itu juga tidak umum
    Dalam beberapa hal, prompt engineering terasa seperti hack buruk yang mengelilingi seluruh kumpulan masalah ini
  • Saya tidak yakin sepenuhnya setuju dengan ungkapan itu, tetapi jelas memang ada sesuatu di sana. Di satu sisi, saya pernah melihat “kompleksitas umum” seperti model yang secara default membuat proyek CMake raksasa, padahal Makefile dengan satu target saja sudah cukup
    Di sisi lain, saya pernah mendapat jawaban seperti, “Saya tidak merekomendasikan ini untuk proyek satu bulan. Bagaimana kalau commit saja dalam keadaan sekarang dan biarkan jadi demo?” lalu saya harus membujuk dan menenangkan LLM. Padahal saya tahu keduanya bisa selesai dalam waktu kurang dari satu jam. Namun kalau diberi, “Oke, coba bikin sesuatu yang benar-benar baru. Cari sendiri caranya,” model tetap akan mencoba, jadi dalam arti itu bisa juga dibilang tidak punya rasa takut
  • Pembahasan yang bernuansa soal “vibe coding” di Lobsters? Mungkin neraka sudah membeku /s
    Tapi di luar bercandanya, saya setuju. Itu juga cocok dengan pengalaman saya

• Saya umumnya tidak terlalu setuju dengan pernyataan “biaya memahami kode menjadi lebih mahal”
  Kalau yang dimaksud adalah kode LLM yang dihasilkan tanpa pikir panjang, mungkin benar, tetapi dengan arahan yang tepat LLM juga bisa membuat kode yang mudah dibaca dan lapisannya tertata rapi. Tentu saja, dalam kasus itu sebagian besar pilihan arsitektur tetap dibuat manusia, dan memang seharusnya begitu
  Sebagai contoh tandingan, saya merasa LLM sangat hebat untuk memahami kode yang ditulis orang yang tidak kita kenal. Kita bisa meminta Claude Code menganalisis kode tertentu secara mendalam, membuat dokumen Markdown yang menjelaskan tiap bagiannya, dan bahkan menyarankan urutan bagi saya untuk mulai me-review atau memahaminya
  Ini benar-benar sangat bernilai

  • Pengalaman memakai LLM untuk kode yang tidak familiar umumnya bagus, tetapi pada bagian yang menyimpang dari konvensi, model kadang mengarang secara kreatif dan berbohong. Masalahnya, karena kodenya asing, sulit membedakan keduanya

• “Manusia umumnya tidak pandai memahami kurva eksponensial. Karena itu mereka percaya dongeng seperti bunga majemuk.” Jadi maksudnya bunga majemuk itu dongeng? Atau saya yang salah paham?