Menggunakan AI untuk Menulis Kode yang Lebih Baik dengan Lebih Lambat

• AI untuk coding dapat dimanfaatkan bukan hanya untuk menghasilkan kode berkualitas rendah dalam jumlah besar dengan cepat, tetapi juga untuk meninjau PR secara mendalam dan membuat kode berkualitas tinggi secara perlahan
• Agen LLM kuat dalam mendeteksi bug di codebase, tetapi tantangan sebenarnya ada pada penentuan prioritas dan verifikasi terhadap temuan tersebut
• Claude skill yang menggunakan beberapa model sekaligus meninjau PR dengan Claude sub-agent, Codex, dan Cursor Bugbot lalu membuat laporan akhir yang mengurangi false positive
• Alur pemrosesannya adalah memperbaiki masalah critical/high secara berulang, melewati item yang manfaatnya rendah dibanding biayanya, dan membatalkan PR jika ada terlalu banyak masalah fatal
• Pendekatan ini lebih mengutamakan kesehatan codebase daripada kecepatan, serta memperkuat pemrograman yang hati-hati dengan memahami failure mode dan bug yang sudah ada

---

Cara lambat menggunakan AI untuk coding

• Pandangan bahwa AI untuk coding hanya berguna untuk menghasilkan kode berkualitas rendah dalam jumlah besar dengan cepat meremehkan fleksibilitas LLM
• LLM dapat digunakan secara efektif bukan hanya untuk pembuatan kode cepat, tetapi juga untuk menulis kode berkualitas lebih tinggi dengan lebih lambat
• Berlawanan dengan pendekatan seperti slop cannons yang membanjiri dengan PR besar tanpa verifikasi, ada juga cara untuk meninjau PR lebih dalam dan dengan gigih memeriksa kemungkinan kegagalan

Verifikasi dan prioritas lebih penting daripada deteksi bug

• Mythos menunjukkan bahwa agen LLM sangat mampu menemukan bug di codebase
• Dalam contoh lain, model selain Mythos juga dapat menemukan banyak bug di codebase yang belum ditinjau
• Model publik terbaru dari Anthropic dan OpenAI memang berbeda dalam kemampuan mendeteksi bug yang subtil dan menghindari false positive, tetapi tetap mampu menemukan cukup banyak bug
• Kesulitan yang sebenarnya bukan pada menemukan bug itu sendiri, melainkan pada penentuan prioritas dan verifikasi

Claude skill yang meninjau PR dengan beberapa model

• Pendekatan AI code review yang membandingkan dan memperdebatkan beberapa model berfokus pada gagasan bahwa semakin banyak model berbeda yang dilibatkan, semakin kecil kemungkinan halusinasi atau laporan bug yang keliru
• Claude skill yang digunakan menjalankan Claude sub-agent, Codex, dan Cursor Bugbot untuk meninjau PR
• Setiap alat memberi peringkat bug dalam PR sebagai critical/high/medium/low, lalu hasilnya digabungkan untuk membuat laporan akhir yang sudah menyaring false positive
• Cakupan “bug” dapat diperluas sesuai standar proyek
  • Pelanggaran prinsip KISS dan DRY
  • Apakah HTML/JSX ditulis dengan aksesibilitas yang baik
  • Apakah query SQL menggunakan indeks yang tepat
  • Standar kualitas spesifik proyek lainnya

Workflow nyata dan kriteria pengambilan keputusan

• Pendekatan ini dapat menemukan banyak bug di PR, dengan tingkat false positive yang bisa ditekan hingga hampir nol
• Masalah yang ditemukan beragam, mulai dari bug fatal terkait keamanan dan akurasi, masalah performa, hingga masalah dengan tingkat keparahan rendah seperti “komentarnya menyesatkan”

• Alur penanganan umum

  • Masalah dengan peringkat critical dan high diperbaiki oleh agen, tetapi solusi yang tepat diarahkan oleh manusia
  • Proses ini diulang sampai tidak ada lagi critical/high
  • Masalah high/medium yang manfaatnya rendah dibanding biaya perbaikannya dilewati
  • Contoh khasnya adalah ketika dibutuhkan 100 baris kode untuk memperbaiki edge case yang sempit
  • Jika ada terlalu banyak masalah critical hingga pendekatan keseluruhannya dianggap salah, PR dibatalkan

