Data Pemakaian Claude Code: Temuan dari 400.000 Sesi

Saya sudah menulis banyak kalimat penuh keyakinan tentang cara memakai Claude Code, semuanya ditarik dari sesi saya sendiri. Sesi saya sendiri adalah sampel berjumlah satu, dan sifat sampel berjumlah satu adalah ia selalu setuju dengan Anda. Jadi ketika Anthropic menerbitkan analisis atas sekitar 400.000 sesi nyata dari kira-kira 235.000 orang, saya membacanya sambil mencari bagian yang tidak setuju dengan saya.

Ternyata ada dua bagian, dan keduanya mengubah kebiasaan harian saya. Tulisan ini menarik keluar angka yang benar-benar bisa ditindaklanjuti — pembagian mode kerja, asimetri keputusan, bagaimana keahlian mengubah bentuk sesi alih-alih sekadar hasilnya, dan apa yang dikatakan pergeseran setahun ini tentang arah ke depan. Setiap angka di bawah berasal dari studi tersebut.

Apa isi datasetnya, dan apa yang tidak bisa dikatakannya

Studi ini mencakup sekitar 400.000 sesi Claude Code dari kira-kira 235.000 orang antara Oktober 2025 dan April 2026, disertai catatan bahwa porsi proyek GitHub dengan aktivitas coding agent sudah lebih dari dua kali lipat sejak akhir 2025 dan bahwa pengguna Claude Code kini rata-rata memakai perkakas ini sekitar dua puluh jam per minggu. Angka terakhir itulah yang membingkai ulang sisanya: ini bukan bantuan sesekali, ini tempat sebagian besar pekan seseorang mengalir.

Perlu jujur soal batasnya sebelum mengutip apa pun. Ini data observasional tentang apa yang orang lakukan, bukan perbandingan terkendali terhadap bekerja tanpa perkakasnya, jadi tidak ada di sini yang mengukur produktivitas dalam pengertian ekonomi. Keberhasilan dinilai dari sesinya sendiri. Yang memang diukur dengan baik adalah bentuk — apa yang orang minta, seberapa banyak yang dikerjakan agent per permintaan, dan bagaimana kedua hal itu berbeda antara yang baru memakainya dan yang tidak.

Sebagian besar sesi bukan menulis kode baru

Koreksi mental terbesar yang diberikan data ini kepada saya adalah: menulis kode baru adalah aktivitas minoritas. Sekitar 56 persen sesi berisi menulis, memperbaiki, atau menguji dan mengorkestrasi kode — tetapi menulis hanya 25 poin dari itu, memperbaiki 26, dan menguji serta orkestrasi cuma 5. Sisa distribusinya adalah bagian yang paling diremehkan orang.

Ke mana sesi-sesi itu sebenarnya pergi:

Pembagian keputusan adalah temuan yang seharusnya mengubah kebiasaan Anda

Manusia mengambil sekitar 70 persen keputusan perencanaan dan hanya sekitar 20 persen keputusan eksekusi. Ini bukan keluhan soal otonomi — ini deskripsi tentang di mana perhatian Anda punya daya ungkit. Setiap prompt memicu rantai sekitar sepuluh aksi rata-rata, kadang lebih dari seratus, di dalam sesi yang biasanya berjalan sekitar empat giliran seperti itu.

# The number that reframes everything else in the study:
#
#   1 prompt  ->  ~10 actions by Claude, on average
#                 (sometimes over 100)
#
#   A typical session is about FOUR such turns.
#
# So a four-turn session is roughly forty tool calls you did
# not individually approve. That is why the planning decision
# is the one worth your attention: you make ~70% of those,
# and only ~20% of the execution decisions.

Baca aritmetika itu dengan jujur dan kesimpulannya tidak nyaman tetapi berguna: dalam sesi biasa, Anda secara pribadi hanya memutuskan sebagian kecil dari apa yang benar-benar terjadi. Karena itu setiap menit yang dipakai mempertajam rencana bernilai berkali-kali lipat dibanding menit yang dipakai memeriksa eksekusi setelahnya, dan itulah sebabnya plan mode serta rencana tertulis selalu muncul di setiap panduan workflow yang serius. Anda tidak sedang diminta melambat demi melambat. Anda diminta membelanjakan keputusan di tempat yang masih sebagian besar milik Anda.

Keahlian mengubah bentuk sesi, bukan cuma hasilnya

