The Stack Was the Workaround

Konsepnya sederhana: daripada harus log in ke CMS, navigasi menu, mencari content block yang tepat, mengedit, melakukan preview, lalu menekan tombol publish, klien cukup memberi tahu AI agent tentang apa yang ingin mereka ubah. "Perbarui banner beranda untuk mempromosikan kampanye musim panas kami." "Tambahkan case study baru ke halaman portofolio." "Ubah jam operasional di halaman kontak." Agent yang akan mengurus sisanya.

Itu berhasil. Klien senang. Kami pun beralih ke pekerjaan berikutnya.

Namun, ada satu hal yang terus mengusik pikiran saya. Jadi, saya mencoba mengambil jarak dan mengajukan pertanyaan sederhana: apa yang sebenarnya kami bangun dan apa niat utama di baliknya?

Niat awalnya bukanlah "menghubungkan AI ke CMS." Niat utamanya adalah mempermudah seseorang yang nonteknis untuk memasukkan konten ke situs web mereka tanpa usaha ekstra. CMS hanyalah mekanisme yang kebetulan kami gunakan. Dan kami menempelkan AI agent pada mekanisme tersebut supaya prosesnya makin mudah.

Hal ini memicu pertanyaan lanjutan yang cukup mengusik: jika agent yang berinteraksi dengan CMS, untuk apa CMS masih membutuhkan interface yang human-friendly?

Interface yang enggak dipakai lagi oleh siapa pun

Bayangkan apa yang terjadi pada skema yang kami bangun. Klien berbicara dengan agent. AI agent menerjemahkannya menjadi API calls ke CMS. CMS memproses pemanggilan tersebut, menyimpan konten di database-nya, lalu frontend mengambil dan menyajikannya (render).

Seluruh visual editor, interface drag-and-drop, block builder, media library dengan thumbnail preview-nya, panel role-based access, hingga preview environment: tidak ada satu pun yang tersentuh. Agent melompati itu semua. Kami membangun conversational layer di atas visual layer yang sebenarnya enggak lagi terpakai dalam prosesnya.

Visual layer itu tidak gratis. Ada biaya lisensi perangkat lunak. Butuh hosting, pemeliharaan, update, hingga security patch. Semua itu menambah kompleksitas arsitektur. Padahal dalam skema ini, fungsinya hanya satu: menjadi perantara database dengan UI yang enggak pernah dibuka oleh siapa pun.

Mengambil sudut pandang yang lebih luas

Ini bukan cuma soal satu proyek. Seluruh web stack modern mulai terlihat berbeda jika dilihat dari sudut pandang ini.

Coba pikirkan kenapa tiap layer itu ada. Anda memiliki CMS karena content editor membutuhkan interface yang ramah pengguna. Anda menggunakan React atau Vue karena butuh komponen untuk menyajikan (render) konten dinamis dari CMS tersebut. Anda menerapkan server-side rendering (SSR) atau static site generation (SSG) karena butuh hasil render berupa HTML yang cepat. Anda menambahkan caching layer karena semua proses rendering tersebut memakan biaya yang mahal.

Setiap layer adalah konsekuensi dari layer sebelumnya. Dan efek domino pertama yang memicu seluruh rangkaian ini adalah satu kendala sederhana: orang nonteknis tidak bisa menulis HTML.

Itulah seluruh kisah asal-usul content stack modern. Miliaran dolar venture capital, ribuan perusahaan, dan jutaan jam kerja developer, semuanya dihabiskan untuk membangun toolchain yang makin canggih demi menjembatani celah antara "Saya ingin menyampaikan ini di website saya" dan hadirnya kode HTML di browser.

AI agent memangkas celah tersebut secara langsung. Seseorang cukup mengatakan apa yang ia inginkan. Agent akan menuliskan kode HTML-nya. Selesai.

Apa yang sebenarnya jadi enggak perlu

Visual CMS editor adalah hal pertama yang paling jelas tidak diperlukan. Bukan penyimpanan konten terstruktur (structured content storage) itu sendiri. Kalau Anda memiliki banyak frontend yang mengonsumsi konten yang sama, headless CMS sebagai data layer masih memiliki peran penting. Namun, UI drag-and-drop, WYSIWYG, dan block editor yang dibangun bertahun-tahun oleh berbagai perusahaan—dan dibayar mahal lisensinya oleh para klien? Itulah yang digantikan oleh agent.

Frontend framework sebagai content rendering layer adalah urutan berikutnya. React, Vue, Svelte: untuk situs berbasis konten seperti blog, landing page, situs pemasaran, dan halaman produk, framework ini ada hanya untuk mengubah data terstruktur CMS menjadi UI interaktif. Ketika AI agent mampu menghasilkan HTML bersih secara langsung, Anda dapat melompati framework, build pipeline, hydration, hingga bundle optimization. Hasil akhirnya jauh lebih ringan dan cepat dibandingkan dengan mayoritas situs berbasis framework.

