Claude Code untuk investigasi kinerja: alur kerja terukur

Mengapa pekerjaan performa salah tanpa pengukuran

Bug performa mengundang tebak-tebakan. Seseorang merasa halaman terasa lambat atau sebuah API timeout, dan langkah tercepat adalah "membersihkan" kode, menambah caching, atau menulis ulang sebuah loop. Masalahnya, "terasa lambat" bukan metrik, dan "lebih bersih" tidak sama dengan lebih cepat.

Tanpa pengukuran, tim menghabiskan jam mengubah hal yang salah. Jalur panas mungkin ada di database, jaringan, atau alokasi tak terduga tunggal, sementara tim memoles kode yang nyaris tidak dieksekusi. Lebih buruk, perubahan yang tampak cerdas bisa membuat performa lebih buruk: logging ekstra di loop ketat, cache yang menambah tekanan memori, atau pekerjaan paralel yang menciptakan kontensi lock.

Tebak-tebakan juga berisiko merusak perilaku. Ketika Anda mengubah kode untuk mempercepatnya, Anda mungkin mengubah hasil, penanganan error, urutan, atau retry. Jika Anda tidak memeriksa kembali kebenaran dan kecepatan bersama-sama, Anda bisa "menang" pada benchmark sambil diam-diam mengirim bug.

Perlakukan performa seperti eksperimen, bukan perdebatan. Loopnya sederhana dan dapat diulang:

• Pilih satu metrik yang mewakili masalah (latensi, throughput, CPU, memori, waktu DB).
• Tangkap baseline dalam kondisi yang sama.
• Ubah satu hal kecil.
• Ukur lagi dan bandingkan.

Banyak kemenangan berskala kecil: mengurangi 8% pada p95, menurunkan memori puncak 50 MB, atau memangkas satu query database. Itu tetap penting, tetapi hanya jika diukur, diverifikasi, dan dapat diulang.

Alur kerja: ukur, hipotesis, ubah, ukur ulang

Ini bekerja terbaik sebagai loop, bukan permintaan satu kali "buat lebih cepat". Loop membuat Anda jujur karena setiap tindakan terkait bukti dan angka yang bisa dipantau.

Urutan yang jelas:

• Measure: pilih satu metrik dan catat baseline.
• Hypothesize: jelaskan apa yang Anda kira lambat dan mengapa.
• Change: lakukan tweak terkecil yang menguji hipotesis.
• Re-measure: jalankan pengukuran yang sama lagi dan bandingkan.

Setiap langkah melindungi Anda dari jenis tipuan diri yang berbeda. Mengukur dulu menghentikan Anda dari "memperbaiki" sesuatu yang bukan masalah nyata. Hipotesis tertulis menghentikan Anda mengubah lima hal sekaligus lalu menebak mana yang berpengaruh. Perubahan minimal mengurangi risiko merusak perilaku atau menambah bottleneck baru. Mengukur ulang menangkap kemenangan plasebo (mis. run lebih cepat karena cache hangat) dan mengekspos regresi.

"Selesai" bukan perasaan. Itu hasil: metrik target bergerak ke arah yang benar, dan perubahan tidak menyebabkan regresi nyata (error, memori lebih tinggi, p95 yang lebih buruk, atau endpoint lain yang melambat).

Mengetahui kapan berhenti adalah bagian dari alur kerja. Berhenti ketika keuntungan menyurut, metrik sudah cukup baik untuk pengguna, atau ide berikutnya memerlukan refactor besar dengan upside kecil. Pekerjaan performa selalu punya biaya peluang; loop membantu Anda menghabiskan waktu di tempat yang memberi hasil.

Pilih metrik dan kunci baseline

Jika Anda mengukur lima hal sekaligus, Anda tidak akan tahu apa yang membaik. Pilih satu metrik utama untuk investigasi ini dan anggap yang lain sebagai sinyal pendukung. Untuk banyak masalah user-facing, metrik itu adalah latensi. Untuk pekerjaan batch bisa throughput, waktu CPU, penggunaan memori, atau bahkan biaya cloud per run.

Spesifik tentang skenarionya. "API lambat" terlalu samar. "POST /checkout dengan keranjang tipikal 3 item" bisa diukur. Jaga input stabil supaya angkanya bermakna.

