Alur Prompt-ke-PR dengan Claude Code: Perubahan Kecil

Mengapa Prompt-ke-PR lebih baik daripada prompt besar sekaligus

Prompt besar sekaligus sering berujung pada perubahan besar dan berantakan: puluhan file tersentuh, refactor yang tak terkait, dan kode yang belum sempat Anda pahami. Meski hasilnya teknis benar, review terasa berisiko karena sulit melihat apa yang berubah dan mengapa.

Diff kecil memperbaiki masalah itu. Ketika setiap perubahan dibatasi dan fokus, Anda bisa membacanya dalam beberapa menit, menangkap kesalahan lebih awal, dan menghindari merusak bagian lain yang tak ingin disentuh. Reviewer lebih mempercayai PR kecil, jadi merge terjadi lebih cepat dan dengan lebih sedikit komentar bolak-balik.

Prompt-ke-PR adalah loop sederhana:

• Minta satu perubahan kecil dengan batas yang jelas.
• Periksa diff dan konfirmasi sesuai maksud.
• Jalankan pemeriksaan biasa (tes, lint, build).
• Jika sesuatu gagal, re-prompt dengan error dan konteks yang tepat.
• Ulangi hingga siap di-merge.

Irama ini mengubah kegagalan menjadi umpan balik cepat daripada kejutan di akhir. Jika Anda meminta Claude Code mengubah aturan validasi, batasi hanya pada aturan itu. Jika sebuah tes gagal, tempelkan output yang gagal dan minta perbaikan terkecil yang membuat tes lulus, bukan penulisan ulang seluruh modul.

Satu hal tidak berubah: Anda tetap bertanggung jawab atas kode akhir. Perlakukan model seperti pasangan pemrogram lokal yang mengetik cepat, bukan autopilot. Anda yang memutuskan apa yang masuk, apa yang tetap, dan kapan aman membuka PR.

Siapkan repo dan pengaturan pairing lokal Anda

Mulailah dari baseline yang bersih. Jika branch Anda tertinggal atau tes sudah gagal, setiap saran berubah jadi tebak-tebakan. Tarik perubahan terbaru, rebase atau merge sesuai tim Anda, dan pastikan status saat ini sehat sebelum meminta apapun.

Pengaturan “pasangan pemrogram lokal” berarti Claude Code mengedit file di repo Anda sementara Anda mengendalikan tujuan, batasan, dan setiap diff. Model tidak tahu codebase Anda kecuali Anda tunjukkan, jadi jelaskan secara eksplisit file, batasan, dan perilaku yang diharapkan.

Sebelum prompt pertama, putuskan di mana pemeriksaan akan dijalankan. Jika Anda bisa menjalankan tes secara lokal, Anda akan mendapat umpan balik dalam beberapa menit yang menjaga iterasi tetap kecil. Jika beberapa pemeriksaan hanya berjalan di CI (aturan lint tertentu, suite panjang, langkah build), putuskan kapan Anda akan mengandalkan CI agar tidak menunggu setelah setiap perubahan kecil.

Pre-flight sederhana:

• Perbarui branch Anda dan konfirmasi aplikasi berhasil build atau berjalan.
• Jalankan pemeriksaan cepat secara lokal (lint, unit test, type check).
• Catat pemeriksaan yang hanya ada di CI dan berapa lama biasanya berjalan.
• Konfirmasi Anda bisa mereproduksi isu atau melihat fitur yang hilang dengan jelas.
• Pastikan Anda bisa membatalkan perubahan dengan mudah (status bersih, commit kecil).

Buka catatan kecil saat bekerja. Tulis batasan seperti "no API changes," "pertahankan kompatibilitas mundur," "sentuh hanya modul X," serta keputusan yang Anda buat. Saat tes gagal, tempelkan pesan error persis di sana juga. Catatan kecil itu menjadi input terbaik untuk prompt berikutnya dan mencegah sesi melenceng.

Tulis prompt yang membawa ke diff kecil secara alami

Diff kecil dimulai dari prompt yang sengaja sempit. Jalan tercepat ke kode yang bisa di-merge adalah satu perubahan yang bisa Anda review dalam semenit, bukan refactor yang harus Anda pahami selama satu jam.

