Bagaimana Saya Menggunakan Codex untuk Meninjau 15 Proyek Tanpa Melepas Kontrol Manual

Beberapa tahun lalu, gagasan meninjau 15 proyek software secara serius pada saat yang sama akan terasa tidak realistis bagi saya. Maksud saya bukan membuka 15 repository dan melihat sekilas. Maksud saya adalah berulang kali memeriksa proyek nyata untuk bug, asumsi yang lemah, masalah SEO, kesalahan terjemahan, inkonsistensi lokalisasi, test yang hilang, regresi, dan kode lama yang tidak lagi cocok dengan sistem lainnya.

Batasnya bukan kecepatan mengetik. Batasnya adalah perhatian. Setiap proyek punya sejarah, konvensi, edge case, dan kode yang tampak salah tetapi sebenarnya sengaja dibuat demikian. Review yang hati-hati membutuhkan membaca, mencari, membandingkan, menjalankan check, lalu baru memutuskan apa yang benar-benar perlu diubah.

Codex mengubah biaya pekerjaan repetitif itu bagi saya. Ia bisa melakukan first pass pada repository, mengikuti referensi, memeriksa file terkait, menyoroti pattern mencurigakan, menyarankan test, dan membantu menyelidiki area yang dulu harus saya buka satu per satu. Keputusan akhir tidak menjadi otomatis. Bagian mahal sebelum keputusan menjadi jauh lebih cepat.

Aturan terpenting yang saya pelajari sederhana: saya tidak menggunakan Codex untuk mengeluarkan diri saya dari review loop. Saya menggunakannya untuk memperluas review loop itu.

Bottleneck sebenarnya adalah repetisi, bukan menulis kode

Ketika memelihara satu proyek, kita bisa mengingat banyak context. Dengan banyak proyek, itu tidak lagi scalable. Jenis pekerjaan yang sama muncul berulang kali:

• mencari bug serupa di komponen berbeda;
• memeriksa apakah refactor meninggalkan call site lama;
• meninjau test setelah perubahan perilaku;
• mencari inkonsistensi metadata, aturan bahasa, heading, atau internal link;
• membandingkan localization keys dan konten terjemahan;
• mencari error handling yang hilang dan edge case;
• memeriksa apakah perubahan “kecil” menyentuh terlalu banyak file;
• membaca diff yang sederhana satu per satu tetapi mahal jika dikumpulkan.

Tidak ada yang glamor dari tugas ini. Semuanya penting. Ketika review yang sama harus diulang pada banyak codebase, biayanya menjadi besar.

Di sinilah AI coding agent paling berguna bagi saya. Ia menghabiskan bagian berulang dari ruang pencarian sehingga perhatian saya bisa dipakai untuk judgment.

Saya mulai dari inspeksi, bukan izin untuk menulis ulang semuanya

Salah satu cara termudah mendapatkan hasil buruk adalah memberi tugas besar seperti “review seluruh proyek dan perbaiki semuanya”. Kedengarannya efisien, tetapi mencampur discovery, prioritas, arsitektur, implementasi, dan validation dalam satu tugas tanpa kontrol.

Hasil saya jauh lebih baik ketika tahapannya dipisah.

inspect → explain findings → prioritize → change → validate → review diff

Pertama saya ingin agent memahami area terkait dan menjelaskan apa yang ditemukan. Saya ingin path file konkret, kode yang terdampak, alasan mengapa sesuatu mencurigakan, dan kemungkinan impact. Baru setelah itu saya ingin perubahan.

Ini penting karena AI bisa salah dengan sangat percaya diri. Kode yang terlihat redundant bisa ada untuk browser lama, payment edge case, jalur migrasi, atau business rule yang tidak terlihat dari satu file. Inspeksi memberi kesempatan untuk menghentikan asumsi buruk sebelum berubah menjadi diff besar.

Saya memperlakukan finding sebagai petunjuk, bukan keputusan

Review Codex yang bagus tidak berhenti pada “saya menemukan 17 masalah”. Angka itu sendiri hampir tidak berarti. Saya ingin evidence.

Untuk finding yang benar-benar actionable, saya ingin tahu:

• di mana masalah berada;
• mengapa itu masalah;
• perilaku apa yang bisa gagal;
• seberapa yakin kesimpulannya;
• check apa yang dapat membuktikan atau menolaknya;
• fix terkecil yang aman.

