Rekayasa alat: memanfaatkan Codex di dunia agen

Selama lima bulan terakhir, tim kami telah menjalankan sebuah eksperimen: membangun dan merilis beta internal dari sebuah produk perangkat lunak dengan 0 baris kode yang ditulis secara manual.

Produk ini memiliki pengguna harian internal dan penguji alpha eksternal. Produk dirilis, diterapkan, rusak, dan diperbaiki. Yang berbeda adalah bahwa setiap baris kode—logika aplikasi, pengujian, konfigurasi CI, dokumentasi, observabilitas, dan perkakas internal—ditulis oleh Codex. Kami memperkirakan bahwa kami membangun ini dalam waktu sekitar 1/10 dari waktu yang dibutuhkan untuk menulis kode secara manual.

Manusia yang mengemudikan. Agen yang menjalankan.

Kami sengaja memilih batasan ini agar kami dapat membangun apa yang diperlukan untuk meningkatkan kecepatan rekayasa secara signifikan. Kami memiliki waktu berminggu-minggu untuk menyelesaikan apa yang pada akhirnya menjadi satu juta baris kode. Untuk melakukan itu, kami perlu memahami apa yang berubah ketika pekerjaan utama tim rekayasa perangkat lunak bukan lagi menulis kode, tetapi merancang lingkungan, menentukan maksud, dan membangun siklus umpan balik yang memungkinkan agen Codex bekerja dengan andal.

Tulisan ini membahas apa yang kami pelajari dengan membangun produk baru bersama tim agen—apa yang rusak, apa yang bertambah parah, dan bagaimana memaksimalkan satu-satunya sumber daya kami yang benar-benar langka: waktu dan perhatian manusia.

Commit pertama ke repositori kosong dilakukan pada akhir Agustus 2025.

Scaffold awal—struktur repositori, konfigurasi CI, aturan pemformatan, penyiapan package manager, dan kerangka kerja aplikasi—dihasilkan oleh Codex CLI menggunakan GPT‑5, dipandu oleh sejumlah kecil templat yang sudah ada. Bahkan file AGENTS.md awal yang mengarahkan para agen tentang cara bekerja di repositori itu sendiri ditulis oleh Codex.

Tidak ada kode yang ditulis oleh manusia yang sudah ada sebelumnya yang menjadi landasan sistem. Sejak awal, repositori dibentuk oleh agen.

Lima bulan kemudian, repositori tersebut berisi sekitar satu juta baris kode yang mencakup logika aplikasi, infrastruktur, alat, dokumentasi, dan utilitas pengembang internal. Selama periode tersebut, sekitar 1.500 pull request telah dibuka dan digabungkan dengan tim kecil yang hanya terdiri dari tiga insinyur yang mengendalikan Codex. Ini berarti rata-rata throughput sebesar 3,5 PR per insinyur per hari, dan secara mengejutkan, throughput tersebut telah meningkat seiring dengan pertumbuhan tim menjadi tujuh insinyur saat ini. Yang penting, ini bukan sekadar keluaran untuk keluaran itu sendiri: produk ini telah digunakan oleh ratusan pengguna internal, termasuk pengguna internal yang aktif setiap hari.

Sepanjang proses pengembangan, manusia tidak pernah secara langsung menyumbangkan kode. Ini menjadi filosofi inti bagi tim: tidak ada kode yang ditulis secara manual.

Kurangnya pengodean manusia secara langsung memperkenalkan jenis pekerjaan teknik yang berbeda, yang berfokus pada sistem, kerangka, dan pemanfaatan.

Kemajuan awal lebih lambat daripada yang kami harapkan, bukan karena Codex tidak mampu, tetapi karena lingkungannya kurang terdefinisi. Agen kekurangan alat, abstraksi, dan struktur internal yang dibutuhkan untuk mencapai kemajuan menuju tujuan tingkat tinggi. Tugas utama tim teknik kami adalah mendorong para agen melakukan pekerjaan yang bermanfaat.

