[🤖] Saya Mencoba Menerapkan Graph Engineering pada Codex

✨ Ringkasan GPT-5.6 Sol

Setelah pekerjaan Codex selama 16 jam berakhir kacau, saya terus menguji apakah Graph Engineering benar-benar solusinya, mengecilkannya menjadi Gate Skill minimal, lalu mencobanya pada kontrak otorisasi nyata.

Kemarin, setelah berdiskusi panjang, saya menyelesaikan spesifikasi per halaman untuk perombakan total UI/UX dan menetapkan Goal Codex agar pengembangan dilakukan berdasarkan spesifikasi itu. Goal tersebut berjalan selama 16 jam.

Hari ini saya membuka layarnya dengan penuh harapan, tetapi hasilnya benar-benar buruk.

Dua hari sebelumnya saya sudah menulis bahwa saya perlu keluar dari ilusi keajaiban AI sekali jadi. Kali ini saya tidak hanya memberi instruksi satu baris. Saya sudah mendefinisikan pekerjaan per peran dan spesifikasi per halaman, termasuk kalender, table view, pencarian, filter, dan pemulihan kegagalan. Setelah melalui prototype yang gagal, saya bahkan membuat kriteria audit UI secara terpisah.

Namun setelah beberapa worker menulis kode semalaman dan melaporkan bahwa test serta audit sudah lulus, yang saya lihat justru layar administrasi lama yang begitu sulit dipahami sampai saya tidak mengerti apa yang hendak disampaikan. Ke mana kalender dan table view yang begitu sering saya bicarakan?

Token dalam jumlah besar telah digunakan, kode dalam jumlah besar telah berubah, dan laporan PASS menumpuk. Namun hasil yang sebenarnya saya inginkan tidak ada.

Saya kembali rendah hati. Lagi.

Karena itu saya memutuskan untuk mencoba menerapkan Graph Engineering pada Codex. Bukan sekadar mempelajari istilah terbaru atau langsung memasang framework raksasa, melainkan membuat bentuk terkecil yang benar-benar dapat mengurangi kegagalan yang baru saja saya alami.

Saya Mendapat Alasan untuk Mencoba Graph Engineering

Saya meminta AI menganalisis bagaimana hal ini bisa terjadi. Aturan bersama juga bermasalah, dan audit UI terlalu berfokus pada hal yang mudah diukur seperti ukuran huruf dan tinggi tombol. Namun masalah terbesar ada di tempat lain.

Saya tidak memeriksa setiap hasil antara yang dibuat Codex. Sesi implementasi menyatakan pekerjaannya sendiri selesai, lalu sesi lain mewarisi hasil itu dan terus membuat halaman serta backend berikutnya. Arsitektur informasi yang salah sejak awal menyebar ke banyak layar sebelum benar-benar diverifikasi. Ketika saya akhirnya membuka produk nyata, 16 jam pekerjaan sudah terbangun di atas arah yang keliru itu.

Jadi yang saya perlukan bukanlah cara membiarkan AI bekerja lebih lama.

Saya memerlukan struktur yang mencegah pekerjaan berikutnya dimulai jika hasil antara ternyata salah.

Saat terus membahas masalah ini dengan AI, saya menemukan istilah Graph Engineering. Pendekatan ini tidak menyerahkan semuanya pada loop panjang satu Agent, melainkan menghubungkan beberapa Agent, verifier, dan keputusan manusia sebagai node dan edge, lalu merancang secara eksplisit hasil seperti apa yang boleh membuka tahap selanjutnya. Ini terasa bukan sebagai teknologi yang sepenuhnya baru, tetapi lebih sebagai nama baru untuk gagasan workflow dan state machine yang sudah ada.¹

Hal pentingnya bukan menghafal satu buzzword lagi. Kini satu sesi Codex dapat menangani pekerjaan yang cukup besar, sehingga hasil sesi itu sendiri dapat dijadikan node dan syarat untuk beralih ke sesi berikutnya dapat dirancang.

Dalam percobaan saya, Graph Engineering dipetakan seperti ini:

