Ada momen kecil yang mengubah cara saya bekerja. Suatu malam, alih-alih membuka sepuluh file untuk melacak sebuah bug, saya mengetik satu kalimat di terminal: "cari kenapa total keranjang kadang salah saat diskon dan kupon dipakai bersamaan." Beberapa detik kemudian, agen itu membaca kode, menunjukkan baris yang keliru, menjelaskan sebabnya, menulis perbaikan sekaligus test-nya, lalu menjalankan test itu di depan mata saya. Yang biasanya makan satu jam, selesai dalam hitungan menit.

Buku ini tentang alat yang membuat momen itu mungkin: OpenAI Codex — sebuah AI coding agent yang hidup di terminal Anda. Codex bukan tombol ajaib dan bukan pengganti pemahaman Anda. Ia adalah rekan kerja yang sangat cepat: mampu membaca basis kode, menyusun rencana, memakai alat, membuat perubahan, menjalankan perintah, dan menjelaskan temuannya — selama Anda memberinya konteks, batas, dan standar verifikasi yang jelas.

Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.

Linus Torvalds

Saya menulis buku ini untuk semua level. Jika Anda belum pernah menyentuh coding agent, bab-bab awal memandu dari nol: apa itu, cara memasang, dan bagaimana alur dasarnya. Jika Anda sudah terbiasa, bab-bab tengah dan akhir menawarkan pola kerja nyata, prompt siap salin, strategi keamanan, dan perbandingan jujur dengan alat lain. Dan karena kita hidup di zaman ketika mesin pun membaca dokumen, ada satu bab khusus — Cara Dibaca AI — yang membuat buku ini ramah bagi manusia sekaligus model bahasa yang mungkin meringkasnya untuk Anda.

Buku ini bisa dibaca berurutan atau dilompati sesuai kebutuhan. Berikut peta besarnya agar Anda tahu di mana berada.

Struktur buku

• Bab 1–3 — Fondasi. Apa itu Codex, cara memasang, dan alur kerja dasar. Wajib bagi pemula.
• Bab 4–5 — Kendali & Konteks. Mode persetujuan, sandbox keamanan, dan cara memberi proyek Anda "ingatan" lewat AGENTS.md. Ini jantung pemakaian yang aman.
• Bab 6–8 — Kerja Nyata. Bikin fitur, perbaiki bug, refactor, test, migrasi, alur Git, dan menjalankan perintah terminal dengan aman.
• Bab 9–11 — Mahir. Pustaka prompt siap salin, tips & jebakan, biaya/token, dan perbandingan dengan alat lain.
• Bab 12–13 — Penutup. Cara dibaca AI, FAQ, glosarium, dan checklist.

Rambu-rambu di dalam teks

Beberapa elemen visual berulang sepanjang buku. Kenali artinya sekali, lalu Anda akan membacanya dengan cepat:

Anda juga akan sering menemukan "screenshot terminal" — mockup jendela terminal yang meniru sesi Codex sungguhan, lengkap dengan perintah dan keluaran berwarna. Ini menggantikan tangkapan layar biasa agar tetap tajam di layar apa pun dan bisa dicetak. Di beberapa tempat, ada komponen interaktif (pemilih mode persetujuan dan cheatsheet klik-untuk-salin) yang hanya berfungsi saat dibuka di peramban.

Peta perjalanan: jalur baca sesuai kebutuhan

Tidak semua pembaca butuh semuanya sekaligus. Pilih jalur yang cocok dengan situasi Anda hari ini, lalu kembali untuk sisanya nanti.

Berapa pun jalur yang Anda pilih, satu benang merah mengikat semuanya: konteks, batas, dan verifikasi. Itulah tiga kata yang, kalau Anda ingat hanya itu dari buku ini, sudah cukup membuat Anda memakai Codex dengan aman dan efektif.

Bayangkan perbedaan antara sebuah kamus dan seorang penerjemah. Kamus memberi Anda kata yang tepat saat Anda menunjuknya; penerjemah memahami maksud Anda, menyusun kalimat utuh, lalu memeriksa apakah pesannya sampai. Perbedaan itulah yang memisahkan autocomplete dari sebuah coding agent. Codex ada di kubu penerjemah.

OpenAI Codex adalah agen pemrograman berbasis AI. Dalam buku ini, fokus kita adalah Codex CLI — versi yang berjalan di terminal, bersifat sumber terbuka (open source), dan bekerja langsung di dalam folder proyek Anda. Alih-alih hanya menyarankan baris berikutnya, Codex dapat menelusuri banyak file, memahami arsitektur, menulis dan mengubah kode, menjalankan perintah seperti test dan linter, membaca hasilnya, lalu memperbaiki diri — semua dalam satu percakapan.

Agent vs Autocomplete: apa bedanya?

Autocomplete (seperti saran inline di editor) hebat untuk melengkapi satu baris atau satu fungsi yang sedang Anda ketik. Ia reaktif, lokal, dan tidak punya rencana. Sebuah agent berbeda pada empat sumbu:

Keduanya bukan saingan; mereka saling melengkapi. Autocomplete mempercepat pengetikan; agent mempercepat penyelesaian tugas. Nilai terbesar Codex bukan sekadar menulis baris kode, melainkan memperpendek jarak dari pertanyaan ke bukti.

Anatomi sebuah coding agent

Di balik layar, Codex bekerja dalam sebuah lingkaran (agentic loop). Memahami lingkaran ini membuat Anda tahu kapan agen sedang "berpikir", kapan ia butuh izin, dan mengapa ia kadang salah arah.

1. Persepsi. Membaca prompt Anda, file yang relevan, dan konteks proyek (termasuk AGENTS.md).
2. Rencana. Menyusun langkah: file mana yang disentuh, perintah apa yang dijalankan, urutannya.
3. Aksi. Memanggil alat — membaca/menulis file, menjalankan perintah shell, memakai git.
4. Observasi. Membaca hasil aksi: keluaran test, pesan error, diff.
5. Refleksi. Menilai apakah tujuan tercapai; jika belum, kembali ke langkah 2.

Apa yang bisa dan tidak bisa dilakukan Codex

Sekilas sejarah: dari saran kode ke agen

Nama "Codex" punya sejarah berlapis di OpenAI. Awalnya ia adalah model yang dilatih khusus untuk kode dan menjadi mesin di balik generasi awal asisten pemrograman — era ketika bantuan AI berarti "melengkapi baris berikutnya". Seiring model menjadi jauh lebih mampu bernalar dan memakai alat, gagasannya bergeser: bukan lagi sekadar menyarankan teks, tetapi bertindak — membaca, mengubah, menjalankan, dan memeriksa.