Dalam praktiknya, ini berarti bekerja secara mendalam: menguraikan tujuan yang lebih besar menjadi blok-blok pembangun yang lebih kecil (desain, kode, peninjauan, pengujian, dll), mendorong agen untuk membangun blok-blok tersebut, dan menggunakannya untuk membuka tugas yang lebih kompleks. Ketika sesuatu gagal, solusinya hampir tidak pernah “berusaha lebih keras.” Karena satu-satunya cara untuk membuat kemajuan adalah dengan membuat Codex melakukan pekerjaan tersebut, para insinyur manusia selalu turun tangan dalam tugas itu dan bertanya: “kemampuan apa yang kurang, dan bagaimana kita membuatnya mudah dipahami dan dapat ditegakkan untuk agen?”

Manusia berinteraksi dengan sistem hampir sepenuhnya melalui prompt: seorang insinyur menjelaskan sebuah tugas, menjalankan agen, dan mengizinkannya untuk membuka pull request. Untuk menyelesaikan PR, kami menginstruksikan Codex untuk meninjau perubahannya sendiri secara lokal, meminta peninjauan tambahan dari agen tertentu baik secara lokal maupun di cloud, menanggapi umpan balik dari manusia atau agen, dan mengulangi proses ini dalam sebuah siklus hingga semua agen peninjau merasa puas (ini secara efektif adalah Ralph Wiggum Loop⁠(terbuka di jendela baru)). Codex menggunakan alat pengembangan standar kami secara langsung (gh, skrip lokal, dan keterampilan yang disematkan di repositori) untuk mengumpulkan konteks tanpa manusia menyalin dan menempelkan ke dalam CLI.

Manusia dapat meninjau pull request, tetapi tidak diwajibkan untuk melakukannya. Seiring waktu, kami telah mendorong hampir semua upaya peninjauan untuk ditangani dari agen ke agen.

Seiring throughput kode meningkat, hambatan kami menjadi kapasitas QA manusia. Karena kendala tetap adalah waktu dan perhatian manusia, kami telah berupaya menambahkan lebih banyak kapabilitas pada agen dengan membuat hal-hal seperti antarmuka pengguna aplikasi, log, dan metrik aplikasi itu sendiri dapat dibaca langsung oleh Codex.

Sebagai contoh, kami membuat aplikasi dapat di-boot per git worktree, sehingga Codex dapat meluncurkan dan mengendalikan satu instans per perubahan. Kami juga menghubungkan Chrome DevTools Protocol ke dalam runtime agen dan menciptakan keterampilan untuk bekerja dengan snapshot DOM, tangkapan layar, dan navigasi. Ini memungkinkan Codex untuk mereproduksi bug, memvalidasi perbaikan, dan menalar tentang perilaku UI secara langsung.

Kami melakukan hal yang sama untuk alat observabilitas. Log, metrik, dan jejak diekspos ke Codex melalui tumpukan observabilitas lokal yang bersifat sementara untuk setiap worktree. Codex bekerja pada versi aplikasi yang sepenuhnya terisolasi—termasuk log dan metriknya, yang akan dihapus setelah tugas tersebut selesai. Agen dapat mengkueri log dengan LogQL dan metrik dengan PromQL. Dengan konteks tersedia, prompt seperti “pastikan startup layanan selesai dalam waktu kurang dari 800ms” atau “tidak ada rentang dalam empat perjalanan pengguna kritis ini yang melebihi dua detik” menjadi dapat diatasi.

Kami secara rutin melihat satu kali run Codex mengerjakan satu tugas selama lebih dari enam jam (sering kali saat manusia sedang tidur).

Manajemen konteks adalah salah satu tantangan terbesar dalam membuat agen efektif dalam menangani tugas-tugas besar dan kompleks. Salah satu pelajaran paling awal yang kami pelajari itu sederhana: berikan Codex peta, bukan manual instruksi setebal 1.000 halaman.

Kami mencoba pendekatan “satu AGENTS.md⁠(terbuka di jendela baru) besar”. Dan gagal dengan cara yang dapat diprediksi:

• Konteks adalah sumber daya yang langka. File instruksi raksasa mengesampingkan tugas, kode, dan dokumen yang relevan—sehingga agen baik melewatkan batasan-batasan utama atau mulai mengoptimalkan untuk batasan yang salah.
• Panduan yang terlalu banyak justru menjadi bukan panduan. Ketika semuanya “penting,” tidak ada yang penting. Agen akhirnya mencocokkan pola secara lokal daripada menavigasi dengan sengaja.
• Membusuk secara seketika. Buku petunjuk monolitik berubah menjadi kuburan aturan usang. Agen tidak dapat mengetahui apa yang masih benar, manusia berhenti memeliharanya, dan file tersebut diam-diam menjadi gangguan yang menarik.
• Sulit untuk memverifikasi. Satu blob tidak cocok untuk pemeriksaan mekanis (cakupan, kebaruan, kepemilikan, tautan silang), sehingga penyimpangan tidak dapat dihindari.

Jadi alih-alih memperlakukan AGENTS.md sebagai ensiklopedia, kami memperlakukannya sebagai daftar isi.

Basis pengetahuan repositori berada dalam direktori docs/ yang terstruktur dan dianggap sebagai sistem pencatatan resmi. AGENTS.md yang singkat (sekitar 100 baris) disisipkan ke dalam konteks dan terutama berfungsi sebagai peta, dengan petunjuk ke sumber kebenaran yang lebih mendalam di tempat lain.

Dokumentasi desain dikatalogkan dan diindeks, termasuk status verifikasi dan serangkaian keyakinan inti yang mendefinisikan prinsip operasional yang mengutamakan agen. Dokumentasi Arsitektur⁠(terbuka di jendela baru) menyediakan peta tingkat atas dari domain dan pelapisan paket. Dokumen kualitas menilai setiap domain produk dan lapisan arsitektur, serta melacak kesenjangan dari waktu ke waktu.

Rencana diperlakukan sebagai artefak utama. Rencana sementara yang ringan digunakan untuk perubahan kecil, sementara pekerjaan yang kompleks dicatat dalam rencana eksekusi⁠(terbuka di jendela baru) dengan log kemajuan dan keputusan yang dimasukkan ke dalam repositori. Rencana aktif, rencana yang telah selesai, dan utang teknis yang diketahui semuanya diberi versi dan ditempatkan bersama, memungkinkan agen beroperasi tanpa bergantung pada konteks eksternal.

Ini memungkinkan pengungkapan progresif: para agen memulai dengan titik masuk yang kecil dan stabil serta diajarkan ke mana harus melihat selanjutnya, alih-alih merasa kewalahan sejak awal.

Kami menegakkan ini secara mekanis. Linter khusus dan pekerjaan CI memvalidasi bahwa basis pengetahuan sudah terkini, saling tertaut, dan terstruktur dengan benar. Agen “doc-gardening” yang berulang memindai dokumentasi yang basi atau usang yang tidak mencerminkan perilaku kode yang sebenarnya dan membuka pull request untuk perbaikan.

Seiring berkembangnya basis kode, kerangka kerja Codex untuk keputusan desain juga perlu berkembang.

Karena repositori ini sepenuhnya dibuat oleh agen, dioptimalkan pertama-tama untuk legibilitas Codex. Dengan cara yang sama seperti tim berupaya meningkatkan kemudahan navigasi kode mereka bagi rekrutan insinyur baru, tujuan para insinyur manusia kami adalah memungkinkan sebuah agen untuk menalar tentang seluruh domain bisnis langsung dari repositori itu sendiri.

Dari sudut pandang agen, apa pun yang tidak dapat diaksesnya dalam konteks saat berjalan secara efektif tidak ada. Pengetahuan yang ada di Google Docs, utas obrolan, atau di kepala orang tidak dapat diakses oleh sistem. Artefak yang diberi versi dan bersifat lokal di repositori (misalnya, kode, markdown, skema, rencana yang dapat dieksekusi) adalah satu-satunya hal yang dapat dilihatnya.

Kami mempelajari bahwa kami perlu memasukkan makin banyak konteks ke dalam repo seiring waktu. Diskusi di Slack yang menyelaraskan tim pada pola arsitektur itu? Jika tidak dapat ditemukan oleh agen, maka hal itu tidak dapat dibaca, sama seperti halnya tidak akan diketahui oleh karyawan baru yang bergabung tiga bulan kemudian.