Prompt yang baik menyebutkan satu tujuan, satu area codebase, dan satu hasil yang diharapkan. Jika Anda tidak bisa menunjuk di mana perubahan harus ditempatkan (file, folder, atau modul), model akan menebak dan diff akan menyebar.

Bentuk prompt yang menjaga perubahan tetap kecil:

• Goal: perilaku tunggal yang ingin diubah.
• Location: file(s) atau komponen yang akan disentuh.
• Constraints: apa yang tidak boleh berubah.
• Acceptance: seperti apa tanda "selesai".
• Diff size: minta secara eksplisit perubahan terkecil yang bekerja.

Batasan adalah senjata rahasia. Alih-alih "perbaiki bug login," nyatakan apa yang harus tetap: "Jangan ubah bentuk API," "Jangan ubah nama fungsi publik," "Tidak ada edit hanya karena formatting," "Hindari dependensi baru." Itu memberitahu pasangan Anda di mana tidak boleh menjadi pintar.

Saat perubahan masih terasa tidak jelas, minta rencana sebelum kode. Rencana singkat memaksa pekerjaan ke langkah-langkah dan memberi Anda kesempatan menyetujui langkah kecil pertama.

Goal: Fix the null crash when rendering the profile header.
Location: src/components/ProfileHeader.tsx only.
Constraints: Do not change styling, props, or any exported types.
Expected outcome: If user.name is missing, show "Anonymous" and no crash.
Diff constraint: Minimal diff. No refactors. No unrelated formatting.
If unclear: First reply with a 3-step plan, then wait for approval.

Jika Anda bekerja di tim, tambahkan juga batasan review: "Jaga di bawah ~30 baris perubahan" atau "Satu file saja kecuali sangat perlu." Itu membuat diff lebih mudah dipindai dan memperjelas prompt lanjutan saat ada yang gagal.

Pilih unit kerja yang tepat untuk tiap iterasi

Jaga setiap loop fokus pada satu perubahan kecil yang bisa dites. Jika Anda bisa mendeskripsikan tujuan dalam satu kalimat dan memprediksi file yang akan berubah, itu ukuran yang tepat.

Unit kerja yang baik termasuk: memperbaiki satu bug dalam satu jalur (dengan repro dan guard), menyesuaikan satu tes untuk satu perilaku, melakukan refactor yang mempertahankan perilaku (rename, extract function, hapus duplikasi), atau memperbaiki satu pesan error atau aturan validasi.

Batasi waktu tiap loop. 10–20 menit biasanya cukup untuk menulis prompt jelas, menerapkan diff, dan menjalankan pemeriksaan cepat. Jika masih eksplorasi setelah 20 menit, perkecil unit atau alihkan ke investigasi saja (catatan, logging, tes yang gagal) dan hentikan di sana.

Definisikan "selesai" sebelum mulai:

• Perubahan tetap dalam file dan perilaku yang dimaksud.
• Satu pemeriksaan membuktikan bekerja (tes, lint, atau langkah run sederhana).
• Tidak ada peringatan baru atau perubahan formatting yang berisik.
• Diff mudah dijelaskan dalam dua kalimat.

Saat ruang lingkup mulai membesar, berhenti lebih awal. Jika Anda mendapati diri berkata "sekalian saja," itu berarti Anda menemukan iterasi berikutnya. Tangkap itu sebagai tindak lanjut, commit diff kecil saat ini, dan terus bergerak.

Review diff sebelum menjalankan pemeriksaan

Sebelum menjalankan tes atau build, baca diff seperti reviewer. Di sinilah alur tetap bersih atau diam-diam melenceng ke wilayah "kenapa file ini tersentuh?".

Mulailah dengan meminta Claude Code meringkas apa yang diubah dalam bahasa biasa: file yang disentuh, perubahan perilaku, dan apa yang tidak diubah. Jika model tidak bisa menjelaskan perubahan dengan jelas, kemungkinan diff terlalu banyak.

Lalu baca sendiri. Cepat lihat dulu untuk scope, lalu baca untuk maksud. Anda mencari drift: formatting yang tidak terkait, refactor ekstra, simbol yang diganti nama, atau perubahan yang tak diminta.

