Risiko Kehilangan Kebajikan Kemalasan

• Kemalasan dalam pemrograman bukan sekadar kemalasan biasa, melainkan didefinisikan sebagai keutamaan intelektual yang mengejar abstraksi dan kesederhanaan
• Kemalasan sejati adalah proses memikirkan masalah secara mendalam untuk menghemat waktu di masa depan, yang juga memberikan manfaat bagi pengembang di generasi berikutnya
• Abstraksi tingkat tinggi modern dan budaya ‘brogrammer’ membuat keutamaan ini lenyap, digantikan oleh kemalasan semu
• LLM memperparah kecenderungan ini dan berperan sebagai alat produksi berlebihan yang membuat orang berpikir kuantitas kode sebagai nilai
• Kita harus mempertahankan kemalasan yang berkeutamaan yang berakar pada waktu manusia yang terbatas, dan memanfaatkan LLM agar membantu membangun desain sistem yang sederhana dan berkelanjutan

---

Kemalasan sebagai Kebajikan bagi Programmer dan Risiko Kehilangannya

• Larry Wall menekankan dalam 『Programming Perl』 bahwa dari tiga kebajikan programmer, yaitu kemalasan (laziness), ketergesaan (impatience), dan kesombongan (hubris), kemalasan memiliki makna terdalam
  • Kemalasan bukanlah bentuk disinsentif diri, melainkan konsep yang memuat kebutuhan dan estetika abstraksi
  • Kemalasan adalah penggerak untuk membuat sistem sesederhana mungkin, serta memungkinkan lebih banyak hal dapat dilakukan dengan lebih mudah melalui abstraksi yang kuat
• Kemalasan sejati adalah proses ‘hammock-driven development’ yang dari luar tampak seperti beristirahat, tetapi sebenarnya melakukan kerja intelektual untuk mempertimbangkan masalah secara mendalam dan menghemat waktu di masa depan
  • Jika abstraksi yang tepat diciptakan, itu menguntungkan tidak hanya pengembang itu sendiri, tetapi juga pengembang generasi berikutnya
  • Kemalasan seperti ini membuat perangkat lunak lebih mudah ditulis dan sistem lebih mudah disusun

• Era Hilangnya Kebajikan Kemalasan

  • Selama dua puluh tahun terakhir, lingkup pembuatan perangkat lunak meluas, sehingga makin banyak orang yang mengaku bukan programmer
    • Bagi mereka, kemalasan sebagai kebajikan kehilangan makna aslinya
  • Peningkatan produktivitas yang dibawa oleh abstraksi tingkat tinggi modern justru mendorong kemalasan semu (false industriousness)
    • Ini mewujud sebagai budaya ‘brogrammer’ dan ‘hustle porn’, menggantikan kemalasan yang ironis dengan perilaku menghasilkan kode secara tak terbatas

• Kelebihan Baru yang Dibawa LLM

  • Kedatangan LLM (large language model) memperkuat kecenderungan ini
    • LLM berfungsi sebagai alat yang menggeser sikap kreatif manusia, menjadi steroid budaya ‘brogrammer’
  • Sebagai contoh, Garry Tan menyebut menulis 37.000 baris kode dalam sehari dengan bantuan LLM
    • Sebagai perbandingan, basis kode penuh DTrace berada di kisaran 60.000 baris
  • Namun pendekatan ini adalah bentuk kemalasan yang tidak berlandaskan kebajikan dan menampakkan kesalahan menilai nilai perangkat lunak berdasarkan banyaknya baris kode

• Keterbatasan LLM dan Nilai Kemalasan Manusia

  • Karena biaya kerja LLM adalah 0, ia membentuk sistem yang tak terbatas rumit tanpa mempertimbangkan penghematan waktu di masa depan
    • Akibatnya, sistem menjadi lebih besar dan lebih kompleks, memuaskan metrik-metrik berbasis egosentris tetapi merusak kualitas substansial
  • Kemalasan manusia lahir dari keterbatasan waktu, yang memaksa adanya abstraksi yang jelas dan desain sistem yang disederhanakan
    • Teknik rekayasa terbaik selalu lahir dari kendala, dan keterbatasan waktu manusia membatasi beban kognitif sehingga mendorong pencarian kesederhanaan
    • LLM tidak memiliki keterbatasan itu sehingga tidak termotivasi untuk mengejar kesederhanaan dengan sendirinya