Tuliskan baseline dan detail lingkungan sebelum Anda menyentuh kode: ukuran dataset, tipe mesin, mode build, feature flag, concurrency, dan warmup. Baseline ini adalah jangkar Anda. Tanpanya, setiap perubahan bisa tampak seperti kemajuan.

Untuk latensi, andalkan persentil, bukan hanya rata-rata. p50 menunjukkan pengalaman tipikal, sementara p95 dan p99 menyingkap ekor yang menyakitkan yang dikeluhkan pengguna. Perubahan yang memperbaiki p50 tetapi memperburuk p99 masih bisa terasa lebih lambat.

Putuskan di awal apa arti "bermakna" agar Anda tidak merayakan noise:

• Latensi: minimal perbaikan 10% di p95 (atau ambang tetap seperti 50 ms)
• Throughput: minimal 5% lebih banyak request per detik pada error rate yang sama
• CPU atau memori: pengurangan yang cukup untuk menghindari scale atau crash
• Biaya: penurunan terukur per run atau per 1.000 request

Setelah aturan ini ditetapkan, Anda bisa menguji ide tanpa memindahkan tujuan.

Kumpulkan bukti dengan profiling dan metrik sederhana

Mulailah dengan sinyal termudah yang bisa Anda percaya. Satu timing sekitar sebuah request bisa memberi tahu apakah Anda punya masalah nyata, dan kira-kira seberapa besar. Simpan profiling mendalam hanya saat Anda perlu menjelaskan mengapa lambat.

Bukti yang baik biasanya datang dari campuran sumber:

• Log aplikasi (durasi request, error rate, endpoint terlambat)
• APM traces (di mana waktu dihabiskan antar layanan)
• Output profiler atau flame graphs (fungsi panas dan call stack)
• Statistik database (query lambat, lock wait, cache hit rate)
• Metrik infrastruktur (CPU, memori, jaringan, restart container)

Gunakan metrik sederhana ketika pertanyaannya adalah "apakah ini lebih lambat, dan seberapa banyak?" Gunakan profiling ketika pertanyaannya adalah "ke mana waktu itu pergi?" Jika p95 latency melambung dua kali lipat setelah deploy, mulai dengan timing dan log untuk mengonfirmasi regresi dan mengerucutkan cakupan. Jika timing menunjukkan sebagian besar delay ada di kode aplikasi (bukan DB), maka profiler CPU atau flame graph dapat menunjuk fungsi tepat yang tumbuh.

Jaga pengukuran tetap aman. Kumpulkan apa yang perlu untuk debug performa, bukan isi pengguna. Prefer agregat (durasi, hitungan, ukuran) daripada payload mentah, dan redaksi identifier secara default.

Noise itu nyata, jadi ambil beberapa sampel dan catat outlier. Jalankan request yang sama 10 sampai 30 kali, dan catat median serta p95 daripada satu run terbaik.

Tuliskan resep uji yang persis agar Anda bisa mengulanginya setelah perubahan: lingkungan, dataset, endpoint, ukuran body request, level concurrency, dan bagaimana Anda menangkap hasil.

Ubah bukti menjadi hipotesis yang jelas

Mulailah dengan gejala yang bisa Anda namai: "p95 latency melompat dari 220 ms ke 900 ms saat puncak traffic," "CPU bertahan di 95% pada dua core," atau "memori tumbuh 200 MB per jam." Gejala samar seperti "terasa lambat" memicu perubahan acak.

Selanjutnya, terjemahkan apa yang Anda ukur ke area tersangka. Flame graph mungkin menunjukkan sebagian besar waktu di JSON encoding, trace mungkin menunjukkan jalur panggilan lambat, atau statistik DB mungkin menunjukkan satu query mendominasi total waktu. Pilih area terkecil yang menjelaskan sebagian besar biaya: sebuah fungsi, satu query SQL, atau satu panggilan eksternal.

Hipotesis yang baik satu kalimat, dapat diuji, dan terkait prediksi. Anda meminta bantuan untuk menguji ide, bukan meminta alat membuat semuanya lebih cepat secara ajaib.

Template hipotesis sederhana

Gunakan format ini:

• Karena (bukti), (tersangka) menyebabkan (gejala).
• Jika kita mengubah (perilaku spesifik), maka (metrik) harus membaik sekitar (perkiraan).
• Kita akan tahu berhasil jika (hasil pengukuran ulang).