• node: hasil antara yang dapat diperiksa pengguna secara mandiri
• edge: syarat yang mengembalikan pekerjaan untuk diperbaiki atau membawanya ke tugas berikutnya berdasarkan verdict audit
• state: catatan tentang hasil apa yang diaudit dengan kriteria apa dan tindakan apa yang kini diizinkan
• cycle: pengulangan yang hanya memperbaiki hasil yang sama lalu memeriksanya lagi ketika audit menemukan cacat

Memanggil banyak Agent saja bukanlah Graph Engineering. Inti percobaan saya adalah merancang topologi dan transisi state lebih dahulu agar node yang belum diverifikasi tidak dapat membuka edge sesudahnya.

Graph Pertama Saya Hanya Memiliki Sesi Kerja dan Sesi Audit

Ketika saya mengusulkan Graph Engineering untuk masalah ini, AI segera mulai memperbesar strukturnya. Coordinator, Worker, dan Auditor dipisahkan, lalu ditambahkan persetujuan arah oleh pengguna, versi kontrak, durable ledger, serta cold audit menyeluruh.

Masing-masing bukan gagasan yang salah. Namun saya khawatir.

“Bukankah ini menjadi rumit tanpa perlu?”

Jika untuk mencegah pekerjaan 16 jam menghabiskan seluruh token tanpa hasil saya malah membuka banyak Agent serta menumpuk state dan laporan, apa yang benar-benar berbeda? Jika menerapkan Graph Engineering sendiri berubah menjadi proyek besar, ia mungkin kembali hanya menyedot token.

Yang saya bayangkan jauh lebih sederhana.

Sesi kerja menyelesaikan satu hasil yang dapat diperiksa.
→ Hasil diserahkan ke sesi audit dan sesi kerja menunggu.
→ Sesi audit mengembalikan PASS atau permintaan perubahan.
→ Baru setelah itu sesi kerja bergerak lagi.

Saya bertanya apakah alur ini dapat dijadikan Skill agar dapat dipakai berulang kali. Namun AI terus membahas struktur sesi dan keterbatasan pemaksaan mekanis sehingga semuanya menjadi rumit. Saya bahkan membawa jawaban dari sesi lain dan bertanya lagi.

“Membuatnya sebagai Skill benar-benar tidak efisien? Serius? Bukankah kamu hanya bicara sesukamu?”

Saya juga terus meminta AI mengkritik, bukan sekadar menyetujui. Saya tidak ingin mendengar kesimpulan bahwa gagasan saya benar. Saya ingin tahu apakah cara ini sungguh dapat mencegah kegagalan 16 jam atau hanya menciptakan mainan baru yang terlihat canggih.

Saya Memperkecil Percobaan dengan Terus Membantah

Setelah beberapa kali peninjauan kritis, saya mengakui bahwa rancangan sederhana saya juga memiliki celah.

Jika sesi kerja ikut menentukan kriteria audit, ia dapat membuat kriteria yang menguntungkan hasilnya sendiri. Jika semua reasoning dan evaluasi diri worker diberikan kepada sesi audit, auditor mungkin hanya membaca ulang penjelasan worker alih-alih menilai secara mandiri. Jika pekerjaan berikutnya sudah dimulai selama audit, PASS gate tidak berarti apa-apa. Runtime bisa berubah sementara auditor melihat layar lama, atau PASS sebelumnya dapat diingat secara keliru setelah conversation compaction.

Sebaliknya, saya juga tidak perlu menerima seluruh usulan AI. Saya membuang tiga sesi berumur panjang, graph runtime terpisah, database, dashboard, audit setiap halaman, dan audit ulang total setiap kontrak berubah. Jika semua dibuat, sistem pengelolaannya akan lebih besar daripada produk.

Akhirnya hanya prinsip berikut yang saya pertahankan:

• Sesi utama menangani koordinasi sekaligus pekerjaan.
• Sesi audit terpisah hanya dibuka pada hasil yang benar-benar memerlukan Gate.
• Seluruh percakapan sebelumnya tidak diberikan kepada sesi audit.
• Hasil yang diaudit dibekukan, dan hasil itu maupun pekerjaan langsung sesudahnya tidak diubah sampai audit selesai.
• Kesalahan implementasi dibedakan dari kesalahan arah pekerjaan itu sendiri.
• Jika masalah penting masih tersisa setelah satu perbaikan dan audit ulang, patch dihentikan dan rencana dibuka kembali.
• Jika kontrak berubah, hanya pekerjaan yang terdampak yang diperiksa ulang.
• PASS audit tidak menggantikan persetujuan saya atas arah produk maupun izin deploy.

