Cara Efektif Menulis Kode Berkualitas Tinggi dengan AI

• Dalam lingkungan pengembangan yang berkolaborasi dengan AI, manusia harus mendefinisikan arah proyek dan pengambilan keputusan secara jelas agar kualitas tetap terjaga
• Melalui dokumentasi yang akurat, baik AI maupun pengembang lain harus dapat memahami kebutuhan dan batasan secara jelas
• Bangun sistem debug dan proses code review untuk memperkuat keandalan serta proses verifikasi kode yang dihasilkan AI
• Pastikan stabilitas dan konsistensi kode melalui penandaan fungsi berisiko keamanan, pemisahan pengujian, dan aturan linting yang ketat
• Pertahankan kendali atas pembuatan kode AI dan maksimalkan efisiensi melalui pembagian unit kerja dan meminimalkan kompleksitas

---

1. Menetapkan visi yang jelas

• Manusia memahami dunia, tim, dan perilaku pengguna, tetapi AI tidak memiliki pengalaman sehingga memerlukan instruksi yang eksplisit
  • Dalam proyek, keputusan yang tidak terdokumentasi akan diambil oleh AI sebagai gantinya
• Arsitektur, antarmuka, struktur data, dan algoritme perlu dibahas sebelumnya dan metode pengujiannya harus didefinisikan
• Keputusan jangka panjang dan sulit diubah harus selalu dikelola langsung oleh manusia

2. Menjaga dokumentasi yang akurat

• Agar AI dapat menghasilkan kode yang sesuai tujuan, penyampaian kebutuhan secara rinci sangat penting
• Karena pengembang lain juga harus dapat memberikan informasi yang sama kepada AI, dokumen dengan format standar perlu disertakan dalam repositori kode
  • Catat secara rinci kebutuhan, batasan, arsitektur, standar coding, design pattern, dan sebagainya
  • Gunakan diagram UML, flowchart, dan pseudocode untuk merepresentasikan struktur yang kompleks secara visual

3. Membangun sistem debug yang mendukung AI

• Siapkan sistem debug yang efisien agar AI dapat memverifikasi fungsi kode dengan cepat
  • Contoh: kumpulkan log dari semua node dalam sistem terdistribusi dan berikan informasi ringkas seperti “data telah dikirim ke semua node”
• Dengan ini, biaya eksekusi perintah dapat ditekan dan kecepatan identifikasi masalah dapat ditingkatkan

4. Menandai tingkat code review

• Intensitas review harus dibedakan berdasarkan tingkat pentingnya kode
  • Contoh: tambahkan komentar //A setelah fungsi yang ditulis AI untuk menunjukkan apakah sudah ditinjau manusia
• Sistem ini memudahkan identifikasi dan pengelolaan kode yang belum ditinjau

5. Menulis spesifikasi tingkat tinggi dan menguji langsung

• Demi lolos pengujian, AI dapat mengakali dengan mock object atau nilai hardcoded
• Untuk mencegah hal ini, property-based testing harus ditulis langsung oleh manusia
  • Contoh: restart server dan verifikasi konsistensi nilai dalam database
• Kode pengujian harus dipisahkan ke area terpisah agar AI tidak dapat mengubahnya

6. Memisahkan pengujian antarmuka

• Biarkan AI menulis pengujian antarmuka tanpa mengetahui konteks kode lain
  • Dengan begitu, objektivitas pengujian tetap terjaga karena tidak terpengaruh oleh AI yang membuat implementasi
• Pengujian ini juga harus dilindungi agar AI tidak bisa mengubahnya secara sembarangan

7. Aturan linting dan formatting yang ketat

• Gaya kode yang konsisten dan aturan linting sangat penting untuk menjaga kualitas dan menemukan kesalahan lebih awal
• Baik AI maupun manusia dapat lebih mudah memeriksa kualitas kode

8. Memanfaatkan prompt code agent sesuai konteks

• Gunakan file prompt per proyek seperti CLAUDE.md untuk mengurangi biaya pemahaman awal AI
• Sertakan standar coding, design pattern, kebutuhan, dan lainnya untuk meningkatkan kualitas serta efisiensi pembuatan kode oleh AI

