Judul asli: Aturan 4 CLAUDE.md Karpathy mengurangi kesalahan Claude dari 41% menjadi 11%. Setelah 30 basis kode, saya tambahkan 8 lagi
Penulis asli: @Mnilax
Disusun ulang: Peggy, BlockBeats

Catatan editor: Pada Januari 2026, keluhan Andrej Karpathy tentang cara Claude menulis kode memunculkan sebuah file yang tampaknya kecil, tetapi sangat penting dalam alur kerja pemrograman AI: CLAUDE.md. Forrest Chang kemudian merangkum masalah tersebut menjadi 4 aturan perilaku, berusaha membatasi kesalahan umum Claude saat pengkodean: asumsi diam, overengineering, kerusakan tidak terkait, dan kurangnya standar keberhasilan yang jelas.

Namun beberapa bulan kemudian, skenario penggunaan Claude Code sudah tidak lagi sekadar “membiarkan model menulis sepotong kode”. Dengan munculnya agen multi-langkah, trigger rantai hook, pemuatan skill, dan kolaborasi multi-repositori menjadi norma, pola kegagalan baru mulai muncul: model kehilangan kendali dalam tugas panjang, lulus pengujian tanpa memverifikasi logika nyata, melewati kesalahan secara diam-diam setelah migrasi selesai, serta gaya kode yang salah digabungkan.

Penulis artikel ini menguji 30 basis kode selama 6 minggu, dan menambahkan 8 aturan baru di atas 4 aturan asli Karpathy, berusaha menutupi masalah baru dalam transisi dari pengisian otomatis tunggal ke kolaborasi berbasis agen.

Berikut adalah teks aslinya:

Pada akhir Januari 2026, Andrej Karpathy mengirimkan rangkaian tweet yang mengeluhkan cara Claude menulis kode. Ia menunjukkan tiga jenis masalah utama: asumsi salah tanpa penjelasan, overkompleksitas, dan kerusakan tidak terkait pada kode yang seharusnya tidak diubah.

Forrest Chang melihat rangkaian tweet ini, merangkum keluhan tersebut menjadi 4 aturan perilaku, menuliskannya ke dalam file CLAUDE.md terpisah, dan mengunggahnya ke GitHub. Proyek ini mendapatkan 5.828 bintang di hari pertama, dikoleksi 60.000 kali dalam dua minggu, dan kini memiliki 120.000 bintang, menjadi repositori kode satu file dengan pertumbuhan tercepat di 2026.

Selanjutnya, saya menguji dengan 30 basis kode selama 6 minggu.

Keempat aturan ini memang efektif. Kesalahan yang sebelumnya muncul sekitar 40% dari waktu, dalam tugas yang cocok dengan aturan ini, turun menjadi kurang dari 3%. Tapi masalahnya, template ini awalnya dirancang untuk mengatasi kesalahan saat Claude menulis kode pada Januari.

Pada Mei 2026, ekosistem Claude Code menghadapi masalah yang berbeda: konflik antar agen, trigger rantai hook, konflik pemuatan skill, dan gangguan alur kerja multi-sesi.

Oleh karena itu, saya menambahkan 8 aturan lagi. Berikut adalah versi lengkap dari CLAUDE.md dengan 12 aturan: mengapa setiap aturan penting untuk dimasukkan, dan di mana template asli Karpathy secara diam-diam gagal dalam 4 area tersebut.

Jika Anda ingin melewati penjelasan dan langsung menyalin, file lengkap ada di bagian akhir.

Mengapa ini penting

CLAUDE.md dari Claude Code adalah file yang paling diremehkan dalam seluruh tumpukan teknologi pemrograman AI. Sebagian besar pengembang biasanya melakukan tiga kesalahan berikut:

Pertama, menganggapnya sebagai tempat sampah preferensi, memasukkan semua kebiasaan mereka, sehingga ukurannya membengkak hingga lebih dari 4000 token, dan tingkat kepatuhan terhadap aturan turun menjadi 30%.

