Plan Mode Mulai Kehilangan Gunanya di Era Banyak Agen

Dalam setahun terakhir, plan mode menjadi fitur standar di hampir semua alat pemrograman berbasis model bahasa. Alurnya kira-kira sama di semua tempat: sebelum agen menyentuh kode, ia diminta menyusun rencana lebih dulu, rencana itu ditinjau dan disetujui manusia, baru eksekusi berjalan. Idenya masuk akal. Kalau rencananya benar, hasilnya lebih terarah, dan manusia tetap punya titik kendali sebelum perubahan besar terjadi.

Namun pada 24 September 2026, Ayman Nadeem menulis sebuah artikel berjudul Plan mode is dead yang menantang anggapan itu. Ia bukan pengamat luar. Ia membangun dan meluncurkan aplikasi pengembangan berbasis desktop bernama Nuanced yang justru bertumpu pada gagasan perencanaan sebelum implementasi. Kegagalan produknya menjadi dasar argumentasinya: plan mode kehilangan salah satu dari dua fungsinya, dan fungsi yang tersisa makin penting tetapi justru tidak cocok diselesaikan lewat plan mode bentuk sekarang.

Artikel ini membahas argumen tersebut dan apa artinya bagi tim yang sehari-hari memakai agen pengkodean.

Dua Fungsi Plan Mode

Nadeem membedah plan mode menjadi dua fungsi yang sejak awal menempel padanya. Fungsi pertama bersifat teknis: plan mode menghasilkan instruksi yang cukup presisi bagi agen untuk bekerja. Fungsi kedua bersifat manusiawi: plan mode membantu orang memahami apa yang sedang mereka bangun.

Menurutnya, fungsi pertama sedang cepat menjadi usang. Model yang makin mampu mencerna maksud pengguna tidak lagi butuh instruksi sedetail dulu untuk menghasilkan pekerjaan yang benar. Rencana yang dulunya berfungsi sebagai jembatan antara maksud manusia dan kemampuan mesin kini kehilangan sebagian besar alasan keberadaannya, karena model bisa menutup jarak itu sendiri.

Sebaliknya, fungsi kedua justru makin penting. Masalahnya, plan mode dianggapnya bukan abstraksi yang tepat untuk fungsi itu, terutama ketika jumlah agen yang dijalankan paralel terus bertambah. Di sinilah inti argumennya: kebutuhan yang nyata bukan membuat rencana yang lebih rinci, melainkan menjaga pemahaman manusia atas sistem yang berubah lebih cepat daripada kemampuan manusia memeriksanya.

Masalah Sesungguhnya: Mental Model yang Tergerus

Nuanced dibangun untuk menjawab satu pertanyaan yang menurutnya akan selalu relevan: bagaimana manusia menjaga model mental yang utuh atas sebuah sistem perangkat lunak sementara mesin mengubahnya lebih cepat daripada kemampuan manusia memeriksa perubahan-perubahan itu.

Model bahasa bisa menulis ribuan baris kode dalam hitungan menit. Akibatnya, beban pemeliharaan sudah terbentuk sebelum seseorang sempat berpikir matang tentang apa yang sedang dibangun dan mengapa. Penalaran tentang perilaku sistem menjadi sulit, dan asumsi keliru yang terlanjur mengeras menjadi kode jauh lebih mahal untuk diperbaiki.

Nadeem mengakui sisi psikologis dari kemudahan itu. Menghasilkan kode dengan cara tersebut memberi dorongan kepuasan yang lebih besar, tetapi sekaligus mengaburkan pekerjaan yang tidak menyenangkan: memahami mengapa sesuatu perlu dibangun, apakah memang perlu dibangun, dan mengevaluasi keputusan produk, desain, serta infrastruktur secara serius. Kalimatnya yang paling sering dikutip dari artikel itu adalah pengakuannya bahwa ia sering kali sudah memiliki produk sebelum secara sadar membuat keputusan produk apa pun.

Ketika Agen Mengisi Celah yang Tidak Diisi Manusia

Ada mekanisme teknis di balik gejala itu. Kalau arsitektur dibiarkan kurang dispesifikasikan, agen akan mengisi celah tersebut dengan pilihannya sendiri. Masalahnya, cara agen menarik batas abstraksi belum tentu sesuai dengan cara manusia yang akan merawat kode itu nanti. Ketidaksesuaian ini tidak muncul sebagai kesalahan yang menghentikan program, melainkan sebagai keputusan struktur yang menimbulkan kesulitan di kemudian hari.