Pre-check cepat:

• Apakah file yang diubah sesuai permintaan?
• Adakah edit sambil lalu (whitespace, refactor tak terkait)?
• Apakah diperkenalkan perilaku baru yang tidak diminta?
• Apakah ada dependensi baru atau perubahan config yang butuh alasan nyata?
• Bisakah reviewer mengerti ini tanpa membaca lima file lain?

Jika diff lebih besar dari yang diharapkan, jangan mencoba mengujinya dengan berharap. Roll back dan re-prompt untuk langkah yang lebih kecil. Misalnya: "Tambahkan test gagal yang mereproduksi bug. Tidak ada refactor." Diff kecil membuat kegagalan lebih mudah diinterpretasi dan membuat prompt berikutnya lebih tepat.

Jalankan pemeriksaan setelah setiap perubahan kecil

Diff kecil hanya bermanfaat jika Anda memverifikasinya segera. Tujuannya adalah loop rapat: ubah sedikit, periksa sedikit, tangkap kesalahan selagi konteks masih segar.

Mulailah dengan pemeriksaan tercepat yang bisa memberitahu "ini rusak." Jika Anda mengubah formatting atau import, jalankan lint atau formatter dulu. Jika Anda menyentuh logika bisnis, jalankan tes unit terfokus yang mencakup file atau paket itu. Jika Anda mengedit tipe atau konfigurasi build, jalankan kompilasi cepat.

Urutan praktis:

• Lint atau format.
• Tes unit terfokus untuk area yang diubah.
• Build atau typecheck untuk memastikan semuanya cocok.
• Suite yang lebih lambat (integration, end-to-end) setelah dasar-langkah lulus.

Saat sesuatu gagal, rekam dua hal sebelum memperbaiki apapun: perintah yang Anda jalankan dan output error lengkap (copy apa adanya). Rekaman itu menjaga prompt berikutnya spesifik dan mencegah loop "masih gagal" yang samar.

Jaga scope tetap ketat. Jika lint gagal dan tes juga gagal, perbaiki lint dulu, jalankan ulang, lalu tangani tes. Jangan gabungkan "bersih-bersih cepat" dengan perbaikan crash dalam pass yang sama.

Re-prompt dengan kegagalan sampai pemeriksaan hijau

Saat pemeriksaan gagal, perlakukan output kegagalan sebagai prompt Anda berikutnya. Loop tercepat adalah: tempel error, dapatkan diagnosis, terapkan perbaikan minimal, jalankan ulang.

Tempel kegagalan apa adanya, termasuk perintah dan stack trace penuh. Minta kemungkinan penyebab terlebih dahulu, bukan daftar opsi. Claude Code bekerja lebih baik ketika bisa berlabuh pada nomor baris dan pesan yang tepat daripada menebak.

Tambahkan satu kalimat tentang apa yang sudah Anda coba agar tidak mengirim Anda berputar-putar. Ulangi batasan yang penting ("Jangan ubah public APIs," "Pertahankan perilaku saat ini, hanya perbaiki crash"). Lalu minta patch terkecil yang membuat pemeriksaan lulus.

Prompt kegagalan yang baik mencakup:

• Output gagal persis (verbatim).
• File(s) dan baris yang terlibat.
• Apa yang Anda ubah di diff terakhir.
• Apa yang sudah Anda coba.
• Permintaan untuk patch terkecil yang membuat pemeriksaan lulus.

Jika perbaikan yang diusulkan mengubah perilaku, minta tes yang membuktikan perilaku baru itu benar. Jika sebuah handler kini mengembalikan 400 bukan 500, minta satu tes fokus yang gagal pada kode lama dan lulus pada perbaikan. Itu menjaga pekerjaan jujur dan membuat PR lebih dipercaya.

Berhenti setelah pemeriksaan hijau dan diff masih merepresentasikan satu ide. Jika model mulai memperbaiki kode yang tidak terkait, re-prompt dengan: "Hanya tangani tes yang gagal. Tidak ada pembersihan."

Buat PR mudah direview dan di-merge

