Tulis kode seolah-olah akan dipelihara oleh manusia

• Bahkan jika LLM terus menulis kode sebagai pengganti kita, jika if yang duplikatif dan implementasi sementara digabungkan apa adanya, kode yang dihasilkan berikutnya bisa mengikuti kebiasaan itu seolah-olah itu adalah aturan proyek
• Jika logika pemeriksaan hak akses diulang di route handler, background job, API endpoint, webhook, dan lainnya, pengujian mungkin tetap lolos tetapi beban pemeliharaan tetap ada
• Karena model membuat kode berikutnya dengan melihat file yang terbuka, pola yang sudah ada, dan perubahan terbaru, 4 if hasil salin-tempel menjadi sinyal yang memanggil salinan kelima
• Meskipun nanti diminta melakukan refactor, sulit menjamin LLM akan merapikan semua salinan yang ada dengan benar, dan pola buruk menjadi lebih mirip gaya codebase daripada kesalahan sekali saja
• Jika if duplikatif, fungsi “god”, dan merge “rapikan nanti” terus menumpuk, akan sulit membalikkannya hanya dengan prompt dan pada akhirnya manusia harus memperbaikinya sendiri

---

Yang dirujuk LLM adalah codebase saat ini

• LLM tidak menulis kode dalam “ruang hampa”, melainkan membaca codebase pengguna
  • file yang sedang dibuka
  • pola yang sudah ada
  • perubahan terbaru
• Jalan pintas yang sudah digabungkan ke codebase menjadi sinyal pembelajaran bahwa “di sini caranya seperti ini”
• Kondisi kontrol akses yang sama bisa berulang di banyak lokasi

if (user.isActive && user.hasPermission('read') &&
!user.isSuspended && account.status === 'open') {
  // do a thing
}

• if ini bisa diekstrak menjadi helper bersama, tetapi bisa saja tetap digabungkan begitu saja karena kode buatan LLM berfungsi dan tesnya lolos
• Saat diminta endpoint kelima dengan aturan yang sama, model lebih mungkin mengikuti salinan yang sudah ada di repositori daripada merancang dari awal

Ilusi menyerahkan pemeliharaan kepada LLM

• Pikiran seperti “nanti saat diubah LLM juga yang mengerjakannya” membuat duplikasi dan code smell dibiarkan begitu saja
• Beberapa if duplikatif mungkin tidak fatal, tetapi code smell seperti ini akan terus menumpuk
  • if duplikatif
  • fungsi “god”
  • merge yang diputuskan untuk “dirapikan nanti”
• Ketika pola buruk bertambah, hasil prompt berikutnya juga ikut terpengaruh, dan sulit percaya bahwa nanti LLM akan memperbaiki semua instance tanpa ada yang terlewat
• Sekalipun merasa pemeliharaan sudah di-outsource ke LLM, pada praktiknya situasinya justru bisa membuat kebiasaan yang makin buruk terus diulang
• Kode harus ditulis seolah-olah akan dipelihara oleh manusia, dan pola kode yang diserap lalu dikembalikan oleh LLM harus dijaga tetap dalam kondisi baik

[GN⁺]

Komentar Hacker News