Codex CLI adalah wujud gagasan itu di terminal: sebuah program sumber terbuka yang membungkus kemampuan model menjadi agen yang bekerja di dalam proyek Anda. Detail teknis dan nama model yang menyalakannya terus berganti, tetapi arah besarnya jelas dan konsisten — dari autocomplete menuju otonomi yang terkendali.

Mengapa terminal?

Anda mungkin bertanya: kenapa agen di terminal, bukan di editor grafis yang cantik? Terminal punya kelebihan yang tak selalu terlihat. Ia ada di mana-mana — di laptop, server, container, maupun sesi SSH jarak jauh. Ia mudah diotomatiskan — bisa dipanggil dari skrip dan pipeline CI. Dan ia dekat dengan alat sejati: git, test runner, compiler, dan shell hidup di sana. Bagi banyak engineer, terminal bukan tempat kerja darurat, melainkan rumah. Codex datang ke rumah itu.

Memasang Codex sesungguhnya cepat — lebih lama membaca bab ini daripada menjalankannya. Yang penting bukan sekadar "berhasil terpasang", melainkan memahami apa yang Anda pasang, cara Codex mengenali Anda, dan bagaimana memastikan lingkungan siap sebelum menyuruhnya bekerja.

Syarat sistem

Codex CLI ringan, tetapi ada beberapa prasyarat. Anggap daftar ini sebagai titik awal dan cek dokumentasi resmi untuk angka versi terbaru.

Memasang Codex

Cara paling umum adalah lewat npm sebagai paket global. Di macOS, banyak orang juga memakai Homebrew. Berikut dua jalur yang lazim:

# Jalur 1 — npm (lintas platform)
npm install -g @openai/codex

# Jalur 2 — Homebrew (macOS)
brew install codex

# Verifikasi instalasi
codex --version

Nama paket resmi bisa berbeda dari contoh di atas seiring waktu. Jika perintah gagal, jangan menebak — buka dokumentasi resmi dan salin perintah instalasi yang tertera di sana.

Login & API key: dua jalur otentikasi

Agar Codex bisa memanggil model, ia perlu mengenali Anda. Ada dua cara umum, dan Anda memilih salah satu:

Jalur A — Login dengan akun ChatGPT

Menjalankan codex login akan membuka peramban untuk masuk dengan akun ChatGPT Anda. Cara ini menyenangkan karena pemakaian dihitung dari langganan Anda, bukan tagihan API terpisah. Ketersediaan bergantung pada paket (mis. Plus/Pro/Team/Enterprise) dan bisa berubah.

Jalur B — API key

Alternatifnya, gunakan API key dari platform OpenAI. Cara ini menagih pemakaian ke akun API Anda (bayar per token) dan cocok untuk otomatisasi, CI, atau server tanpa peramban.

# Set API key sebagai environment variable
export OPENAI_API_KEY="sk-..."

# Atau simpan di file konfigurasi ~/.codex/ sesuai dokumentasi resmi

Controlling complexity is the essence of computer programming.

Brian Kernighan

Konfigurasi: file config & direktori kerja

Codex menyimpan pengaturan dan kredensial di direktori ~/.codex/ (di home Anda). Di sana biasanya ada berkas konfigurasi — sering berformat config.toml — tempat Anda menetapkan model default, mode persetujuan default, dan preferensi lain. Struktur pastinya bisa berubah, jadi rujuk dokumentasi resmi.

# Contoh ilustratif ~/.codex/config.toml
# (nama field bisa berbeda — verifikasi ke dokumentasi resmi)
model = "gpt-5-codex"
approval_policy = "on-request"

[sandbox]
mode = "workspace-write"

Menjalankan Codex pertama kali

Setelah terpasang dan login, masuklah ke folder proyek Anda dan jalankan codex. Anda akan disambut antarmuka TUI (text user interface) interaktif — sebuah kotak percakapan di dalam terminal.

Masalah instalasi yang umum

Sebagian besar hambatan instalasi berpola sama. Berikut peta cepat gejala dan penawarnya:

Memperbarui & mencopot

Karena Codex berkembang cepat, biasakan memperbaruinya berkala. Bila terpasang lewat npm, perbarui dengan perintah instalasi yang sama, dan copot bila perlu:

# Perbarui ke versi terbaru
npm install -g @openai/codex@latest

# Copot
npm uninstall -g @openai/codex

Begitu Codex terbuka, Anda berhadapan dengan hal yang tampak sederhana: sebuah baris untuk mengetik. Namun di baliknya ada siklus kerja yang, sekali Anda pahami iramanya, akan terasa alami seperti berbincang dengan rekan sebelah meja. Bab ini mengajarkan irama itu.

Siklus: prompt → rencana → diff → jalankan

Hampir setiap interaksi produktif dengan Codex mengikuti empat gerakan. Anda tidak perlu menghafalnya; ia akan mengalir sendiri. Tapi menamainya membantu Anda tahu di mana harus menyela.

1. Prompt. Anda menyampaikan tujuan dalam bahasa biasa. Semakin jelas hasil yang diinginkan dan batasnya, semakin sedikit Codex menebak.
2. Rencana. Codex membaca proyek dan menjelaskan apa yang akan ia lakukan: file mana, langkah apa. Di sinilah Anda mengoreksi arah jika perlu.
3. Diff. Codex mengusulkan perubahan sebagai diff — baris hijau ditambah, baris merah dihapus. Anda meninjau sebelum menyetujui.
4. Jalankan. Codex (atau Anda) menjalankan test/build untuk membuktikan perubahan bekerja. Jika gagal, lingkaran berlanjut.

Berikut satu sesi utuh yang menampilkan keempat gerakan itu sekaligus — sebuah permintaan kecil dari prompt sampai test hijau.

Dua cara memakai: interaktif vs sekali jalan

Codex bisa dipakai dalam dua gaya:

• Interaktif (TUI). Ketik codex lalu berdialog. Cocok untuk eksplorasi, tugas bertahap, dan saat Anda ingin meninjau tiap langkah.
• Sekali jalan (non-interaktif). Berikan tugas langsung sebagai argumen, mis. codex exec "...". Cocok untuk skrip, CI, atau tugas yang sudah jelas. Nama sub-perintah pastinya — verifikasi ke dokumentasi resmi.

