Claude Code vs Codex, akhirnya pilih yang mana? Solusi nyata "memakai keduanya" tanpa kecelakaan

“Jadi, akhirnya aku harus pakai yang mana?”

Claude Code dan Codex dari OpenAI. Justru orang yang sudah menyentuh keduanya pasti masih galau di pertanyaan ini. Saya pun awalnya mengira “harus memilih salah satu”.

Tapi setelah memakainya setengah tahun, jawabannya ternyata sepele. Bukan salah satu. Pakai keduanya. Cuma, bagi pekerjaan yang didelegasikan. Cuma ini.

Masalahnya bukan “mana yang lebih pintar”. Sama seperti kita tidak membandingkan mana yang lebih hebat antara pisau dapur dan gunting. Kalau sayuran, pakai pisau; kalau kertas, pakai gunting. Tiap alat punya bentuk yang dia kuasai, dan salah pakai bisa bikin jari teriris. Hari ini saya bahas “pekerjaan mana dioper ke siapa”, plus cara menatanya supaya menjalankan keduanya sekaligus pun tidak kecelakaan.

Saya tidak akan mengompori. Tidak juga menyimpulkan mana yang lebih unggul. Saya jajarkan dengan jujur ranjau-ranjau yang benar-benar saya injak saat mengoperasikan situs ini.

Pertama, dari beda watak keduanya

Perbandingan kepintaran kita sisihkan dulu, mari bicara soal watak.

Claude Code itu partner yang ikut beres-beres bareng di sampingmu, di kamar berantakan yang ada di depan mata. Ia membuka repository-mu, membaca aturan yang kamu tulis di CLAUDE.md, lalu memperbaiki secara dialog sambil menyambung konteks: “kalau yang ini dibetulkan, sekalian yang sini juga”. Ia jago menangkap seluk-beluk kode yang ada sekarang. Karena itu ia kuat di refactor proyek lama dan penyetelan halus secara lokal.

Codex lebih mirip pihak ketiga di ruang lain yang menggarap sendiri pekerjaan yang kamu titipkan. Ia cocok dengan gaya delegasi: lempar tugas lalu jalankan di sisi cloud, atau lempar Pull Request lalu masuk ke antrean review. OpenAI pun menjelaskan Codex sebagai partner yang bisa dititipi pekerjaan kode (OpenAI: Introducing Codex). Ia jago melepas tangan lalu menyerahkan.

Singkatnya, Claude Code itu “bareng di sebelah”, Codex itu “titip lalu tunggu”. Ingat perbedaan suhu ini, dan pembagian tugasnya langsung masuk dengan mulus.

Tapi, nama model, harga, dan batasan kemampuan yang saya tulis di sini cukup cepat berubah. Keduanya update-nya kencang. Jadi untuk kelebihan-kekurangan dan harga finalnya, wajib cek versi terbaru di sumber resmi (dokumentasi OpenAI dan dokumentasi Claude Code). Anggap artikel ini “peta cara berpikir” saja.

Pekerjaan mana, dioper ke yang mana?

Cuma peta saja susah dipakai, jadi saya taruh pembagian nyata versi saya. Ini cuma rasa saya saat ini, bukan jawaban mutlak.

Yang ingin dikerjakan	Penanggung jawab utama	Kenapa
Refactor rumit di repository lama	Claude Code	Membaca konteks sekitar dan menghindari kecelakaan beruntun
Desain dan penyetelan sambil dialog secara lokal	Claude Code	Bolak-balik “eh, ubah jadi begini” lebih cepat
Delegasi tugas independen yang bisa dipisah jelas	Codex	Lempar lalu pindah ke pekerjaan lain
Membuat PR lalu masuk ke review	Codex	Mengalir mengikuti alur delegasi + review
Kepatuhan pada aturan khas proyek	Claude Code	Membaca CLAUDE.md dan menerapkannya dengan baik
Menjalankan banyak tugas secara paralel	Keduanya	Satu untuk dialog, satu untuk delegasi, jadi tidak mampet