• Ada baiknya membuat perintah /review sebagai file Markdown kosong di .claude/commands/review.md, lalu menaruh checklist yang harus diperiksa agen di sana
  Saat perlu code review, ketik /review, lalu agen akan melihat checklist itu, merencanakan hal-hal yang layak diperbaiki, dan kemudian bertanya
  File saya dimulai dengan “masuk ke mode perencanaan. lihat perbedaan antara branch ini dan main. hal-hal yang perlu dipertimbangkan: ...”, dan karena saya terus menambahkan item yang ditemukan saat code review agar agen bisa memperbaikinya, sekarang jumlahnya sekitar 200
  Agen tidak terlalu terganggu meski menerima dinding feedback umum dan memeriksa item satu per satu, dan ketika saya menambahkan “pastikan hal-hal baru yang dibuat tidak menduplikasi kode yang sudah ada”, saya terkejut karena ia benar-benar mulai merencanakan pekerjaan perapian
  Ini masih baru menggores permukaannya saja, dan kita perlu memberi alat untuk alat agar tool bisa menjadi tool yang lebih baik

  • Semakin banyak item yang dimasukkan ke daftar, performa agen justru cenderung makin buruk
    Bahkan sekarang pun saya memakai instruksi yang cukup sederhana, tetapi Claude sering melanggar instruksi awal seperti “jangan commit ke git tanpa izin” dan “jangan sign commit message”
    Jika ditanya, ia menjawab “benar, ada instruksi itu tetapi saya mengabaikannya”, dan jika dikoreksi dengan sopan dalam sesi, ia memahaminya, tetapi setelah itu kadang malah jadi tidak bisa commit sama sekali
    Jika disuruh meninjau checklist 200 item, kemungkinan besar ada cukup banyak yang diam-diam terlewat
  • Bagian yang selalu membuat saya tidak puas dengan tool AI adalah sulitnya mengetahui ekspektasi kualitas
    Kalau ini engineer manusia, ketika sudah ada 200 test yang memakai assertion library tertentu, mereka tidak akan menulis test baru dengan library yang sama sekali berbeda, tetapi Claude sudah beberapa kali melakukan hal seperti itu
    Karena itu saya terus menambahkan item seperti “sebelum menulis, periksa dulu konvensi test”
    Sebaliknya, hal-hal dasar seperti apa itu fungsi, atau bahwa test harus menangani diff perubahan, mestinya tidak perlu dijelaskan; tetapi tidak ada daftar yang jelas tentang mana yang perlu disebutkan dan mana yang aman untuk diabaikan, jadi rasanya seperti membangun metode yang lumayan berguna lewat trial and error
  • Penasaran apakah daftar itu bisa dibagikan
    Dalam kasus saya, sering kali saya bolak-balik dengan agen sambil merapikan “sampai terlihat oke menurut mata dan selera saya”, tetapi saya belum membuat daftar seperti itu
    Tergantung proyeknya, kadang masalah kecil atau magic number masih dibiarkan, dan di proyek lain justru diwajibkan konstanta dengan nama bermakna seperti SECONDS_IN_A_DAY = 24 * 60 * 60, jadi ini sangat bergantung konteks
  • Saya mencoba open-code-review dan mendapat hasil yang bagus
    https://github.com/alibaba/open-code-review
    https://layandreas.github.io/personal-blog/posts/beyond-vide...
  • Saya memakai skill review buatan sendiri, dan kalau menambahkan satu hal pada penjelasannya: bagus juga untuk menyuruhnya melihat seluruh kode lebih dulu, lalu melakukan kembali review multi-peran sesuai perubahan
    Misalnya, suruh ia memilih N peran yang paling cocok untuk perubahan tersebut dari daftar peran panjang seperti Senior Engineer, Security Engineer, WCAG specialist
    Claude menjalankan review-review itu secara paralel lalu menggabungkan feedback-nya
    Karena saya melakukan development berbasis spesifikasi, issue yang ditemukan saya tambahkan ke spesifikasi agar jejak issue dan keputusan tetap tersimpan