Perintah dalam sesi (slash commands)

Di dalam TUI, ketik garis miring / untuk memunculkan perintah bawaan. Ini mempercepat hal-hal umum tanpa keluar dari sesi.

Cheatsheet perintah (klik untuk menyalin)

Berikut kumpulan perintah yang paling sering dipakai. Klik kartu mana pun untuk menyalin perintahnya ke clipboard — praktis saat Anda ingin langsung mencobanya di terminal. (Fitur salin bekerja saat halaman dibuka di peramban.)

Sepuluh menit pertama Anda

Teori paling melekat saat langsung dipraktikkan. Berikut sesi latihan singkat yang bisa Anda tiru pada proyek apa pun. Tujuannya bukan menyelesaikan sesuatu yang besar, melainkan merasakan iramanya dengan aman.

1. Buka di repo bersih. Masuk ke folder proyek dan pastikan git status bersih.
2. Mulai read-only. Minta penjelasan tanpa perubahan — cara teraman berkenalan.
3. Minta rencana kecil. Pilih perbaikan sepele, minta rencananya dulu.
4. Setujui & verifikasi. Terapkan, jalankan test, baca diff.
5. Batalkan. Karena ini latihan, kembalikan dengan git restore untuk merasa nyaman bahwa semua bisa dibatalkan.

Inilah bab paling penting soal keamanan. Sebuah agen yang bisa mengedit file dan menjalankan perintah adalah alat yang ampuh — dan alat ampuh perlu rem. Codex memberi Anda dua rem yang bekerja bersama: mode persetujuan (kapan agen harus minta izin) dan sandbox (apa yang secara teknis bisa agen sentuh). Pahami keduanya, dan Anda bisa memakai Codex dengan percaya diri.

The most dangerous phrase in the language is, "We've always done it this way."

Grace Hopper

Pemilih mode persetujuan (interaktif)

Codex umumnya menawarkan tiga tingkat kebebasan. Klik salah satu mode di bawah untuk melihat apa yang boleh dilakukan agen, seberapa besar risikonya, dan kapan sebaiknya dipakai. (Panel interaktif ini berfungsi di peramban.)

Ketiga mode berdampingan

Panel interaktif di atas bagus untuk mengeksplorasi satu per satu; tabel berikut memudahkan membandingkan ketiganya sekaligus.

Cara kerja sandbox

Mode persetujuan mengatur kapan agen bertanya. Sandbox mengatur apa yang secara teknis mungkin, bahkan jika agen mencoba. Keduanya adalah lapisan berbeda: mode persetujuan bisa dilewati oleh keputusan Anda, sandbox tidak.

Saat menjalankan perintah, Codex membungkusnya dalam sandbox sistem operasi:

• macOS — memakai mekanisme Seatbelt (sandbox bawaan Apple) untuk membatasi akses berkas dan jaringan.
• Linux — memakai mekanisme kernel seperti Landlock dan seccomp untuk mengurung proses.

Dua batasan yang paling penting secara default:

1. Akses tulis dibatasi ke workspace. Agen umumnya hanya boleh menulis di dalam folder proyek, bukan seluruh disk Anda.
2. Jaringan dimatikan. Dalam mode otomatis, perintah biasanya berjalan tanpa internet, sehingga tidak bisa mengunduh hal tak terduga atau mengirim data keluar.

Git adalah jaring pengaman terbaik Anda

Apa pun modenya, kebiasaan tunggal yang paling menyelamatkan adalah bekerja di repo git yang bersih. Sebelum menyuruh Codex melakukan perubahan besar, pastikan tidak ada perubahan yang belum di-commit. Dengan begitu, apa pun yang Codex lakukan bisa Anda tinjau lewat git diff dan batalkan dengan git restore atau git checkout.

# Sebelum tugas besar — pastikan bersih
git status
git add -A && git commit -m "checkpoint sebelum sesi codex"

# Setelah sesi — tinjau semuanya
git diff

# Batalkan bila tak sesuai
git restore .        # buang perubahan belum ter-stage
git reset --hard HEAD  # kembali ke commit terakhir (hati-hati!)

Codex sepandai konteks yang Anda beri. Model yang sama bisa terasa jenius atau ngawur, tergantung apakah ia tahu konvensi proyek Anda, perintah build yang benar, dan aturan yang tak boleh dilanggar. Bab ini soal memberi proyek Anda "ingatan" — agar Anda tidak mengulang instruksi yang sama di setiap prompt.

AGENTS.md: kontrak antara Anda dan agen

Cara paling ampuh memberi konteks permanen adalah lewat berkas AGENTS.md di akar proyek. Ini adalah dokumen teks biasa (Markdown) yang otomatis dibaca Codex sebagai instruksi. Anggap ia sebagai onboarding untuk rekan kerja baru: apa proyek ini, cara menjalankannya, gaya kodenya, dan hal yang pantang dilakukan.

Isi yang paling bernilai untuk AGENTS.md:

• Perintah penting — cara build, test, lint, dan menjalankan aplikasi.
• Struktur proyek — folder utama dan tanggung jawabnya.
• Konvensi kode — gaya, penamaan, pola yang dipakai (mis. "pakai Zod untuk validasi").
• Aturan keras — hal yang tak boleh disentuh (mis. "jangan ubah migrasi database tanpa izin").
• Format laporan — bagaimana Anda ingin agen meringkas pekerjaannya.

# AGENTS.md — Proyek Toko Online

## Perintah
- Install: `pnpm install`
- Dev: `pnpm dev`
- Test: `pnpm test` (Vitest)
- Lint: `pnpm lint` (ESLint + Prettier)
- Type-check: `pnpm typecheck`

## Struktur
- `src/components/` — komponen React (satu file per komponen)
- `src/lib/` — util murni, tanpa efek samping
- `src/server/` — API routes & akses database (Prisma)

## Konvensi
- Validasi input SELALU pakai Zod di batas API.
- Gaya: functional components + hooks. Hindari class component.
- Format uang lewat helper `formatRupiah()`, jangan inline.

## Aturan keras
- JANGAN ubah file migrasi di `prisma/migrations/` tanpa persetujuan.
- JANGAN commit rahasia. Semua kunci lewat env var.
- Setiap endpoint baru wajib punya minimal satu test jalur gagal.

## Format laporan
Setelah selesai, ringkas: file yang diubah, alasan, perintah verifikasi
yang dijalankan beserta hasilnya, dan risiko yang tersisa.