Yang terpenting, saya tidak akan menerapkan struktur ini pada semua pekerjaan. Salah ketik, bug yang selesai dengan satu test penentu, atau eksplorasi bebas yang jalurnya belum diketahui tidak memerlukan sesi audit. Gate hanya ditempatkan pada titik tempat hasil yang salah dapat mencemari banyak pekerjaan lanjutan.

Saya juga tidak otomatis menjadikan satu halaman sebagai satu unit. Jika pekerjaan pengguna adalah mencari di daftar, masuk ke detail, menyelesaikan tindakan, lalu kembali ke filter semula, seluruh journey itulah unit yang harus diperiksa. Sebaliknya, tidak perlu mengaudit terpisah setiap layar yang hanya mengulang pattern yang sama.

Dengan pemangkasan ini, graph sederhana yang saya inginkan tetap terjaga, sekaligus menjadi jelas mengapa harus berhenti dan apa yang harus diaudit.

Saya Memindahkan Graph Minimal ke Codex Skill

Akhirnya saya meminta Codex membuat Skill bersama bernama custom-graph-engineering-gate. OpenAI sudah menyediakan cara untuk menyimpan workflow berulang sebagai Skill dan memungkinkan Agent utama memanggil subagent terpisah lalu mengambil hasilnya.²³ Saya tidak perlu membuat service baru untuk mengatur bolak-balik antara sesi kerja dan audit.

Saya juga meminta agar pekerjaan tidak dibesarkan. Tidak ada script eksekusi, database terpisah, ataupun graph dashboard. Hanya isi Skill dan metadata minimum untuk menampilkannya di Codex.

Skill ini melakukan tiga hal utama.

Pertama, ia menilai apakah pekerjaan saat ini cukup penting untuk membuka Gate. Skill hanya digunakan ketika hasil antara yang salah dapat merusak beberapa hasil lanjutan.

Kedua, ia membekukan hasil yang akan diaudit dalam satu kalimat. Yang dicatat hanyalah hasil yang akan diterima pengguna, kriteria yang membedakan keberhasilan dan kegagalan, candidate yang tepat, jalur verifikasi normal, serta pekerjaan lanjutan langsung yang dibuka oleh PASS. Jumlah file yang diubah atau test yang dijalankan tidak dapat menggantikan hasil pengguna.

Ketiga, ia membatasi transisi antara pekerjaan dan audit.

PASS              → hanya melanjutkan pekerjaan langsung berikutnya
CHANGES_REQUESTED → memperbaiki hasil yang sama satu kali lalu mengaudit ulang
REPLAN_REQUIRED   → meninjau ulang kontrak atau pembagian kerja, bukan melanjutkan implementasi
NOT_VERIFIABLE    → tidak meluluskan tanpa bukti

Sesi audit tidak mewarisi percakapan sebelumnya. Alasan saya marah, seberapa keras sesi kerja berusaha, dan bagian mana yang dianggap bagus oleh implementer bukanlah bukti audit. Reviewer melihat langsung permintaan asli dan hasil saat ini.

Jika source atau Runtime berubah selama audit, verdict lama dibuang. Jika interupsi atau compaction membuat kita tidak dapat memulihkan candidate mana yang menerima verdict apa, Skill tidak menebak bahwa hasil tersebut telah lulus.

Struktur ini tidak jauh berbeda dari gagasan awal saya. Skill hanya menyimpan syarat transisi yang mudah terlupakan agar ide “mempertahankan satu sesi audit” dapat dijalankan dengan topologi yang sama pada sesi berikutnya.

Saya Menguji Graph pada Kontrak Nyata

Jika saya langsung percaya bahwa Skill sudah bagus hanya karena selesai dibuat, saya akan mengulangi kesalahan yang sama. Karena itu Skill baru tersebut juga saya serahkan kepada reviewer terpisah yang tidak mewarisi percakapan sebelumnya.