Ini sangat penting untuk security, SEO, dan business logic. Agent bisa menunjukkan sesuatu yang layak diselidiki, tetapi penjelasan yang terdengar seperti security report belum berarti vulnerability yang terbukti. Warning SEO belum tentu masalah ranking. Kondisi aneh belum tentu dead code.

AI menurunkan biaya menemukan kandidat. Verifikasi tetap menentukan apa yang nyata.

Validation loop membuat workflow dapat dipercaya

Code generation adalah bagian yang paling terlihat dari AI-assisted development, tetapi validation adalah bagian yang membuatnya berguna di production.

Setelah perubahan, saya ingin codebase memberikan jawaban. Tergantung proyek, itu bisa mencakup:

• TypeScript atau compiler/type checker lain;
• lint;
• unit dan integration tests;
• build check;
• search terarah untuk nama lama atau call site;
• review manual pada final diff;
• verifikasi manual perilaku yang terlihat pengguna.

Command spesifik kurang penting dibanding loop-nya. Agent membuat asumsi, repository memberikan evidence, lalu keputusan berikutnya dibuat dari evidence itu.

Karena itu saya suka proyek yang strongly typed untuk AI-assisted work. Saya menulis terpisah tentang mengapa TypeScript bekerja sangat baik bersama Codex dalam software delivery nyata: type mengubah banyak asumsi salah menjadi feedback langsung yang dapat dibaca mesin.

Beberapa kategori review sangat cocok untuk AI

Bug dan regresi

Agent dapat mengikuti nilai melintasi file, memeriksa caller, membandingkan implementasi serupa, dan mencari branch yang tidak konsisten. Ini membantu mempersempit asal sebuah gejala. Saya tetap mereproduksi atau memverifikasi perilakunya sebelum menerima kesimpulan.

Test

AI berguna untuk menemukan perilaku yang berubah tanpa test coverage yang sesuai, menyarankan edge case, dan menjelaskan apa yang sebenarnya dilindungi test yang ada. Ia juga dapat menemukan test yang hanya memverifikasi detail implementasi.

SEO

Technical SEO berisi banyak pekerjaan consistency: metadata, language alternates, indexability, internal links, templates, sitemap generation, redirects, dan convention per halaman. Agent dapat membandingkan aturan ini pada codebase besar lebih cepat daripada saya membuka setiap route. Tetapi saya selalu memisahkan correctness teknis dari pertanyaan yang lebih sulit: apakah kontennya sendiri layak ranking?

Lokalisasi dan terjemahan

Ini salah satu area paling repetitif pada produk multibahasa. AI dapat membandingkan key, mencari value yang hilang, mendeteksi bahasa yang salah, memeriksa placeholder, dan menunjukkan locale yang menyimpang secara struktur. Jauh lebih cepat daripada menelusuri translation object besar secara manual, walau copy penting tetap membutuhkan judgment manusia.

Konsistensi setelah refactoring

Refactor besar sering gagal dengan cara membosankan: satu import lama tersisa, satu route masih memakai field name lama, satu test fixture masih punya shape lama. Repository-wide search bersama agent yang memahami tujuan perubahan sangat berguna di sini.

Kerja paralel hanya membantu bila task independen

Memulai banyak agent dan membiarkan semuanya mengubah hal secara bersamaan sangat menggoda. Throughput bisa naik, tetapi conflict dan asumsi yang tidak kompatibel juga bisa berlipat.

Saya melihat parallelism sebagai masalah koordinasi. Audit independen cocok: satu proyek dapat dicek untuk localization sementara proyek lain direview untuk test, atau repository terpisah diperiksa bersamaan. Dua agent yang menulis ulang architecture yang sama tanpa rencana bersama adalah cerita lain.

Semakin paralel pekerjaan, semakin penting batas: project jelas, task jelas, definition of done jelas, dan hasil yang bisa direview secara terpisah.

Tujuannya bukan memaksimalkan jumlah agent yang berjalan. Tujuannya memaksimalkan progress yang berguna dan dapat diverifikasi.

Apa yang tidak saya delegasikan secara buta

