Di Balik CLI Coding Agentic: Loop, Konteks, Izin

Model itu bagian yang paling mudah. Setidaknya begitu klaimnya, dan setelah mengamati belasan CLI coding agentic yang muncul, bercabang, dan tersandung selama beberapa tahun terakhir, saya rasa itu benar: CLI coding agentic berhasil atau gagal karena harness-nya, bukan modelnya. Rilis OpenCode 2.0, agen coding open-source berbasis terminal yang minggu ini mendapat banyak perhatian, adalah alasan yang bagus untuk mengatakan ini keras-keras. Hal yang menarik di rilis itu bukan integrasi model baru. Melainkan pemisahan client/server, plugin yang bisa di-hot-reload, tugas yang bisa berjalan di latar belakang, dan loop agen yang didesain ulang. Singkatnya, plumbing. Plumbing itulah produknya.

Saya mantan ML engineer, jadi kesimpulan ini cukup mengganggu saya. Saya ingin kualitas model menjadi pembeda utama. Tapi setiap kali saya memikirkan alasan saya tetap memakai atau meninggalkan alat-alat ini, jawabannya tidak pernah “modelnya jadi lebih pintar”. Jawabannya lebih seperti “alatnya berhenti meminta saya menyetujui setiap perintah”, atau “akhirnya config saya dimuat ulang tanpa restart”, atau “saya bisa menyambungkan GUI ke sesi yang berjalan di mesin remote”. Mari kita bedah tiga subsistem yang benar-benar menentukan apakah agen coding berguna: loop tool-call, manajemen konteks, dan model izin. Setelah itu saya akan mengakui di mana klaim kontrarian ini mulai goyah.

Loop Tool-Call Adalah Sistem Terdistribusi

Lepaskan semua jargon pemasaran, dan setiap agen coding adalah program yang sama: panggil model dengan prompt dan daftar tool, terima teks atau tool call, jalankan tool-nya, tambahkan hasilnya, ulangi. Loop itu kedengarannya sepele. Padahal tidak sepele, dan alat yang menganggapnya sepele akan terasa janky dalam lima menit pemakaian nyata.

Coba pikirkan apa saja yang harus ditangani loop ini. Eksekusi tool bisa gagal: compiler error, test suite yang hang, file yang tidak ada di path tersebut karena model berhalusinasi. Model menghasilkan JSON yang rusak untuk argumen tool-nya. Sebuah tool call memakan waktu empat puluh detik dan pengguna menekan Escape di tengah jalan. Dua tool call datang dalam satu turn dan salah satunya tidak boleh dijalankan jika yang lain gagal. Context window penuh di tengah tugas dan sesuatu harus dikorbankan. Semua ini adalah masalah konkurensi dan kegagalan, bukan masalah kecerdasan. Saya pernah berargumen bahwa agen LLM sebenarnya adalah sistem terdistribusi, dan CLI coding adalah contoh paling murni: ada komponen remote yang tidak andal dan nondeterministik (model) yang berkoordinasi dengan komponen lokal yang punya efek samping (shell, filesystem, LSP), dan loop adalah protokol konsensus di antara keduanya.

Itu sebabnya penting bahwa OpenCode 2.0 dilaporkan membangun ulang loop-nya di atas Effect, framework TypeScript untuk structured concurrency dan typed error. Pilihan ini menandakan tim berhenti memandang loop sebagai “while loop dengan fetch di dalamnya” dan mulai memperlakukannya sebagaimana adanya: sebuah sistem effect yang bisa diinterupsi, bisa dikomposisi, bisa di-retry, dengan channel error yang eksplisit. Ketika loop agen punya semantik cancellation yang nyata, “pengguna menekan Escape” menjadi event kelas satu, bukan state yang rusak. Ketika hasil tool bertipe, kamu bisa memvalidasi output model sebelum dieksekusi, dan ini cocok sekali dengan teknik seperti constrained decoding, di mana ruang output model dibatasi sehingga tool call yang rusak menjadi mustahil, bukan sekadar tertangkap.