Saya mengira pengguna berpengalaman menjalankan sesi yang lebih rapat dan lebih pendek. Kenyataannya sebaliknya. Sesi dari pemula menghasilkan sekitar lima aksi Claude dan kira-kira 600 kata keluaran; sesi dari pengguna ahli menghasilkan dua belas aksi dan sekitar 3.200 kata. Orang ahli bukan meminta lebih sedikit, mereka meminta lebih banyak dan berhasil melangkah lebih jauh dengannya.

# Session shape by expertise (verified-success sessions):
#
#   novice   :  5 actions,   ~600 words of output
#   expert   : 12 actions, ~3,200 words of output
#
# Verified success rate:
#   novice          : 15%   (partial success 77%)
#   intermediate /
#   expert          : 28-33% (partial success 91-92%)
#
# Abandonment:
#   novice   : 19% of sessions
#   expert   : 5-7%
#
# Experts do not get shorter sessions out of the tool.
# They get LONGER ones that finish.

Pekerjaannya bergeser dari memperbaiki ke membangun dalam tujuh bulan

Antara Oktober 2025 dan April 2026 komposisinya bergeser ke arah yang konsisten, dan arahnya berbicara lebih banyak daripada angka tunggal mana pun:

• Porsi sesi yang memperbaiki kode rusak turun dari 33 persen ke 19 persen.
• Mengoperasikan software naik dari 14 persen ke 21 persen.
• Menulis dan analisis data kira-kira berlipat ganda, dari sekitar 10 persen ke 20 persen.

Estimasi nilai sesi rata-rata naik 27 persen pada periode yang sama, dengan tugas membangun naik sekitar 43 persen, tugas mengoperasikan 34 persen, dan memperbaiki 32 persen. Perkakas yang semula lebih banyak memperbaiki kini lebih banyak membuat dan menjalankan, dan itu selaras dengan arah produknya sendiri — setahun terakhir rilisnya didominasi orkestrasi, permission, dan menjalankan pekerjaan tanpa pengawasan, bukan menulis fungsi yang lebih baik.

Bukan hanya software engineer, dan jaraknya kecil

Pekerjaan di bidang software mencapai 30 persen verified success secara keseluruhan dibanding 26 persen untuk profesi lain, dan khusus pada sesi yang menghasilkan kode angkanya 34 dan 29 persen. Setiap satu dari sepuluh pekerjaan terbesar berada dalam rentang tujuh poin dari software engineer.

Selisih empat poin secara keseluruhan jauh lebih sempit daripada yang tersirat dari perbincangan seputar perkakas AI coding, dan itu selaras dengan 13 persen sesi yang menghasilkan analisis atau prosa alih-alih kode. Kalau Anda developer yang heran kenapa product manager Anda terus mengirimkan transkrip terminal, inilah alasannya: perkakas ini tidak berhenti di departemen engineering.

Apa yang saya ubah setelah membacanya

Empat kebiasaan konkret, diurutkan dari yang paling cepat terasa hasilnya:

1. Dahulukan rencananya. Kalau saya memegang 70 persen keputusan perencanaan dan 20 persen keputusan eksekusi, rencana yang ditinjau lima menit mengalahkan diff yang ditinjau dua puluh menit.
2. Pantau pengabaian, bukan kepuasan. Sekarang saya mencatat kapan satu sesi tidak menghasilkan apa pun yang terpakai, dan setiap kali penyebabnya adalah masalah ruang lingkup, bukan masalah prompt.
3. Berhenti menganggap sesi panjang sebagai tanda bahaya. Sesi pengguna ahli lebih dari dua kali lebih panjang dari sisi keluaran; mode gagalnya adalah sesi panjang tanpa rencana, bukan panjangnya itu sendiri.
4. Anggarkan untuk mengoperasikan, bukan cuma menulis. Seperlima sesi adalah menjalankan dan merangkai software, jadi permission dan akses tool untuk pekerjaan itu layak mendapat usaha setup yang sama seperti aturan pengeditan.

Studi ini paling berguna sebagai koreksi atas apa pun yang diajarkan sesi Anda sendiri. Sesi saya mengajarkan bahwa lebih pendek berarti lebih aman dan bahwa kode baru adalah acara utamanya; datanya bilang pengguna ahli menjalankan sesi lebih panjang dan bahwa menulis kode baru hanya seperempat pekerjaannya. Kebiasaan yang saya simpan darinya sempit dan murah: belanjakan perhatian Anda pada rencananya, karena itulah bagian sesi yang sebagian besar masih Anda pegang.