Lewati ke konten utama
Versi: 1.0

Langkah 5 — Review & QA Loop

Volume kode naik berkali lipat begitu agent paralel jalan — dan kualitas jebol justru di titik ini kalau review masih 100% manual. Solusinya berlapis: CI menangkap yang mekanis, agent reviewer menangkap yang logis, kamu menangkap yang strategis.

PR dibuka
  ├─ Lapis 1: CI — test, lint, typecheck, build        (otomatis, wajib hijau)
  ├─ Lapis 2: agent reviewer — bug, edge case, desain   (otomatis, komentar di PR)
  └─ Lapis 3: kamu — checklist manusia                  (menit, bukan jam)
        └─ merge
Lapis 1 — test gate di CI

Semua yang bisa diperiksa mesin harus diperiksa mesin, di setiap PR:

.github/workflows/ci.yml
name: ci
on:
  pull_request:
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: {node-version: 22, cache: npm}
      - run: npm ci
      - run: npm run check   # lint + format + typecheck
      - run: npm test
      - run: npm run build

Pastikan job ini terdaftar sebagai required status check di branch protection (Langkah 1).

Checkpoint: PR dengan test gagal tidak bisa di-merge, bahkan olehmu sendiri.

Lapis 2 — agent me-review agent

Kuncinya: reviewer harus sesi terpisah dengan konteks bersih — bukan agent yang menulis kodenya (dia akan membela pekerjaannya sendiri). Dua cara:

Cara cepat (manual trigger dari terminal/Telegram):

cd <REPO> && git fetch origin
claude -p "Review PR #42 (jalankan: gh pr diff 42). Fokus: bug nyata, \
edge case yang tidak di-test, pelanggaran aturan AGENTS.md, masalah keamanan. \
Jangan komentari gaya. Tulis temuan sebagai komentar review via gh."

Claude Code juga punya perintah bawaan /code-review untuk me-review diff/PR langsung.

Cara otomatis (setiap PR): pasang reviewer di CI — mis. Claude Code GitHub Action yang me-review setiap PR atau merespons mention @claude, atau job serupa dengan tool pilihanmu.

Lalu tutup loop-nya: temuan reviewer dikembalikan ke agent penulis di worktree-nya — "perbaiki temuan review di PR #42" — sampai reviewer tidak menemukan masalah baru.

Checkpoint: satu PR melewati siklus penuh tulis → review otomatis → perbaikan → review bersih, tanpa kamu membaca kode sekalipun (kamu baru membaca di lapis 3).

Lapis 3 — checklist manusia (yang tidak boleh didelegasikan)

Waktumu sekarang terkonsentrasi di pertanyaan yang agent paling buruk menjawabnya sendiri:

  • Apakah ini menyelesaikan masalah yang benar? Kesesuaian dengan intensi task — bukan sekadar kriteria tertulis.
  • Keamanan & data: perubahan pada auth, kripto, penanganan uang/PII, query yang menyentuh data produksi — selalu baca barisnya satu per satu.
  • Irreversibilitas: migrasi DB destruktif, perubahan API publik, format data yang dipersist.
  • Ketergantungan baru: package baru = permukaan serangan & maintenance baru. Kenapa perlu?
  • Diff yang mencurigakan besar: kalau task kecil menghasilkan diff 40 file, tolak dan minta dipecah — jangan dipaksa baca.

Sisanya (gaya, penamaan, struktur test) sudah ditangani lapis 1–2; latih dirimu untuk tidak mengulang pekerjaan mesin.

Checkpoint: review manusia per PR turun ke ± 5–10 menit untuk PR rutin, tanpa insiden kualitas baru.

Ukur kebocoran, kencangkan sistem

Sekali seminggu, tanya: bug apa yang lolos sampai main (atau production) minggu ini, dan lapis mana yang seharusnya menangkapnya?

  • Lolos karena tidak ada test → tambah aturan "wajib test untuk X" di AGENTS.md / CI.
  • Lolos karena reviewer tidak melihat → pertajam prompt reviewer dengan kelas bug itu.
  • Lolos karena kamu skip lapis 3 pada PR sensitif → perjelas definisi "PR sensitif".

Kelas bug yang sama tidak boleh lolos dua kali — itu definisi sistem yang belajar.

Checkpoint: ada catatan (issue/nota) berisi minimal satu perbaikan sistemik hasil retro minggu ini.

Selanjutnya: Langkah 6 — Deploy ke Production

Diperbaharui pada