Yang membuat situasi ini berbahaya adalah lokasinya. Salah paham tentang perilaku dan desain yang dimaksud menyebar ke beberapa berkas, jauh di bawah permukaan percakapan. Karena berkas itu tidak dibaca satu per satu, kekeliruan tersebut mudah terlewat. Mencari masalah di bawah permukaan seperti itu terasa jauh lebih tidak efisien daripada merancang dengan benar sejak awal. Di titik ini, argumen penulis bertemu dengan pengalaman banyak tim: bug bukan lagi soal salah tulis, melainkan soal maksud yang tidak pernah disepakati.

Efek Banyak Agen Paralel

Pendorong yang mempercepat masalah ini adalah kemampuan menjalankan banyak agen sekaligus. Nadeem menyebut alat seperti Conductor dan Codex yang memungkinkan menjalankan lebih banyak agen secara paralel. Menurut pengalamannya, di sinilah rasa terputus itu muncul paling kuat: ia menggambarkan dirinya merasa seperti berjalan dalam mode otomatis, tidak bisa fokus, dan tidak bisa mencapai kedalaman pemahaman yang sama seperti saat ia bekerja sebelum era agen.

Dampak praktisnya langsung terasa pada verifikasi. Ketika perubahan datang dari banyak arah sekaligus, memeriksa apakah hasilnya benar menjadi makin sulit. Ia menyoroti ketiadaan jejak yang bisa dibaca: tidak ada jalur yang jelas yang menghubungkan perintah pengguna, keputusan agen, kode yang dihasilkan, dan perilaku produk yang muncul. Tanpa jejak itu, verifikasi berubah menjadi tebakan yang dibungkus keyakinan.

Jalan Tengah yang Diinginkan

Yang menarik, kesimpulannya bukan ajakan kembali membaca kode baris demi baris. Nadeem justru berpendapat bahwa bernalar tentang gagasan dalam bahasa alami lebih mudah dan lebih efisien daripada membaca berkas. Ia ingin bisa melayang di atas kode tanpa harus mengorbankan pemahaman tentang cara sistem bekerja.

Masalahnya, plan mode bentuk lama tidak cukup kolaboratif untuk itu. Ia mengaku berpindah dari satu alat ke alat lain, mulai dari CLI coding agent berbasis terminal, lalu Conductor, hingga akhirnya Codex, sambil terus membentuk dan menghaluskan rencana tanpa tempat yang layak untuk mengulanginya. Cara kerjanya sederhana tetapi melelahkan: menyusun rencana lewat percakapan, menyalin potongannya ke pesan baru untuk direvisi, lalu mengulanginya lagi. Alur salin tempel itu membuat rencana terasa seperti benda yang tidak pernah punya rumah.

Yang ia inginkan adalah rencana yang punya tempat tetap, terhubung dengan alur kerja keseluruhan, dan berubah dari serpihan teks sementara yang hilang di riwayat percakapan menjadi dokumen hidup yang bertahan. Ia merumuskan empat kebutuhan yang harus dilayani rencana: berpikir tentang apa yang akan dikerjakan, memastikan deskripsinya cukup presisi, memahami apa yang sudah dikerjakan, dan memahami kapan sesuatu berjalan salah beserta sebabnya.

Eksperimen Nuanced

Nuanced adalah upaya mewujudkan kebutuhan itu menjadi produk. Konsepnya berbasis thread, di mana setiap thread adalah satu percakapan. Pengguna membahas apa yang ingin dibangun, sistem memunculkan ambiguitas dan keputusan yang membutuhkan masukan, lalu bersama-sama menghasilkan rencana yang bertahan sebelum implementasi dimulai. Setelah rencana disepakati, Nuanced menjalankan implementasi dan berusaha memastikan kode yang dihasilkan mengikuti persyaratan yang tertulis di rencana. Tujuannya adalah saluran menyeluruh yang dimulai dari maksud dan berjalan terus sampai hasil, alih-alih dari perintah singkat ke kode tanpa jejak penalaran.

Pendekatan Nuanced pada akhirnya gagal sebagai produk. Tetapi kegagalan itu justru menghasilkan kesimpulan yang lebih luas: bahwa plan mode pada umumnya tidak lagi menyelesaikan fungsi pertama, sementara fungsi kedua menuntut bentuk yang berbeda dari yang disediakan alat-alat hari ini.

Pelajaran untuk Tim yang Memakai Agen Pengkodean