• Agak aneh betapa banyak engineer yang menambahkan prompt lain di atasnya
  Menurut pengalaman saya, makin begitu hasilnya malah makin buruk: tetap ada abstraksi, tetapi abstraksinya keliru, dan komentarnya berlebihan sampai membuat pemanggilan LLM berikutnya ikut bingung
  Pada codebase yang bagus, ini masih lumayan bisa jalan, tetapi perlahan membuat kode makin buruk, dan jika terus dipakai lalu suatu saat tidak berfungsi, pada akhirnya harus membayar harga karena selama ini tidak benar-benar membangunnya sendiri saat memperbaikinya
  Kalau agent dimasukkan ke codebase baru, biasanya masih ada model mental tentang kode tersebut dan kodenya juga cukup ringkas, tetapi setelah pengulangan menumpuk, keduanya hilang dan performa LLM juga menurun
  Jadi saya memakai LLM untuk eksplorasi dan review, lalu menulis kodenya sendiri
  Coding sendiri juga bukan bagian yang sangat memakan waktu, malah justru yang paling menyenangkan, jadi sulit dipahami kenapa orang ingin menghindarinya; kadang kalau adu balap debugging dengan AI memakai prompt /bug, AI juga tidak selalu lebih cepat

  • Saya setuju dengan kalimat, “Saya menulis kode sendiri. Sulit dipercaya kenapa banyak engineer berusaha menghindarinya”
    Dalam beberapa tahun terakhir, pekerjaan software berubah dari salah satu tempat pelarian rekayasa praktis bagi para otak penasaran yang suka ngoprek dan pecandu teka-teki, menjadi jalur karier bagi orang-orang pintar yang mengejar uang, seperti di keuangan, hukum, atau kedokteran
    Banyak orang yang sekarang menyandang gelar “software engineer” sejak awal memang tidak pernah menikmati pekerjaan itu; mereka hanya cukup pintar dan bertanggung jawab untuk mencapai target yang cukup masuk akal dari pemberi kerja
    Orang-orang seperti itu paling ingin AI agent menyingkirkan kebutuhan akan desain yang ketat dan kerja teka-teki, lalu memungkinkan kecerdasan bawaan mereka dipakai dengan cara yang lebih malas
    Karena mereka tidak pernah menginternalisasi coding dan prinsip-prinsip rekayasa, ketika dikelilingi rekan dengan pola pikir serupa, sulit menebak hasil seperti apa yang akan lahir dari cara ini ke depan
    Jika coding itu sendiri sejak awal terasa sangat membuat frustrasi dan penuh gesekan, akan mudah merasa bahwa AI lebih cepat
  • Inilah alasan saya tetap berpandangan bahwa orang harus menulis kode sendiri bahkan di dunia tempat agent menulis kode “lebih baik”
    Kode tidak cukup hanya dibaca; ia harus dialami dengan susah payah agar benar-benar terinternalisasi
    Agent sering kali membungkus kode lama secara defensif alih-alih bertanya apakah jalur yang sudah ada itu masih perlu dipertahankan, sehingga muncul efek kode defensif dalam jumlah besar yang menumpuk berlapis-lapis seperti boneka Rusia
    https://softwaredoug.com/blog/2026/07/09/write-code
  • Saya sudah cukup lama melakukan “adu balap debugging” dengan AI, dan sebelum Opus 4.8, kalau masalahnya sedikit saja rumit, perbandingannya benar-benar tidak seimbang
    Opus 4.8 adalah titik baliknya, dan terutama untuk masalah rumit, sekarang saya sudah tidak sering bisa mengalahkan Opus 4.8
    Kalau semua orang memakai Opus 4.8 atau yang lebih tinggi untuk semua tugas dan pertanyaan, suasana keseluruhannya akan sangat berbeda, dan saya rasa tidak akan banyak skeptis AI yang tersisa
  • Jika Anda harus memuntahkan kode secepat mungkin hanya untuk menutup tiket tanpa peduli kualitas, AI selalu lebih cepat
  • Saya bekerja dengan alur yang mirip
    Saya masih tetap menulis kode dengan tangan, dan sebagian, meski tidak semuanya, dihasilkan oleh Opus

• Mungkin ini pikiran yang nyeleneh, tetapi ya tinggal tulis saja kodenya sendiri
  Di era AI ini mungkin terdengar seperti konsep yang sulit dipercaya, tetapi kalau kodenya memang harus dibaca dan dipelihara manusia, lebih baik menulisnya langsung demi orang-orang itu
  Saat membaca kode yang terlalu bertele-tele dan hasil salin-tempel, Anda pasti kesal, dan orang lain juga akan begitu
  Kalau menulis sendiri, Anda akan memperbaikinya sendiri dan menuliskannya dengan cara yang masuk akal untuk dipelihara orang lain
  Atau Anda bisa mencoba menenangkan agent dan loop dengan membuat jaring file Markdown yang rumit agar mereka memahami bentuk kode yang akan diharapkan oleh maintainer di masa depan
  Saya tidak tahu jalan mana yang dalam jangka panjang lebih mudah, dan saya penasaran apakah ada orang yang pernah mewarisi lalu mencoba memahami codebase yang digerakkan agent berbasis loop