PR bisa di-merge cepat ketika jelas apa yang berubah, mengapa, dan bagaimana membuktikannya bekerja. Dengan alur ini, PR harus terbaca seperti cerita pendek: langkah kecil, alasan jelas.

Samakan commit dengan iterasi Anda. Jika Anda meminta satu perubahan perilaku, buat itu satu commit. Jika lalu memperbaiki tes yang gagal, itu commit berikutnya. Reviewer bisa mengikuti jalur dan percaya Anda tidak menyelundupkan perubahan ekstra.

Tulis pesan commit untuk menjelaskan maksud, bukan nama file. "Perbaiki redirect login saat session kadaluarsa" lebih baik daripada "Update auth middleware." Saat pesan menamai hasil yang terlihat pengguna, reviewer tidak perlu menebak.

Hindari mencampur refactor dengan perubahan perilaku dalam commit yang sama. Jika ingin mengganti nama variabel atau memindahkan helper, lakukan terpisah (atau lewati dulu). Noise memperlambat review.

Di deskripsi PR, tetap singkat dan konkret:

• Apa yang berubah (1–2 kalimat).
• Mengapa berubah (bug atau kebutuhan).
• Cara mengetes (langkah tepat, termasuk flag atau data yang diperlukan).
• Apa yang tidak Anda ubah (mengatur ekspektasi).
• Risiko atau catatan rollback.

Contoh: halaman billing crash karena record customer null. Commit 1 menambah guard dan state error yang jelas. Commit 2 menambah tes untuk kasus null. Deskripsi PR: "Buka Billing, muat customer tanpa profil, konfirmasi halaman menampilkan empty state baru." Itu tipe PR yang bisa disetujui cepat.

Perangkap umum yang memperlambat

Irama ini rusak ketika scope diam-diam meluas. Prompt yang dimulai sebagai "perbaiki tes yang gagal" berubah jadi "tingkatkan error handling di seluruh modul," dan tiba-tiba Anda mereview diff besar dengan maksud yang tidak jelas. Jaga ketat: satu tujuan, satu set perubahan, satu set pemeriksaan.

Perlambatan lain adalah menerima refactor yang terlihat lebih bagus. Rename, pindah file, dan perubahan gaya menciptakan noise dan menyulitkan melihat perubahan perilaku yang nyata.

Perangkap umum:

• Membiarkan model menyentuh file tak terkait "sekalian saja."
• Memperbaiki gejala (null check tambahan) alih-alih penyebab akar yang ditunjukkan tes.
• Menempelkan hanya baris akhir log dan menyembunyikan error pertama.
• Melewatkan pemeriksaan cepat diff sebelum menjalankan tes.
• Re-prompt dengan "masih gagal" tanpa perintah dan output yang tepat.

Contoh konkret: sebuah tes gagal dengan "expected 400, got 500." Jika Anda hanya menempel bagian akhir stack trace, Anda sering mendapat saran try/catch generik. Jika Anda menempel output tes penuh, Anda mungkin melihat isu nyata: cabang validasi yang hilang. Itu mengarah ke diff kecil dan fokus.

Sebelum commit, baca diff seperti reviewer. Tanyakan: apakah setiap baris melayani permintaan, dan bisa saya jelaskan dalam satu kalimat? Jika tidak, revert perubahan ekstra dan re-prompt dengan permintaan yang lebih sempit.

Contoh: perbaikan bug jadi PR yang bisa di-merge dalam beberapa loop

Seorang pengguna melapor: "Halaman settings kadang kembali ke default setelah menyimpan." Anda tarik main, jalankan tes, dan melihat satu kegagalan. Atau tidak ada tes, hanya repro jelas.

Perlakukan ini sebagai loop: satu permintaan kecil, satu diff kecil, lalu pemeriksaan.

Pertama, berikan Claude Code konteks terkecil yang berguna: output tes yang gagal (atau langkah reproduksi), path file yang dicurigai, dan tujuan ("pertahankan perilaku kecuali perbaiki reset"). Minta diagnosis dan patch minimal, bukan refactor.

Lalu bekerja dalam loop singkat:

1. Loop 1 (patch minimal): Terapkan perubahan terkecil yang masuk akal memperbaiki bug. Jaga ketat: kondisi guard, null check yang hilang, nilai default yang salah, atau daftar dependency yang keliru.

Jalankan pemeriksaan setelah mereview diff.

2. Loop 2 (umpan balik output gagal): Jika tes gagal, salin output gagal persis kembali ke Claude Code. Sertakan nama file, nomor baris, dan pesan assert. Tanyakan: "Perubahan terkecil apa untuk memperbaiki kegagalan ini tanpa melebar?"

Jika pemeriksaan lulus tetapi Anda khawatir regresi, tambahkan coverage.

3. Loop 3 (sesuaikan tes atau tambah tes baru): Tambah tes yang gagal tanpa patch dan lulus setelah patch. Fokus pada bug itu. Jalankan pemeriksaan lagi.

Akhiri dengan deskripsi PR kecil: apa bugnya, kenapa terjadi, dan apa yang berubah. Tambahkan catatan reviewer seperti "hanya menyentuh file X" atau "menambah satu tes untuk kasus reset" agar review terasa aman.

Daftar cepat sebelum membuka PR

Tepat sebelum membuka pull request, lakukan satu pass terakhir agar pekerjaan mudah direview dan aman di-merge.

• Diff sesuai tujuan awal dan cukup kecil untuk dipahami dalam beberapa menit.
• Jalankan pemeriksaan relevan (tes, lint, typecheck, build) dan semuanya lulus. Jika tim Anda menggunakan CI, konfirmasi set pemeriksaan yang sama akan berjalan di sana.
• Perubahan punya safety net yang tepat: tes untuk bug atau fitur bila praktis, atau alasan jelas mengapa tes tidak diperlukan.
• Deskripsi PR spesifik: apa yang berubah, kenapa berubah, dan langkah tepat untuk verifikasi.
• Tidak ada edit sambil lalu: formatting tak terkait, rename style-only, atau refactor yang tidak perlu.

Contoh cepat: jika Anda memperbaiki bug login tapi juga mereformat 20 file, batalkan commit formatting. Reviewer Anda harus fokus pada perbaikan login, bukan heran apa lagi yang bergeser.

Jika ada item yang gagal, lakukan satu loop kecil lagi: buat diff kecil, jalankan pemeriksaan, dan perbarui catatan PR. Loop terakhir sering menghemat jam bolak-balik.

Langkah selanjutnya: jadikan irama ini kebiasaan

Konsistensi mengubah sesi yang baik menjadi alur yang dapat diandalkan. Pilih loop default dan jalankan dengan cara yang sama setiap kali. Setelah seminggu, prompt Anda akan lebih singkat dan diff Anda lebih mudah direview.

Rutin sederhana:

• Pilih satu hasil kecil (satu bug, satu edge case, satu fungsi).
• Minta satu diff kecil dan penjelasan singkat tentang apa yang berubah.
• Baca diff seperti reviewer, lalu jalankan pemeriksaan lokal.
• Re-prompt dengan output kegagalan yang tepat dan nama file.
• Berhenti segera setelah pemeriksaan hijau dan perubahan jelas.

Template prompt pribadi membantu Anda disiplin: "Ubah hanya yang diperlukan. Sentuh maksimal 2 file. Pertahankan perilaku publik kecuali saya katakan lain. Kasih tahu perintah yang harus dijalankan dan seperti apa suksesnya."

Jika Anda membangun di dalam Koder.ai, Anda bisa memakai loop yang sama di antarmuka chat-nya. Mode perencanaan cocok untuk merencanakan slice mergeable terkecil (input, output, dan pemeriksaan penerimaan), dan snapshot serta rollback membantu Anda cepat pulih saat eksperimen melenceng.

Setelah perubahan stabil, ekspor source code untuk menjalankan tooling lokal biasa, CI, dan review rekan seperti di repo normal Anda. Deploy saat butuh validasi di dunia nyata, misalnya mengecek alur end-to-end.

Jadikan loop ini kebiasaan. Prompt kecil, diff kecil, pemeriksaan sering, dan koreksi cepat akan menghasilkan PR yang terasa membosankan dalam arti terbaiknya.