Pair Programming dengan Claude Code: Percepat Dev Tanpa Kehilangan Kendali

Pair programming dengan Claude Code bukan berarti menyerahkan seluruh pekerjaan coding ke AI. Pola yang paling aman justru lebih terstruktur: manusia memegang tujuan, batasan, dan kriteria berhasil; Claude Code membantu membaca codebase, menyusun rencana, membuat perubahan kecil, menjalankan pengecekan, dan menyiapkan bahan review.

Dokumentasi resmi Claude Code overview menjelaskan Claude Code sebagai agentic coding tool yang bisa membaca codebase, mengedit file, menjalankan command, dan terhubung ke development tools. Kemampuan ini sangat berguna, tetapi prompt yang kabur juga bisa membuatnya bergerak cepat ke arah yang salah.

Artikel ini adalah lanjutan praktis dari panduan mulai Claude Code. Fokusnya adalah workflow yang bisa dipakai untuk bug kecil, penambahan test, refactor terbatas, dan persiapan pull request.

Tentukan peran sebelum mulai

Sebelum meminta implementasi, tentukan keputusan apa yang tetap harus dipegang manusia. Claude bisa membaca banyak file dan menulis kode cepat, tetapi tidak seharusnya mengubah niat produk, batas keamanan, atau kriteria merge tanpa persetujuan.

Area	Tanggung jawab manusia	Tanggung jawab Claude Code
Tujuan	Menentukan apa yang berubah dan tidak berubah	Mencari file dan jalur implementasi
Riset	Membatasi area yang perlu dibaca	Membaca code, test, diff, dan log
Implementasi	Menyetujui ukuran dan risiko diff	Membuat perubahan kecil dan fokus
Verifikasi	Menentukan sinyal pass atau fail	Menjalankan test, lint, build, atau screenshot
Review	Memutuskan apakah bisa merge	Menyebutkan risiko, test yang kurang, dan alternatif

Dengan pembagian ini, Claude Code menjadi rekan kerja yang produktif, bukan pengganti tanpa pengawasan. Untuk pemula, ini juga lebih mudah dipelajari. Mulai dari satu bug, satu file test, atau satu component sebelum meminta feature besar.

Siapkan repo dalam 10 menit pertama

Persiapan sering lebih menentukan daripada prompt yang terlihat canggih. Claude Code best practices menekankan pentingnya memberi Claude cara memverifikasi hasil dan memisahkan eksplorasi, planning, implementasi, dan pengecekan. Saya biasanya melakukan tiga hal.

Pertama, kerja di branch atau worktree, bukan langsung di main. Kedua, buat CLAUDE.md yang pendek. Memory documentation menjelaskan bahwa CLAUDE.md dibaca di awal session sebagai instruksi persisten. Ketiga, tulis command yang membuktikan perubahan berhasil.

# CLAUDE.md

## Project rules
- Before editing, summarize the files you plan to inspect.
- Prefer small diffs and explain risky changes before applying them.
- After code edits, run `npm run lint` and the narrowest relevant test.
- Do not read `.env*` files or change deployment settings without approval.

## Common commands
- `npm run lint`
- `npm run test`
- `npm run build`

Jangan jadikan CLAUDE.md ensiklopedia proyek. Semakin panjang file ini, semakin mudah aturan penting tenggelam. Prosedur yang berulang lebih cocok dipindahkan ke Skills, karena hanya dimuat saat diperlukan.

Gunakan loop explore, plan, implement, verify

Kesalahan umum adalah langsung meminta “implementasikan ini” sebelum Claude memahami kode yang ada. Loop yang lebih aman:

flowchart LR
  A[Jelaskan tujuan] --> B[Explore file relevan]
  B --> C[Review rencana]
  C --> D[Edit kecil]
  D --> E[Jalankan check dan baca diff]
  E --> F{Lulus?}
  F -- Tidak --> C
  F -- Ya --> G[Ringkas untuk PR]

Prompt pertama tidak perlu panjang, tetapi harus memuat tujuan, scope, larangan, dan cara verifikasi.

Tujuan: memperbaiki error 500 di halaman profile setelah login.
Scope: mulai dari `src/auth` dan `src/pages/profile`.
Jangan: mengubah strategi auth, mengubah schema DB, atau membaca `.env`.
Proses: baca file relevan, sebutkan 3 kemungkinan penyebab, lalu tampilkan rencana sebelum edit.
Verifikasi: jalankan test auth yang ada dan `npm run lint`.

Jika rencananya terlalu besar, persempit sebelum memberi izin edit.

Rencananya masuk akal, tapi tulis test reproduksi dulu.
Konfirmasi test itu gagal sebelum mengubah production code.
Setelah itu usulkan perubahan production code satu file per satu file.

Ini cocok dengan TDD, atau test-driven development. Nilainya praktis: test yang gagal membuat masalah terlihat, dan perbaikannya lebih mudah direview.

Contoh kecil yang bisa dijalankan