Memberikan lebih banyak konteks kepada Codex berarti mengatur dan menampilkan informasi yang tepat agar agen dapat menalar berdasarkan informasi tersebut, daripada membebaninya dengan instruksi ad-hoc. Dengan cara yang sama seperti Anda mengajari rekan satu tim baru tentang prinsip produk, norma rekayasa, dan budaya tim (termasuk preferensi emoji), memberikan informasi ini kepada agen menghasilkan keluaran yang lebih selaras.

Pembingkaian ini memperjelas banyak pertukaran. Kami mengutamakan dependensi dan abstraksi yang dapat sepenuhnya diinternalisasi dan dipertimbangkan dalam repo. Teknologi yang sering digambarkan sebagai “membosankan” cenderung lebih mudah bagi agen untuk dimodelkan karena komposabilitas, stabilitas API, dan representasi dalam set pelatihan. Dalam beberapa kasus, lebih murah bagi agen untuk mengimplementasikan ulang subset fungsionalitas daripada mengatasi perilaku upstream yang tidak jelas dari pustaka publik. Misalnya, alih-alih menggunakan paket generik bergaya p-limit, kami mengimplementasikan pembantu pemetaan dengan konkurensi kami sendiri: pembantu ini terintegrasi erat dengan instrumentasi OpenTelemetry kami, memiliki cakupan pengujian 100%, dan berperilaku persis seperti yang diharapkan oleh runtime kami.

Menarik lebih banyak bagian sistem ke dalam bentuk yang dapat diperiksa, divalidasi, dan dimodifikasi langsung oleh agen meningkatkan daya ungkit—bukan hanya untuk Codex, tetapi juga untuk agen lain (misalnya, Aardvark) yang juga sedang mengerjakan basis kode tersebut.

Dokumentasi saja tidak dapat menjaga basis kode yang sepenuhnya dihasilkan oleh agen tetap koheren. Dengan menegakkan invarian, bukan mengatur secara mikro implementasi, kami memungkinkan agen merilis dengan cepat tanpa merusak fondasi. Misalnya, kami mengharuskan Codex untuk mengurai bentuk data di batas⁠(terbuka di jendela baru), tetapi tidak menentukan cara spesifik untuk melakukannya (model tampaknya menyukai Zod, tetapi kami tidak menentukan pustaka spesifik tersebut).

Agen paling efektif di lingkungan dengan batasan ketat dan struktur yang dapat diprediksi⁠(terbuka di jendela baru), sehingga kami membangun aplikasi berdasarkan model arsitektur yang kaku. Setiap domain bisnis dibagi menjadi serangkaian lapisan tetap, dengan arah dependensi yang divalidasi secara ketat dan serangkaian tepi yang diizinkan yang terbatas. Kendala ini ditegakkan secara mekanis melalui linter kustom (tentu saja dihasilkan oleh Codex!) dan pengujian struktural.

Diagram di bawah ini menunjukkan aturan: dalam setiap domain bisnis (misalnya, Pengaturan Aplikasi), kode hanya dapat bergantung “ke depan” melalui serangkaian lapisan tetap (Types → Config → Repo → Service → Runtime → UI). Masalah lintas fungsi (otentikasi, konektor, telemetri, bendera fitur) diakses melalui antarmuka tunggal yang eksplisit: Penyedia. Hal lain apa pun tidak diizinkan dan ditegakkan secara mekanis.

Ini adalah jenis arsitektur yang biasanya Anda tunda hingga Anda memiliki ratusan insinyur. Dengan agen pengkodean, ini adalah prasyarat awal: batasan adalah yang memungkinkan kecepatan tanpa penurunan atau penyimpangan arsitektur.

Dalam praktiknya, kami menegakkan aturan ini dengan linter khusus dan pengujian struktural, ditambah sejumlah kecil “invarian selera.” Misalnya, kami secara statis menegakkan logging terstruktur, konvensi penamaan untuk skema dan tipe, batas ukuran file, serta persyaratan keandalan khusus platform dengan lint kustom. Karena lint bersifat kustom, kami menulis pesan kesalahan untuk menyisipkan instruksi perbaikan ke dalam konteks agen.