• Keputusan arsitektur: model dapat memberi opsi, tetapi trade-off jangka panjang sering membutuhkan context di luar repo.
• Kesimpulan security: finding membutuhkan verifikasi, threat context, dan sering tool khusus.
• Business rules: kode dapat konsisten secara internal dan tetap mengimplementasikan perilaku produk yang salah.
• Refactor destruktif besar: diff besar lebih sulit dipahami dan lebih mudah disetujui tanpa cukup perhatian.
• Production deployment: test lulus tidak menghapus operational risk.
• Final review: saya ingin tahu apa yang berubah sebelum menaruh nama saya di perubahan itu.

Bukan karena AI tidak berguna di area ini, tetapi karena jawaban salah yang terlihat masuk akal bisa sangat mahal.

AI review bukan pengganti static analysis

Saya juga tidak melihat Codex sebagai pengganti compiler, linter, test, scanner, atau monitoring. Tool itu punya kelebihan yang AI tidak punya: sempit, deterministik, dan repeatable.

Workflow terkuat menggabungkan semuanya. Codex dapat reasoning pada context dan menyarankan tempat untuk diperiksa. Static tools menegakkan aturan presisi. Test memverifikasi behavior. Log dan monitoring menunjukkan realitas. Human review menghubungkan semua sinyal itu dengan product intent.

Tanpa feedback systems ini, saya justru akan lebih sedikit mempercayai AI.

Gain produktivitas terbesar adalah alokasi perhatian yang lebih baik

Mudah mengatakan “Codex menghemat waktu”, tetapi itu mengecilkan perubahan yang saya rasakan.

Resource langka dalam software development bukan keystroke. Itu adalah perhatian berkualitas tinggi. Sebelum AI coding agents, banyak perhatian habis untuk discovery repetitif: mencari pattern yang sama, membaca file serupa, mengikuti reference, memastikan perubahan sudah menyebar, lalu mengulang audit yang sama di repository lain.

Sekarang saya dapat mendelegasikan lebih banyak first-pass work dan menyimpan perhatian saya untuk keputusan yang sulit diotomatisasi: apakah finding penting, apakah fix sesuai architecture, apakah UX membaik, apakah risk dapat diterima, apakah saya benar-benar ingin ship perubahan itu.

Itulah mengapa menjaga dan mereview banyak proyek terasa berbeda sekarang. Saya tidak mereview lebih sedikit. Dalam banyak kasus saya dapat mereview lebih banyak karena bagian mekanis tidak menghabiskan seluruh budget.

Workflow yang saya percaya

1. Tentukan tujuan review yang sempit. Bug, test, SEO, localization, refactor, atau concern konkret lain.
2. Biarkan agent inspect sebelum edit. Saya ingin evidence dan lokasi terdampak dulu.
3. Prioritaskan findings. Tidak setiap masalah teoretis layak diubah.
4. Jaga perubahan tetap bounded. Diff kecil dan koheren lebih mudah divalidasi.
5. Jalankan machine checks. Typecheck, lint, test, build, search, atau validasi spesifik proyek.
6. Baca diff secara manual. Cari rewrite tidak perlu, asumsi salah, edge case yang hilang, dan perubahan di luar scope.
7. Verifikasi behavior penting. Terutama users, uang, security, SEO, dan production infrastructure.
8. Baru lanjut ke proyek berikutnya. Parallelism berguna, tetapi ketidakpastian yang belum selesai tidak boleh menyebar.

Lima belas proyek tidak lagi terasa seperti lima belas kali pekerjaan review

Codex tidak membuat 15 proyek menjadi sederhana dan tidak menghapus tanggung jawab saya. Ia mengubah hubungan antara scale dan repetitive effort.

Saya dapat meminta first pass lebih dalam, consistency check lebih luas, lebih banyak ide test, dan audit lebih sistematis tanpa menghabiskan setiap menit mencari sendiri di setiap file. Lalu perhatian yang tersisa dapat saya pakai untuk keputusan yang masih membutuhkan developer.

Inilah AI-assisted development yang menurut saya bernilai: bukan autopilot, bukan blind trust, dan bukan “generate code sampai sesuatu lolos”. Ini loop yang lebih rapat antara inspection skala mesin dan judgment skala manusia.

Bagi saya, itulah leverage sebenarnya dari Codex. Ia tidak menghilangkan review. Ia membuat review serius mungkin dilakukan pada skala yang sebelumnya jauh lebih sulit dipertahankan.