Programs must be written for people to read, and only incidentally for machines to execute.

Harold Abelson

Contoh: instruksi lemah vs kuat

Perbedaannya bukan panjang, tetapi ketepatan. Bandingkan pasangan berikut:

Aturan praktisnya: jika sebuah instruksi tidak bisa dibuktikan benar atau salah, tulis ulang sampai bisa. Instruksi yang terukur adalah instruksi yang dipatuhi.

Hierarki: global, proyek, dan sub-folder

Instruksi bisa berlapis. Codex umumnya menggabungkan beberapa sumber, dari yang paling umum ke paling spesifik:

Memori & konteks percakapan

Selain AGENTS.md yang permanen, ada "ingatan jangka pendek": konteks percakapan dalam sesi berjalan. Codex mengingat apa yang sudah dibahas dalam sesi itu — tapi konteks ini punya batas (jendela konteks model). Semakin panjang sesi, semakin banyak yang harus "diingat", dan pada titik tertentu kualitas bisa menurun.

Sesudah AGENTS.md ada, Anda akan melihat perilaku agen berubah tanpa perlu diingatkan. Perhatikan bagaimana ia otomatis memakai perintah & konvensi yang tertulis di sana:

Ketika konteks ada di luar repo

Kadang jawaban tidak ada di dalam kode: keputusan bisnis, dokumen desain, tiket, atau diskusi tim. Codex tidak tahu hal-hal ini kecuali Anda beri tahu. Dalam kasus begitu, tempelkan potongan relevan ke prompt, atau — jika Anda memakai integrasi seperti MCP (Model Context Protocol) — sambungkan sumber eksternal secara eksplisit. Prinsipnya tetap: agen tidak bisa menebak konteks yang tak pernah ia lihat.

Teori sudah cukup; sekarang ke lantai kerja. Bab ini menelusuri enam tugas yang paling sering Anda hadapi — bikin fitur, perbaiki bug, refactor, tulis test, jelaskan kode, dan migrasi — masing-masing dengan pola prompt dan contoh sesi yang bisa langsung Anda tiru.

Satu prinsip menyatukan semuanya: bekerja dalam lingkaran kecil. Perubahan kecil yang bisa diverifikasi jauh lebih aman daripada satu lompatan raksasa. Codex bekerja terbaik ketika setiap langkah punya cara untuk dibuktikan benar.

1. Membuat fitur baru

Untuk fitur, minta rencana dulu pada tugas yang tidak sepele. Ini kesempatan Anda mengoreksi arah sebelum satu baris pun ditulis. Format prompt yang efektif: tujuan, batas (yang boleh & tidak boleh disentuh), konteks (pola yang harus diikuti), dan definisi selesai.

Tujuan: tambahkan fitur "wishlist" — user bisa menyimpan produk favorit.
Batas: jangan ubah skema tabel Order; buat tabel baru bila perlu.
Konteks: ikuti pola API di src/server/routes/cart.ts.
Selesai bila: ada endpoint tambah/hapus/lihat, plus test jalur sukses & gagal.
Langkah 1: tunjukkan rencana file-per-file dulu, JANGAN menulis kode.

2. Memperbaiki bug (dengan bukti)

Bug adalah keahlian utama coding agent. Kunci prompt yang baik: minta agen mereproduksi dulu, temukan akar masalah (bukan menambal gejala), lalu tulis regression test agar bug itu tak kembali.

Bug: total keranjang salah saat diskon & kupon dipakai bersamaan.
Langkah:
1) Reproduksi dengan test yang gagal lebih dulu.
2) Temukan akar masalah, jelaskan sebabnya.
3) Patch sekecil mungkin.
4) Pastikan test lulus dan tak ada regresi lain.
Akhiri dengan: akar masalah, file berubah, perintah verifikasi, hasil.

Everyone knows that debugging is twice as hard as writing a program in the first place.

Brian Kernighan

3. Refactor tanpa merusak

Refactor adalah tempat agen bersinar — perubahan mekanis berskala besar yang membosankan bagi manusia. Aturannya: jaga perilaku, ubah bentuk. Pastikan ada test sebelum refactor sebagai jaring, jaga API publik tetap sama, dan ubah satu area pada satu waktu.

Refactor: ubah semua pemanggilan fetch manual di src/ menjadi
memakai wrapper apiClient() yang sudah ada di src/lib/api.ts.
Aturan: jangan ubah perilaku/URL; hanya ganti mekanismenya.
Setelah tiap file: jalankan typecheck. Di akhir: jalankan semua test.

4. Menulis & melengkapi test

Anda bisa meminta Codex menambah cakupan test pada kode yang belum teruji. Mintalah test yang menguji perilaku, termasuk kasus tepi dan jalur gagal — bukan sekadar menaikkan angka coverage dengan test kosong.

Tulis unit test untuk src/lib/validasi.ts.
Cakup: input valid, input kosong, format salah, dan batas panjang.
Utamakan kasus tepi & jalur gagal. Pakai Vitest sesuai pola di repo.

5. Menjelaskan kode & onboarding

Salah satu pemakaian paling aman (dan sangat berguna) adalah meminta penjelasan tanpa mengubah apa pun. Ini ideal saat masuk ke basis kode asing. Tegaskan "jangan ubah apa pun" agar agen tetap read-only.

Jangan ubah apa pun. Jelaskan alur autentikasi di repo ini:
dari request login sampai session tersimpan. Sebutkan file kunci,
urutan pemanggilan, dan tempat yang paling mungkin jadi sumber bug.

6. Migrasi & upgrade

Migrasi (mis. naik versi framework, ganti library, ubah pola API) cocok untuk agen karena repetitif dan berpola. Tapi ini juga berisiko, jadi lakukan bertahap dan terverifikasi. Jangan migrasi seluruh repo dalam satu commit raksasa.

Migrasi: ganti library tanggal dari moment ke date-fns.
Lakukan bertahap: satu folder per langkah, jalankan test tiap langkah.
Mulai dari src/lib/. Tunjukkan daftar file terdampak sebelum mulai.
Jangan sentuh folder src/legacy/ (akan dihapus terpisah).

Studi kasus: satu fitur dari nol sampai PR

Mari satukan semuanya dalam satu contoh utuh. Misi: menambahkan endpoint "riwayat pesanan" ke API. Perhatikan bagaimana keempat gerakan (prompt, rencana, diff, jalankan) berpadu dengan mode persetujuan dan git.

