Akhir-akhir ini di X dan Discord makin banyak tulisan seperti "menggunakan Claude Code dan Codex bersama", dan karena semua orang bilang bagus, saya pun mencoba memasang dan menjalankan kedua alat itu bersama dalam satu repo selama sekitar sebulan. Saat benar-benar hendak mengadopsinya, ternyata ada banyak sekali titik keputusan: mulai dari harus setup dari mana, bagaimana membagi peran dua alat itu agar tidak saling bentrok, sampai apakah AGENTS.md dan CLAUDE.md boleh diisi dengan isi yang sama. Jadi saya merapikannya dalam bentuk kurikulum 8 bab agar orang-orang yang belum mulai karena punya kekhawatiran serupa bisa mengurangi trial and error.
Workflow dua agen ini sederhana. Jika model yang sama diminta menulis kode lalu mereview kodenya sendiri, ia cenderung menerima begitu saja asumsi yang ia buat sendiri sehingga celah mudah terlewat. Karena itu, strukturnya adalah menempatkan model lain di sampingnya sebagai reviewer advisory (bukan pemblokir). Claude Code menjadi penulis utama, Codex menjadi reviewer advisory. Yang penting bukan siapa yang lebih pintar, melainkan bahwa modelnya berbeda. Begitu keduanya dijadikan gate satu sama lain, workflow-nya akan rusak, jadi aturan terbesarnya adalah advisory sama sekali tidak boleh dijadikan pemblokir.
Latar belakang — perubahan yang saya tinjau ulang saat merapikan
• Dulu pertanyaannya: "alat coding AI mana yang paling bagus"
• Sekarang pertanyaannya: "bagaimana membagi peran dua alat atau lebih", "bagaimana menutup blind spot satu alat dengan alat lain"
• Dengan hadirnya slash command dan sub-agent di Claude Code, pemisahan review/exec di Codex, serta file konteks seperti AGENTS.md, inilah momen ketika menanamkan struktur ganda ke dalam workflow untuk pertama kalinya menjadi opsi yang realistis
Inti pola struktur ganda (bagian yang paling berkesan setelah dipakai sebulan)
• advisory sama sekali bukan pemblokir — bahkan jika Codex menemukan hal CRITICAL, push tetap lolos. Sekali diubah menjadi pemblokir, saat model down seluruh pekerjaan akan berhenti, dan satu false positive saja akan membuat pengguna mulai melewati seluruh hook dengan --no-verify
• CLAUDE.md / AGENTS.md tidak diisi dengan isi yang sama — untuk penulis, fokusnya adalah "bagaimana membuatnya"; untuk reviewer, fokusnya adalah "apa yang harus dicurigai". Jika lebih dari 80% isinya tumpang tindih, itu tanda pembagian perannya pada dasarnya belum berjalan
• codex review --base vs codex exec dibagi berdasarkan use case — review langsung membaca git sehingga rapi, tetapi pada PR besar token bisa membengkak; exec memungkinkan diff dimasukkan langsung ke prompt sehingga biaya bisa dikendalikan. Untuk perubahan lebih dari 100 file, polanya adalah beralih ke exec
• dua lapis pertahanan rahasia di pre-push hook — pola file (.env, *.pem, secrets/) membuat push dibatalkan, regex inline (sk-, ghp_, AKIA…) hanya memberi peringatan. Aturan "never block" pada advisory adalah aturan output model, sedangkan push file rahasia adalah insiden keamanan yang berbeda sehingga pemblokiran memang jawaban yang benar
• diserap dengan satu wrapper graceful degradation — JSON envelope sebagai default + --raw Markdown, timeout native bash, selalu exit 0. Pemanggil cukup bercabang berdasarkan status saja
Hal yang berubah setelah dipakai sebulan
• Bug yang tertangkap tepat sebelum merge bertambah. Cukup sering ada kasus ketika Claude dengan percaya diri merasa "ini sudah ditulis dengan baik", tetapi Codex justru menunjukkan race condition atau null check yang terlewat
• Kebiasaan membuka kembali PR keesokan harinya lalu berpikir "loh, kenapa saya menulisnya begini" hampir hilang. Karena sudah ada satu sudut pandang lain yang masuk, biaya review regresi pun berkurang
• Kelelahan self-review saat melihat kode sendiri berkurang secara nyata. Efeknya seperti menambahkan satu reviewer manusia lagi
• Pada perubahan yang sulit dibatalkan seperti SQL migrasi atau alur pembayaran, fakta bahwa ada model lain yang melihatnya sekali lagi sebelum eksekusi adalah perbedaan psikologis terbesar
Susunan kurikulum (8 bab, 5 bagian)
• Part 1 cara berpikir penggunaan dua agen · 1 bab — blind spot agen tunggal, kriteria justifikasi biaya
• Part 2 lingkungan dan konteks · 2 bab — setup dasar VSCode + Claude Code + Codex CLI, pembagian AGENTS.md vs CLAUDE.md
• Part 3 pola otomatisasi review · 3 bab — skrip wrapper advisory, pipeline multi-fase slash command, otomatisasi pre-push hook
• Part 4 panduan operasional · 1 bab — pohon keputusan pemilihan alat per jenis pekerjaan, panduan biaya dan model, bagian Security & Privacy
• Part 5 boilerplate · 1 bab — satu paket template wrapper, hook, dan CLAUDE.md/AGENTS.md yang bisa langsung dipasang di repo sendiri
Pikiran yang muncul saat merapikannya
• Nilai sebenarnya dari struktur ganda adalah bahwa "dua alat itu tidak menjadi gate satu sama lain". Jika pemblokiran sekali saja diizinkan, saat salah satu down pekerjaan akan berhenti, dan satu false positive akan membuat pengguna mulai melewati seluruh hook sehingga hook itu sendiri menjadi lumpuh
• Semakin cepat alat AI berkembang, rasanya variabel yang menentukan bukan lagi "alat apa yang dipakai", melainkan "bagaimana blind spot dari beberapa alat ditumpuk untuk saling menutupi". Strukturnya sama seperti alasan mengapa review kode manusia dilakukan oleh lebih dari satu orang
• Saya membagikan ini karena rasanya akan berguna bagi yang selama ini merasa kurang yakin mereview ulang kode sendiri saat bekerja dengan alat coding AI, atau yang terus menunda apakah perlu memasang Claude Code dan Codex bersama. Jika ada bagian yang saya pahami atau rangkum dengan keliru, beri tahu saya lewat komentar dan akan saya perbaiki.
3 komentar
Saya biasanya membuat satu skill verifikasi bernama trilateral-validation dengan menggabungkan claude subagent (fresh context)+codex+gemini lalu memakainya.
Untuk eksperimen atau desain yang bukan sekadar kesalahan kecil, tetapi memang arahannya sendiri perlu diubah, pengembangan utama saya lakukan dengan Claude, lalu saya verifikasi dengan memasang GitHub App di gpt 5.5pro. (karena codex tidak mendukung model pro...)
Karena saya hanya melakukan riset dan bukan pengembangan production, saya belum kepikiran, tapi sepertinya saya juga harus coba memasang git hook.
Katanya ada yang bekerja seperti ini, jadi saya penasaran metode seperti apa yang mereka pakai.
Apakah tanpa mengikat kedua alat itu sebagai agen terpisah, lalu developer memanggil masing-masing secara langsung setiap kali dibutuhkan,
atau mereka mengaturnya agar Codex otomatis melakukan review saat Git Hook dijalankan, itu yang ingin saya ketahui.
Kami akhirnya menetap dengan memakai keduanya.
Di dalam alur slash command, kami menyisipkan fase cross-review Codex (di dalam
/shipdengan urutan perencanaan → implementasi → verifikasi → review Codex → pelaporan), dan pada saat yang sama kami juga memasang review yang sama di pre-push hook. Kalau hanya mengandalkan slash command, saat sedang buru-buru orang bisa langsungpushsehingga review terlewat, dan kalau hanya mengandalkan hook, hasilnya baru keluar tepat sebelumpushsehingga terasa terlambat.Di kedua jalur itu, kami tidak memanggil Codex CLI secara langsung, melainkan dari kedua sisi memanggil skrip bash pembungkus yang sama,
codex-review.sh. Skrip itu menangani timeout, pemeriksaan autentikasi, pemeriksaan secret, dan format output di satu tempat, sehingga baik dari slash command maupun hook, sisi pemanggilnya tetap rapi.Kuncinya adalah kami sama sekali tidak pernah menjadikan hasil review Codex sebagai pemblokir. Walaupun CLI mati atau muncul CRITICAL,
pushtetap dibiarkan lolos dan hanya hasilnya yang ditampilkan. Kalau sekali saja dijadikan pemblokir, saat Codex keliru menandai kode yang sebenarnya tidak bermasalah, pengguna akan memakai opsi untuk melewati hook saat inginpush(git push --no-verify), dan kalau itu menjadi kebiasaan, hasilnya sama saja seperti hook terpasang tetapi tidak pernah dijalankan. Jadi, pemeriksaan yang memang perlu memblokir (lint, type, test, secret file push) kami pisahkan sebagai gate tersendiri, sementara pendapat model hanya kami jadikan referensi.Isi skrip, slash command, dan body hook dimuat apa adanya di chapter track 4–6, jadi silakan dijadikan referensi.