Pertama, saya memastikan bahwa Skill ini memang tidak perlu dipakai untuk perubahan kalimat sederhana. Tidak menggunakannya ketika tidak perlu adalah pengujian pertama untuk mencegah pemborosan token.

Kemudian saya memilih kontrak transisi otorisasi yang akan dipakai bersama oleh beberapa fitur sebagai node nyata pertama. Candidate dibekukan dan dikirim ke sesi audit. Verdict pertama bukan PASS, melainkan CHANGES_REQUESTED. Kontrak belum cukup jelas menentukan pada waktu mana otorisasi dinilai, dari mana wewenang delegasi berasal dan bagaimana pencabutannya menyebar, serta apakah pengguna, izin, dan perusahaan target benar-benar terikat pada scope yang sama.

Jika kontrak itu langsung diterapkan ke banyak fitur, batas otorisasi secara keseluruhan harus dibongkar lagi di kemudian hari. Sesi kerja hanya memperbaiki lingkup yang sama, lalu sesi audit yang sama meninjaunya kembali sebelum memberikan PASS. Selama itu implementasi lanjutan dan deploy tetap tertutup.

Percobaannya kecil, tetapi efek Graph Engineering yang saya inginkan terlihat. Edge lanjutan tetap tertutup pada node yang dianggap “cukup” oleh worker, dan masalah diperbaiki sebelum menyebar. Langkah berikutnya baru dapat dibuka setelah sesi audit yang sama memeriksa candidate yang sudah diperbaiki dan mengembalikan PASS.

Percobaan Pertama Lulus, tetapi Belum Menyelesaikan Kegagalan UI

Graph yang dirancang bekerja pada percobaan pertama. Namun saya belum dapat mengatakan bahwa Skill ini akan mencegah kegagalan UI selama 16 jam tersebut. Mengaudit kontrak otorisasi dengan source yang relatif jelas berbeda dari menghentikan arah visual yang keliru di tengah jalan. Saya belum menguji apakah ia mengurangi total waktu dan token pada pekerjaan UI besar yang nyata. Sesi audit memakai model yang sama dan melihat Working Tree yang sama, sehingga dapat ikut terjebak dalam asumsi salah milik sesi kerja. Skill adalah instruksi, bukan enforcement engine.

Karena itu pekerjaan panjang berikutnya tidak boleh dinilai dari jumlah PASS.

• Apakah arah salah pertama ditemukan sebelum diperluas?
• Apakah biaya pengerjaan ulang yang dicegah lebih besar daripada token audit?
• Apakah waktu ketika saya pertama melihat hasil sementara menjadi lebih lambat?
• Apakah sesi kerja dan audit sama-sama tertipu oleh kontrak yang salah?

Jika percobaan ini tidak efektif, saya harus memakai Gate lebih sedikit, bukan menambah aturan. Jika kegagalan yang sama berulang, sebelum menambah tahap audit saya harus meninjau kembali apa yang saya kelompokkan sebagai satu hasil dan bukti apa yang saya berikan kepada reviewer.

Mengetahui istilah Graph Engineering tidak serta-merta membuat saya mahir menggunakan AI. Namun kali ini saya tidak langsung memasang framework raksasa setelah mendengar istilah populer. Saya hanya menyimpan graph yang diperlukan untuk kegagalan yang saya alami, terus membantah usulan AI yang berlebihan, dan mengubahnya menjadi Skill kecil yang dapat diuji lagi pada sesi berikutnya.

Agar saya tidak baru mengetahui setelah 16 jam bahwa seluruh arahnya salah.

Referensi

1. LangChain, “3 Years of Graph Engineering with LangGraph”. Menjelaskan istilah baru Graph Engineering dan sudut pandang merancang workflow Agent sebagai graph eksplisit. ↩

2. OpenAI, “Build skills”. Jalur resmi untuk menyimpan workflow yang dapat digunakan berulang sebagai Codex Skill. ↩

3. OpenAI, “Subagents”. Menjelaskan cara Agent utama membuat subagent terpisah dan mengumpulkan hasilnya. ↩