Kedua, sama sekali tidak menggunakannya, melainkan selalu prompt ulang dari awal. Ini menyebabkan pemborosan token hingga lima kali lipat, dan kurang konsistensi antar sesi.

Ketiga, menyalin template sekali lalu tidak peduli lagi. Mungkin efektif selama dua minggu, tetapi seiring perubahan basis kode, akan secara diam-diam menjadi usang.

Dokumentasi resmi Anthropic menyatakan dengan jelas: CLAUDE.md pada dasarnya hanyalah saran. Claude kira-kira mengikuti aturan ini 80% waktu. Jika lebih dari 200 baris, tingkat kepatuhan akan menurun secara signifikan karena aturan penting tertutup oleh noise.

Template Karpathy memecahkan masalah ini: satu file, 65 baris, 4 aturan. Ini adalah standar minimum.

Namun, batas atasnya bisa lebih tinggi. Setelah menambahkan 8 aturan berikut, cakupannya tidak hanya menyelesaikan masalah penulisan kode yang dikeluhkan Karpathy pada Januari 2026, tetapi juga masalah pengaturan agen yang muncul pada Mei 2026—yang belum ada saat template awal dibuat.

4 Aturan asli

Jika Anda belum melihat repositori Forrest Chang, mulai dari versi dasar ini:

Aturan 1: Pikirkan sebelum menulis.

Jangan diam-diam membuat asumsi. Jelaskan asumsi Anda, ungkapkan pertimbangan. Ajukan pertanyaan sebelum menebak. Jika ada solusi yang lebih sederhana, usulkan keberatan secara aktif.

Aturan 2: Utamakan kesederhanaan.
Gunakan kode minimal yang bisa menyelesaikan masalah. Jangan menambahkan fitur yang tidak perlu. Jangan buat abstraksi untuk kode sekali pakai. Jika seorang insinyur senior menganggapnya terlalu rumit, sederhanakan.

Aturan 3: Modifikasi secara bedah.
Hanya ubah bagian yang wajib diubah. Jangan sembarangan “mengoptimalkan” kode, komentar, atau format di sekitarnya. Jangan refaktor yang tidak rusak. Pertahankan gaya yang sudah ada.

Aturan 4: Fokus pada tujuan.
Tentukan standar keberhasilan terlebih dahulu, lalu lakukan iterasi sampai verifikasi selesai. Jangan beri Claude instruksi langkah demi langkah, melainkan beritahu hasil keberhasilan seperti apa yang diharapkan, biarkan dia iterasi sendiri.

Keempat aturan ini mampu mengatasi sekitar 40% dari pola kegagalan yang saya lihat dalam sesi Claude Code tanpa pengawasan. Sisanya sekitar 60% tersembunyi di area-area berikut.

8 Aturan tambahan yang saya buat dan alasannya

Setiap aturan berasal dari situasi nyata: 4 aturan awal Karpathy sudah tidak cukup lagi. Berikut saya jelaskan situasinya, lalu berikan aturan yang sesuai.

Aturan 5: Jangan biarkan model melakukan pekerjaan non-lingkungan

Claude bisa digunakan untuk: klasifikasi, penyusunan draf, ringkasan, ekstraksi informasi dari teks tidak terstruktur.
Jangan gunakan untuk: routing, retry, penanganan kode status, konversi deterministik. Jika sebuah kode status sudah menjawab pertanyaan, biarkan kode biasa yang menjawabnya.

Aturan ini tidak tercakup oleh aturan Karpathy. Akibatnya, model mulai memutuskan hal-hal yang seharusnya ditangani kode deterministik: apakah harus mencoba ulang API, bagaimana merutekan pesan, kapan melakukan upgrade penanganan. Hasilnya, setiap keputusan mingguan berbeda-beda. Anda mendapatkan logika if-else yang tidak stabil, dengan biaya sekitar $0.003 per token.