• Saya tidak begitu yakin seberapa tepat kalimat, “Saat berikutnya Anda meminta endpoint dengan aturan akses yang sama ke LLM, model tidak mulai berpikir dari nol, melainkan memulai dari empat salinan yang sudah ada di repositori”
  Dalam praktiknya, tampaknya ada bias bawaan untuk mengulang struktur dasar dan lebih jarang melakukan reuse atau abstraksi
  Jika pola yang ada memang seperti itu, model tampak seolah mengikutinya, tetapi sebenarnya kemungkinan besar ia akan tetap melakukannya ke arah mana pun
  Bahkan setelah saya lebih dulu menyiapkan abstraksi yang ketat dan contoh penggunaannya, lalu secara eksplisit memerintahkan agar hanya memakai API abstraksi tertentu dan menyalin cara saya menulisnya, pada LLM terbaru pun sering kali keduanya tidak dilakukan; model malah mengimplementasikan ulang struktur dasar dari bawah dan sebagian atau sepenuhnya mengabaikan abstraksi
  Saya tidak tahu pasti kenapa, tetapi saya menduga mungkin karena terlalu banyak kode seperti ini di data latih, sehingga bobot model lebih “tahu” cara menghasilkan keluaran dengan pola tersebut

  • Itulah kenyataan menyedihkan saat ini, dan untuk menghindarinya Anda harus memberi instruksi yang sangat spesifik kepada model tentang cara mengimplementasikannya
    Meski begitu, saya tetap menganggap LLM layak dipakai sebagai mesin implementasi yang cepat
    Tantangannya adalah membuat model memunculkan keputusan implementasi semacam ini lebih dulu sebelum ia berlari ke arah yang salah

• Setelah perubahan besar, saya mendapat hasil bagus dengan prompt berikut
  “Sekarang lakukan pemeriksaan akhir kode. Apakah semuanya sudah rapi dan komponen mengikuti prinsip separation of concerns? Apakah kondisinya dapat dipahami dan dipelihara? Apakah ada asumsi yang mungkin sudah tidak lagi benar? Apakah ada kode sisa dari edit atau eksperimen sebelumnya yang masuk ke codebase? Apakah dokumentasi masih mencerminkan keadaan kode saat ini?”

  • Biasanya saya bilang sesuatu seperti, “Tolong pastikan kode ini sudah dalam kondisi profesional yang layak dikirim oleh seorang engineer senior”
    Lalu model umumnya bisa menyimpulkan yang disebut di atas dan lebih dari itu
    Hanya saja, satu hal yang tetap harus terus saya tunjukkan langsung adalah menghapus semua komentar untuk “pelacakan progres”, dan hanya menyisakan komentar yang cocok untuk pemeliharaan jangka panjang
    Claude meninggalkan komentar seperti “Klik tombol sekarang memicu penyimpanan dan tidak lagi memakai onBlur”, padahal kode sebenarnya tidak pernah memakai onBlur, dan itu hanya jejak dari sesuatu yang sebelumnya ingin dilakukan Claude lalu saya belokkan dalam task/branch yang sama
  • Ini lebih mirip versi panjang dari “jangan membuat kesalahan”, dan mungkin lebih masuk akal kalau ada cron job malam hari yang meninjau pekerjaan hari sebelumnya lalu membuat tugas pagi dengan karakter serupa
    Model memang akan menafsirkannya sesuka hati, tetapi tetap saja sering lebih baik daripada tidak melakukan apa-apa
  • Ini contoh bagus dari cara berpikir native-AI
    Anda mengajarkan semuanya ke AI lalu bertanya apakah ia sudah mempelajarinya dengan benar, dan hasilnya ternyata cukup baik
    Saya mengikuti langkah-langkah yang mirip dengan tulisan ini
    https://www.lucasfcosta.com/blog/backpressure-is-all-you-nee...