Client/Server Adalah Fitur yang Tidak Pernah Dipasarkan

Salah satu keputusan desain paling berpengaruh dalam CLI coding adalah apakah agennya berupa proses atau layanan. Desain naif, yaitu satu proses, satu terminal, dan sesi mati ketika terminal ditutup, adalah cara kebanyakan alat ini dimulai, dan itu adalah batas atas. Model client/server OpenCode (di mana server berumur panjang memiliki sesi dan sejumlah client seperti TUI, aplikasi desktop, atau web UI terhubung ke dalamnya) menghilangkan batas itu. Secara praktis, artinya: sesimu bertahan saat terminal ditutup, kamu bisa menjalankan agen di dev box remote dan mengendalikannya dari aplikasi native di laptop, dan beberapa antarmuka bisa mengamati sesi yang sama.

Kalau kamu pernah mencoba menjalankan agen di VM lewat SSH lalu sesinya rusak karena reconnect, kamu tahu ini bukan sekadar kenyamanan. Ini perbedaan antara mainan dan infrastruktur. Agen yang berjalan lama termasuk kategori yang sama dengan build dan test suite: hal-hal yang kamu jalankan, tinggalkan, lalu cek lagi nanti. Tugas OpenCode 2.0 yang bisa berjalan di latar belakang juga bergerak ke arah yang sama. Agen berhenti menjadi percakapan sinkron dan berubah menjadi job runner dengan antarmuka chat.

Sekarang, catatannya, karena saya konsisten dengan pendapat ini: arsitektur server tidak berarti daemon permanen. Beberapa komentator dengan curiga mencatat bahwa setiap harness agen tiba-tiba ingin proses latar belakang yang terus berjalan di mesin mereka. Insting itu benar. Saya pernah menulis bahwa alat CLI sebaiknya tidak memasang daemon latar belakang secara default, dan saya tetap pada pendirian itu. Ada jalan tengah yang bersih: jalankan server saat dibutuhkan, batasi pada direktori proyek, dan hentikan ketika client terakhir terputus. Kamu tetap mendapat persistensi sesi dan multi-client attach tanpa proses yang selalu menyala dan diam-diam menghubungi pihak luar dari mesinmu. OpenCode yang memuat config dari folder sesi, bukan dari working directory server (perubahan 2.0 lainnya), menunjukkan bahwa mereka paham server seharusnya mengikuti proyek, bukan sebaliknya.

Manajemen Konteks Adalah Tempat Kualitas Berada

Tanyakan pada praktisi mana pun kenapa agen “jadi bodoh” setelah satu jam bekerja, dan jawabannya hampir tidak pernah regresi model. Itu context rot. Window-nya penuh dengan output tool yang sudah usang, jalan buntu, dan teks lengkap file yang relevan empat puluh turn lalu. Model kini mengambil keputusan di atas tumpukan jerami, dan kemampuan menemukan jarum menurun jauh sebelum kamu mencapai batas token nominal.

Harness yang baik memperlakukan konteks sebagai anggaran dengan kebijakan alokasi, bukan sebagai pipa. Secara konkret, ada beberapa hal yang bekerja bersama:

• Pemotongan output tool dengan jalur pengambilan ulang. Log test 5.000 baris sebaiknya masuk ke konteks sebagai empat puluh baris yang gagal ditambah catatan bahwa log lengkapnya ada di path yang bisa dibaca ulang oleh model. Harness memutuskan apa yang penting; model memutuskan kapan ia butuh lebih.
• Sub-session dan sub-agen. “Pelajari cara auth bekerja di repo ini dan laporkan balik” sebaiknya berjalan di konteks terisolasi dan mengembalikan ringkasan, bukan seluruh transkrip eksplorasi. Peningkatan komunikasi sub-session di OpenCode 2.0 persis merupakan ide ini.
• Kompaksi yang menjaga maksud. Ketika window penuh, sesuatu harus meringkas percakapan sejauh ini. Harness yang meringkas secara naif akan kehilangan batasan pengguna (“jangan sentuh modul billing”) bersama derau lainnya. Kompaksi yang baik mempertahankan keputusan dan batasan secara verbatim dan hanya memadatkan narasinya.
• Config dan skill sebagai konteks, bukan kode. Instruksi tingkat proyek, tool yang didefinisikan plugin, dan file skill semuanya memakan window. Hot-reload untuk hal-hal ini, perbaikan 2.0 lainnya, penting karena mengedit konteks agen tanpa me-restart sesinya adalah cara kamu mengiterasi perilaku agen itu sendiri.