Contoh situasi: ada kode yang memanggil Claude untuk “menilai apakah harus retry saat menerima 503”. Awalnya berjalan baik selama dua minggu, lalu menjadi tidak stabil karena model mulai memasukkan isi permintaan sebagai bagian dari konteks penilaian. Strategi retry menjadi acak karena prompt sendiri bersifat acak.

Aturan 6: Tetapkan batas token keras tanpa pengecualian

Batas anggaran tugas tunggal: 4.000 token.
Batas anggaran sesi: 30.000 token.
Jika mendekati batas, ringkas status saat ini, lalu mulai ulang. Jangan dipaksa terus. Ungkapkan secara jelas jika anggaran terlampaui, daripada diam-diam melebihi.

Tanpa batas anggaran, CLAUDE.md sama seperti cek kosong. Setiap iterasi bisa melampaui 50.000 token, dan model tidak akan berhenti sendiri.

Contoh situasi: satu sesi debugging berlangsung 90 menit. Model terus mengulang-ulang sekitar 8KB pesan error yang sama, dan secara perlahan lupa langkah-langkah yang sudah dicoba. Pada akhirnya, dia mengusulkan 40 solusi yang sudah saya tolak sebelumnya. Jika ada batas token, proses ini harus dihentikan pada menit ke-12.

Aturan 7: Ungkap konflik, jangan kompromi rata-rata

Jika dua mode dalam basis kode bertentangan, jangan gabungkan keduanya. Pilih salah satu, utamakan yang terbaru atau yang sudah lebih banyak diuji, berikan alasan, dan tandai mode lain untuk dibersihkan nanti.
“Rata-rata kode” yang mencoba memenuhi dua aturan sekaligus adalah kode terburuk.

Ketika dua bagian kode bertentangan, Claude akan mencoba menyenangkan keduanya, hasilnya menjadi kode yang tidak koheren.

Contoh situasi: ada basis kode dengan dua mode penanganan error: satu pakai async/await dengan try/catch eksplisit, lain pakai error boundary global. Claude menulis kode baru yang menggabungkan keduanya. Akibatnya, error ditangani dua kali. Saya butuh 30 menit untuk memahami mengapa error hilang dua kali.

Aturan 8: Baca dulu, baru tulis

Sebelum menambahkan kode baru ke sebuah file, baca dulu isi ekspor, pemanggil langsung, dan fungsi alat yang terkait.
Jika tidak memahami struktur kode yang ada, ajukan pertanyaan, jangan langsung menambah.
“Menurut saya ini tidak terkait” adalah kalimat paling berbahaya dalam basis kode ini.

Aturan ini mengingatkan Claude: jangan ubah kode di sekitarnya tanpa memahami. Tanpa langkah ini, Claude bisa menulis kode yang bertentangan dengan kode yang sudah ada 30 baris di atasnya.

Contoh situasi: Claude menambahkan fungsi yang sama persis di samping fungsi yang sudah ada, tanpa membaca fungsi sebelumnya. Kedua fungsi melakukan hal yang sama, tetapi karena urutan import, fungsi baru menimpa yang lama, yang sudah menjadi standar selama 6 bulan.

Aturan 9: Pengujian bukan opsional, tetapi pengujian sendiri bukan tujuan

Setiap pengujian harus menjelaskan “mengapa perilaku ini penting”, bukan hanya “apa yang dilakukan”.
Contoh: expect(getUserName()).toBe(‘John’) tidak berguna jika fungsi itu menerima ID yang sudah di-hardcode.
Jika tidak bisa membuat pengujian yang gagal saat logika berubah, fungsi tersebut salah.

Aturan “Fokus pada tujuan” dari Karpathy mengisyaratkan pengujian sebagai standar keberhasilan. Tapi dalam praktik, Claude sering menganggap “lulus pengujian” sebagai satu-satunya tujuan, sehingga menulis kode yang lolos pengujian dangkal tapi merusak bagian lain.