9. Mengidentifikasi dan menandai fungsi berisiko keamanan

• Fungsi yang sensitif terhadap keamanan seperti autentikasi, otorisasi, dan pemrosesan data harus ditandai secara eksplisit
  • Contoh: gunakan komentar //HIGH-RISK-UNREVIEWED, //HIGH-RISK-REVIEWED
• Jika AI memodifikasi fungsi tersebut, status review harus diubah secara otomatis
• Pengembang harus selalu memastikan status ini tetap akurat

10. Meminimalkan kompleksitas kode

• Satu baris kode yang tidak perlu pun menghabiskan context window AI dan menambah biaya
• Pertahankan struktur sesederhana mungkin agar AI dan manusia sama-sama lebih mudah memahaminya

11. Mengeksplorasi masalah melalui eksperimen dan prototipe

• Manfaatkan karakteristik biaya rendah dari pembuatan kode oleh AI untuk menguji berbagai solusi
• Buat beberapa prototipe dengan spesifikasi minimal untuk menjelajahi pendekatan yang paling optimal

12. Hindari pembuatan skala besar yang sembarangan

• Pekerjaan yang kompleks harus dipecah menjadi unit-unit kecil agar AI dapat menanganinya secara bertahap
  • Contoh: alih-alih seluruh proyek, buat fungsi atau kelas secara terpisah
• Setiap komponen harus diverifikasi apakah sesuai dengan spesifikasi, dan
  jika kompleksitas kode tidak lagi terkendali, proyek harus dikembalikan ke kondisi awal

[GN⁺]

Komentar Hacker News

• Saya masih merasa proses menulis kode sendiri sambil merapikan alur pikir itu penting
  Bagi saya, kode adalah semacam mekanisme pemaksa yang membuat saya mengasah detail
  Rasanya menulis spesifikasi saja tidak memberi kedalaman seperti itu

  • Saya juga berpikir begitu. Sejak kecil, inti proses belajar bagi saya adalah belajar dengan benar-benar membuat sesuatu sendiri
    Kalau proses itu diserahkan ke LLM, rasanya seperti pesawat kehilangan daya angkat lalu mental ikut macet
    Stres dalam memecahkan masalah memang berkurang, tetapi motivasi untuk berpikir dan mencipta juga hilang
    Di sekitar saya banyak yang suka AI menulis kode untuk mereka, tetapi saya bukan bagian dari kelompok itu
  • Saya juga merasakan hal serupa.
    Sulit bagi saya mempercayai orang yang bilang bisa bikin SaaS sambil minum kopi dan menjalankan 5 agent
    Kalau ingin kode berkualitas baik, saya rasa perlu benar-benar menyelam ke dalam kode sendiri
    Meski begitu, untuk pekerjaan berulang yang sederhana seperti menulis tes atau menyelesaikan masalah konfigurasi, AI cukup berguna
    Misalnya, saya menghidupkan lagi proyek yang saya tinggalkan 5 tahun lalu dengan Claude, dan dalam beberapa jam rasanya sudah maju setengah jalan
  • Saya masih tetap meninjau dan menguji kode sendiri
    Hanya saja sekarang terasa seperti kembali ke pendekatan yang berpusat pada spesifikasi
    Berkat agent, siklus mencoba dan membuang bisa berulang dengan cepat sehingga alur pengembangan iteratif tetap terjaga
    Saya menganggap spesifikasi dan tes sebagai hasil kerja yang sesungguhnya, lalu terus merevisinya sambil merapikan pemikiran
  • Saya sangat setuju dengan kalimat “kode membuat kita mengasah detail”
    Spesifikasi saja tidak bisa memuat seluruh kompleksitas dunia nyata
    Kode yang ditulis LLM sering kali bertele-tele dan bergerak ke arah yang aneh, jadi tetap perlu dikelola langsung
    Sebaliknya, LLM cukup bagus sebagai mitra untuk mendiskusikan dan mematangkan ide
  • Dulu ada banyak upaya melihat software engineering seperti lini perakitan, padahal kenyataannya itu adalah proses merancang sambil membangun
    Sekarang karena menulis kode jadi lebih murah dan cepat, mungkin justru kita perlu memperkuat tahap desain formal

