Diagram jalur rekayasa internal OpenAI menjadi semi-viral di X minggu ini. Diagram tersebut menunjukkan sepuluh kotak, mulai dari "pembuat perangkat lunak mendefinisikan hasil" hingga agen yang memantau grafik produksi dan mengajukan laporan insidennya sendiri. Sumbernya adalah buletin Gergely Orosz, The Pragmatic Engineer, dalam artikel berjudul "OpenAI’s agentic software factory", dan diagram itu sendiri menyebar dengan cepat di X.
Sebagian besar reaksi melewatkan detail penting: beberapa dari sepuluh kotak tersebut menjelaskan pengaturan rekayasa internal OpenAI, bukan produk Codex yang dapat Anda instal hari ini. Menyamakan keduanya adalah kesalahan paling umum dalam diskusi seputar diagram ini. Artikel ini membahas kotak demi kotak dan berhenti pada satu tahap yang benar-benar dapat ditiru oleh tim eksternal: CI.
Sepuluh tahapan, secara berurutan
Diagram ini dibaca dari kiri ke kanan sebagai sebuah siklus: seorang manusia menetapkan tujuan, sebuah agen menulis kode, gerbang otomatis memeriksanya, dan agen terus berulang hingga gerbang-gerbang tersebut lulus. Berikut adalah urutan lengkapnya dengan batasan internal-versus-dikirimkan yang ditandai untuk setiap tahap.
| # | Tahap | Apa yang terjadi | Hanya internal atau dikirimkan dalam Codex |
|---|---|---|---|
| 1 | Pengembang perangkat lunak | Seorang insinyur atau PM mendefinisikan hasil | Langkah manusia, bukan perangkat lunak |
| 2 | Codex menulis/mengedit kode | Menarik konteks dari sumber, dokumen, GitHub, Slack, Notion, keterampilan internal, dan sistem data seperti Databricks dan Datadog | Codex yang dikirimkan menulis kode; grafik konteks internal (Slack, Notion, data internal) hanya untuk internal |
| 3 | CI: bangun + uji | Pipeline sedang dibangun kembali untuk beban skala agen, ditambah "Perf Harness" | Dikirimkan (CI Anda sendiri); pekerjaan penskalaan khusus OpenAI adalah internal |
| 4 | Peninjauan kode agensi | Peninjauan paralel dari agen spesialis data, infrastruktur, cloud, dan keamanan, ditambah klasifikasi risiko | Hanya internal |
| 5 | Keputusan risiko rendah | Perubahan risiko rendah dilanjutkan; perubahan risiko tinggi mendapatkan peninjauan insinyur manusia tambahan | Hanya internal |
| 6 | Penerapan agensi | Sebuah agen "mengawasi" perubahan ke produksi, termasuk peluncuran fitur-flag, dan membangun dasbornya sendiri | Hanya internal |
| 7 | Pemantauan produksi | Agen memantau grafik, sinyal, dan peringatan pada tumpukan observabilitas internal OpenAI | Hanya internal |
| 8 | Gangguan terdeteksi -> Sevbot | Menyelidiki insiden, mengusulkan mitigasi, menjawab pertanyaan | Hanya internal |
| 9 | Pabrik Kinerja | Menyaring peringatan duplikat, menemukan regresi latensi, mengusulkan perbaikan | Hanya internal |
| 10 | Kembali berulang | Agen memperbaiki masalah hingga CI dan peninjauan lulus, lalu pengembang mendapatkan perbaikan yang diusulkan | Menggambarkan siklus internal |
Tepat satu tahap, yaitu langkah CI, ditambah sebagian dari tahap 2, adalah sesuatu yang bisa ditunjuk oleh tim eksternal dan mengatakan "kami juga punya itu." Segala sesuatu mulai dari peninjauan agensi hingga Sevbot adalah pembangunan internal OpenAI.
Kolom "hanya internal" itu juga merupakan masalah sumber. Bagian-bagian yang disimpan OpenAI di balik firewall-nya, orkestrasi, gerbang peninjauan, persetujuan manusia, adalah lapisan yang justru tidak dimiliki oleh sebagian besar tim. Sharkly adalah salah satu tempat netral penyedia untuk membangunnya: seorang pengembang mendefinisikan hasil sebagai Tugas, menetapkannya kepada Agen, dan Agen berjalan di Komputer menggunakan Runtime apa pun yang sudah Anda miliki, Claude Code atau Codex. "Siap untuk Dirilis" adalah status yang harus diubah oleh manusia sebelum sesuatu mencapai "Selesai", sehingga persetujuan tetap menjadi pekerjaan manusia, bukan pipeline. Sharkly tidak menggantikan Codex atau menulis kode itu sendiri; ia menjalankan Runtime yang sudah Anda bayar dan memberikan tempat bagi siklus di sekitarnya untuk berfungsi.
Tahap 1-2: manusia masih menetapkan tujuan, Codex masih menulis kode
Seorang pengembang perangkat lunak, yang berarti seorang insinyur atau manajer produk, mendefinisikan hasil yang mereka inginkan. Codex kemudian membuat serangkaian perubahan kode hingga mencapai tujuan tersebut dan memverifikasi hasilnya berfungsi. Siklus verifikasi itulah bagian dari Codex yang dikirimkan hari ini: aplikasi desktop (Mac pada Februari 2026, Windows pada Maret), integrasi ChatGPT Work mulai Juli 2026, plugin dan keterampilan berbasis peran, serta perintah /goal untuk tugas-tugas yang berjalan dalam jangka waktu panjang. Jika Anda ingin mengetahui mekanisme perintah tersebut, kami telah membahas /goal untuk eksekusi agen otonom secara terpisah.
Yang tidak dikirimkan adalah grafik konteks yang memberi makan Codex secara internal: hampir setiap sistem OpenAI, mulai dari utas Slack hingga dasbor Databricks. Artikel Orosz menyatakannya secara langsung: Codex internal OpenAI “jauh lebih canggih daripada rekannya di eksternal karena terhubung ke hampir setiap sistem OpenAI.” Kesenjangan antara Codex internal dan eksternal inilah tesis sebenarnya dari artikel tersebut.
Tahap 3: CI adalah tempat siklus benar-benar ditegakkan
Ini adalah tahap yang patut diperlambat, karena inilah satu-satunya kotak dalam seluruh pipeline yang sudah dimiliki oleh tim mana pun, bukan hanya OpenAI. Artikel tersebut mencatat CI di OpenAI sedang dibangun kembali untuk peningkatan beban sekitar 10x selama sekitar enam bulan, karena agen sekarang mendorong lebih banyak perubahan melalui pipeline daripada yang pernah dilakukan manusia sendiri. Sebuah "Perf Harness" berjalan bersamanya untuk menangkap regresi kinerja sebelum mencapai peninjauan.
Inilah bagian yang terlewatkan: agen yang "memperbaiki masalah hingga CI dan peninjauan lulus" hanya dapat dipercaya sejauh apa yang benar-benar diperiksa oleh CI. Jika rangkaian pengujian Anda mencakup logika unit tetapi bukan kontrak API, agen dapat berulang ke pembangunan hijau yang masih menghasilkan perubahan yang merusak. Kode status, bentuk skema, perilaku otentikasi, dan anggaran waktu respons di bawah beban adalah kelas pemeriksaan yang sebagian besar tim kurang investasi relatif terhadap pengujian unit. Inilah kotak tempat Apidog cocok: menjalankan skenario pengujian Apidog melalui Apidog CLI di dalam langkah CI Anda memberikan agen gerbang yang lebih sulit untuk dipenuhi daripada "kode telah dikompilasi." Kami telah menulis tentang cara menyambungkannya di Apidog CLI di dalam Codex. Itulah satu-satunya peran Apidog dalam pipeline ini. Ini bukan agen, dan tidak menyentuh deploy, peninjauan, atau respons insiden.
Tahap 4-5: agen peninjau spesialis dan keputusan risiko
Setelah CI lolos, pengaturan internal OpenAI mengarahkan perubahan melalui peninjauan paralel dari agen spesialis data, infrastruktur, cloud, dan keamanan. Orosz menggambarkannya sebagai "setara dengan memiliki pakar domain manusia dari setiap tim infrastruktur yang relevan untuk meninjau setiap perubahan," yang merupakan standar peninjauan yang lebih berat daripada yang dapat dipenuhi oleh sebagian besar tim manusia untuk setiap permintaan tarik. Fitur peninjauan kode yang dikirimkan Codex adalah hal yang berbeda dan lebih ringan daripada agen spesialis internal ini; jika Anda memutuskan apa yang dapat dilakukan oleh peninjau agensi tujuan umum untuk tumpukan Anda sendiri, rangkuman alat peninjauan kode AI kami adalah titik awal yang adil, dan artikel pendamping kami tentang peninjauan agensi dan desain gerbang risiko OpenAI membahas lebih dalam tentang satu kotak ini (saudara, konfirmasi tayang sebelum menautkan).
Klasifikasi risiko kemudian memutuskan apa yang terjadi selanjutnya. Area kode berisiko rendah dapat mengizinkan agen untuk secara otomatis menyetujui PR-nya sendiri, memotong persetujuan manusia dari siklus sepenuhnya untuk jenis perubahan tersebut. Perubahan berisiko tinggi mendapatkan lebih banyak pemeriksaan peninjauan AI, peninjauan manusia wajib, atau keduanya. OpenAI belum mempublikasikan aturan pasti tentang apa yang tergolong berisiko rendah, dan kami tidak akan menebak-nebak di sini. Satu ide yang berlaku umum melampaui pengaturan spesifik OpenAI: perubahan yang merusak kontrak API publik tidak boleh diklasifikasikan sebagai risiko rendah, tidak peduli seberapa kecil perbedaan yang terlihat. Alat bantu yang mengutamakan spesifikasi yang menjaga definisi OpenAPI dan pengujian Anda di tempat yang sama membuat pembedaan itu lebih mudah ditegakkan secara otomatis, karena perbedaan skema adalah sinyal risiko yang jauh lebih bersih daripada perbedaan jumlah baris.
Tahap 6-8: deploy, pantau, dan respons, tanpa manusia dipanggil terlebih dahulu
Jika suatu perubahan lolos peninjauan, agen internal "mengawasi" perubahan tersebut ke produksi, termasuk peluncuran fitur-flag, dan membangun dasbor pemantauannya sendiri untuk perubahan spesifik tersebut. Setelah tayang, agen yang sama (atau agen terkait) memantau grafik dan peringatan pada tumpukan observabilitas internal OpenAI. Ketika terjadi masalah, Sevbot mengambil alih: ia menyelidiki insiden tersebut, mengusulkan mitigasi, dan menjawab pertanyaan pengembang di Slack. Penting untuk bersikap presisi tentang apa yang tidak dilakukan Sevbot. Ia mengusulkan; ia tidak mengeksekusi. Seorang manusia masih mengizinkan mitigasi dan masih memegang oncall. Seperti yang dinyatakan jelas dalam artikel, “tugas oncall bukanlah sesuatu dari masa lalu.” Tidak ada tahap 6 hingga 8 yang ada dalam produk Codex yang dapat Anda beli.
Tahap 9-10: regresi kinerja dan siklus kembali
Pabrik Kinerja (Perf Factory) berjalan berdampingan dengan jalur insiden. Ia menyaring peringatan dan dasbor, menyaring sinyal duplikat, menemukan regresi latensi nyata, dan mengusulkan perbaikan, yang kemudian mengalir kembali ke pengembang awal. Bersama Sevbot, ini adalah jawaban OpenAI untuk kelelahan peringatan (alert fatigue): alih-alih insinyur on-call yang menangani setiap ping, agen terlebih dahulu menyaring dan mendiagnosis. Siklus ditutup dengan tahap 10: agen terus merevisi hingga CI dan setiap lapisan peninjauan lulus.
Mengapa batas internal/eksternal penting untuk tim Anda
Jika Anda mengevaluasi apakah rekayasa agensi "gaya OpenAI" adalah sesuatu yang dapat diadopsi tim Anda pada kuartal ini, jawaban jujurnya adalah: Anda dapat mengadopsi tahap 1 hingga 3 hari ini, dan tahap 4 hingga 9 menggambarkan arah, bukan fitur yang dapat dibeli. Ini bukan kritik terhadap OpenAI; perangkat internal pada skala tersebut membutuhkan waktu bertahun-tahun. Salah satu proyek sumber terbuka, orchflows, adalah upaya publik untuk mendekati siklus ini dengan perintah /software-factory untuk Claude Code dan Codex; README-nya terus terang tentang tujuannya, berargumen bahwa Anda hanya membutuhkan dua keterampilan alih-alih banyak. Ini adalah proyek awal yang tidak terafiliasi, bukan rilis OpenAI, jadi anggaplah sebagai implementasi referensi daripada pabrik siap pakai.
Adopsi di dalam OpenAI sendiri telah bergerak cepat pada bagian-bagian yang tidak memerlukan plumbing internal kustom: penggunaan Codex di tim non-teknik meningkat dari sekitar 0% menjadi 90% dalam empat bulan, Februari hingga Mei 2026. Itu adalah sinyal yang lebih tajam daripada diagram pipeline saja, karena menunjukkan bahwa bagian yang mudah (agen yang menulis kode menuju tujuan yang ditetapkan) sudah menjadi hal normal di OpenAI, sementara bagian yang sulit (deploy agensi, peninjauan, dan respons insiden yang terhubung ke setiap sistem internal) masih bersifat khusus.
Apa yang tetap manusiawi
Artikel ini berhati-hati mengenai apa yang tidak berubah. Pengembang masih mendefinisikan hasil. Manusia masih menyetujui perubahan berisiko tinggi dan mengotorisasi mitigasi insiden. Seseorang masih meninjau apa yang Sevbot lakukan setelah kejadian, dan rotasi oncall masih ada. Baris penutup artikel ini menangkap pergeseran itu lebih baik daripada statistik apa pun: "Penilaian, prioritas, dan selera menjadi lebih penting." Dua peringatan juga menjaga hal ini tetap pada jalurnya: peninjauan toko aplikasi seluler masih merupakan hambatan manual yang tidak dapat dihindari agen, dan penskalaan infrastruktur adalah pertarungan bulanan, bukan masalah yang sudah terpecahkan.
Jika Anda sedang membangun versi Anda sendiri dari tahap 1 hingga 3 daripada menunggu vendor untuk mengirimkan tahap 4 hingga 9, mulailah dengan gerbang yang sudah ada di pipeline Anda: CI. Artikel pendamping kami tentang membangun pabrik perangkat lunak yang lebih ringan di sekitar Codex menjelaskan pembangunan tersebut (saudara, konfirmasi tayang sebelum menautkan), dan desain Sevbot/Perf Factory mendapatkan perlakuan tersendiri dalam artikel kami tentang pabrik kinerja dan Sevbot OpenAI (saudara, konfirmasi tayang sebelum menautkan). Agen yang berulang hingga pengujian lulus adalah ide yang bagus hanya jika pengujian yang dilaluinya benar-benar menyatakan sesuatu. Apidog menyimpan pengujian kontrak API di samping spesifikasi sehingga gerbang tersebut tetap jujur saat agen, bukan hanya manusia, mulai mendorong perubahan melaluinya.