Contoh situasi: Claude menulis 12 pengujian untuk fungsi otentikasi, semuanya lulus. Tapi logika otentikasi di produksi rusak. Pengujian hanya memeriksa fungsi “mengembalikan sesuatu”, bukan apakah mengembalikan yang benar. Fungsi bisa lolos karena mengembalikan konstanta.

Aturan 10: Operasi jangka panjang butuh checkpoint

Dalam tugas multi-langkah, setelah menyelesaikan setiap langkah, ringkas apa yang sudah dilakukan, diverifikasi, dan apa yang tersisa.
Jangan lanjutkan dari status yang tidak bisa Anda jelaskan kembali. Jika merasa kehilangan jejak, berhenti dan ulangi penjelasan status saat ini.

Aturan ini penting karena alur kerja Claude yang nyata sering multi-langkah: refaktor 20 file, bangun fitur dalam satu sesi, debug melalui beberapa commit. Tanpa checkpoint, satu langkah salah bisa menghapus semua kemajuan sebelumnya.

Contoh situasi: sebuah tugas refaktor 6 langkah gagal di langkah ke-4. Saat saya menyadari, Claude sudah melanjutkan ke langkah ke-5 dan ke-6. Mengurai dan memperbaiki memakan waktu lebih lama daripada mengulang seluruh tugas. Jika ada checkpoint, masalah bisa ditemukan di langkah ke-4.

Aturan 11: Konvensi lebih utama daripada inovasi

Jika basis kode menggunakan snake_case, dan Anda lebih suka camelCase: tetap gunakan snake_case.
Jika basis kode memakai class-based components, dan Anda lebih suka hooks: tetap pakai class-based.
Perbedaan pendapat adalah diskusi lain. Dalam basis kode, konsistensi lebih penting daripada preferensi pribadi.
Jika Anda yakin konvensi tertentu berbahaya, ajukan secara jelas. Jangan diam-diam membuat cabang.

Dalam basis kode yang sudah mapan, Claude cenderung memperkenalkan gaya sendiri. Bahkan jika lebih baik, memperkenalkan mode kedua justru lebih buruk daripada mengikuti satu gaya saja.

Contoh situasi: Claude menambahkan hooks ke basis kode React berbasis class. Ia bisa berjalan, tetapi merusak pengujian lama yang bergantung pada componentDidMount. Akhirnya, saya harus menghapus dan menulis ulang.

Aturan 12: Tampilkan kegagalan secara eksplisit, jangan diam-diam

Jika Anda tidak yakin sesuatu berhasil, katakan secara tegas.
Jika 30 record dilewati diam-diam, jangan katakan “migrasi selesai”.
Jika Anda melewatkan pengujian apa pun, jangan katakan “berhasil”.
Jika Anda tidak memverifikasi batasan yang diminta, jangan katakan “fungsi aktif”.
Ungkapkan ketidakpastian secara terbuka, bukan sembunyi-sembunyi.

Kegagalan Claude yang paling mahal seringkali tampak seperti keberhasilan. Fungsi “berjalan”, tetapi mengembalikan data salah; migrasi “selesai”, tetapi melewati 14% record yang menimbulkan konflik; pengujian “lulus”, tetapi hanya karena assertion salah.

Contoh situasi: Claude menyatakan migrasi database “berhasil”. Tapi sebenarnya, dia diam-diam melewati 14% record yang melanggar constraint. Log ini tertulis, tapi tidak jelas. 11 hari kemudian, saat laporan data mulai bermasalah, kita baru sadar.

Hasil data

Dalam 6 minggu, saya melacak 50 tugas representatif dari 30 basis kode, dan menguji tiga konfigurasi berbeda.

Tingkat kesalahan adalah: tugas yang perlu diperbaiki atau ditulis ulang agar sesuai dengan niat asli. Termasuk asumsi diam-diam, overengineering, kerusakan tidak terkait, kegagalan diam-diam, pelanggaran konvensi, kompromi konflik, dan melewatkan checkpoint.