Untuk latihan, jangan mulai dari kode produksi. Simpan contoh ini sebagai pair-check.test.ts dan jalankan dengan Vitest.

import { describe, expect, it } from "vitest";

type ClaudeMode = "direct" | "plan-first" | "human-review";

export function decideClaudeMode(input: {
  changedFiles: number;
  touchesSecrets: boolean;
  hasReliableTests: boolean;
}): ClaudeMode {
  if (input.touchesSecrets) return "human-review";
  if (input.changedFiles > 3) return "plan-first";
  if (!input.hasReliableTests) return "plan-first";
  return "direct";
}

describe("decideClaudeMode", () => {
  it("allows direct work for small, well-tested changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("direct");
  });

  it("requires a plan for broad changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 5,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("plan-first");
  });

  it("requires human review for secret-related work", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: true,
        hasReliableTests: true,
      }),
    ).toBe("human-review");
  });
});

npm install -D vitest typescript
npx vitest run pair-check.test.ts

Lalu minta Claude Code menambahkan aturan: “jika menyentuh billing, wajib human-review.” Minta ia menambah test dulu, memastikan test gagal, menerapkan rule, lalu menjalankan Vitest lagi. Contohnya kecil, tetapi disiplin yang dilatih sama dengan saat mengubah API handler, React component, atau migration script.

Empat use case yang efektif

Use case pertama adalah menambahkan kondisi kecil ke feature yang sudah ada, misalnya “sembunyikan CSV export untuk akun free plan.” Ini memaksa pengecekan UI, permission, dan test tanpa merombak arsitektur.

Use case kedua adalah investigasi bug. Berikan error message, langkah reproduksi, dan expected behavior. Halaman resmi Common workflows juga menyarankan command reproduksi dan stack trace agar Claude menelusuri root cause, bukan menebak.

Use case ketiga adalah memperluas test. Minta Claude membaca style test yang ada, lalu tambahkan case sukses, unauthorized, input invalid, dan data kosong. Untuk pendekatan lebih sistematis, gunakan testing strategies guide.

Use case keempat adalah self-review sebelum PR. Minta Claude membaca git diff dan memprioritaskan security, backward compatibility, test yang kurang, dan naming yang membingungkan. Dokumentasi GitHub tentang pull request reviews menjelaskan bagaimana comment, approval, dan request changes menjaga kualitas. Claude Code sebaiknya menyiapkan review manusia, bukan menggantikannya.

Jebakan umum dan cara menghindarinya

Jebakan	Dampak	Kebiasaan lebih aman
“Bikin lebih bagus”	Refactor yang tidak diminta ikut masuk	Tulis scope, non-goals, acceptance criteria
Diff terlalu besar	Review lambat dan bug tersembunyi	Satu task, satu diff, satu plan
Tanpa verifikasi	Perubahan hanya terlihat selesai	Minta test, lint, build, atau screenshot
CLAUDE.md terlalu panjang	Aturan penting tenggelam	Pindahkan prosedur ke Skills
Permission terlalu luas	Secrets atau production action bisa tersentuh	Gunakan permission dan hooks

Risiko yang sering tidak terasa adalah approval fatigue. Jika semuanya minta approval, orang akan mulai klik approve tanpa membaca. Jika hampir semua diizinkan, prompt yang salah bisa berdampak terlalu jauh. Aturan praktisnya: high trust untuk pekerjaan reversible, high friction untuk pekerjaan irreversible. Untuk contoh setup, lihat approval and sandbox guide.

Ubah session menjadi PR yang mudah direview

Dalam tim, jangan biarkan konteks hanya ada di chat. Tutup session dengan ringkasan pull request.

Ringkas diff ini untuk pull request.
Sertakan:
- Alasan perubahan
- File utama yang berubah
- Command verifikasi dan hasilnya
- Risiko yang perlu dilihat reviewer
- Area yang sengaja tidak diubah

Claude bisa membuat draft, tetapi manusia tetap harus menyunting versi final. Untuk security, payments, privacy, dan penghapusan data, confidence model bukan bukti. Bukti adalah diff, output test, log, dan diskusi review.

Hasil saat workflow ini dicoba

Saat Masa memakai loop ini untuk perbaikan kecil di Next.js, review berjalan lebih cepat dibanding prompt sederhana “implementasikan ini.” Penyebabnya bukan karena Claude menulis kode sempurna, tetapi karena prompt pertama membatasi file, menyebutkan larangan, dan meminta lint plus test. Claude Code menyentuh lebih sedikit file tidak relevan dan meninggalkan hasil verifikasi di percakapan. Untuk perubahan UI dengan test lemah, review visual manusia tetap diperlukan. Kesimpulannya jelas: pair programming dengan Claude Code bukan melepas tanggung jawab, tetapi merancang batas tanggung jawab.

Untuk session berikutnya, pilih satu task kecil dan jalankan explore, plan, implement, verify. Jika tim membutuhkan prompt bersama dan standar review, lihat ClaudeCodeLab training.