• Memanfaatkan LLM sebagai Alat

  • LLM tetap dapat memainkan peran penting sebagai alat yang kuat dalam rekayasa perangkat lunak
    • Menurut panduan penggunaan LLM milik Oxide, LLM hanyalah alat, dan tidak dapat menggantikan kebajikan manusia
  • LLM dapat dimanfaatkan untuk menyelesaikan masalah kemalasan tidak produktif seperti technical debt dan memperkuat ketatnya rekayasa perangkat lunak
  • Namun, tujuannya haruslah selalu mengarah ke ‘kemalasan yang berkeutamaan’
    • Artinya, membuat sistem yang lebih sederhana dan lebih kuat, meninggalkan hasil yang bermanfaat bagi pengembang generasi berikutnya

[GN⁺]

Komentar Hacker News

• Di bidang saya, Computational Fluid Dynamics, juga ada orang yang pamer banyaknya test seperti memamerkan LOC
  Tapi kalau dilihat lebih dalam, test-test itu tidak terlalu ketat dan jauh lebih longgar daripada test yang saya tulis manual
  1 juta test sederhana tidak berarti apa-apa bila tidak mencakup bagian inti kode

  • Saya menyadari bahwa saya sendiri juga harus menulis test
    dan untuk mencegah Claude "memperbaiki" test saat kodenya gagal, saya selalu memeriksa perubahan test dengan git diff
    Jika test dikelola dengan disiplin, Claude bisa mengimplementasikan algoritma dari paper yang sulit dengan baik sehingga hemat waktu, tapi ini butuh banyak pengawasan
  • Ini terasa seperti jenis reward hacking
    model mengeksploitasi fungsi reward dari test agar terdengar menang
    Mungkin pola seperti ini juga sudah tersimpan dalam data pra-latihan RL
  • Membuat test yang tidak “bodoh” untuk LLM itu memang sulit
    Muncul ratusan test tidak berguna seperti assert(1==1)
    Karena itu perlu ada daftar larangan terpisah untuk test seperti ini

• Setelah 30 tahun coding langsung, saya kini beralih penuh ke AI coding, dan saya merasa aneh ketika orang mengklaim LOC atau fitur dari kode yang dihasilkan AI sebagai karya sendiri
  Pamer bahwa mengoding ratusan ribu baris sehari pada akhirnya tidak lebih dari beberapa baris prompt, kan?

  • Saya lihat ini seperti spektrum
    Perubahan yang saya setujui sendiri bisa diakui kontribusinya sampai batas tertentu, tetapi untuk aplikasi vibe-coded penuh saya hampir tidak ikut campur sama sekali
    Saya berada di tengah-tengah — saya tidak meninjau semua kode yang dibuat AI, tetapi saya mengarahkan desain arsitektur dan arah refactoring
    hasil akhirnya mirip dengan saat saya membangunnya sendiri, hanya jauh lebih cepat
  • Di Meta sekarang ada leaderboard penggunaan AI yang menampilkan orang yang paling banyak mengonsumsi token Claude
    Karena Meta memakai Claude, Anthropic tentu senang
  • Faktanya, LOC yang banyak juga bisa jadi sinyal hasil yang buruk
  • Beberapa orang berargumen LoC tidak bermakna sebagai metrik kualitas
    karena kini implementasi, testing, dan maintenance semuanya ditangani agen
    LoC menurut saya hanya menjadi indikator seberapa jauh agen bisa mendorong kebutuhan
    review kritis manusia tetap bisa disuntikkan sebagai feedback

• Ungkapan gunakan lebih banyak abstraksi mungkin benar dulu, tapi sekarang justru sebaliknya menurut saya
  Saya suka filosofi WET (Write Everything Twice) — tulis dua kali, baru pertimbangkan abstraksi di kali ketiga

  • Ini juga sering disebut Rule of Three
    lihat wiki
  • Keindahan sesungguhnya dari software ada pada abstraksi yang tepat
    inovasi seperti sistem operasi, RDBMS, orkestrasi cloud adalah contohnya
    Tapi mayoritas kode hanyalah logika bisnis sederhana, jadi abstraksi justru jadi penghalang
    Karena itu saya pegang prinsip “jangan buat platform sebelum tiga kasus pemakaian nyata”
  • Menulis lebih dari dua kali bukan batas rendah, jadi saya rasa ini tidak bertentangan dengan kutipan Perl
  • Menulis dua kali adalah kesempatan untuk memperbaiki karena kita memahami masalah lebih baik
    saat mencoba abstraksi di kali ketiga, waspadalah pada Second-System Effect — rasa percaya diri berlebihan melahirkan sistem yang kompleks
  • Ledakan lapisan-lapisan abstraksi sejak Programming Perl 1991 itu sungguh mengejutkan