Fokus pada kesehatan codebase, bukan produktivitas

• Teknik ini tidak selalu meningkatkan kecepatan pengembangan
• Selama proses review, bug lama yang sudah ada sebelum PR dapat ditemukan, lalu berujung pada penulisan unit test dan perbaikan cacat yang subtil
• Pendekatan ini nyaris kebalikan dari gaya pengembangan “produktivitas 10x” yang sering diasosiasikan dengan “vibe coding”
• Dalam arsitektur yang kompleks, failure mode bisa lebih menarik daripada jalur normal, dan proses memahami serta memperbaiki titik kegagalan itu dapat menjadi cara untuk mempelajari codebase
• Berguna untuk memperbaiki kesehatan seluruh codebase sambil mempelajari bagian-bagian yang kurang dikenal

Praktik untuk vibe coding yang lambat

• Jika Anda adalah developer yang memakai agen untuk membuat PR ratusan baris yang bahkan belum sepenuhnya Anda pahami, Anda bisa mencoba pendekatan yang lebih lambat
• Anda dapat bertanya kepada agen bagaimana PR tersebut bekerja dan di mana ia bisa gagal
• Jika perlu, Anda dapat memintanya menulis dokumen Markdown yang menyertakan Mermaid charts
• Anda dapat memakai skill Matt Pocock /grill-me sampai benar-benar memahami PR dari awal sampai akhir
• “Produktivitas” yang diukur berdasarkan jumlah baris kode mungkin tidak meningkat, dan setelah menghabiskan banyak token, Anda bisa saja sampai pada kesimpulan bahwa rencana awal memang salah
• Pendekatan ini lebih dekat pada bentuk yang memperkuat pemrograman yang hati-hati, sistematis, dan terobsesi pada kualitas yang sudah lama diupayakan bahkan sebelum era LLM

[GN⁺]

Opini Lobste.rs

• Di tempat kerja saya, kami sudah menyerah pada mimpi bergerak lebih cepat dengan AI. Dalam kasus kami, coding bukan bottleneck
  Meski begitu, hal yang bagus dari agen coding adalah ia membuat kami bekerja seperti insinyur yang selalu ingin kami jadi
  Misalnya, membuat test harness yang layak agar bisa mendorong kode sedikit lebih jauh, menambahkan tahap CI yang memverifikasi apakah kode hasil generasi sesuai dengan sumber aslinya, dan memantau deployment perubahan dengan benar
  Dulu hal-hal seperti ini tidak mungkin saya tanggung dari sisi jadwal, karena saya harus membaca manual GitLab CI, mencari tahu cara memenuhi kondisinya, dan memahami cara kerja perusahaan kami yang berbelit-belit; sekarang itu jadi mungkin, dan menurut saya inilah masa depannya

• Saya cukup sukses menggunakan LLM sebagai partner spike yang paham API atau alat refactoring mekanis, terutama di bahasa yang strongly typed. Ini juga bagus untuk menulis test, tetapi perlu ada prosedur berlapis untuk memastikan test itu benar-benar punya daya paksa
  Mutation testing cukup membantu, dan seperti yang disarankan tulisan aslinya, peninjauan berulang juga diperlukan
  Dulu saya jauh lebih negatif terhadap LLM, dan kalau dipikir-pikir sampai agak tidak rasional, tetapi sebagian besar itu karena software berkualitas rendah yang terus dimuntahkan LLM
  Setelah saya menggali sendiri, ternyata yang tepat adalah memperlakukannya sebagai alat prototyping dari kardus dan juru ketik yang jauh lebih cepat. Misalnya, kalau saya bilang “cari pola ini di semua teorema pada proyek Lean ini lalu ubah jadi pola itu, dan tandai yang tidak langsung berhasil lalu beri saya daftar sisanya”, ia akan memperbaiki lebih dari 100 teorema per chunk dalam waktu yang biasanya saya habiskan untuk satu-dua percobaan awal dengan campuran vim, sed, awk, dan akal-akalan
  Lean sangat cocok karena, berkat karakteristik bahasa dan jenis pekerjaan saya, jarak antara “berhasil dikompilasi” dan “berfungsi” itu sempit, dan di Rust saya merasakan hal serupa jika dipasangkan dengan test suite yang bagus dan mutation testing
  Ekor panjang dari alat-alat ini bukanlah “tekan tombol lalu produk jadi”, melainkan insinyur yang baik menerima alat ini, memusatkan energinya pada hal-hal penting, dan mendelegasikan banyak pekerjaan remeh yang dulu harus dilakukan sendiri kepada mesin

  • Awalnya saya juga sangat negatif terhadap LLM, tetapi sekarang menurut saya kualitasnya sudah membaik sampai titik di mana lebih sering membantu daripada mengganggu
    Contohnya menarik; dulu ketika saya bekerja di tim framework JavaScript, saya menulis sendiri codemod untuk pekerjaan seperti upgrade atau migrasi. Itu pekerjaan berat mengutak-atik AST
    Kalau sekarang, rasanya saya bisa menyerahkannya ke LLM dan mencapai sekitar 90%