• Saya merasa hal yang paling besar pengaruhnya terhadap kualitas kode adalah menyiapkan alat analisis statis secara sistematis
  Untuk TypeScript, saya menggabungkan tsc, eslint, sonarjs, knip, jscpd, dependency-cruiser, semgrep, lalu menyatukannya lewat perintah pnpm check
  Saya juga membuatnya berjalan otomatis lewat pre-commit hook agar masalah yang luput dari LLM bisa dicegah
  Berkat ini, saat LLM mentok pun saya masih bisa memperbaiki secara manual dengan mudah

  • Saya juga merasa jauh lebih mudah menerapkan aturan lint yang ketat
    Kalau gaya kode konsisten, proses review jadi jauh lebih mudah, dan kebingungan berkurang meski kode AI dan kode manusia bercampur
  • Saya juga memakai setelan yang mirip. pre-commit hook itu wajib
    Hanya saja, meski lint dan tes semuanya lolos, tetap bisa muncul kode yang berjalan tidak sesuai niat
    Misalnya API yang mengembalikan array kosong alih-alih 404; secara sintaks benar, tetapi secara makna salah
    Penilaian akurasi perilaku seperti ini masih jadi bagian yang paling sulit
  • Kadang LLM juga melaporkan hasil palsu
  • Konfigurasinya bagus. Tapi saya penasaran kenapa batas panjang baris maksimum masih perlu. Karena operator ternary?
  • Menurut saya justru masalah yang lebih besar adalah kurangnya kejelasan kode dan defensive coding yang berlebihan
    Kadang saya merasa maintainability perlu diprioritaskan di atas aturan lint

• Saya melakukan refactor secara rutin setiap kali menambahkan fitur
  Setiap beberapa fitur, saya meninjau seluruh codebase dan merapikannya
  Saya sudah menulis kode selama 40 tahun, dan justru sekarang saya paling puas dengan kode saya

  • Dulu budaya “kalau sudah jalan ya langsung deploy saja” sangat kuat
    Tapi berkat LLM, biaya refactor sekarang nyaris mendekati nol
    Tidak ada alasan lagi membiarkan kode buruk tetap seperti itu
    Menurut saya, nilai sebenarnya adalah memakai alat yang meningkatkan efisiensi untuk benar-benar meningkatkan kualitas
  • Saya juga mendapat pelajaran serupa
    Saya membuat alat internal yang menandai baris kode di setiap commit dengan baik (hijau)/perlu refactor (kuning)/perlu ditulis ulang (merah)
    Ini lebih rapi dan sistematis daripada komentar “TODO refactor”, dan saya berencana segera merilisnya sebagai open source

• Saat ini saya merasa pengembangan berbasis spesifikasi adalah cara paling stabil untuk bekerja bersama AI
  Saya menghabiskan lebih banyak waktu untuk mematangkan spesifikasi secara rinci dan saling bertukar ide dengan tim maupun AI
  Kalau spesifikasinya tidak lengkap, AI akan membuat kode yang melenceng
  Ketika pemahaman domain makin dalam, rasanya lebih baik menyuruhnya mengimplementasikan ulang dari awal

  • Mendengar cerita seperti ini mengingatkan saya pada mimpi era 90-an seperti UML, 4GL, Rational
    Waktu itu ada visi bahwa “cukup definisikan requirement, lalu sistem akan membangun semuanya sendiri”
    Pada akhirnya gagal dan agile menjadi arus utama, tetapi sekarang rasanya teknologi membuat mimpi itu mungkin lagi

