Mendapatkan hasil yang baik dengan Claude Code

 (dzombak.com)
45 poin oleh GN⁺ 2025-08-09 | 5 komentar | Bagikan ke WhatsApp
  • Dalam beberapa bulan terakhir, setelah bereksperimen dengan berbagai agen pemrograman LLM, Claude Code menjadi alat yang paling memuaskan
  • Berkat Claude Code, sekitar 12 program dan proyek dapat dibuat dalam waktu singkat, termasuk pekerjaan yang biasanya tidak akan dimulai karena keterbatasan waktu
  • Untuk penggunaan yang sukses, kuncinya adalah menulis spesifikasi yang jelas, menyediakan dokumentasi berisi struktur proyek serta cara menjalankan build dan lint, meminta AI melakukan review atas kodenya sendiri, dan menggunakan panduan agen global yang dipersonalisasi
  • Kode yang ditulis AI sering kali tidak akurat atau tidak efisien, поэтому semua kode dan test case harus selalu ditinjau langsung, lalu pengujian yang kurang ditambahkan sendiri atau diminta ke AI dan ditinjau ulang
  • Panduan agen global yang dibagikan di lampiran mencakup panduan pengembangan terperinci seperti rencana implementasi bertahap, test-driven development, filosofi yang berfokus pada kesederhanaan, kejelasan, dan pragmatisme, standar kualitas, serta proses pemecahan masalah

Pengalaman dan dampak penggunaan Claude Code

  • Selama beberapa bulan terakhir, berbagai agen pemrograman LLM telah diuji, dan pengalaman menggunakan Claude Code adalah yang terbaik
  • Meski bukan tanpa masalah, lebih dari 12 program dan proyek dapat diselesaikan dalam waktu singkat
  • Tanpa Claude Code, hampir mustahil menyelesaikan semua pekerjaan ini dalam periode yang sama
  • Banyak di antaranya adalah proyek yang bahkan tidak akan dicoba karena memakan terlalu banyak waktu

Strategi menggunakan Claude Code

  • Menulis spesifikasi yang jelas
    • Sebelum memulai proyek, kebutuhan dan konteks didokumentasikan dengan jelas lalu diberikan kepada agen
    • Ini memperjelas arah dan cakupan penulisan kode
  • Mendokumentasikan struktur proyek
    • Menyiapkan dokumen yang mencakup cara menjalankan build, lint, dan test
    • Dengan begitu agen dapat menavigasi codebase dan bekerja dengan lebih efektif
  • Meminta review kode dari agen
    • Meminta Claude Code meninjau langsung kode yang dihasilkannya agar dapat menemukan potensi perbaikan atau bug yang tak terduga
  • Menggunakan panduan global pribadi
    • Menjaga proses pengembangan yang konsisten melalui ~/.claude/CLAUDE.md, yang berisi aturan pribadi seperti pendekatan pemecahan masalah, penerapan TDD, menjaga kesederhanaan dan kejelasan, serta batas jumlah percobaan (3 kali)

Memverifikasi kode yang ditulis LLM

  • Kode yang dihasilkan AI sering memiliki masalah seperti kesalahan logika, penurunan performa, dan pengujian yang tidak lengkap
  • Penulis meninjau semua kode secara manual dan memverifikasi perilakunya
    • Menambahkan sendiri test case yang terlewat
    • Atau meminta AI menuliskannya lalu meninjau ulang kode dan test tersebut
  • Ditekankan bahwa dalam lingkungan profesional, selama nama Anda tercantum di PR, tanggung jawab akhir atas kualitas ada pada diri Anda sendiri

Isi utama panduan agen “global” pribadi