Semua ini bukan soal kecerdasan model. Tapi semua ini menentukan seberapa cerdas model itu terlihat. Model frontier dengan kebijakan konteks yang berantakan akan kalah dari model yang lebih murah di belakang harness yang disiplin, untuk tugas apa pun yang berlangsung lebih dari dua puluh menit.

Model Izin: Fitur Membosankan yang Menentukan Adopsi

Ini pertanyaan dari diskusi HN yang menurut saya merupakan pertanyaan produk paling penting di ruang ini: apakah ada sesuatu di antara “setujui setiap perintah” dan “mode yolo”? Persetujuan otomatis penuh memang berbahaya, karena agen coding dengan akses shell bisa menjalankan rm -rf, git push --force, dan membocorkan environment variable-mu dalam satu turn. Persetujuan manual penuh juga benar-benar tidak bisa dipakai. Menyetujui delapan puluh perintah per jam berarti kamu tidak sedang mengawasi agen, kamu hanya jadi interupsi keyboard manusia yang lambat. Alat yang berhasil menemukan jalan tengah akan memenangkan hati para pragmatis.

Jalan tengah itu adalah model izin bertingkat, dan ruang desainnya lebih dipahami daripada yang orang kira:

• Read-only vs. write vs. execute. Membaca hampir tanpa biaya; menulis sebaiknya dibatasi pada pohon proyek; eksekusi adalah tempat kebijakan paling penting.
• Allowlist yang sadar argumen. git status disetujui otomatis; git push meminta konfirmasi. Alat naif mencocokkan nama binary; alat yang baik mencocokkan verb dan flag, karena npm test dan npm publish adalah binary yang sama dengan radius dampak yang sangat berbeda.
• Izin berbasis sesi. “Selalu izinkan perintah ini di sesi ini” adalah fitur izin dengan nilai tertinggi yang ada. Ia mengubah tujuh puluh konfirmasi menjadi satu.
• Containment untuk yang tidak bisa dibatalkan. Akses jaringan, apa pun di luar direktori proyek, dan apa pun yang menyentuh kredensial sebaiknya dibatasi secara struktural, bukan sekadar ditanyakan.

Poin terakhir itu adalah bagian yang paling sering kurang diperhatikan oleh harness, karena meminta konfirmasi itu mudah sedangkan containment itu sulit. Tapi konfirmasi hanyalah pertanyaan yang berharap kamu menjawabnya dengan benar pukul 6 sore di hari Jumat. Sandboxing process tree agen, dengan jaringan terbatas dan mount filesystem yang dibatasi, membuat seluruh kelas kegagalan menjadi mustahil, apa pun yang dilakukan model atau pengguna. Saya sudah menjelaskan trade-off ini secara detail di containment vs. monitoring untuk agen AI; ringkasannya, prompt adalah monitoring, sandboxing adalah containment, dan kamu butuh containment untuk apa pun yang tidak bisa dibatalkan. Ekosistem CLI perlahan mempelajari hal ini. Yang paling cepat mempelajarinya akan mendapatkan kepercayaan yang membuat pengguna benar-benar mau mengaktifkan persetujuan otomatis untuk 90% pekerjaan yang membosankan.

Ekstensibilitas dan Masalah Model Self-Hosted