Poinnya ada di baris terakhir. Bukan dua pilihan, tapi pembagian peran. Saya akhirnya menetap di gaya dua pedang: menggali desain di depan layar bersama Claude Code, sambil melempar tugas-tugas remeh yang bisa dipisah ke Codex agar digarap di ruang sebelah.

Dan ini inti pembahasannya. Mau pakai yang mana pun, cara berpikir alat pengamannya sama. Daripada memilih AI yang pintar, lebih dulu buat penataan yang tidak melukai saat terjatuh. Ini saya sebut “harness = pijakan dan tali pengaman AI”. Yang ingin paham dari konsepnya, silakan ke Panduan lengkap harness engineering.

Pijakan ini lebih mudah dirapikan kalau dipikir dalam 4 lapisan. Tidak susah, kok.

Permintaanmu
  ↓
AI (Claude Code / Codex)
  ↓
[1] Lapisan izin    Apa yang disuruh kerjakan, apa yang dihentikan
[2] Lapisan alur    Dengan urutan apa dikerjakan
[3] Lapisan verif.  Setelah selesai, dengan apa "OK" dipastikan
[4] Lapisan pulih   Kalau gagal, bagaimana mengembalikannya
  ↓
File / Shell / Layanan eksternal / Deploy

Kalau 4 hal ini bolong, baik di Claude Code maupun Codex, umumnya terjatuh di tempat yang kira-kira sama.

Situasi di mana “memakai keduanya” ampuh (3 contoh)

1. Desain pakai Claude Code, produksi massal pakai Codex

Pekerjaan yang butuh “bolak-balik” seperti desain data fitur baru, saya gali di depan layar bersama Claude Code. Setelah ditentukan, pekerjaan sederhana macam “8 file lagi dengan bentuk yang sama” saya pisah lalu lempar ke Codex. Waktu pakai otak dan waktu sekadar menunggu jadi terpisah rapi.

2. Inti pakai Claude Code, review pakai Codex

Kode yang saya tulis bareng Claude Code, kadang ingin dilihat oleh mata yang lain, kan? Maka saya putar review PR ke Codex. Dibanding AI yang sama yang menulis lalu mereview, sudut pandangnya bergeser, dan temuannya bertambah. Lumayan jadi “saringan tahap pertama” sebelum review manusia.

3. Operasi berbahaya, di yang mana pun, manusia yang menekan terakhir

Ini yang paling penting. Deploy, update DB produksi, kirim email, git push, npm publish. Khusus “operasi yang tidak bisa diralat” semacam ini, baik di Claude Code maupun Codex, di akhir manusia yang menekan tombol. Pembuatan dan draf boleh otomatis. Tapi operasi yang terbang keluar, hentikan. Kalau dipaksakan dari sisi pijakan, tidak akan kecelakaan tengah malam.