Tingkat kepatuhan adalah: seberapa besar kemungkinan Claude secara eksplisit menerapkan aturan saat berlaku.

Hasil yang benar-benar menarik bukan hanya penurunan kesalahan dari 41% ke 3%. Lebih penting lagi, dari 4 aturan menjadi 12 aturan, tingkat kepatuhan hanya turun dari 78% menjadi 76%, tetapi tingkat kesalahan turun 8 poin persentase. Aturan tambahan menutupi pola kegagalan yang tidak tertangani oleh 4 aturan awal, dan mereka tidak bersaing dalam anggaran perhatian yang sama.

Di mana template Karpathy diam-diam gagal

Bahkan tanpa menambahkan aturan baru, template 4 aturan asli Karpathy setidaknya gagal di 4 area.

Pertama, tugas agen jangka panjang.
Aturan Karpathy fokus pada saat Claude menulis kode. Tapi apa yang terjadi saat Claude menjalankan pipeline multi-langkah? Template awal tidak punya aturan anggaran, tidak ada checkpoint, dan tidak ada aturan “gagal keras”. Akibatnya, pipeline melantur perlahan.

Kedua, konsistensi multi-basis kode.
“Sesuaikan gaya yang ada” hanya menganggap satu gaya. Tapi dalam monorepo dengan 12 layanan, Claude harus memilih gaya mana yang dipakai. Aturan awal tidak memberi panduan. Akibatnya, dia bisa memilih secara acak atau mencampur gaya.

Ketiga, kualitas pengujian.
“Fokus pada tujuan” menganggap “lulus pengujian” sebagai keberhasilan, tapi tidak menjelaskan bahwa pengujian harus bermakna. Akibatnya, Claude bisa menulis pengujian yang hampir tidak memverifikasi apa-apa, tetapi tetap lolos.

Keempat, perbedaan antara lingkungan produksi dan prototipe.
Aturan 4 bisa mencegah overengineering di produksi, tetapi memperlambat pengembangan prototipe. Karena di tahap awal, kadang perlu 100 baris kode eksplorasi. Aturan “Utamakan kesederhanaan” bisa terlalu sering memicu.

8 aturan tambahan ini bukan untuk menggantikan 4 aturan awal Karpathy, tetapi untuk mengisi kekurangannya: template awal cocok untuk skenario otomatisasi otomatis Januari 2026; sedangkan Mei 2026, Claude Code sudah berada di lingkungan kolaborasi multi-agen dan multi-repositori, yang berbeda masalahnya.

Metode mana yang tidak efektif

Sebelum menetapkan 12 aturan ini, saya juga mencoba beberapa pendekatan lain.

Menggunakan aturan dari Reddit / X yang saya lihat.
Sebagian besar hanya mengulang 4 aturan Karpathy dengan kata berbeda, atau aturan domain spesifik yang tidak umum, seperti “selalu pakai Tailwind”. Akhirnya saya hapus.

Lebih dari 12 aturan.
Saya maksimal menguji sampai 18. Setelah 14, tingkat kepatuhan turun dari 76% ke 52%. Batas 200 baris memang nyata. Lebih dari itu, Claude mulai mengenali pola “ada aturan di sini” tanpa benar-benar membaca satu per satu.

Mengandalkan alat tertentu.
Misalnya “selalu pakai eslint”, tapi jika proyek tidak pakai eslint, aturan ini diam-diam gagal. Saya ubah menjadi “ikuti gaya yang sudah ditegakkan di basis kode”, tanpa bergantung alat tertentu.

Menaruh contoh di CLAUDE.md, bukan aturan.
Contoh lebih banyak konteks, tapi Claude mudah overfitting. Aturan adalah abstraksi, contoh adalah konkret. Jadi, lebih baik pakai aturan.