Dari satu kalimat menjadi PR yang teruji, dalam satu percakapan — tetapi tiap langkah penting tetap melewati persetujuan Anda. Itulah keseimbangan yang buku ini kejar: cepat, tetapi terkendali.

Bonus: menulis dokumentasi & komentar

Alur ketujuh yang sering terlupakan: dokumentasi. Codex sangat baik menulis README, komentar fungsi, dan catatan perubahan karena ia bisa membaca kode sebenarnya, bukan menebak. Mintalah dokumentasi yang menjelaskan mengapa dan cara memakai, bukan sekadar mengulang nama fungsi.

Tulis dokumentasi untuk modul src/lib/cart.ts.
Sertakan: tujuan modul, cara memakai fungsi publik dengan contoh,
asumsi/keterbatasan, dan catatan kasus tepi (mis. diskon + kupon).
Format: JSDoc di atas tiap fungsi publik + satu blok ringkasan di awal file.

Benang merah keenam alur

Git dan Codex adalah pasangan alami. Git memberi agen jaring pengaman (semua bisa dibatalkan) dan memberi Anda mikroskop (setiap perubahan terlihat sebagai diff). Menguasai kolaborasi keduanya mengubah Codex dari "penulis kode" menjadi "kontributor yang bisa Anda review seperti rekan tim."

Diff sebagai percakapan

Cara terbaik meninjau kerja Codex adalah lewat diff. Jangan membaca kode akhir seolah muncul dari langit; baca perubahannya. Tiga pertanyaan saat meninjau diff:

1. Apakah ini menjawab tujuan? Cocokkan dengan acceptance criteria Anda.
2. Adakah perubahan samping tak terduga? File yang tak seharusnya tersentuh, format yang berubah massal, dependensi baru.
3. Apa yang belum diverifikasi? Bagian mana yang test-nya belum menjangkau.

Membuat commit & pull request

Codex bisa membantu menyusun commit yang rapi dan membuka pull request. Mintalah pesan commit yang menjelaskan mengapa, bukan sekadar apa (diff sudah menunjukkan apa). Untuk PR, deskripsi yang baik memuat konteks, ringkasan perubahan, dan cara mengujinya.

# Minta Codex menyusun commit bermakna
Buat commit dari perubahan ter-stage. Pesan: satu baris ringkas
(imperative mood) + body yang menjelaskan alasan perbaikan.

# Membuka PR (mis. lewat GitHub CLI, bila terpasang)
Buat pull request ke branch main. Sertakan: ringkasan, alasan,
langkah verifikasi, dan risiko. Judul mengikuti Conventional Commits.

Codex sebagai reviewer

Anda juga bisa membalik peran: minta Codex mereview kode (milik Anda atau milik orang lain). Agar berguna, minta temuan yang dapat ditindaklanjuti — skenario gagal konkret, lokasi, dampak, dan perbaikan terkecil — bukan pujian umum.

Review diff pada branch ini. Cari: bug konkret, regresi, celah keamanan,
validasi hilang, dan test yang kurang. Untuk tiap temuan sebutkan:
file:baris, skenario yang gagal, dampak, dan perbaikan minimal.
Jangan memuji; fokus pada yang perlu diperbaiki.

Strategi branch: beri agen ruang sendiri

Kebiasaan yang sangat membantu: jalankan sesi Codex pada branch terpisah, bukan langsung di main. Dengan begitu pekerjaan agen terisolasi, mudah dibandingkan lewat PR, dan gampang dibuang bila tak jadi. Ini juga membuat Anda dan agen bisa bekerja paralel tanpa saling menimpa.

# Buat branch untuk sesi agen
git switch -c fitur/wishlist

# ... jalankan sesi Codex di sini ...

# Puas? gabungkan lewat PR. Tidak puas? buang branch-nya.
git switch main
git branch -D fitur/wishlist

Simplicity is prerequisite for reliability.

Edsger W. Dijkstra

Kemampuan menjalankan perintah shell adalah bagian paling kuat sekaligus paling menakutkan dari sebuah coding agent. Perintah yang tepat menjalankan test dan membuktikan kerja; perintah yang salah bisa menghapus data. Bab ini soal memakai kekuatan itu tanpa terbakar.

Empat prinsip perintah aman

1. Sandbox dulu. Biarkan sandbox (Bab 4) menjadi lapisan pertahanan utama: tulis terbatas ke workspace, jaringan mati. Jangan matikan tanpa alasan kuat.
2. Baca sebelum setuju. Dalam mode Suggest/Auto-edit, Codex menampilkan perintah sebelum menjalankan. Baca — terutama yang mengandung rm, mv, git reset, > (redirect timpa), atau curl | sh.
3. Idempoten & reversibel. Utamakan perintah yang bisa diulang tanpa efek merusak dan yang mudah dibatalkan (lewat git).
4. Perintah destruktif = jeda manusia. Apa pun yang menghapus, menimpa, atau mengubah sistem di luar proyek harus Anda konfirmasi sadar.

Loop verifikasi: biarkan agen membuktikan dirinya

Perintah bukan cuma bahaya; ia juga alat pembuktian. Kekuatan sejati agen muncul saat ia bisa menjalankan test dan membaca hasilnya sendiri, lalu memperbaiki bila gagal. Inilah "loop verifikasi" — dan ia hanya bekerja jika agen tahu perintah verifikasi yang benar (taruh di AGENTS.md).

Perintah yang layak diotomatiskan

Sebaliknya, banyak perintah aman dan justru sebaiknya sering dijalankan agen karena memberi umpan balik cepat:

Untuk otonomi tinggi: pakai lingkungan terisolasi

Jika Anda ingin memberi Codex kebebasan penuh (full-auto, bahkan dengan jaringan), lakukan di dalam container atau VM sekali-pakai — bukan mesin utama Anda. Contohnya sebuah kontainer Docker yang hanya berisi salinan repo, tanpa akses ke kredensial pribadi, SSH key, atau folder lain. Kalau ada yang kacau, buang saja kontainernya.

Prompt yang baik tidak harus panjang; ia harus mengurangi tebakan. Sesudah ribuan sesi, pola yang berhasil selalu punya empat unsur: hasil yang diinginkan, bagian yang boleh disentuh, aturan yang tak boleh dilanggar, dan cara membuktikan selesai. Bab ini merangkum pola-pola itu menjadi pustaka yang bisa langsung Anda salin dan sesuaikan.