• Ada pepatah lama
  “beri komentar pada kode seolah-olah pemelihara berikutnya adalah pembunuh gila yang tahu di mana kamu tinggal”

  • Belakangan ini komentar yang paling bikin marah adalah komentar berlebihan ala LLM yang diletakkan tepat di atas definisi fungsi dan menjelaskan perilaku pemanggil tertentu saat ini dari fungsi itu, sehingga merusak enkapsulasi
    Baru-baru ini aku menemui hal seperti itu lagi dan lagi saat review PR, lalu menulis komentar dengan kesal, dan aku sendiri pun terkejut
    Aku tidak tahu kalau aku bisa bereaksi seperti itu
  • Seseorang yang dulu pernah bekerja bersamaku sering berkata, “komentar adalah permintaan maaf”
    Maksudnya, komentar itu ada karena kodenya sendiri tidak cukup jelas, dan memang ada kasus seperti itu, tetapi secara umum menurutku komentar yang lebih banyak lebih baik daripada lebih sedikit
    Terutama jika komentar itu menjelaskan bagaimana kode terhubung dengan kebutuhan bisnis atau fungsional yang nyata, dan bukan sekadar mengulang apa yang dilakukan kode
    Beberapa tahun lalu aku sering menulis komentar lebih dulu
    Menjelaskan tujuan keseluruhan, membaginya menjadi rutinitas dan urutan pekerjaan, lalu setelah terasa pas, mengisi blok-blok kode di antara komentar
    Rasanya seperti semacam pemrograman literer, tetapi aku sudah melakukannya bahkan sebelum tahu istilah itu, dan sebenarnya itu lebih mirip memberi prompt kepada diri sendiri menuju tujuan
    Kekurangannya, komentar pada akhirnya mudah berubah menjadi sekadar penjelasan dalam bahasa Inggris tentang apa yang dilakukan kode, sehingga belum tentu banyak membantu pemelihara di masa depan
  • Hal yang paling memicu dorongan membunuh bukanlah kode tanpa komentar, melainkan komentar yang usang atau tidak akurat
  • Ini terdengar seperti resep yang mengundang komentar berlebihan
    Kode seharusnya bisa menjelaskan dirinya sendiri, dan komentar dipakai di tempat yang memang ada naganya

• Dalam konteks serupa, prompt yang kusukai adalah “tolong tinjau test yang kamu tulis. Apakah test ini benar-benar menguji hal yang dimaksud? Jika kodenya rusak, apakah test-nya juga gagal?”
  Sungguh mengejutkan betapa seringnya LLM menulis test kosong yang tidak memverifikasi apa pun

  • Aku juga sering melihat test buatan manusia yang tidak memverifikasi kode sebenarnya, melainkan hanya memverifikasi framework test
  • Alur kerjaku adalah menulis test dulu, memastikan test itu gagal, lalu menulis kode minimum agar test itu lolos, dan memastikan statusnya hijau

• Rasanya aneh kalau hal seperti ini masih harus dibahas serius
  Kalau sudah begitu banyak “eksperimen” dengan LLM, bukankah ini seharusnya sudah diterima sebagai hal yang jelas?
  Aku penasaran kapan kita bisa kembali membicarakan coding manual tanpa memperlakukannya seperti sesuatu yang tabu
  LLM memang berguna dalam banyak hal, tetapi ketika melihat orang-orang mendelegasikan pengetikan seluruh source code kepada agen, rasanya
  mirip seperti diberi tahu bahwa web itu bagus jadi kita seharusnya bahagia

• Aku terus menjalankan codebase lewat berbagai model untuk mencari bau kode buruk seperti kode duplikat
  Cukup efektif, dan sepertinya kalau tidak terus dirawat seiring waktu, itu akan menjadi gumpalan berantakan yang makin menumpuk

  • Aku penasaran bagaimana pendapatmu tentang penganalisis statis berbasis AST seperti SonarQube dan Rubocop, yang bisa sangat ampuh mendeteksi kompleksitas siklomatis atau duplikasi kode
    Itu juga bisa dimasukkan ke pipeline build, dan sama sekali tidak memakai token
  • Aku juga penasaran apakah menurutmu memakai model yang berbeda itu penting
    Atau justru proses review dan reset konteks yang lebih penting?

• Aku sudah melihat banyak duplikasi seperti ini, dan hal-hal yang lebih buruk, bahkan pada kode yang dipelihara orang selama 20 tahun
  Sejujurnya, dalam kebanyakan kasus kode yang ditulis dan dipelihara manusia justru lebih buruk daripada yang dibuat LLM sekarang
  Kadang karena kurang pengalaman, kadang karena kelalaian yang disengaja, tetapi biasanya karena jadwal yang ketat dan tekanan untuk segera menyelesaikannya
  Orang tahu cara melakukannya dengan lebih baik, tetapi tidak punya waktu dan anggaran untuk benar-benar melakukannya
  LLM juga mempelajari itu

  • Sebelum LLM, Copilot sudah sering mengulang-ulang, dan sebelum itu ada copy-paste dan Stack Overflow