Gunakan OpenCode sebagai reviewer kedua yang membaca diff hasil Antigravity secara read-only. Fokusnya bukan mengganti tool utama, tapi menambah sudut pandang independen sebelum kamu menerima perubahan.
30m bacaanKuis WajibMicro Badge Lesson
OpenCode sebagai Reviewer Kedua
Di materi utama, Google Antigravity menjadi tool utama. Ia membantu membangun halaman campaign, flow donasi, verifikasi, laporan transparansi, sampai launch checklist.
Tapi ada satu masalah yang sering tidak terasa: agent yang menulis kode biasanya kurang ideal menjadi satu-satunya reviewer untuk kodenya sendiri.
Bukan karena agent “jahat”. Masalahnya lebih sederhana: konteksnya sama. Ia tahu niat perubahan yang ia buat, lalu cenderung melihat perubahan itu sebagai masuk akal. Kamu tetap harus baca diff sendiri, tapi ada situasi di mana reviewer kedua membantu.
Di sinilah OpenCode masuk sebagai bonus: bukan untuk mengganti Antigravity sebagai penulis utama, tapi untuk membaca diff sebagai pihak kedua.
Posisi OpenCode dalam workflow
Gunakan pembagian peran seperti ini:
text
Antigravity → penulis utama fiturKamu → pemilik keputusan dan verifikasiOpenCode → reviewer kedua untuk diff/test tertentu
Jangan campur perannya.
Kalau Antigravity menulis fitur, lalu OpenCode ikut menulis ulang fitur yang sama, kamu punya dua penulis yang bisa saling bertabrakan. Untuk pemula, itu membuat project sulit dipahami.
Lebih aman:
text
Antigravity mengubah kodeOpenCode membaca dan memberi temuanKamu memutuskan terima/revisi/revert
Unit review terbaik adalah diff kecil
OpenCode jangan langsung diminta “review seluruh project”. Itu terlalu luas.
Unit yang bagus:
bash
git statusgit diff
Diff yang belum di-commit adalah potongan kerja yang jelas. Kamu bisa melihat:
file apa yang berubah;
apakah perubahan sesuai scope;
apakah ada file nyasar;
apakah ada logic yang terlalu lebar;
apakah ada risiko regresi.
Contoh kondisi yang cocok direview:
text
Antigravity baru memperbaiki confirmation page agar token salah menghasilkan notFound().Sebelum commit, minta OpenCode review diff itu secara read-only.
Kondisi yang tidak cocok:
text
Review semua folder src dan kasih tahu semua masalah.
Itu akan menghasilkan laporan panjang yang sulit dipakai.
Jalankan OpenCode secara read-only
Di terminal, cara umum memakai OpenCode adalah lewat opencode run. Model dan konfigurasi bisa berbeda per mesin, jadi cek dokumentasi/CLI lokalmu. Jika perlu melihat model yang tersedia:
bash
opencode models
Untuk task pendek, opencode run bersifat single-shot: ia menjawab satu prompt lalu selesai. Karena itu, prompt review harus sempit.
Contoh:
bash
opencode run "Review git diff saat ini sebagai reviewer kedua. Jangan ubah file apa pun. Laporkan temuan dengan file/baris, risiko, dan keputusan SETUJU/SETUJU DENGAN CATATAN/TOLAK."
Kalau kamu memakai flag file/context, pastikan mengikuti format CLI yang benar di mesinmu. Prinsipnya tetap: review diff, bukan menulis fitur.
Prompt review yang aman
Pakai prompt seperti ini:
text
Kamu reviewer kedua untuk Platform Donasi Amanah.Mode: read-only.Jangan mengubah file. Jangan menjalankan migration, seed, commit, formatter, atau auto-fix.Tugas:1. Jalankan git status dan git diff untuk membaca perubahan terakhir.2. Review hanya diff yang belum di-commit.3. Nilai terhadap: - perubahan sesuai scope; - tidak ada file di luar scope; - tidak ada secret/PII yang terbuka; - tidak ada perubahan status donasi yang melanggar rules; - tidak ada regresi obvious pada route, RLS, atau validation.4. Jangan memperbaiki. Laporkan saja.Format laporan:- Ringkasan diff- Temuan P0/P1/P2 dengan file/baris- Hal yang sudah baik- Keputusan: SETUJU / SETUJU DENGAN CATATAN / TOLAK- Konfirmasi bahwa kamu tidak menulis file apa pun
Perhatikan: prompt ini tidak meminta OpenCode “lebih pintar”. Ia memberi peran yang sempit.
Cara menilai hasil review
Kalau OpenCode memberi SETUJU, jangan langsung commit. Cocokkan dulu dengan diff kamu sendiri.
git status --short: melihat file baru/terhapus yang mungkin tidak kamu sadari.
Kalau OpenCode bilang “tidak ada file di luar scope”, tapi git diff --stat menunjukkan file lain ikut berubah, percaya command-mu. Agent reviewer juga bisa salah.
Setelah review, pastikan OpenCode tidak mengubah file
Karena mode yang kamu minta read-only, bukti paling sederhana:
bash
git status --short
Bandingkan sebelum dan sesudah review. Harusnya tidak ada perubahan baru akibat OpenCode.
Kalau ada file baru dari review, berarti prompt atau setup kurang terkunci. Jangan commit dulu. Baca file itu, hapus jika tidak dibutuhkan, lalu perbaiki SOP review.
Keputusan tetap di kamu
OpenCode bisa memberi tiga hasil:
text
SETUJUSETUJU DENGAN CATATANTOLAK
Cara menyikapinya:
Nilai
Tindakan kamu
SETUJU
Tetap jalankan verifikasi utama sebelum commit
SETUJU DENGAN CATATAN
Baca catatan, putuskan apakah masuk P0/P1/P2
TOLAK
Cari bukti; kalau benar, minta Antigravity revisi dengan error spesifik
OpenCode bukan hakim final. Ia reviewer kedua. Hakim final tetap bukti: diff, build, test, browser, SQL, dan keputusanmu.
Checkpoint
OpenCode diposisikan sebagai reviewer kedua, bukan penulis utama.
Scope review dibatasi ke diff yang belum di-commit.
Prompt review menyebut read-only dan larangan mengubah file.
Hasil review dibandingkan dengan git diff sendiri.
git status --short dicek setelah review.
Keputusan akhir tetap berdasarkan bukti, bukan klaim salah satu agent.
Kalau selama ini kamu merasa harus memilih satu tool paling hebat, bonus ini sengaja mengubah sudut pandang itu. Tool tidak perlu saling menggantikan. Yang penting, tiap tool punya peran yang jelas dalam sistem kerja kamu.
Checkpoint KuisTarget: 70%
Kuis B.1 — OpenCode sebagai Reviewer Kedua
Kuis ini wajib untuk sertifikat. Kamu tetap bisa lanjut ke pelajaran berikutnya dan mengerjakannya nanti.