The competent programmer is fully aware of the strictly limited size of his own skull.

Edsger W. Dijkstra

Anatomi prompt yang efektif

Ingat rumus ini dengan singkatan T-B-K-S:

Pustaka prompt siap salin

Klik kartu mana pun untuk menyalin templat prompt. Ganti bagian dalam [KURUNG] sesuai kebutuhan Anda.

Teknik prompt lanjutan

• Minta rencana, lalu setujui. Untuk tugas > 15 menit kerja manusia, pisahkan "berpikir" dari "melakukan". Rencana yang salah murah dikoreksi; kode yang salah mahal.
• Beri satu contoh (few-shot). "Ikuti pola di cart.ts" jauh lebih kuat daripada mendeskripsikan pola itu dengan kata-kata.
• Tetapkan format keluaran. "Akhiri dengan: file berubah, perintah verifikasi, hasil" membuat laporan agen konsisten dan mudah dipindai.
• Pecah yang besar. Fitur besar → beberapa prompt kecil yang masing-masing bisa diuji. Sesi panjang menurunkan kualitas; tugas kecil menjaga fokus.
• Koreksi dengan spesifik. Jangan cuma "salah, ulangi". Katakan "jangan ubah API", "pakai komponen X", atau "test ini gagal; cari mengapa".

Pustaka tambahan: situasi khusus

Beberapa templat lagi untuk situasi yang sering muncul. Klik untuk menyalin.

Setiap alat ampuh punya sisi tumpul. Bab ini jujur soal batas Codex: di mana ia gemilang, di mana ia menipu, dan bagaimana biaya bekerja agar Anda tak terkejut oleh tagihan atau kuota yang habis di tengah jalan.

Sepuluh tips emas

1. Mulai dari repo bersih. Commit dulu; jadikan git jaring pengaman Anda.
2. Rencana dulu untuk tugas besar. Koreksi arah sebelum kode ditulis.
3. Satu tujuan per sesi. /clear antar tugas menjaga konteks tetap tajam.
4. Tulis AGENTS.md sekali, hemat ratusan instruksi.
5. Beri file yang tepat. Jangan biarkan agen menebak seluruh repo.
6. Biarkan agen memverifikasi dirinya. Pastikan ia tahu perintah test.
7. Baca diff, bukan hanya hasil akhir.
8. Naikkan/turunkan model sesuai kesulitan. Hemat model kuat untuk masalah sulit.
9. Koreksi dengan spesifik saat meleset.
10. Manusia memutuskan hal berisiko. Uang, izin, data, produksi.

Jebakan yang sering menjerat

Premature optimization is the root of all evil.

Donald Knuth

Batasan yang perlu Anda terima

Codex, seperti semua sistem berbasis model bahasa, memiliki batasan mendasar:

• Bisa salah dengan percaya diri. Keluaran yang meyakinkan belum tentu benar. Verifikasi adalah tanggung jawab Anda.
• Tak tahu yang tak dilihatnya. Konteks bisnis, keputusan lisan, atau sistem di luar repo tidak diketahui kecuali diberi tahu.
• Jendela konteks terbatas. Repo raksasa tidak muat sekaligus; agen bekerja dengan potongan.
• Non-determinisme. Prompt sama bisa memberi hasil sedikit berbeda tiap kali.
• Pengetahuan punya batas waktu. Library sangat baru mungkin belum dikenali sempurna.

Memilih model dengan bijak

Codex bisa dijalankan dengan model yang berbeda, dan pilihan itu menukar tiga hal: kemampuan, kecepatan, dan biaya/kuota. Tidak ada pilihan "terbaik" universal — yang ada adalah pilihan yang tepat untuk tugas di depan Anda.

Anda bisa berganti model di tengah sesi dengan /model — mulai murah untuk menjelajah, lalu naik saat menemui bagian yang benar-benar sulit.

Biaya, token, & kuota

Ada dua model biaya, tergantung cara login (Bab 2):

• Lewat langganan ChatGPT. Pemakaian dihitung dari allowance paket Anda (ada batas per periode yang bisa reset). Tidak ada tagihan per-token terpisah, tapi ada limit pemakaian.
• Lewat API key. Bayar per token — satuan potongan teks. Input (yang dikirim ke model) dan output (yang dihasilkan) dihitung, dengan tarif berbeda per model.

Apa yang menghabiskan token/kuota? Terutama: ukuran konteks (banyak file yang dibaca), panjang sesi (percakapan yang menumpuk), pemakaian alat (tiap perintah & hasilnya masuk konteks), dan model yang dipakai (model lebih kuat biasanya lebih mahal).

Kapan sebaiknya JANGAN pakai agent

Pemakai dewasa tahu batas alatnya. Ada situasi di mana menyerahkan tugas ke agen justru lebih lambat, lebih berisiko, atau kurang tepat:

• Perubahan sepele satu karakter yang lebih cepat Anda ketik sendiri daripada menjelaskannya.
• Keputusan yang butuh konteks manusia — arah produk, prioritas, trade-off politik tim. Agen bisa membantu menyusun opsi, tapi keputusannya milik Anda.
• Saat Anda sendiri belum paham masalahnya. Jika Anda tak bisa menilai benar/salahnya jawaban, Anda tak bisa mengawasi agen. Pahami dulu, baru delegasikan.
• Kode super-sensitif tanpa cara verifikasi. Bila tak ada test atau cara membuktikan, risiko naik tajam.
• Belajar konsep dari nol. Kadang mengetik sendiri adalah cara belajar; jangan lewatkan latihan itu demi kecepatan.

Codex bukan satu-satunya coding agent, dan buku yang jujur tidak berpura-pura demikian. Lanskap ini bergerak cepat dan setiap alat punya kekuatan berbeda. Bab ini membandingkan secara ringkas dan jujur — bukan untuk menobatkan pemenang, tapi agar Anda memilih sesuai konteks.

Cara memilih dengan jernih

• Anda hidup di terminal? Codex CLI, Claude Code, atau Aider terasa alami.
• Anda ingin agen di dalam editor grafis? Cursor atau Copilot lebih nyaman.
• Butuh otonomi + sandbox untuk tugas panjang? Codex CLI dan Claude Code kuat di sini.
• Butuh mode non-interaktif untuk CI? Agen terminal (termasuk Codex exec) unggul.
• Sudah investasi di ekosistem tertentu? Sering kali alat sepanggung ekosistem itu paling mulus.