Panduan tersebut dikelola dalam file ~/.claude/CLAUDE.md

  • Filosofi dan prinsip inti

    • Progres bertahap: ubah dalam unit kecil, dan selalu pastikan kompilasi serta test lulus
    • Pelajari kode yang ada: analisis pola kode dan susun rencana sebelum implementasi
    • Pragmatisme diutamakan: pendekatan yang fleksibel sesuai situasi proyek
    • Kejelasan diutamakan: kode yang mudah dibaca dan jelas maksudnya, hindari trik yang tidak perlu

  • Definisi kesederhanaan

    • Fungsi dan kelas memiliki satu tanggung jawab
    • Hindari abstraksi terlalu dini
    • Kurangi kompleksitas dan arahkan pada kode yang tidak perlu penjelasan

  • Proses kerja

    • 1. Perencanaan dan penetapan tahap:
      • Pekerjaan yang kompleks dibagi menjadi 3~5 tahap dan dicatat di IMPLEMENTATION_PLAN.md
      • Nyatakan tujuan tiap tahap, kriteria keberhasilan, test case, dan status progres
    • 2. Alur implementasi:
      • pahami → tulis test (merah) → implementasi minimum (hijau) → refactor → commit
    • 3. Evaluasi ulang setelah batas 3 percobaan:
      • Jika gagal, catat riwayat percobaan, error, dan penyebabnya
      • Jelajahi alternatif (2~3 pendekatan)
      • Tinjau ulang desain mendasar atau pemecahan masalah
      • Coba pola atau fitur lain

  • Standar teknis

    • Utamakan composition, gunakan dependency injection
    • Gunakan interface, pastikan kemudahan pengujian
    • Alur data yang eksplisit
    • TDD dianjurkan, menonaktifkan test dilarang

  • Aturan kualitas kode

    • Semua commit harus berhasil dikompilasi, lulus test, menyertakan test untuk fitur baru, dan mengikuti gaya kode
    • Jalankan formatter dan linter sebelum commit, lakukan self-review terhadap perubahan, dan tulis pesan commit yang menjelaskan "mengapa"

  • Penanganan error

    • Gagal lebih cepat dengan pesan yang spesifik
    • Berikan konteks yang diperlukan untuk debugging
    • Tangani exception di level yang tepat, jangan menyembunyikan exception

  • Kriteria pengambilan keputusan

    • 1. Kemudahan pengujian
    • 2. Keterbacaan yang tetap mudah dipahami bahkan 6 bulan kemudian
    • 3. Konsistensi dengan pola proyek
    • 4. Kesederhanaan
    • 5. Kemudahan perubahan

  • Integrasi proyek

    • Analisis 3 atau lebih fitur serupa
    • Gunakan kembali pola dan library yang sudah ada
    • Gunakan utilitas test yang sama
    • Mengadopsi alat baru harus punya alasan yang kuat

  • Quality gate

    • Semua test lulus
    • Mematuhi aturan proyek
    • Tidak ada peringatan linter
    • Pesan commit jelas
    • Implementasi sesuai rencana
    • TODO mencantumkan nomor issue

  • Panduan pengujian

    • Test berfokus pada perilaku, bukan implementasi
    • Jika memungkinkan, satu asersi per test
    • Nama yang jelas untuk menjelaskan skenario
    • Gunakan kembali utilitas test yang sudah ada
    • Test harus deterministik

  • Larangan mutlak

    • Melewati hook dengan --no-verify
    • Menonaktifkan test
    • Commit kode yang tidak bisa dikompilasi
    • Menebak tanpa verifikasi

  • Wajib dilakukan

    • Commit bertahap
    • Perbarui dokumentasi secara berkelanjutan
    • Belajar dari implementasi yang ada
    • Evaluasi ulang pendekatan setelah gagal 3 kali

Proyek open source yang dibuat dengan Claude Code

Bacaan terkait

5 komentar

 
wedding 2025-08-11

Kalau hasilnya bagus, apakah itu berarti seseorang sudah merujuk dengan baik pada kode yang dibuat orang lain sebelumnya.
 
aeolian21 2025-08-11

Semua yang dilakukan penulis itu sudah dilakukan orang-orang sejak lama, jadi jangan pamer hal yang tidak perlu.
Akan jauh lebih bermakna kalau menulis alasan dan dasar kenapa, saat dibandingkan antar-LLM, kamu menganggap Claude yang paling baik.
Misalnya perbandingan kode yang benar-benar dihasilkan, frekuensi error kompilasi, stabilitas dalam memahami konteks, dan sebagainya.
Sebenarnya kemampuan memahami konteks yang paling unggul adalah Gemini (1 juta token).
 
zxcv123 2025-08-10

Yang dibuat cuma hal-hal yang nyaris tidak berguna, dan tulisannya cuma dipanjang-panjangin.
 
knunu 2025-08-11

Mungkin ini bisa berguna bagi sebagian orang hehe
 