Penarikan garis izin, kalau disimpan dalam file seperti ini, tidak akan bingung. Untuk Claude Code, bisa ditulis di .claude/settings.json.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(node scripts/content-trend-report.mjs *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Triknya, jangan menulis larangan dengan “kayaknya bahaya nih”. rm -rf, git reset --hard, pembacaan .env, jenis deploy produksi. Tulis dengan nama command yang spesifik. Cara menyusunnya lebih detail, Claude Code settings adalah pintu masuknya. Praktik Approval/Sandbox saya rangkum di Panduan setelan Approval/Sandbox.

Di sisi Codex pun ada gagasan yang sama. Lewat sandbox (ruang kerja terisolasi) dan approval (persetujuan), ia memisah “sampai sini boleh jalan sendiri, mulai sini tanya manusia”. Nama setelannya beda, tapi yang ingin dicapai sama. Sekali kamu menguasai cara berpikir harness, ganti alat pun tetap bisa diterapkan.

Tiga kesalahan yang pernah saya bikin

Saya tulis jujur saja. Memakai keduanya, di awal cukup sering kecelakaan.

Yang pertama. Menyerahkan pekerjaan yang sama ke keduanya, lalu jadi perang saling menimpa. File yang sedang saya perbaiki di Claude Code, saya lempar juga ke Codex dengan “betulkan yang ini”. Tentu saja, perubahan satu pihak tertimpa pihak lain, dan saya tak tahu lagi mana yang benar. Sekarang saya pisah jangkauannya: “file ini sekarang di sisi Claude Code”. Jangan pakai satu talenan berdua bersamaan. Sebenarnya hal biasa, sih.

Yang kedua. Tugas yang dilempar ke Codex terlalu kabur. Melempar permintaan bergantung konteks macam “betulkan yang bener ya” ke sisi delegasi, hasilnya tidak akan bagus. Delegasi itu seperti memberi ke pihak ketiga, jadi prinsipnya: potong dulu jadi bentuk yang tuntas secara mandiri baru diserahkan. Sebaliknya, pekerjaan yang butuh konteks jangan dipaksa didelegasikan, gali lewat dialog bersama Claude Code. Bentuk permintaan itulah yang menentukan pilihan alat.

Yang ketiga. Saya jalankan dengan “toh nanti aku yang cek”, lalu ambruk di hari sibuk. Pernah URL publik tetap 404, tag iklan tetap hilang, tanpa saya sadari semuanya jalan terus. Pengecekan manual pasti dilewat saat sibuk. Maka pengecekan yang bisa dilakukan mesin, suruh mesin yang kerjakan. Misalnya, untuk memeriksa apakah halaman publik hidup, saya buat skrip kecil seperti ini.

// scripts/verify-published-page.mjs
const url = process.argv[2];

if (!url) {
  throw new Error("Cara pakai: node scripts/verify-published-page.mjs <url>");
}

const response = await fetch(url, { redirect: "follow" });
if (!response.ok) {
  throw new Error(`Halaman mengembalikan ${response.status}: ${url}`);
}

const html = await response.text();
const checks = [
  ["title", /<title>.+<\/title>/i],
  ["description", /<meta name="description"/i],
  ["main content", /<article|data-pagefind-body|blog-post/i],
];

for (const [name, pattern] of checks) {
  if (!pattern.test(html)) {
    throw new Error(`${name} hilang di ${url}`);
  }
}

console.log(`OK: ${url}`);

Ini bukan verifikasi sempurna. Tapi kecelakaan konyol macam “merasa sudah publikasi padahal 404” atau “tag penting hilang”, terhenti oleh ini. AI cenderung cuma melihat baris terakhir log kegagalan lalu memperbaiki hal yang meleset, jadi menentukan dengan apa baru dianggap OK lebih dulu dalam kode itu ampuh.

Kalau mau mulai, mulailah dari sini

Jangan langsung menyusun dua pedang yang sepenuhnya otomatis. Ada urutannya.

Pertama, bagi satu pekerjaan hari ini ke sisi yang pakai otak dan sisi yang bisa ditunggu. Bagian yang butuh keputusan, lewat dialog bersama Claude Code. Pekerjaan sederhana yang bisa dipisah, delegasikan ke Codex. Cuma dengan ini, kecepatan yang terasa langsung berubah.

Berikutnya, jatuhkan semua operasi berbahaya ke “tanya manusia (ask)”. Deploy, push, kirim, DB produksi—di awal tanpa tawar-menawar masuk antrean persetujuan. Hanya yang sudah terbukti aman yang nanti dinaikkan ke otomatis. Melebarkan nanti saja. Di awal, sempit dulu.

Lalu, kalau punya satu template permintaan yang bisa langsung diserahkan, tiap kali jadi tidak goyah. Ini template saya saat mendelegasikan ke Codex. Tinggal copas dan isi bagiannya.

# Tugas (dalam satuan yang tuntas secara mandiri)
<contoh: tambahkan unit test untuk fungsi format tanggal di bawah src/utils/>

# Jangkauan yang boleh disentuh
- Boleh sentuh: <contoh: hanya src/utils/date.ts dan tests/date.test.ts>
- Jangan sentuh: <contoh: file selain di atas. Jangan baca file konfigurasi atau .env>

# Syarat selesai (ini yang dijadikan patokan OK)
- npm run test lolos semua
- Jangan ubah signature fungsi yang sudah ada
- Selain file baru, buat diff seminimal mungkin

# Yang tidak boleh dilakukan
- Jangan git push (cukup sampai menyodorkan PR/diff)
- Jangan menambah paket dependensi seenaknya
- Jangan lakukan operasi jenis produksi, deploy, atau kirim sama sekali

Yang jadi kunci adalah menuliskan “jangkauan yang jangan disentuh” dan “yang tidak boleh dilakukan” secara hitam di atas putih. AI sisi delegasi kadang sok pengertian lalu menyentuh tempat yang tak perlu, jadi pagari dari awal. Ini sekaligus jadi penangkal kecelakaan di mana instruksi dari dokumen eksternal disalahartikan sebagai perintah kerja (Prompt Injection). Cara menghindari permintaan berbahaya semacam ini saya tulis detail di Cek praktis menghindari prompt berbahaya.

Hasil setelah saya coba sendiri

Ini kesimpulan setelah setengah tahun memakai keduanya untuk mengoperasikan situs ini.

Yang efeknya paling besar, di luar dugaan, bukan “aturan larangan” melainkan “batas yang disisakan di ask”. Draf artikel, terjemahan, dan menelurkan ide refactor, mau di Claude Code maupun Codex, jarang bermasalah meski diotomatiskan. Tapi khusus deploy, git push, kirim email, dan update URL produksi, sisakan konfirmasi manusia. Cuma dengan mati-matian menjaga ini, jumlah momen jantung berhenti turun drastis.

Sebaliknya, yang jelas-jelas gagal adalah cara menjejalkan seluruh prosedur ke dalam prompt panjang. Saat saya serakah ingin menyuruh semuanya sekali jalan, sesi jadi berat dan gampang berhenti di tengah. Buat instruksi pendek, lalu pindahkan aturan eksekusi ke sisi pijakan (settings atau garis persetujuan). Cara ini jauh lebih bisa diulang hasilnya.

Dan rasa dari pembagian tugasnya. Melepas “memilih salah satu” itulah yang paling ampuh. Seperti memegang pisau dan gunting sekaligus, saya gerakkan sisi sebelah dengan Claude Code dan ruang lain dengan Codex secara bersamaan. Rasa “otak cuma satu tapi pekerjaan jalan dua kali lipat” itu, sekali dirasakan, sulit untuk kembali. Tapi sekali lagi, kelebihan, harga, dan model keduanya update-nya kencang, jadi sebelum benar-benar berinvestasi, cek versi terbaru di sumber resmi ya.

Penutup

Jawaban saya untuk “Claude Code dan Codex, yang mana?” adalah “Keduanya. Cuma, bagi pekerjaan yang didelegasikan dan operasi yang dihentikan.”

• Kalau memperbaiki bareng di sebelah pakai Claude Code, kalau titip lalu tunggu pakai Codex
• Pekerjaan yang butuh konteks lewat dialog, pekerjaan yang bisa dipisah lewat delegasi
• Pakai yang mana pun, cara berpikir alat pengaman (izin, alur, verifikasi, pemulihan) sama
• Operasi berbahaya (deploy, kirim, DB produksi), di akhir manusia yang menekan

Coba ubah waktu yang habis untuk galau memilih alat menjadi waktu membuat satu pijakan. Kualitas pekerjaan ditentukan bukan oleh AI mana yang lebih pintar, melainkan oleh cara penataan di sisi luarnya.

Kalau ingin menata desain izin, CI, sampai aturan operasional tim sekaligus, saya rangkum template yang bisa langsung dipakai di daftar materi. Kalau ingin didampingi sesuai repository perusahaanmu, silakan dari pelatihan dan konsultasi.