The best way to predict the future is to invent it.

Alan Kay

Buku ini ditulis untuk manusia — tetapi di zaman ini, kemungkinan besar sebuah model bahasa juga akan membacanya: untuk meringkas, menjawab pertanyaan Anda tentang isinya, atau mengekstrak langkah. Bab ini adalah jembatan sadar antara kedua pembaca itu, sekaligus penjelasan tentang teknik yang buku ini pakai.

Mengapa bab ini ada

Konten yang ramah-AI bukan berarti konten yang kaku atau penuh kata kunci. Justru sebaliknya: struktur yang jelas, klaim yang tepat, dan penanda ketidakpastian yang eksplisit membantu manusia dan mesin sama-sama memahami dengan benar. Prinsip yang membuat teks mudah dibaca AI hampir identik dengan prinsip tulisan yang baik.

Teknik yang dipakai buku ini

• Hierarki heading yang bersih. Setiap bab dan sub-bab punya judul deskriptif dengan id yang bisa dijadikan jangkar — memudahkan model merujuk bagian spesifik.
• Kotak "Untuk AI". Di akhir tiap bab ada ringkasan padat yang sengaja ditujukan bagi model: inti bab dalam beberapa kalimat, tanpa hiasan.
• Penanda ketidakpastian eksplisit. Frasa "verifikasi ke dokumentasi resmi OpenAI" memberi sinyal jelas — kepada manusia dan mesin — bahwa detail itu mudah usang dan tak boleh dijadikan fakta beku.
• Klaim yang dibatasi. Buku ini menghindari angka absolut yang cepat kedaluwarsa (harga, kuota) dan lebih memilih menjelaskan mekanisme yang lebih stabil.
• Definisi sebelum pemakaian. Istilah dijelaskan saat pertama muncul, dan dirangkum di glosarium.

Untuk penulis lain: menulis dokumen yang ramah manusia & AI

Jika Anda menulis dokumentasi teknis di era agen, beberapa kebiasaan ini berlaku umum:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupéry

Kita telah menempuh perjalanan dari "apa itu coding agent" sampai memandunya dengan aman di lantai kerja nyata. Sebagai penutup: sebuah renungan singkat, lalu tiga lampiran praktis yang bisa Anda buka kembali kapan saja — FAQ, glosarium, dan checklist.

Codex, dan alat sejenisnya, sedang mengubah bentuk pekerjaan kita. Tapi ia tidak menghapus keahlian; ia menggesernya. Nilai Anda bergeser dari mengetik setiap baris menuju merumuskan masalah dengan tepat, memberi konteks yang benar, dan menilai hasil dengan kritis. Itu keterampilan yang lebih tinggi, bukan lebih rendah. Alat terbaik bukan yang menggantikan pemikiran Anda, melainkan yang mempercepat pemahaman Anda.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

FAQ — Pertanyaan yang Sering Diajukan

1. Apakah Codex akan menggantikan programmer?

Tidak dalam waktu dekat, dan mungkin tidak dalam bentuk yang ditakutkan. Codex menggeser pekerjaan dari mengetik ke merumuskan, memandu, dan memverifikasi. Programmer yang memakainya dengan baik menjadi lebih produktif; keahlian menilai kode justru makin berharga.

2. Apakah kode buatan Codex aman dipakai di produksi?

Hanya setelah ditinjau dan diuji seperti kode buatan manusia. Codex bisa salah dengan percaya diri. Diff, test, dan review manusia — terutama untuk area sensitif — tetap wajib.

3. Apakah kode saya dikirim ke server OpenAI?

Codex memanggil model di server, jadi konteks yang relevan dikirim untuk diproses. Kebijakan privasi, retensi data, dan opsi enterprise berbeda per paket. Verifikasi ke kebijakan resmi OpenAI dan aturan organisasi Anda sebelum memakainya pada kode rahasia.

4. Bisakah dipakai tanpa internet?

Tidak untuk bagian "berpikir" — pemanggilan model butuh koneksi. Namun eksekusi perintah lokal bisa berjalan di sandbox dengan jaringan dimatikan.

5. Apa bedanya Codex CLI dengan ekstensi IDE atau versi cloud?

Bentuk dan alurnya. CLI hidup di terminal dan open-source; ada juga integrasi editor dan varian cloud. Prinsip memandunya sama. Detail produk verifikasi resmi.

6. Model apa yang sebaiknya saya pakai?

Aturan praktis: model seimbang untuk mayoritas kerja, model terkuat untuk masalah sulit/konteks besar, model cepat untuk eksplorasi. Nama model tersedia berubah — cek /model dan dokumentasi resmi.

7. Bagaimana kalau Codex terus salah?

Biasanya masalah konteks atau prompt, bukan model. Beri file yang tepat, perjelas definisi selesai, pecah tugas, atau mulai sesi baru dengan ringkasan. Kalau tetap buntu, kerjakan manual bagian yang sulit lalu serahkan sisanya.

8. Amankah memberi mode Full-auto?

Aman jika: repo git bersih, ada test sebagai penilai, dan idealnya di lingkungan terisolasi. Hindari untuk hal yang menyentuh produksi, kredensial, atau data penting.

9. Bagaimana Codex menangani banyak file / repo besar?

Ia membaca potongan yang relevan, tidak seluruh repo sekaligus (jendela konteks terbatas). Karena itu menunjuk file yang tepat sangat membantu.

10. Perlukah saya tetap paham kode yang dihasilkan?

Sangat perlu. Anda bertanggung jawab atas kode yang Anda merge. Jika Anda tak paham sebuah perubahan, minta Codex menjelaskannya sampai Anda paham — jangan merge yang buta.

11. Bisakah Codex membuat pull request otomatis?

Ya, bila alat seperti GitHub CLI tersedia dan Anda mengizinkannya. Ia bisa menyusun commit, deskripsi PR, dan membukanya — tetap dengan persetujuan Anda pada perintah git.

12. Bagaimana biaya dihitung?

Lewat langganan ChatGPT (allowance paket) atau API key (bayar per token). Faktor: ukuran konteks, panjang sesi, pemakaian alat, dan model. Angka pasti — verifikasi resmi.

13. Apakah AGENTS.md wajib?

Tidak wajib, tapi sangat dianjurkan. Ia menghemat pengulangan instruksi dan membuat perilaku agen konsisten di seluruh tim.

14. Codex mengusulkan rm -rf / reset — apa yang harus saya lakukan?