Perdebatan antara SSR dan SSG pun runtuh dengan sendirinya. Pre-rendering, hydration strategies, islands architecture, partial hydration: semuanya adalah rekayasa engineering yang cerdik supaya konten berbasis framework dapat bekerja dengan baik. Semua itu tidak lagi relevan ketika Anda menyajikan static HTML yang sejak awal memang bukan aplikasi berbasis framework.

Untuk mengujinya, saya menghabiskan akhir pekan dengan merangkai tiga AI agent: sebuah planner sebagai koordinator, code agent, dan content agent yang terhubung ke Sanity via CLI. Tanpa tooling eksternal, hanya interaksi antar-agent. Konten masuk, HTML keluar, lalu di-deploy. Percobaan pertama langsung live. Lebih ringan dan lebih cepat daripada stack yang kami bangun untuk proyek klien yang mengawali seluruh pemikiran ini.

Apa yang enggak akan hilang

Arsitektur enggak akan hilang. Seseorang tetap harus menentukan apakah pendekatan agent sudah tepat, content store mana yang cocok, bagaimana setiap bagian terhubung, dan seperti apa output yang diharapkan. Proyek akhir pekan saya berhasil karena saya telah menghabiskan waktu bertahun-tahun membangun hal-hal ini dengan rumit, sehingga saya bisa mengambil keputusan dengan cepat.

API justru menjadi semakin penting, bukan berkurang. Antar-sistem tetap harus saling berkomunikasi dan data tetap harus mengalir. Agent adalah konsumen alami API (native API consumers) yang membuat API dengan desain yang baik menjadi jauh lebih berharga.

Bahkan, hal ini sudah mulai berevolusi. Untuk proyek klien tersebut, kami menulis custom integration code untuk menghubungkan agent ke CMS. Itu berhasil, tapi enggak scalable: setiap ada layanan baru, berarti harus menambah custom connector baru. Di sinilah protokol seperti MCP (Model Context Protocol) berperan penting. MCP memberikan standar bagi agent untuk berinteraksi dengan layanan apa pun yang menyediakan server MCP. Tanpa glue code khusus per tool. CMS, database, deployment pipeline, analytics platform: jika mendukung MCP, agent mana pun bisa langsung menggunakannya secara out of the box.

Ini adalah pergeseran yang signifikan. API tradisional dirancang untuk dipanggil oleh developer melalui kode aplikasi. Sementara MCP dirancang supaya bisa ditemukan dan digunakan oleh agent secara otonom. Perbedaannya sangat krusial. Ketika agent dapat menelusuri tools yang tersedia, memahami fungsinya, dan merangkainya tanpa perlu ada orang yang menghubungkannya secara manual, biaya untuk mengintegrasikan layanan baru turun mendekati nol. Hal inilah yang mengubah eksperimen akhir pekan saya dari sekadar uji coba sekali pakai menjadi repeatable pattern.

Jadi, API layer tak hanya bertahan hidup, tetapi juga naik kelas dari "interface antar-codebase" menjadi "interface antara agent dan layanan." Perusahaan yang membuka kapabilitas mereka melalui protokol yang agent-friendly adalah mereka yang akan tetap relevan. Sementara mereka yang mempertaruhkan segalanya hanya pada UI yang cantik… mungkin tidak.

Judgment atau pertimbangan profesional tetap ada pada manusia. Agent bisa saja menghasilkan output yang secara teknis benar sepanjang hari. Namun, menentukan apakah struktur konten dapat melayani pengguna dengan baik, apakah pesan yang disampaikan tepat sasaran, dan apakah arsitekturnya mampu bertahan pada skala besar, itu tetap menjadi tugas kita.

Apa artinya bagi Anda di industri ini

Di Incentro, kami bergerak di bidang konsultansi digital, jadi saya akan katakan secara langsung: jika nilai jual utama (value proposition) Anda berpusat pada pembuatan situs web atau aplikasi menggunakan CMS, Anda sedang menjual solusi untuk sebuah kendala yang kini mulai menghilang. Diskusi harus bergeser dari sekadar implementasi ke arsitektur, dari membangun layer ke pemahaman tentang layer mana yang sebenarnya tak lagi dibutuhkan.

Tim yang akan sukses adalah tim kecil yang memahami sistem, mampu merancang workflow agent yang tepat, serta memiliki taste untuk mengevaluasi output-nya. Sebaliknya, tim yang akan kesulitan adalah mereka yang masih mengemas sprint komponen React untuk situs berbasis konten sebagai penawaran utama mereka.

Ini bukan prediksi untuk dua tahun ke depan. Saya telah membangun versi alternatif ini dalam satu akhir pekan, di atas sofa saya, sebagai eksperimen sampingan. Dan langsung berhasil pada percobaan pertama.