“Lebih hati-hati”, “pikirkan matang-matang”, “fokus lebih”.
Ini hanya noise. Kepatuhan terhadap instruksi ini turun sekitar 30% karena tidak bisa diverifikasi. Saya ganti dengan perintah yang lebih spesifik, seperti “jelaskan asumsi secara eksplisit”.

Meminta Claude berperilaku seperti “insinyur senior”.
Ini tidak berguna. Claude sudah merasa seperti insinyur senior. Masalahnya bukan di persepsinya, tetapi di eksekusinya. Instruksi imperatif bisa memperkecil jarak ini, bukan prompt identitas.

Versi lengkap dari CLAUDE.md dengan 12 aturan

Berikut adalah versi lengkap yang bisa langsung disalin dan tempel.

Saat ini tidak bisa ditampilkan di luar dokumen Feishu.

Simpan sebagai CLAUDE.md di root repositori Anda. Tambahkan aturan khusus proyek di bawahnya, seperti stack teknologi, perintah pengujian, pola kesalahan. Jangan lebih dari 200 baris, karena di atas itu tingkat kepatuhan menurun.

Cara instalasi

Dua langkah saja:

1. Tambahkan 4 aturan dasar Karpathy ke CLAUDE.md Anda
   curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. Tempelkan aturan 5–12 dari artikel ini di bawahnya

Simpan file di root repositori. Perintah “>>” penting agar menambahkan ke file yang sudah ada, bukan menimpa.

Model Pemikiran

CLAUDE.md bukan daftar keinginan, melainkan kontrak perilaku untuk menutup pola kegagalan nyata yang sudah diamati.

Setiap aturan harus menjawab: “Apa kesalahan yang bisa dicegah?”

4 aturan Karpathy mencegah pola gagal Januari 2026: asumsi diam-diam, overengineering, kerusakan tidak terkait, standar keberhasilan lemah. Mereka dasar, jangan dilewatkan.

8 aturan tambahan mencegah pola gagal setelah Mei 2026: loop tanpa anggaran, tugas multi langkah tanpa checkpoint, pengujian yang tidak bermakna, dan masalah kegagalan diam-diam yang disamarkan sebagai keberhasilan. Mereka adalah patch incremental.

Tentu saja, efektivitasnya tergantung pengguna. Jika Anda tidak menjalankan pipeline multi-langkah, aturan 10 tidak terlalu penting. Jika basis kode Anda konsisten dan sudah ditegakkan lint, aturan 11 bisa diabaikan. Setelah membaca 12 aturan ini, simpan yang benar-benar relevan dan hapus sisanya.

Sebuah versi CLAUDE.md yang disesuaikan dengan pola kegagalan nyata akan lebih baik daripada versi 12 aturan yang berisi 6 aturan yang tidak pernah Anda pakai.

Penutup

Tweet Karpathy Januari 2026 sebenarnya keluhan. Forrest Chang mengubahnya menjadi 4 aturan. Akhirnya, 120.000 pengembang memberi bintang. Kebanyakan dari mereka masih hanya pakai 4 aturan itu.

Model sudah maju, ekosistem juga berubah. Multi-agen, trigger rantai hook, pemuatan skill, kolaborasi multi-repositori—semua ini tidak ada saat tweet itu dibuat. 4 aturan awal tidak cukup. Mereka bukan salah, hanya tidak lengkap.

Tambah 8 aturan, 6 minggu, 30 basis kode, dan tingkat kesalahan turun dari 41% ke 3%.

Simpan artikel ini malam ini, tempelkan 12 aturan ini ke CLAUDE.md Anda. Jika membantu Anda menghindari satu minggu kesalahan Claude, sebarkan.

[Link asli]

Klik untuk tahu lebih banyak tentang Low-Beat di BlockBeats yang sedang membuka posisi

Bergabunglah dengan komunitas resmi BlockBeats:

Telegram Berlangganan: https://t.me/theblockbeats

Telegram Grup Diskusi: https://t.me/BlockBeats_App

Akun resmi Twitter: https://twitter.com/BlockBeatsAsia