Argumen ini punya implikasi praktis meski tidak membangun produk baru. Pertama, pergeseran dari menulis rencana rinci ke menjaga pemahaman menunjukkan bahwa nilai waktu manusia lebih baik dihabiskan untuk menyepakati batas abstraksi, konvensi, dan keputusan desain, bukan untuk menulis instruksi langkah demi langkah yang makin cepat ditutup sendiri oleh model.

Kedua, kalau rencana tetap dipakai, tempatnya sebaiknya dokumen yang bertahan dan bisa dikunjungi lagi, bukan potongan teks di riwayat percakapan. Dokumen seperti itu bisa ditinjau ulang saat hasilnya menyimpang, dan bisa dijadikan rujukan ketika pertanyaan muncul beberapa minggu kemudian. Ini sejalan dengan prinsip yang berlaku umum di rekayasa perangkat lunak: keputusan harus punya jejak, karena keputusan yang tidak tercatat akan diambil ulang dengan cara yang berbeda dan lebih buruk.

Ketiga, kecepatan menjalankan agen paralel perlu ditimbang terhadap kemampuan tim memverifikasi hasilnya. Kalau jumlah agen melebihi kapasitas pemeriksaan, yang bertambah bukan hasil, melainkan beban pemeliharaan yang belum terlihat. Menjalankan lebih sedikit agen dengan jejak yang bisa dibaca sering lebih menguntungkan daripada menjalankan banyak agen tanpa titik kendali.

Keempat, kalau ingin memahami sistem yang sedang dibangun, pertanyaan yang lebih berguna bukan sekadar apa yang akan dikerjakan, melainkan mengapa keputusan tertentu diambil dan bagaimana keputusan itu menghubungkan maksud dengan perilaku yang muncul. Pertanyaan itu menuntut alat dan catatan yang mendukung, bukan dokumen rencana yang panjang.

Kelima, pisahkan perencanaan dari eksekusi pada tingkat waktu, bukan pada tingkat dokumen. Menghabiskan waktu untuk menyepakati batas abstraksi sebelum menjalankan agen jauh lebih murah daripada memperbaiki struktur yang salah setelah tersebar di banyak berkas. Biaya memindahkan batas abstraksi setelah kode tumbuh berkali-kali lebih besar daripada biaya mendiskusikannya di depan saat masih murah untuk diubah.

Tanda-Tanda Mental Model Mulai Hilang

Supaya argumen ini bisa dipakai, gejalanya perlu bisa dikenali. Beberapa tandanya cukup khas. Yang pertama adalah ketidakmampuan menjelaskan perilaku sistem tanpa membuka kode. Kalau pertanyaan seperti mengapa satu komponen berperilaku tertentu hanya bisa dijawab dengan membaca berkas, itu tanda pemahaman sudah berpindah ke mesin. Yang kedua adalah keberadaan keputusan yang tidak pernah diputuskan: bagian arsitektur yang ada begitu saja karena agen mengisinya, bukan karena ada yang memilihnya.

Tanda ketiga adalah kesulitan menunjuk jejak. Ketika sebuah perilaku produk dipertanyakan, tim tidak bisa menunjukkan rangkaian yang menghubungkan maksud awal, keputusan agen, dan kode yang akhirnya berjalan. Keempat adalah bertambahnya jumlah agen tanpa bertambahnya kecepatan verifikasi, yang biasanya berujung pada penumpukan perubahan yang tidak pernah benar-benar diperiksa sampai ada masalah yang memaksa. Menyadari tanda-tanda ini lebih awal jauh lebih murah daripada memperbaikinya setelah kode terlanjur mengeras.

Kesimpulan

Plan mode tidak benar-benar mati, tetapi fungsinya bergeser. Bagian yang berfungsi sebagai spesifikasi presisi untuk mesin memang kehilangan relevansi seiring kemampuan model meningkat, dan itu kabar baik karena mengurangi pekerjaan yang harus diulang manusia. Bagian yang berfungsi sebagai alat bantu pemahaman manusia tetap hidup, dan justru menjadi lebih mendesak ketika banyak agen berjalan bersamaan.

Yang perlu berubah adalah bentuknya. Dokumen rencana yang bertahan, jejak yang menghubungkan maksud dengan kode dan perilaku, serta kesadaran untuk tidak memproduksi perubahan lebih cepat daripada kapasitas memeriksanya, adalah tiga hal yang bisa diterapkan tanpa membeli alat baru. Pengalaman Nadeem mengingatkan bahwa alat yang mempermudah produksi kode tidak otomatis mempermudah pemahaman, dan pada akhirnya pemahaman itulah yang menentukan apakah sistem bisa dirawat atau tidak.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.