GN⁺ 2025-08-09
Komentar Hacker News

  • Hari ini untuk pertama kalinya aku benar-benar merasakan pengalaman sukses dengan Claude dan coding agent; sebelumnya aku pernah memakai Cursor, tetapi sekarang juga mencoba Claude dan alat lain. Seperti yang disebutkan di artikel, kuncinya adalah menulis spesifikasi yang jelas. Selama 2 jam aku sendiri menulis dokumen 12 langkah untuk merapikan cara implementasi dan juga menyertakan informasi latar belakang. Claude lalu mengikuti prosedur itu dan menghasilkan kode langkah demi langkah. Menurutku ini mungkin menghemat sekitar 6–10 jam. Sekarang rencananya aku akan meninjau, menguji, lalu menyesuaikan secara bertahap dan menambahkan fitur. Fondasi keberhasilan ini adalah karena aku sendiri menuliskan dengan jelas semua langkah yang harus dilakukan Claude; dengan kata lain, aku yang merancang alur keseluruhan dan Claude hanya mengikuti instruksi. Dari proses ini aku jadi yakin bahwa developer tingkat menengah ke atas tidak akan tergantikan AI dalam waktu dekat. Tapi tetap saja, melihat Claude membaca spesifikasi dari awal sampai akhir lalu mengeluarkan kode yang rapi dan terdokumentasi itu benar-benar pengalaman yang menakjubkan. Fakta bahwa aku tidak perlu menulis kodenya sendiri itu luar biasa

    • Aku bisa mendapatkan hasil bagus dari Claude tanpa persiapan sedetail itu. Aku meminta Claude satu langkah demi satu langkah, hampir seperti saat aku menulis kode sendiri. Setiap kali ada perubahan, aku langsung menerapkannya, commit, lalu meninjau diff-nya. Kalau Claude menghasilkan sesuatu yang aneh, aku langsung minta diperbaiki. Aku juga memberi tahu referensi kode atau fungsi lama yang ingin kupakai. Dengan cara ini, aku bisa mendapat hasil yang sangat bagus dengan jauh lebih sedikit mengetik dan waktu

    • Aku merekomendasikan membaca Naur, “Programming as Theory Building”. Dari sana aku belajar bagaimana memahami masalah secara teoretis dan memodelkannya sendiri. Kalau tidak, LLM bisa membangun teorinya sendiri yang salah
      Membaca “Programming as Theory Building” - Naur

    • Seperti di artikel, spesifikasi yang jelas memang sangat penting. Aku sedang membuat bahasa pemrograman dengan Claude, dan benar-benar merasakan hal ini sendiri. Dalam pemrograman ada sangat banyak pilihan kecil yang harus dibuat terus-menerus. Jika tidak diberi panduan yang jelas, LLM akan menangani sebagian besar hal dengan menebak, dan sering kali memilih dengan salah. Kesalahan-kesalahan kecil ini bisa menumpuk secara majemuk dan berujung pada hasil yang salah

    • Akan sangat bagus jika ada yang bisa membagikan contoh dokumen spesifikasi seperti ini secara langsung. Sebagai orang yang belajar development secara otodidak sambil bereksperimen dengan Claude Code, itu sepertinya akan sangat membantu untuk memahami informasi dan kedalaman seperti apa yang benar-benar berguna

    • Sebenarnya cukup banyak developer menengah dan senior juga tidak bisa menulis spesifikasi yang baik. Tapi aku paham maksud yang ingin disampaikan

  • Membuat ~/.claude/CLAUDE.md dan memasukkan aturan di sana sepertinya pada praktiknya tidak terlalu efektif. Claude bukan manusia dan tidak bernalar hati-hati untuk setiap baris kode. Instruksi yang subjektif dan ambigu tidak akan benar-benar membuatnya mengubah kode. Ada juga masalah yang disebut 'context rot'
    (penjelasan context rot: fenomena ketika LLM kehilangan atau mendistorsi konteks selama percakapan atau pekerjaan yang panjang, tautan referensi: https://news.ycombinator.com/item?id=44564248)
    Secara realistis, mustahil memasukkan segala macam aturan ke dalam satu file lalu berharap AI akan mematuhinya begitu saja. Untuk melakukan itu, setiap aturan perlu dijadikan sub-agent dan dipisahkan ke pipeline biasa, bukan AI. Tapi kalau begitu, biayanya akan meningkat secara eksponensial

    • Soal biaya, setelah workflow sudah stabil, kita bisa memanfaatkan LLM yang lebih murah (meski biaya operasionalnya tetap mahal). Penghematan biaya bisa dicapai lewat fine-tuning, optimasi prompt, teknik distillation yang terspesialisasi, dan sebagainya. Di bidang ini sudah ada banyak riset

    • Aku penasaran apa saja yang bagus untuk dimasukkan ke dalam CLAUDE.md

  • Kalau melihat proyek contoh di bagian bawah halaman, sebagian besar adalah software yang dioptimalkan untuk satu tujuan yang sangat spesifik. Ke depan, proyek open source pun tampaknya akan berevolusi menjadi bentuk yang sangat terspesialisasi untuk memenuhi kebutuhan satu orang seperti ini. Aku merasa software seperti ini (utility) akan menjadi kode sekali pakai yang dihasilkan LLM dalam satu kali jalan

  • Pendekatanku terhadap Claude Code terus berubah. Aku masih belum berhasil membuat Claude Code langsung berkontribusi fitur yang benar-benar berarti ke web app besar di perusahaan. Spesifikasi memang agak membantu, tetapi pada akhirnya alurnya malah menyimpang ke arah aneh dan terjebak dalam loop pengulangan pilihan yang salah. Mungkin ini memang batasan Claude, atau mungkin spesifikasiku masih belum cukup presisi. Aku sudah banyak bereksperimen, tetapi untuk hal-hal yang “menantang atau butuh banyak pengetahuan domain”, kegagalannya terlalu sering, jadi aku tidak lagi mencobanya. Sebagai gantinya, atas saran teman, aku mulai memakai Claude untuk pekerjaan backlog yang hampir tidak membebani mental. Misalnya, aku menyuruh Claude membuat test Playwright di workspace baru untuk hal yang tidak terlalu kupedulikan, dan hasilnya sangat sukses. Aku menjelaskan user experience ke Claude seolah sedang menjelaskannya ke manusia, lalu memberi path dev server. Aku menyuruhnya memakai Playwright MCP untuk mencari tahu feature mana yang harus dipakai dan bagaimana menggunakannya, mendokumentasikan proses eksekusinya, menulis test, dan men-debug error. Itu juga termasuk menyusuri kode UI di proyek untuk menambahkan selector data-testid. Aku merangkum seluruh proses dalam master task.md dan juga menyuruhnya membuat task markdown terpisah untuk tiap feature. Cara ini sangat efektif. Aku bahkan memakainya untuk feature kompleks dengan interaksi dua browser user yang tidak intuitif; memang tidak 100% akurat, dan makin kompleks makin perlu koreksi konteks serta perbaikan kode, tetapi secara keseluruhan ini langsung menyelesaikan pekerjaan merepotkan yang biasanya bisa memakan waktu berhari-hari

  • Menjaga CLAUDE.md tetap minimalis, sebisa mungkin di bawah 100 baris, adalah pendekatan yang paling baik menurut pengalamanku,

    • ringkasan konteks dan tujuan inti proyek
    • penjelasan struktur proyek seminimal mungkin agar tipe, interface, dan helper bisa dipahami
    • hanya perintah-perintah utama agar tidak perlu berulang kali mengurai package.json Dalam alur implementasi/test, dari pengalamanku Claude kadang mencoba menulis semua test sekaligus di awal, atau hanya mengimplementasikan semuanya ketika import gagal (jadi bukan TDD yang benar). Karena itu aku membuat hook bernama TDD-Guard untuk memaksanya hanya meloloskan satu test pada satu waktu, memastikan test gagal karena alasan yang benar, dan mengimplementasikan kode minimum untuk meloloskan test tersebut. Untuk kualitas kode, aku mengotomatiskan husky, lint-staged, commitlint, dan semacamnya, dan mendapatkan hasil yang sangat baik. Dengan begitu, context bisa disisihkan untuk informasi yang lebih penting. Aku setuju bahwa jika Claude Code buntu, yang terbaik pada akhirnya adalah developer turun tangan langsung. Hanya saja, rasanya kurang memuaskan kalau nasihatnya berhenti di level yang terlalu umum,
    • Jika tertarik pada pendekatan otomasi:

  • Sudah lebih dari sebulan aku bekerja dengan Claude Code setiap hari. Aku juga sudah mencoba Cursor, Q, dan lainnya, tetapi Claude Code jauh lebih unggul. Tips yang disebut di artikel banyak yang sejalan dengan hal-hal yang kusadari sendiri,
    untuk menambahkan beberapa pemikiran:

    • Aku memulainya dari sesi ide dengan Claude di web console. Aku menjelaskan tujuan proyek, lalu menyusun domain modeling dan milestone secara garis besar. Kalau proyeknya kecil, dalam beberapa jam saja semuanya bisa dirapikan lewat diskusi bolak-balik. Dari sini lahirlah versi pertama CLAUDE.md

    • Saat memulai proyek yang sebenarnya, Claude membaca CLAUDE.md global milikku dan CLAUDE.md proyek, lalu mulai bekerja. Begitulah cara setiap sesi dimulai

    • Di tengah pengerjaan pun, aku menyuruh Claude Code terus memperbarui CLAUDE.md proyek. Ia menandai progres sambil mengikuti rencana, lalu di akhir sesi menuliskan ringkasan proyek, cara kerjanya, cara menavigasi kode, dan sebagainya. Ini seperti memori jangka panjang, dan hasilnya bagus

    • Sebagus apa pun guideline, Claude tetap punya kecenderungan untuk melangkah terlalu jauh lebih dulu. Karena itu, untuk pekerjaan yang melibatkan diriku langsung, aku selalu memecahnya ke inkremen kecil dan membuatnya fokus tahap demi tahap. Kalau hanya pekerjaan sekali pakai atau prototipe, aku biarkan saja ia mengimplementasikan sesukanya

      • Aku penasaran apakah langganan $20 itu punya value for money yang bagus dibanding Cursor, dan apakah harus dipakai setiap hari supaya terasa sepadan

  • CLAUDE.md di level proyek sebaiknya tidak terlalu panjang dan tetap ringkas, lalu detail yang lebih spesifik dipindahkan ke subfolder. Bagian paling atas dipakai sebagai semacam peta. Setiap kali merencanakan sebuah feature, Claude melihat folder yang sesuai dan merujuk konteks yang dibutuhkan sambil menyusun rencana implementasi bertahap. Di akhir tiap tahap, aku menyuruh Claude memperbarui rencana implementasi dengan konteks baru. Dengan cara ini, konteks mengalir secara alami ke tahap berikutnya, dan window juga bisa di-reset agar masuk ke tahap berikutnya dengan pikiran yang segar

  • Aku sedang membuat game ASCII ala factorio dengan Claude Code. Di awal aku membiarkannya menulis kode hampir tanpa pengawasan, dan ia langsung mengimplementasikan sebagian besar feature utama (save/load, opsi, debug, pembuatan map, konstruksi, belt, crafting, QoL, dll.). Namun saat mencoba memperbaiki detail, misalnya mengubah pergerakan, hal lain terus rusak seperti belt yang ikut bermasalah. Karena itu aku menyuruhnya menambahkan otomasi Playwright, tetapi kualitas test-nya buruk dan penuh pemanggilan sleep. Setelah kuperiksa detail kodenya, ternyata strukturnya memakai frontend React dan useEffect, bukan struktur game engine yang layak. Ia juga kurang baik dalam mematuhi aturan hook dan kurang memahami timing. Jadi kali ini aku mulai membuat ulang dari nol dengan memperkenalkan game engine berbasis tick, dan juga menambahkan code review. Lajunya memang jadi lebih lambat, tetapi pengembangannya jauh lebih kokoh. Kalau demo yang bagus sudah selesai, aku berencana merilisnya di Show HN

    • Sampai kerangka dasar awal terbentuk, kontribusi langsung dari manusia benar-benar sangat berharga. Setelah satu putaran refactoring lewat, barulah setelah itu kita bisa sedikit lebih tenang

  • Kalau ada yang sepertiku memakai langganan Claude untuk kerja dan pribadi sekaligus, alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal claude" bisa dipakai untuk mempermudah perpindahan akun
    Blog tentang cara efisien memakai beberapa akun Claude

  • Semua orang bilang “kuncinya adalah menulis spesifikasi yang jelas di awal untuk memberi context”, tetapi dari pengalamanku ini tidak selalu berhasil. Aku pernah duduk bersama seorang ahli sungguhan dan menjalankan sesi CC dengan Opus 4 & Sonnet 4. Orang itu menyiapkan spec yang benar-benar jelas, tetapi hasilnya tidak lebih baik daripada caraku sendiri, yaitu meminta secara langsung sesuai konteks masing-masing tanpa CLAUDE.md, begitu sebuah fitur terpikirkan. Workflow berbasis spesifikasi sering terus melupakan hal-hal penting, atau mengarang hal yang tidak ada di dokumen konteks (bahkan yang dilarang sekalipun). Sebaliknya, bagiku instruksi langsung seperti “tolong tambahkan halaman CRUD untuk invoice, tapi mulai dulu dengan menganalisis codebase” justru lebih baik. Ini memang cuma pengalaman empirisku, tetapi setelah menjalankan lebih dari 100 proyek dengan Claude, selain hook terpisah untuk mencegah Claude melampaui batas, aku tidak bisa yakin bahwa satu pendekatan tertentu memang lebih unggul. Banyak orang bilang “berbasis spec lebih baik”, tetapi ketika diminta menunjukkannya secara nyata, justru sering terlihat mereka menghabiskan terlalu banyak waktu untuk terus memperbaiki bagian yang jelas-jelas salah. Bahkan kalau ditulis di CLAUDE.md “jangan pernah lakukan hal seperti ini”, Claude tetap cenderung terus melakukannya