Contoh: "Karena profile menunjukkan 38% CPU di SerializeResponse, membuat buffer baru per request menyebabkan lonjakan CPU. Jika kita reuse buffer, p95 latency harus turun sekitar 10–20% dan CPU turun ~15% pada beban yang sama."

Jujurlah dengan menamai alternatif sebelum menyentuh kode. Mungkin bagian lambat sebenarnya dependency upstream, kontensi lock, perubahan cache miss rate, atau rollout yang menambah ukuran payload.

Tuliskan 2–3 penjelasan alternatif, lalu pilih yang paling didukung bukti. Jika perubahan Anda tidak memindahkan metrik, Anda sudah punya hipotesis berikutnya siap diuji.

Cara menggunakan Claude Code tanpa melenceng ke tebak-tebakan

Claude paling berguna dalam pekerjaan performa ketika Anda memperlakukannya seperti analis hati-hati, bukan orakel. Ikat setiap saran pada apa yang Anda ukur, dan pastikan setiap langkah bisa dibuktikan salah.

Berikan input nyata, bukan deskripsi samar. Tempel bukti kecil dan fokus: ringkasan profiling, beberapa baris log di sekitar request lambat, rencana query, dan jalur kode spesifik. Sertakan angka "sebelum" (p95 latency, waktu CPU, waktu DB) agar ia tahu baseline Anda.

Minta penjelasan apa yang data tunjukkan dan apa yang tidak didukung. Lalu paksa penjelasan saingan. Prompt yang bernilai diakhiri dengan: "Berikan 2–3 hipotesis, dan untuk masing-masing, jelaskan apa yang bisa memfalsifikasinya." Itu mencegah terpaku pada cerita pertama yang masuk akal.

Sebelum mengubah apa pun, minta eksperimen terkecil yang dapat memvalidasi hipotesis teratas. Buat cepat dan reversible: tambahkan satu timer di sekitar fungsi, aktifkan satu flag profiler, atau jalankan satu query DB dengan EXPLAIN.

Jika Anda ingin struktur ketat untuk output, minta:

• Apa yang bukti indikasikan (dan tingkat keyakinan)
• 2–3 hipotesis dengan test falsifikasi
• Perubahan kode atau konfigurasi terkecil untuk menguji yang teratas
• Tepat metrik yang harus diukur ulang dan arah yang diharapkan

Jika ia tidak bisa menyebut metrik spesifik, lokasi, dan hasil yang diharapkan, Anda kembali menebak.

Buat perubahan minimal dan reversible

Setelah Anda punya bukti dan hipotesis, lawan dorongan untuk "membersihkan semuanya." Pekerjaan performa paling mudah dipercaya ketika perubahan kode kecil dan mudah di-undo.

Ubah satu hal pada satu waktu. Jika Anda tweak query, menambah caching, dan merombak loop dalam commit yang sama, Anda tidak akan tahu apa yang membantu (atau merugikan). Perubahan single-variable membuat pengukuran berikutnya bermakna.

Sebelum menyentuh kode, tulis angka apa yang Anda harapkan. Contoh: "p95 latency harus turun dari 420 ms ke di bawah 300 ms, dan waktu DB harus turun sekitar 100 ms." Jika hasil meleset, Anda cepat tahu hipotesisnya lemah atau tidak lengkap.

Buat perubahan mudah dibalik:

• Prefer diff kecil yang bisa di-revert bersih.
• Letakkan perubahan di balik flag sehingga bisa dimatikan cepat.
• Hindari refactor yang mengubah nama, format, dan logika sekaligus.
• Jaga scope ketat: satu endpoint, satu hot path, satu panggilan mahal.
• Tambahkan catatan singkat di commit message dengan metrik sebelum/sesudah yang diharapkan.

"Minimal" bukan berarti remeh. Itu berarti fokus: cache satu hasil fungsi mahal, hilangkan satu alokasi berulang di loop ketat, atau hentikan kerja untuk request yang tidak perlu.

Tambahkan timing ringan di sekitar bottleneck tersangka sehingga Anda bisa melihat apa yang berubah. Satu timestamp sebelum dan sesudah panggilan (dilogg atau dikumpulkan sebagai metrik) dapat mengonfirmasi apakah perubahan menyentuh bagian lambat atau sekadar memindahkan waktu ke tempat lain.