Ada dua pelajaran kecil dari diskusi 2.0 yang layak diperhatikan. Pertama: “semuanya plugin” sedang menang. Pengguna membangun skill, editor config, dan hook workflow di atas harness ini, dan harness yang menjadikan plugin sebagai warga kelas satu (di-hot-reload, bisa mengamati sesi, bisa mengubah perilaku) melipatgandakan usaha komunitas alih-alih melawannya. Tanda bahwa OpenCode serius soal ini: aplikasi GitHub mereka sendiri men-triase laporan bug dengan mereproduksi masalahnya dan memberi komentar temuan, pada dasarnya menggunakan agen untuk memelihara agen itu sendiri. Itulah “kesadaran diri” yang dipuji pengguna, dan itu hasil dari arsitektur plugin, bukan hasil dari model.

Kedua: independen dari model itu lebih sulit daripada kelihatannya, dan ini masalah format konteks. Seorang pengguna mencoba model lokal yang sangat bagus dan dilatih untuk mengeluarkan perintah dalam bash, sementara harness-nya bersikeras mengharapkan tool call bergaya JavaScript, dan keduanya sama sekali tidak bisa berinteraksi. Ini adalah coupling tersembunyi di setiap harness agen: format tool-call, asumsi system prompt, dan distribusi training model harus selaras. Harness yang menanamkan konvensi satu keluarga model tidak agnostik terhadap model, paling-paling hanya toleran. Jika model lokal akan berarti bagi agen coding, dan karena alasan biaya dan privasi seharusnya begitu, harness butuh dialek tool-call yang bisa dicolokkan, bukan hanya endpoint API yang bisa dicolokkan.

Di Mana Klaim Kontrarian Mulai Goyah

Saya bilang model itu bagian yang paling mudah. Sekarang saatnya mengakui batasnya. Klaim itu berlaku untuk desain harness (loop, konteks, izin), tapi ada tempat di mana model memang menjadi bottleneck sungguhan. Keandalan penggunaan tool itu sendiri ditanamkan ke dalam model; model yang tidak konsisten menghasilkan function call yang valid membuat setiap harness terlihat rusak, dan tidak ada structured concurrency berbasis Effect yang bisa memperbaiki model yang berdebat dengan skema-nya sendiri. Perencanaan multi-langkah dalam horizon panjang masih membedakan tier model dengan cara yang bisa kamu rasakan dalam satu sesi. Dan kerangka harness-vs-model punya masa pakai: ketika model menyerap perilaku agentic ke dalam training (penggunaan tool native, perencanaan horizon panjang native), kemampuan berpindah dari harness ke bobot model, dan fitur harness yang pintar hari ini menjadi usaha yang terbuang besok. Tim yang membangun harness sebaiknya berasumsi bahwa mereka sedang membangun scaffolding yang nantinya dibuat usang oleh model. Jujur saja, ini justru argumen untuk harness open-source dengan ekosistem plugin, karena yang seperti itu bertahan berkat komunitas, bukan karena celah kemampuan sementara.

Ada juga batas minimum UX yang tidak bisa ditutupi arsitektur sebagus apa pun. Beberapa pengguna sudah mencoba OpenCode 2.0 dan tetap merasa canggung; yang lain mengeluh soal startup yang lambat dan database riwayat chat mati yang terus membengkak. Ini bukan masalah yang dalam, tapi justru ini yang membuat orang meninggalkan alat dalam sepuluh menit pertama, sebelum loop agen yang elegan sempat pamer. Polish juga merupakan fitur, dan ini yang paling sering kurang didanai oleh proyek open-source.

Model yang menulis kodenya, tapi harness yang menentukan apakah kamu cukup percaya untuk membiarkannya.

Jadi saran praktis saya, sebagai orang yang sudah mengamati kategori ini berputar-putar: pilih agen coding-mu seperti kamu memilih database, bukan seperti memilih pemenang benchmark model. Perhatikan penanganan kegagalan loop-nya, kebijakan konteksnya, granularitas izinnya, dan apakah sesinya bertahan saat terminalmu ditutup. Itulah bagian yang akan tetap penting setelah rilis model berikutnya membuat semua orang sama pintarnya lagi.