Berhenti dan baca. Tolak jika ragu (n). Minta pendekatan non-destruktif ("buat commit baru, jangan reset"). Perintah yang menghapus atau menimpa selalu pantas dicurigai.

15. Dari mana saya tahu info di buku ini masih akurat?

Kerangka konsep (agentic loop, mode persetujuan, sandbox, AGENTS.md, pola prompt) relatif stabil. Detail bertanda "verifikasi ke dokumentasi resmi OpenAI" — perlakukan sebagai perlu-dicek. Selalu rujuk halaman resmi untuk angka, nama, dan versi terkini.

16. Apakah keterampilan ini berguna untuk alat lain?

Sangat. Memberi konteks, menetapkan batas, dan memverifikasi hasil berlaku untuk Claude Code, Cursor, Copilot, Aider, dan agen mana pun. Anda belajar cara berpikir, bukan sekadar satu alat.

Kartu Referensi Kilat

Satu tabel untuk ditempel di dekat monitor. Semua nama perintah bertanda "verifikasi ke dokumentasi resmi" karena bisa berubah antar versi.

Glosarium

• AI Coding Agent — program berbasis AI yang bisa membaca kode, menyusun rencana, memakai alat (file/shell/git), dan menyelesaikan tugas pemrograman, bukan sekadar menyarankan teks.
• Agentic loop — siklus kerja agen: persepsi → rencana → aksi → observasi → refleksi, berulang sampai tujuan tercapai.
• AGENTS.md — berkas Markdown di akar proyek berisi instruksi permanen (perintah, konvensi, aturan) yang otomatis dibaca agen.
• Autocomplete — saran kode inline untuk baris/fungsi yang sedang diketik; reaktif dan lokal, tanpa rencana.
• CLI — Command Line Interface; antarmuka berbasis teks yang dijalankan di terminal.
• Diff — representasi perubahan kode: baris ditambah (+) dan dihapus (−).
• Full-auto — mode persetujuan paling otonom; agen mengedit & menjalankan perintah sendiri di dalam sandbox.
• Jendela konteks — batas jumlah teks yang bisa "diingat" model dalam satu waktu.
• Landlock / seccomp — mekanisme kernel Linux untuk membatasi akses sebuah proses (dipakai sandbox).
• MCP (Model Context Protocol) — protokol untuk menyambungkan agen ke sumber data/alat eksternal.
• Mode persetujuan — pengaturan kapan agen harus minta izin sebelum menulis file atau menjalankan perintah.
• Sandbox — lingkungan terisolasi yang membatasi apa yang bisa disentuh proses (akses file & jaringan).
• Seatbelt — mekanisme sandbox bawaan macOS.
• Suggest / Auto-edit — mode konservatif & jalan tengah; lihat Bab 4.
• Token — potongan teks (satuan hitung biaya model); input & output dihitung terpisah.
• TUI — Text User Interface; antarmuka interaktif berbasis teks di dalam terminal.
• Regression test — test yang memastikan bug yang sudah diperbaiki tidak muncul kembali.
• Prompt — instruksi bahasa alami yang Anda berikan kepada agen.
• T-B-K-S — rumus prompt: Tujuan, Batas, Konteks, Selesai-bila (Bab 9).
• Non-interaktif / codex exec — menjalankan Codex sekali jalan tanpa dialog, cocok untuk skrip & CI.
• CI (Continuous Integration) — pipeline otomatis yang menjalankan build/test tiap perubahan kode.
• PR (Pull Request) — usulan penggabungan perubahan dari sebuah branch, tempat kode ditinjau sebelum di-merge.
• Repositori (repo) — folder proyek yang dikelola git, lengkap dengan riwayat perubahannya.
• Halusinasi — saat model menghasilkan keluaran yang terdengar meyakinkan tetapi salah (mis. memanggil fungsi yang tak ada).
• Worktree — kondisi file kerja Anda saat ini, termasuk perubahan yang belum di-commit.
• WSL2 — Windows Subsystem for Linux; lapisan yang menjalankan Linux di dalam Windows, jalur termulus memakai Codex di Windows.
• Diff hunk — potongan berlabel @@ … @@ dalam sebuah diff yang menandai lokasi baris yang berubah.
• Idempoten — sifat operasi yang aman diulang berkali-kali tanpa mengubah hasil akhir.
• Acceptance criteria — kriteria terukur yang menandai sebuah tugas selesai dengan benar.

Checklist Pemakaian Aman

Cetak atau tempel di dekat meja Anda. Jalankan sebelum, selama, dan sesudah sesi Codex.

Sumber Resmi & Bacaan Lanjut

Karena banyak detail dalam buku ini sengaja ditandai "verifikasi ke dokumentasi resmi", berikut jenis sumber yang sebaiknya jadi rujukan utama Anda. (Alamat persis berubah; cari nama resminya lewat mesin pencari.)

• Dokumentasi resmi OpenAI Codex — sumber kebenaran untuk instalasi, perintah, mode, dan model terbaru.
• Repositori sumber terbuka Codex CLI — kode, catatan rilis (changelog), dan diskusi isu. Tempat terbaik melihat apa yang berubah dan kapan.
• Halaman harga & usage OpenAI — untuk angka biaya, kuota, dan kelayakan paket yang mutakhir.
• Kebijakan privasi & data — penting sebelum memakai Codex pada kode rahasia atau di organisasi.
• Standar AGENTS.md — konvensi lintas alat untuk instruksi proyek bagi agen.
• Blog engineering OpenAI — untuk pengumuman fitur dan model baru.

Salam Penutup

Terima kasih telah menempuh seluruh perjalanan ini. Menguasai sebuah coding agent bukan soal menghafal perintah, melainkan menumbuhkan kebiasaan berpikir: memberi konteks yang tepat, menetapkan batas yang jelas, dan tak pernah melewatkan verifikasi. Kebiasaan itu akan tetap berharga meski alatnya berganti nama, berganti model, bahkan berganti perusahaan.

Sekarang giliran Anda. Buka terminal, masuk ke sebuah proyek, ketik codex, dan mulailah percakapan. Setiap sesi kecil menambah jam terbang Anda. Selamat membangun.

Talk is cheap. Show me the code.

Linus Torvalds

// selamat mengoding bersama agen — dengan konteks, batas, dan verifikasi.

Ringkasan Satu Halaman

Bila Anda hanya sempat mengingat satu halaman dari seluruh buku, jadikan halaman ini.

konteks · batas · verifikasi