• Saya suka sudut pandang seperti ini. Kelihatannya sudah jelas bahwa alat ini fleksibel dan tidak harus selalu menghasilkan keluaran berkualitas rendah, tetapi baik pihak yang mendukung maupun yang menolak sering mengabaikan pandangan ini
  Saya belum pernah mencoba code review dengan LLM, tetapi sepertinya perlu saya masukkan ke daftar hal yang harus dicoba. Sejauh ini saya memakainya untuk menghasilkan ide, membantu SQL atau VimScript, dan menulis kode sendiri
  Salah satu risikonya adalah code review juga merupakan keterampilan, jadi kalau terlalu bergantung pada model, kemampuan itu bisa menurun. Namun, di lingkungan komersial, bahkan code review terbaik pun biasanya adalah gabungan dari “waktu yang cukup” dan “apakah saya memercayai orang ini”, bukan sesuatu yang mendekati ketepatan matematis

  • Itu juga benar, tetapi saya justru merasa alur kerja ini meningkatkan kemampuan code review saya. Soalnya saya harus menilai apakah “bug” itu benar-benar mungkin terjadi atau hanya teoritis, apakah layak diperbaiki, atau sebaiknya dipindahkan ke PR berikutnya
    Untuk bug yang rumit, saya cenderung tetap memikirkannya sendiri sampai tuntas, karena 1) halusinasi masih kadang ikut masuk, dan 2) memang ada nilai dalam memahami sistem secara end-to-end

• Sedikit meta, tapi saya tidak paham dengan flag yang dipasang pada tulisan ini. Ada 1 off-topic dan 3 spam, aneh sekali
  Tulisan paling atas di halaman depan juga tentang penggunaan LLM, dan karena itu tulisan tentang penulisan umum, fokus topiknya malah tampak lebih lemah daripada tulisan ini yang berfokus pada coding, tetapi sepertinya tidak kena flag

  • Mungkin dianggap promosi diri, jadi diberi flag spam

• Menyegarkan melihat sudut pandang seperti ini di Lobsters. Sentimen anti-AI yang menyapu rata makin melelahkan. Saya rasa semua orang bisa sepakat bahwa tidak ada yang suka hasil berkualitas rendah
  Tetapi orang-orang yang memboikot AI sepenuhnya dan mengambil sikap menggurui akan lebih sulit menerima masa depan dibanding mereka yang mengambil sikap lebih praktis
  Sejak awal saya selalu mengatakan AI mirip dengan penemuan alat listrik. Kalau Anda ingin mengganti ban dengan kunci roda manual, tidak masalah, tetapi para montir tidak memboikot saat impact drill muncul. Dalam konteks tulisan ini mungkin itu bukan analogi terbaik, tetapi menurut saya tetap relevan
  Saya belajar lebih banyak saat menggunakan AI daripada saat membaca dokumentasi, karena pada dokumentasi Anda tidak bisa bertanya ketika butuh konteks tambahan, penjelasan, atau contoh. Anda bisa saja bilang “buat sesuatu, jangan salah”, tetapi saya lebih suka pendekatan yang lambat untuk benar-benar belajar

  • Saya tidak melihat sentimen anti-AI yang menyapu rata di sini. Bisa beri tautan contohnya?
    Yang saya lihat adalah kritik terhadap perubahan dengan LLM pada jutaan baris kode sekaligus lalu mengirimkannya tanpa review manusia. Secara spesifik, misalnya thread tentang porting Bun dari Zig ke Rust
    Tulisan ini juga mengkritik hal itu