Dalam alur kerja yang mengutamakan manusia, aturan-aturan ini mungkin terasa pedantis atau membatasi. Dengan agen, mereka menjadi pengganda: setelah dikodekan, mereka dapat diterapkan di mana-mana sekaligus.

Pada saat yang sama, kami secara eksplisit menyatakan di mana batasan itu penting dan di mana tidak. Ini mirip dengan memimpin organisasi platform teknik berskala besar: tegakkan batasan secara terpusat, izinkan otonomi secara lokal. Anda sangat peduli tentang batasan, ketepatan, dan reproduktibilitas. Dalam batasan tersebut, Anda memberikan tim—atau agen—kebebasan yang signifikan dalam cara solusi diungkapkan.

Kode yang dihasilkan tidak selalu sesuai dengan preferensi gaya manusia, dan itu tidak masalah. Selama outputnya benar, dapat dipelihara, dan mudah dibaca untuk eksekusi agen di masa mendatang, itu memenuhi standar.

Selera manusia terus dimasukkan kembali ke dalam sistem. Komentar ulasan, pull request refactoring, dan bug yang terlihat oleh pengguna dicatat sebagai pembaruan dokumentasi atau dikodekan langsung ke dalam alat. Ketika dokumentasi tidak memadai, kami mempromosikan aturan tersebut menjadi kode

Seiring throughput Codex meningkat, banyak norma rekayasa konvensional menjadi tidak efektif.

Repositori beroperasi dengan gerbang penggabungan yang memblokir seminimal mungkin. Pull request bersifat sementara. Flake test sering kali ditangani dengan pengujian ulang sebagai tindak lanjut, alih-alih menghambat kemajuan tanpa batas waktu. Dalam sistem di mana throughput agen jauh melampaui perhatian manusia, koreksi murah, dan menunggu mahal.

Ini akan menjadi tindakan yang tidak bertanggung jawab dalam lingkungan dengan throughput rendah. Di sini, sering kali merupakan kompromi yang tepat.

Ketika kami mengatakan bahwa basis kode dihasilkan oleh agen Codex, yang kami maksud adalah seluruh elemen dalam basis kode.

Agen memproduksi:

• Kode produk dan pengujian
• Konfigurasi CI dan alat rilis
• Alat pengembang internal
• Sejarah dokumentasi dan desain
• Alat evaluasi
• Komentar dan tanggapan peninjauan
• Skrip yang mengelola repositori itu sendiri
• File definisi dasbor produksi

Manusia selalu tetap dilibatkan, tetapi bekerja pada lapisan abstraksi yang berbeda dari yang biasa kita lakukan. Kami memprioritaskan pekerjaan, menerjemahkan masukan pengguna menjadi kriteria penerimaan, dan memvalidasi hasil. Ketika agen mengalami kesulitan, kami menganggapnya sebagai sinyal: identifikasi apa yang kurang—alat, pembatas, dokumentasi—dan masukkan kembali ke repositori, selalu dengan meminta Codex sendiri menulis perbaikannya.

Agen menggunakan alat pengembangan standar kami secara langsung. Mereka menarik umpan balik peninjauan, merespons secara inline, mendorong pembaruan, dan sering melakukan squash dan merge pull request mereka sendiri.

Seiring makin banyak siklus pengembangan yang dikodekan langsung ke dalam sistem—pengujian, validasi, peninjauan, penanganan umpan balik, dan pemulihan—repositori baru-baru ini melampaui ambang batas yang signifikan di mana Codex dapat menggerakkan fitur baru secara menyeluruh.

Dengan satu prompt, agen sekarang dapat:

• Memvalidasi keadaan terkini dari basis kode
• Mereproduksi bug yang dilaporkan
• Rekam video yang mendemonstrasikan kegagalan
• Mengimplementasikan perbaikan
• Memvalidasikan perbaikan dengan mengoperasikan aplikasi
• Merekam video kedua yang mendemonstrasikan resolusi
• Membuka sebuah pull request
• Tanggapi masukan dari agen dan manusia
• Mendeteksi dan memperbaiki kegagalan build
• Mengeskalasi ke manusia hanya ketika penilaian diperlukan
• Menggabungkan perubahan tersebut