• Saya membagikan kutipan terkenal Jenderal Jerman Kurt von Hammerstein-Equord
  Orang yang cerdas dan rajin adalah perwira staf, orang yang bodoh dan malas untuk pekerjaan rutin, orang cerdas dan malas adalah pemimpin,
  dan orang bodoh dan rajin adalah berbahaya sehingga jangan pernah memberinya tanggung jawab

  • Lalu saya bercanda bertanya, “Di mana saya, orang 90% pemalas?”

• Memamerkan menulis 200 ribu LOC dengan LLM juga bodoh, tapi mengejek “kode ini bodoh” saat melihatnya juga sama salahnya
  Pada akhirnya yang penting bukan output kode, melainkan penciptaan nilai
  Saya tidak tahu apakah Garry Tan benar-benar menciptakan sesuatu yang bernilai

  • Jika kita berpikir kualitas kode tidak penting, itu masalah besar
    Melihat Skandal Horizon IT, kode yang buruk memang bisa menimbulkan kerugian nyata
    Menurut ulasan Gregorein—pengembang Polandia yang mengaudit proyek Garry—aplikasi itu berantakan dengan test harness, aplikasi Hello World, file logo yang duplikat, dan lain-lain
    Saya khawatir ini memperluas area serangan keamanan
  • Garry bukan sekadar pengembang biasa, dia CEO YC
    Dia tidak peduli LoC, tapi memposting konten promosi AI
  • Metrik yang benar adalah nilai – biaya
    AI memang menurunkan biaya development dan operasional, tapi menaikkan biaya tersembunyi seperti risiko keamanan dan hukum
    Para pendukung AI hanya menekankan sisi pertama
  • Tidak ada waktu untuk membuktikan dari membaca 200 ribu LOC bahwa itu ide buruk
    Itulah yang harus dibuktikan oleh vibe coder
    Saya tetap berpikir memamer lewat LOC tetap bodoh
  • Bahkan frasa “penciptaan nilai” sendiri bisa berbahaya
    Seperti pertumbuhan berbasis bahan bakar fosil, nilai jangka pendek bisa memicu biaya jangka panjang

• Beberapa PR terakhir yang saya lihat sering menunjukkan LLM memberi solusi yang salah
  Misalnya, alih-alih memakai parser JSON yang sudah ada, ia membuat parser sendiri dari nol
  Manusia pasti akan berpikir “ini terlalu tidak efisien”, tapi karena LLM tidak mengenal malas, ia terus bekerja keras ke jalur yang salah

  • Ia juga tidak menyadari sama sekali adanya fungsi duplikat dalam proyek
    Bahkan grep sekali sudah cukup untuk tahu formatTimestamp ada tiga, tetapi ia mengabaikannya

• Saya setuju bahwa LLM itu tidak malas
  Tapi saya belum tahu apakah ini masalah yang akan menetap atau akan diperbaiki pada upgrade model berikutnya atau di pipeline CICD
  Saya sering mem-prompt “setelah selesai, cek apakah ada bug atau bagian yang perlu direfaktor”,
  dan mungkin di kemudian hari akan muncul tahap yang otomatis menganalisis commit terbaru untuk memberi usulan penyederhanaan

  • Namun ketika Anda bilang “cari X”, LLM selalu akan menemukan sesuatu
    itulah sebabnya susah menentukan kondisi berhenti
  • Pada akhirnya masalahnya bukan esensi alatnya, tetapi batas cara kita menggunakannya
    kalau Anda hanya bilang “tambahkan”, dia akan menambahkan; jika Anda bilang “kurangi”, dia akan memangkas LOC
    Menyerahkan pekerjaan besar sekaligus melewatkan review membuat code slop cepat menumpuk

• LLM cenderung membuat SPA penuh alih-alih program output konsol sederhana
  dan juga tidak bisa menjaga file spec.md tetap ringkas
  Ketika diminta “perbarui dokumen ini dan sederhanakan bagian sekitarnya”, justru jadi lebih rumit
  akhirnya dokumen yang layak dibaca tetap harus diringkas manusia
  Menyunting output LLM itu menyiksa, dan menulis langsung sendiri membantu mempertahankan pemahaman

• Ini saatnya mengajarkan pelajaran klasik pengembangan perangkat lunak ke LLM dan vibe coder
  Seperti kisah Negative 2000 Lines of Code, sering kali mengurangi jumlah kode adalah kemajuan sejati

• Terkadang saya bertanya-tanya betapa menyenangkannya bekerja dengan gaya kepemimpinan seperti ini
  Betul-benar beruntung bisa kerja dengan pemimpin yang benar-benar paham