• Nilai sejati AI ada pada kecepatan dan kemampuannya menangani ambiguitas
  Tetapi kalau semua prosedur harus tetap dilalui, akhirnya terasa lambat seperti waterfall
  Saya malah merasa lebih baik menulis kode sendiri lalu memakai AI sebagai reviewer putaran pertama
  Tetap memvalidasi cepat dalam unit kecil adalah pendekatan agile yang benar

  • Ada banyak ide yang berguna bahkan untuk developer berpengalaman
    Terutama saran untuk menandai fungsi yang terkait keamanan; itu membantu menjaga konteks saat kode berubah kemudian
    “Pecah jadi bagian kecil” memang dasar, tetapi sering terlewat oleh pemula
  • Menanggapi kalimat “kalau semua ini dilakukan kita kembali ke waterfall”, ada yang bercanda, “berikutnya mungkin operasi otak berbasis vibe”

• Lucu melihat orang sekarang berkat AI seperti baru menemukan lagi best practice dasar
  Padahal hal seperti ini memang dari dulu seharusnya dilakukan

  • Tetapi secara realistis, tekanan untuk cepat rilis memang membuat semua itu sulit selalu dijaga
    Sekarang ketika waktu coding berkurang, ada ruang lebih untuk mengerjakan hal-hal ini
    Selain itu, AI benar-benar memanfaatkan dokumentasi, jadi menulis dokumentasi yang baik sekarang punya nilai langsung
    Dulu dokumentasi sering diabaikan, tetapi LLM membacanya semua
  • Pengaman seperti ini sebenarnya hanya benar-benar wajib untuk programmer yang buruk (atau burung beo)

• Dulu saya menulis spesifikasi terperinci sebelum coding, tetapi kemudian sadar bahwa langsung masuk ke kode sering lebih cepat
  Tapi sekarang apakah kita kembali lagi ke pendekatan berbasis spesifikasi?
  Kalau kita menulis spesifikasi saat masalahnya belum sepenuhnya dipahami, akhirnya tetap belajar sambil coding
  Sepertinya sekarang kita ada di tengah-tengah dua pendekatan itu

  • Kalau spesifikasi dilewati, sering kali kita malah membuat program yang benar-benar salah arah
    Hanya saja sekarang, berkat AI, biaya dari kode yang salah nyaris nol, jadi nilai spesifikasi terasa menurun
  • Karena AI bisa membuat kode dengan murah, justru kini mungkin untuk mencoba tanpa spesifikasi dulu, belajar, lalu mendesain ulang
    Ini mirip dengan cara pemrograman yang pernah dibicarakan Joe Armstrong
    Sekarang akhirnya itu jadi realistis
  • Kalimat “kita harus merencanakan dan menyusun spesifikasi sebelum menulis kode” itu selalu benar

• Saat memegang posisi lead, saya menulis ticket dengan sangat detail
  Itu untuk junior, tetapi juga agar saya sendiri tidak melupakan detail-detailnya
  Namun pihak manajemen menentangnya sebagai “buang-buang waktu”, dan akhirnya saya kehilangan kebiasaan itu
  Sekarang justru saya diminta menulis spesifikasi yang bahkan lebih rinci dengan lebih cepat

• Saat memakai agent AI, saya penasaran soal rasio Markdown dan kode, serta keterbacaan hasil akhirnya
  Saya juga bertanya-tanya apakah waktu review-nya benar-benar tidak lebih lama daripada menulis kode sendiri

• Ironis melihat developer sekarang dengan antusias membela AI yang justru bisa menggantikan mereka sendiri
  Tautan tweet terkait menyindir fenomena ini

  • Ada juga cerita Underground Resistance tentang “mengotori data AI untuk mengganggunya”
  • Melihat mereka tidak bisa memperbaiki masalah performa Claude, rasanya seperti sedang memperkuat pemasaran menjelang IPO
    Mungkin itu sebabnya muncul pesan “kalau tidak pakai Claude, kamu akan tertinggal”
  • Banyak developer berkata “produktivitas saya naik berkat AI”,
    tetapi pada akhirnya kemungkinan besar ini akan berarti penurunan permintaan dan kompensasi untuk developer
    Terutama developer yang pekerjaannya hanya sebatas merangkai package NPM akan lebih berisiko