Ukur ulang dan putuskan langkah selanjutnya

Setelah perubahan, jalankan ulang skenario persis yang Anda gunakan untuk baseline: input, lingkungan, dan bentuk beban yang sama. Jika test bergantung pada cache atau warm-up, nyatakan itu (mis. "run pertama cold, berikutnya 5 run hangat"). Kalau tidak, Anda akan "menemukan" perbaikan yang hanya keberuntungan.

Bandingkan hasil menggunakan metrik dan persentil yang sama. Rata-rata bisa menyembunyikan rasa sakit, jadi perhatikan p95 dan p99 latency, plus throughput dan waktu CPU. Jalankan cukup repetisi untuk melihat apakah angka stabil.

Sebelum merayakan, periksa regresi yang tidak muncul di angka utama:

• Kebenaran: respons masih sesuai yang diharapkan.
• Error rate: timeout, 5xx, retry.
• Memori: puncak lebih tinggi atau pertumbuhan konsisten.
• Tail latency: p99 memburuk walau p50 membaik.
• Biaya sumber daya: lonjakan CPU atau beban DB.

Lalu putuskan berdasarkan bukti, bukan harapan. Jika perbaikan nyata dan Anda tidak memperkenalkan regresi, pertahankan. Jika hasil campur aduk atau noisy, revert dan susun hipotesis baru, atau isolasi perubahan lebih lanjut.

Jika Anda bekerja di platform seperti Koder.ai, mengambil snapshot sebelum eksperimen dapat membuat rollback menjadi satu langkah, yang memudahkan menguji ide-ide berani dengan aman.

Akhirnya, tuliskan apa yang Anda pelajari: baseline, perubahan, angka baru, dan kesimpulan. Catatan singkat ini mencegah putaran berikutnya mengulangi jalan buntu yang sama.

Kesalahan umum yang membuang-buang waktu

Pekerjaan performa biasanya meleset ketika Anda kehilangan benang antara apa yang Anda ukur dan apa yang Anda ubah. Jaga rantai bukti bersih sehingga Anda bisa mengatakan dengan yakin apa yang membuat lebih baik atau lebih buruk.

Pelaku berulang:

• Memperbaiki target yang salah: Anda merayakan median (p50) yang lebih cepat, tapi ekor (p95/p99) tetap buruk.
• Mengubah banyak hal sekaligus: refactor, caching, dan tweak query dalam satu commit membuat Anda tak tahu apa yang berkontribusi.
• Percaya pada satu run noisy: benchmark lokal yang berayun 20% antara run bukan bukti.
• Menganggap satu profile sebagai kebenaran mutlak: flame graph menunjuk parsing JSON, tapi di produksi request menumpuk saat DB melambat.
• Membandingkan apel dengan jeruk: dataset, feature flag, hardware, atau concurrency berbeda lalu menarik kesimpulan.

Contoh kecil: sebuah endpoint terlihat lambat, jadi Anda tune serializer karena itu panas di profile. Lalu Anda test ulang dengan dataset lebih kecil dan terlihat lebih cepat. Di produksi p99 malah memburuk karena database masih bottleneck dan perubahan Anda menambah ukuran payload.

Jika Anda menggunakan Claude Code untuk mengusulkan perbaikan, kendalikan outputnya. Minta 1–2 perubahan minimal yang cocok dengan bukti yang sudah dikumpulkan, dan desak rencana re-measure sebelum menerima patch.

Checklist cepat sebelum Anda menyatakan "lebih cepat"

Klaim kecepatan runtuh saat test kabur. Sebelum merayakan, pastikan Anda bisa menjelaskan apa yang diukur, bagaimana diukur, dan apa yang diubah.

Mulailah dengan menamai satu metrik dan menulis hasil baseline. Sertakan detail yang mengubah angka: tipe mesin, beban CPU, ukuran dataset, mode build (debug vs release), feature flag, status cache, dan concurrency. Jika Anda tidak bisa merekonstruksi setup besok, Anda tidak punya baseline.

Checklist:

• Metrik dan baseline tercatat dengan catatan lingkungan (hardware, config, data, cache hangat/ dingin).
• Langkah test tertulis dan dapat diulang.
• Anda punya satu hipotesis dengan prediksi (mis. "Jika kita hilangkan N+1 queries, p95 harus turun ~30%.").
• Anda membuat satu perubahan kecil dan reversible dan mendokumentasikan apa yang bergerak (file, fungsi, query, setting).
• Anda mengukur ulang dengan beberapa sampel dan membandingkan sebanding (input, load sama).

Setelah angkanya tampak lebih baik, lakukan pengecekan regresi cepat. Periksa kebenaran (output sama), error rate, dan timeout. Amati efek samping seperti memori lebih tinggi, spike CPU, startup lebih lambat, atau beban DB bertambah. Perubahan yang memperbaiki p95 tetapi menggandakan memori mungkin merupakan trade-off yang salah.

Contoh: menyelidiki endpoint API lambat langkah demi langkah

Sebuah tim melaporkan GET /orders terasa baik di dev, tapi melambat di staging saat beban sedang. Pengguna mengeluh tentang timeout, tapi latensi rata-rata masih terlihat "oke," jebakan klasik.

Pertama, tetapkan baseline. Dengan uji beban stabil (dataset sama, concurrency sama, durasi sama), Anda mencatat:

• p95 latency: 1.8s (target < 600ms)
• CPU API: ~70% dengan spike sesekali
• DB: satu query memakan 900–1100ms, dan total waktu query per request ~1.3s

Sekarang kumpulkan bukti. Trace cepat menunjukkan endpoint menjalankan query utama untuk orders, lalu melakukan loop dan fetch item terkait per order. Anda juga melihat respons JSON besar, tetapi waktu DB mendominasi.

Ubah itu menjadi daftar hipotesis yang bisa diuji:

• Query lambat perlu index.
• N+1 queries mengalikan waktu DB.
• Serialisasi lambat karena payload besar.
• Kontensi lock menahan baca saat write.

Minta perubahan minimal yang cocok bukti terkuat: hilangkan satu panggilan N+1 dengan mengambil item dalam satu query yang dipetakan per order ID (atau tambahkan index yang hilang jika query plan menunjukkan full scan). Jaga reversible dan commit terfokus.

Ukur ulang dengan uji beban yang sama. Hasil:

• p95 latency: 1.8s → 720ms
• Total waktu DB: ~1.3s → 420ms
• CPU: sedikit turun, tapi masih ada spike

Keputusan: ship perbaikan (menang jelas), lalu mulai siklus kedua fokus pada celah tersisa dan spike CPU, karena DB bukan lagi pembatas utama.

Langkah selanjutnya: jadikan alur ini rutinitas

Cara tercepat jadi lebih baik dalam investigasi performa adalah memperlakukan setiap run sebagai eksperimen kecil yang bisa diulang. Saat proses konsisten, hasil lebih mudah dipercaya, dibandingkan, dan dibagikan.

Template satu halaman sederhana membantu:

• Metrik + cara pengukuran (tool, perintah, dataset)
• Baseline (angka, lingkungan, kapan diambil)
• Hipotesis (satu kalimat, dapat diuji)
• Perubahan (diff kecil, apa yang disentuh)
• Hasil (sebelum/sesudah, plus keputusan)

Tentukan di mana catatan ini disimpan agar tidak hilang. Tempat bersama lebih penting daripada alat sempurna: folder repo di samping service, dokumen tim, atau catatan tiket. Keterlihatan adalah kuncinya. Seseorang harus bisa menemukan "p95 latency spike setelah perubahan caching" beberapa bulan kemudian.

Buat eksperimen aman menjadi kebiasaan. Gunakan snapshot dan rollback mudah supaya Anda bisa mencoba ide tanpa takut. Jika Anda membangun dengan Koder.ai, Planning Mode bisa menjadi tempat nyaman untuk merinci rencana pengukuran, mendefinisikan hipotesis, dan menjaga scope sebelum Anda menghasilkan diff ketat dan mengukur ulang.

Tetapkan ritme. Jangan menunggu insiden. Tambahkan pemeriksaan performa kecil setelah perubahan seperti query baru, endpoint baru, payload lebih besar, atau upgrade dependency. Pemeriksaan baseline 10 menit sekarang bisa menyelamatkan satu hari tebak-tebakan nanti.