Perilaku ini sangat bergantung pada struktur dan alat khusus dari repositori ini dan tidak boleh diasumsikan dapat digeneralisasi tanpa investasi serupa—setidaknya, belum.

Otonomi penuh agen juga memperkenalkan masalah baru. Codex mereplikasi pola yang sudah ada di repositori—bahkan yang tidak merata atau kurang optimal. Seiring waktu, hal ini pasti akan menyebabkan penyimpangan.

Pada awalnya, manusia menangani ini secara manual. Tim kami dulu menghabiskan setiap hari Jumat (20% dari satu minggu) untuk membersihkan “sampah AI.” Tidak mengherankan, hal itu tidak dapat diskalakan.

Sebagai gantinya, kami mulai mengintegrasikan apa yang kami sebut “prinsip-prinsip emas” langsung ke dalam repositori dan membangun proses pembersihan berkala. Prinsip-prinsip ini merupakan aturan mekanis terstruktur yang memastikan basis kode tetap mudah dipahami dan konsisten bagi eksekusi agen di masa mendatang. Sebagai contoh: (1) kami lebih memilih paket utilitas bersama dibanding helper buatan sendiri untuk menjaga invarian tetap terpusat, dan (2) kami tidak menguji data dengan cara “gaya YOLO”—kami memvalidasi batasan atau mengandalkan SDK bertipe agar agen tidak dapat secara tidak sengaja membangun sesuatu berdasarkan bentuk data yang hanya ditebak. Secara berkala, kami memiliki serangkaian tugas latar belakang Codex yang memindai penyimpangan, memperbarui nilai kualitas, dan membuka pull request refaktorisasi yang ditargetkan. Sebagian besar dari ini dapat ditinjau dalam waktu kurang dari satu menit dan digabungkan secara otomatis.

Ini berfungsi seperti pengelolaan memori otomatis. Utang teknis itu seperti pinjaman berbunga tinggi: hampir selalu lebih baik untuk melunasinya secara berkelanjutan dalam jumlah kecil daripada membiarkannya berbunga majemuk dan menanganinya dalam ledakan yang menyakitkan. Selera manusia ditangkap sekali, kemudian diterapkan secara terus-menerus pada setiap baris kode. Hal ini juga memungkinkan kami untuk mendeteksi dan mengatasi pola-pola yang buruk secara harian, daripada membiarkannya menyebar di basis kode selama berhari-hari atau berminggu-minggu.

Strategi ini sejauh ini telah berhasil dengan baik hingga peluncuran internal dan adopsi di OpenAI. Membangun produk nyata untuk pengguna nyata membantu menambatkan investasi kami pada realitas dan memandu kami menuju pemeliharaan jangka panjang yang berkelanjutan.

Yang belum kami ketahui adalah bagaimana koherensi arsitektural berkembang selama bertahun-tahun dalam sistem yang sepenuhnya dihasilkan oleh agen. Kami masih mempelajari di mana penilaian manusia memberikan pengaruh terbesar dan bagaimana mengodekan penilaian tersebut agar dapat terakumulasi. Kami juga tidak tahu bagaimana sistem ini akan berkembang seiring dengan model-model yang terus menjadi lebih canggih dari waktu ke waktu.

Yang menjadi jelas: membangun perangkat lunak masih menuntut kedisiplinan, tetapi kedisiplinan itu lebih terlihat dalam struktur pendukung daripada dalam kode. Perkakas, abstraksi, dan umpan balik yang menjaga basis kode tetap koheren menjadi makin penting.

Tantangan tersulit kami saat ini berpusat pada perancangan lingkungan, siklus umpan balik, dan sistem kontrol yang membantu agen mencapai tujuan kami: membangun dan memelihara perangkat lunak yang kompleks dan andal dalam skala besar.

Seiring agen seperti Codex mengambil porsi yang lebih besar dari siklus hidup perangkat lunak, pertanyaan-pertanyaan ini akan menjadi makin penting. Kami berharap bahwa berbagi beberapa pelajaran awal membantu Anda mempertimbangkan di mana harus menginvestasikan upaya Anda sehingga Anda dapat langsung membangun sesuatu.