a16z Pendapat Terbaru: Ketika Agen AI Menjadi Pengguna Utama Perangkat Lunak

Penulis: DeepThink Circle

Apakah kamu pernah berpikir bahwa seluruh logika pembangunan perangkat lunak kita mungkin akan benar-benar dirombak? Dalam puluhan tahun terakhir, semua perangkat lunak dirancang untuk manusia. Kita menghabiskan begitu banyak tenaga untuk mengoptimalkan antarmuka pengguna—membuat tombol lebih mudah ditemukan, menu lebih jelas, alur operasional lebih lancar. Namun bagaimana jika di masa depan pengguna utama perangkat lunak bukan lagi manusia, melainkan AI agent? Jika sebuah perusahaan punya 100 orang karyawan, tetapi 1.000 AI agent yang bekerja, apakah kita masih perlu memusatkan perhatian pada pengoptimalan antarmuka manusia?

Belakangan ini, dalam salah satu episode podcast a16z, Erik Torenberg, Steven Sinofsky, dan Martin Casado berdiskusi secara mendalam dengan CEO Box, Aaron Levie. Masalah inti yang mereka bahas adalah: ketika AI agent menjadi pengguna utama perangkat lunak perusahaan, bagaimana seluruh industri perangkat lunak akan direkonstruksi? Percakapan ini membuat saya sadar bahwa kita sedang berada di ambang perubahan paradigma yang jauh lebih dahsyat daripada yang dibayangkan kebanyakan orang. Ini bukan sekadar menambahkan fitur AI pada perangkat lunak yang sudah ada, melainkan memikirkan ulang secara mendasar bagaimana perangkat lunak harus dibangun, bagaimana perangkat lunak berinteraksi, dan bagaimana perangkat lunak digunakan.

Perangkat lunak harus dibangun untuk AI Agent

Aaron Levie mengemukakan sebuah pandangan yang membuat saya berpikir: jika kamu memiliki AI agent dalam jumlah 100 kali, bahkan 1.000 kali lebih banyak daripada karyawan, maka perangkat lunakmu harus dibangun untuk agent. Ini bukan soal pilihan, melainkan tren yang tak terelakkan. Box sekarang menghabiskan waktu untuk memikirkan antarmuka agent—dengan cara yang sudah setara dengan waktu untuk memikirkan antarmuka manusia. Kecepatan perubahan ini sangat cepat, melampaui ekspektasi saya.

Logikanya sebenarnya sederhana. Ketika AI agent menjadi pengguna utama perangkat lunak, mereka akan berinteraksi dengan sistem melalui protokol seperti API, CLI (command-line interface/antarmuka baris perintah), atau MCP (Model Context Protocol, protokol konteks model). Lalu, paradigma apa yang tampaknya paling efektif saat ini? Memberi akses ke alat SaaS kepada agent yang bisa menulis kode, agar ia bisa mengakses alur kerja pengetahuan serta informasi konteks kamu. Agent seperti ini bukan hanya mampu membaca dan memahami informasi, tetapi yang lebih penting, ia bisa menyelesaikan tugas melalui penulisan kode atau penggunaan API.

Claude Code dari Anthropic, aplikasi super yang sedang dikembangkan OpenAI, serta fungsi komputasi Perplexity semuanya bergerak ke arah tersebut. Saya berpendapat bahwa pertumbuhan gabungan dari kemampuan seperti ini baru saja mulai. Bayangkan sebuah agent yang tidak hanya mampu memahami perintahmu seperti, “Tolong analisis data penjualan kuartal lalu,” tetapi juga bisa menulis kode sendiri untuk mengekstrak data, melakukan analisis, menghasilkan visualisasi grafik, bahkan secara proaktif menemukan tren yang tidak kamu perhatikan. Di mana batas kemampuan itu? Saat ini saya belum bisa melihatnya dengan jelas.

Namun ada satu masalah kunci yang terus membuat saya berpikir: orang sering mengatakan ingin “membangun sesuatu untuk agent”, “memasarkan ke agent”, “memiliki API yang bagus dan bahasa deskripsi antarmuka yang baik”. Martin Casado menyampaikan pendapat balik yang sangat saya setujui: cara berpikir seperti itu hampir sepenuhnya keliru. Mengapa? Karena justru agent adalah yang paling mahir dalam menemukan alat dan sistem backend yang tepat. Mereka tidak akan memilih platform hanya karena dokumentasi API kamu bagus; mereka akan membuat pilihan berdasarkan faktor-faktor nyata seperti parameter biaya, keandalan sistem, ketahanan data, dan hal-hal substansial lainnya. Yang dimiliki agent adalah kebijaksanaan kolektif dari manusia yang menggunakan platform-platform tersebut.

Pandangan ini membuat saya tiba-tiba paham. Sebagai sebuah industri, kita terlalu menaruh perhatian pada antarmuka dan API, tetapi mengabaikan esensinya: kita perlu membangun sistem yang lebih baik itu sendiri. Agent akan mendorong kita kembali ke inti teknologi, bukan sekadar bungkus pemasaran. Dulu, keputusan pembelian perangkat lunak perusahaan sering kali dipengaruhi oleh kemampuan penjualan, kekuatan merek, bahkan jamuan bisnis. Namun di dunia yang dipimpin agent, bobot faktor-faktor tersebut akan turun secara drastis. Agent akan membuat pilihan yang lebih rasional berdasarkan keunggulan teknis. Ini merupakan peluang besar bagi perusahaan yang benar-benar fokus pada teknologi itu sendiri.

Batas Pemikiran Algoritmik: Tidak Semua Orang Bisa Mengarahkan AI Agent

Dalam percakapan itu ada bagian yang sangat berkesan bagi saya: tentang tantangan nyata penggunaan AI agent oleh non-teknisi. Steven Sinofsky mengemukakan pandangan tajam: berpikir secara algoritmik sungguh sangat, sangat sulit bagi sebagian besar orang yang bekerja. Jika kamu meminta siapa pun untuk menggambar diagram alur untuk tugas yang perlu mereka selesaikan, mereka kemungkinan besar akan gagal.

Pengamatan ini tepat sasaran. Bayangkan, dalam sebuah tim yang terdiri dari 50 orang pemasar, yang bertanggung jawab atas satu lini produk besar, mungkin hanya satu orang yang benar-benar memahami dan bisa mendokumentasikan seluruh alur kerja. Jika kamu menempatkan alat kolaborasi atau AI agent ini di depan karyawan biasa, lalu meminta mereka membuat alur otomatisasi, kemampuan mereka untuk menjelaskan dengan jelas “apa yang harus dilakukan” sebenarnya sangat terbatas.

Respons Aaron Levie adalah: ini hanya memindahkan pekerjaan ke satu tingkat lebih tinggi—kamu perlu belajar serangkaian keterampilan baru. Ini sama seperti setiap perubahan teknologi dalam sejarah. Ia memberi contoh yang menarik: growth marketer dari Anthropic—seorang diri menggunakan Claude Code—menyelesaikan pekerjaan yang sebelumnya membutuhkan lima hingga sepuluh orang. Contoh ini bermakna karena orang tersebut pada dasarnya adalah pemikir sistem; ia sudah cukup memahami teknologi untuk bisa melakukan itu.

Namun inti masalahnya adalah ini: jika kamu membayangkan setiap posisi memiliki kolam sumber daya insinyur yang tak terbatas, sehingga bisa mengotomatisasi pekerjaan apa pun yang diinginkan orang tersebut, seperti apa rupa pekerjaan pada masa depan? Saya pikir ini pertanyaan yang layak direnungkan. Mungkin agent akan semakin pandai mengarahkan pengguna menuju pemikiran yang sistematis, tetapi setidaknya pada tahap saat ini, masih sedikit orang yang mampu menggunakan alat-alat ini secara efektif.

Steven Sinofsky membagikan sebuah analogi yang cemerlang. Sepupunya—yang lulus dari sekolah bisnis elit—bergabung dengan pekerjaan pertamanya tepat saat era komputasi mulai. Di masa kuliah, ia tidak pernah menggunakan spreadsheet. Pada tahun pertama bekerja, ia diberi tahu bahwa ia bisa merekrut magang dalam jumlah apa pun. Maka, ia mengelola satu ruangan penuh “agent”—yakni mahasiswa yang mengerjakan semua pekerjaan spreadsheet. Tetapi, ajaibnya, dalam beberapa tahun berikutnya, ia dan rekan-rekannya berubah menjadi ahli spreadsheet. Lapisan abstraksi bergeser ke atas. Dulu pekerjaan yang dilakukan para magang dengan kalkulator dan kalkulator keuangan HP, sekarang dikerjakan sendiri olehnya menggunakan spreadsheet, dan ia bisa melakukan 30 iterasi, bukan hanya 2.

Kisah ini membuat saya sadar bahwa kita sedang berada pada tahap serupa dalam perkembangan AI agent. Kamu mungkin merasa perlu 50 agent kecil, yang dikoordinasikan oleh satu orang super cerdas. Tetapi tidak lama kemudian, semuanya akan saling melipat, akhirnya menjadi kumpulan satu keterampilan—sebuah potongan kode yang kita sebut agent—yang memahami pemasaran. Kamu bisa bertanya tentang pertanyaan-pertanyaan pemasaran, lalu langkah berikutnya, menyuruh agent menjalankan tugas.

Saya berpendapat titik belok kuncinya adalah: saat ini kamu harus menjadi seseorang setara ilmuwan roket untuk membuat 42 agent dan membuat semuanya berjalan. Namun ambang “ilmu roket” seperti itu akan cepat hilang, dan sebagian besar pengetahuan domain akan kembali ke tangan para ahli di bidangnya. Ini hampir sama dengan jalur evolusi spreadsheet.

Ketakutan Perusahaan: Integrasi yang Tak Terkendali dan Mimpi Akses yang Menghantui

Dalam percakapan itu ada sebuah adegan yang sangat menyentuh. Aaron Levie mengatakan bahwa belakangan ini ia menyampaikan pandangan yang mirip optimis di hadapan sekelompok CFO dan CIO, dan enam orang langsung berlari mendekat sambil berkata, “Kamu gila—kamu kehilangan semua kredibilitas di tempatku.” Mengapa? Karena ketika ia mengatakan bahwa masalah integrasi akan menjadi jauh lebih mudah.

Kekhawatiran para eksekutif IT perusahaan ini tidaklah tanpa dasar. Mereka tidak takut hanya pada AI agent itu sendiri, tetapi pada otoritas manusia yang diberi wewenang untuk melakukan integrasi. Ketika kamu mengizinkan karyawan membuat integrasi baru, pada dasarnya kamu sedang berkata, “Silakan datang dan hancurkan sistem inti saya.” Bayangkan ada seseorang yang membuat koneksi API baru antara sistem 27 dan sistem 38. Jika koneksi itu hanya digunakan untuk menghasilkan laporan, maka salahnya adalah urusan orang itu sendiri. Tetapi bagaimana jika menyangkut operasi tulis?

Aaron Levie berpendapat bahwa dalam waktu yang cukup lama ke depan (N adalah angka yang sangat besar), kita akan memiliki integrasi agent versi read-only. Banyak aplikasi AI sekarang berada pada level konsumsi—manusia adalah pengguna akhir. Namun bahkan di level ini, perusahaan tetap menghadapi tantangan baru.

Box baru saja meluncurkan CLI resmi, dan Aaron menggambarkan sebuah skenario: kamu memberi Claude Code Box CLI. Lalu, sekarang kamu bisa berinteraksi dengan seluruh sistem Box menggunakan bahasa alami, dan mengorkestrasi serangkaian operasi dengan model kuat seperti Opus 4.6. Kedengarannya keren—kamu bisa berkata, “Unggah seluruh folder ini dari desktopku ke Box,” atau “Proses semua dokumen dalam folder ini,” dan semuanya bisa dilakukan.

Namun masalah-masalah yang menyusul membuat kepala pusing. Bayangkan sebuah perusahaan dengan 5.000 karyawan: setiap orang bisa mengakses gudang dokumen teknik bersama dan materi pemasaran, dan setiap orang menggunakan CLI. Sekarang kita menghadapi beberapa tantangan baru yang sangat menarik: bagaimana mengoordinasikan permintaan yang bisa mencapai 10.000 kali per jam ke sistem? Bukan masalah performa, melainkan cara memastikan bahwa ketika agent seseorang sedang memindahkan file, agent orang lain tidak sekaligus mencoba melakukan operasi penulisan di folder lain, dan agent pihak ketiga justru mencoba menghapus sesuatu. Ketika agent-agent ini berjalan liar, ini akan menjadi masalah baru yang harus segera ditangani oleh setiap CFO dan CIO hingga rambut mereka terbakar.

Aaron Levie sendiri mengalami masalah ini saat mengujinya. Ketika ia mencoba membuat contoh struktur direktori rencana pemasaran, ia terjebak dalam semacam siklus—terus membuat direktori bersarang. Ia bercanda, “Aku ingin tahu apa batas kedalaman untuk folder bersarang di Box, karena aku hampir menyentuhnya.”

Seloroh kecil ini mencerminkan masalah yang lebih besar: ketika agent diberi kemampuan untuk melakukan eksekusi, mereka mungkin melakukan hal-hal yang tidak kita duga. Dan ketidakpastian seperti inilah yang paling ditakuti perusahaan.

Menganggap AI Agent sebagai Karyawan? Tidak Sesederhana Itu

Dalam percakapan itu ada bagian tentang cara mengelola AI agent yang terasa sangat menarik bagi saya. Ketika semua orang mulai memakai agent pribadi, mereka akan memberikan agent tersebut API key sendiri dan alamat email sendiri. Lalu bagaimana mencegah mereka melakukan hal-hal yang tidak seharusnya?

Martin Casado membagikan sebuah praktik: berikan agent nomor teleponnya sendiri, kartu kreditnya sendiri (semoga dari CVS membeli kartu Visa prabayar), serta akun Gmail-nya sendiri. Gmail sebenarnya memiliki banyak mekanisme RBAC (Role-Based Access Control/pengendalian akses berbasis peran). Kamu bisa berdebat bahwa kita sudah membangun banyak sistem izin seperti ini, jadi agent harus diperlakukan seperti manusia yang independen.

Namun Aaron Levie segera menunjuk kelemahan dari model tersebut. Dalam tim 50 orang, apakah kita akan punya 100 “orang” yang berkolaborasi—50 manusia dan 50 agent—yang berada di ruang bersama yang sama? Jelas saya memiliki pengawasan penuh atas agent saya, tetapi bagaimana jika agent saya berkolaborasi dengan pihak lain dan secara tidak sengaja mengakses sumber daya yang tidak seharusnya ia akses? Sekarang agent yang otonom dan berstatus ini sedang menangani informasi pihak lain.

Di sini ada kontradiksi mendasar. Untuk karyawan sungguhan, kamu tidak bisa melihat saluran Slack mereka, tidak bisa login dengan identitas mereka, dan tidak bisa mengawasi setiap gerak-gerik mereka. Mereka harus bertanggung jawab atas eksekusi mereka sendiri, dan di dunia nyata kamu tidak dihukum karena kesalahan mereka. Namun untuk agent, kamu harus menanggung tanggung jawab atas segala yang mereka lakukan. Kamu perlu memiliki pengawasan penuh; agent tidak punya hak privasi.

Jadi muncul beberapa pertentangan. Saya perlu bisa memberi agent akses, tetapi juga perlu bisa login kapan saja atas nama agent tersebut—misalnya, “Tidak bisa. Kamu sudah merusak semuanya, aku perlu membatalkan semua operasi.” Tetapi jika saya bisa login atas nama mereka, bagaimana agent itu bisa berkolaborasi dengan orang lain di dunia nyata, sambil tetap menjaga kerahasiaan dan keamanan informasi apa pun? Karena itu, agent pada dasarnya hampir tidak mungkin untuk tidak menjadi perpanjangan dari diri kamu.

Aaron Levie juga mengangkat masalah keamanan yang lebih dalam: kita belum tahu bagaimana membuat agent menjaga rahasia. Jika kamu memberi tahu agent, “Jangan mengungkap informasi X di dalam konteks window,” menyelesaikan masalah itu sangat sulit. Jika apa pun bisa masuk ke konteks window agent karena mereka memiliki akses ke sumber daya, secara teori kamu harus menganggap bahwa informasi itu mungkin bocor melalui prompt injection.

Apa artinya ini? Artinya, jika saya tahu alamat email agent baru kamu, saya bisa mengirim email kepadanya dan melakukan social engineering—yang jauh lebih mudah daripada melakukan social engineering terhadap manusia. Sulit untuk membuat agent tersebut sekaligus juga bisa mengakses informasi sensitif seperti dokumen merger dan akuisisi milikmu.

Saya pikir ini adalah salah satu hambatan teknis terbesar yang dihadapi AI agent saat ini. Sebelum masalah ini diselesaikan secara mendasar, agent akan sulit benar-benar diberi wewenang keputusan independen dan akses sumber daya secara mandiri. Mereka akan tetap ada sebagai perpanjangan manusia, bukan entitas yang mandiri.

Keunggulan Startup: Memeluk AI Agent Tanpa Ragu

Ada satu pandangan dalam percakapan yang sangat membuat saya terkesan: kecepatan penyebaran kemampuan AI akan jauh lebih lambat daripada yang disadari orang-orang di Silicon Valley. Alasannya adalah kendala yang dihadapi startup dan perusahaan besar sepenuhnya berbeda.

Aaron Levie mengatakan bahwa kita melihat startup bisa membangun dari nol tanpa risiko-risiko yang sedang kita bicarakan, karena mereka tidak punya apa pun untuk gagal. Jadi, kita menganggap ini sebagai jalur perkembangan yang sedang kita jalani. Namun ketika kamu pergi ke JPMorgan dan bertanya bagaimana mereka mengatur NanoClaw (sebuah AI agent hipotetis) untuk mengotomatisasi bisnis, kamu akan melihat jurang yang besar.

Jurang itu terlihat seperti apa? Perusahaan besar punya 75 sistem legacy yang harus diintegrasikan, memiliki persyaratan kepatuhan yang ketat, standar keamanan data yang terbentuk dari akumulasi selama puluhan tahun, serta mekanisme manajemen izin yang kompleks. Dan yang lebih penting, mereka punya terlalu banyak hal yang tidak bisa mereka tanggung risikonya. Jika sebuah startup mengalami masalah pada agent, paling banter itu hanya menjadi lelucon—bahkan bisa jadi cuma satu episode seperti yang ada di acara《Silicon Valley》. Tetapi jika agent di sebuah bank besar membocorkan data pelanggan, itu bisa menjadi bencana yang membuat perusahaan gulung tikar.

Steven Sinofsky mengajukan prediksi yang tajam: startup akan menghabiskan modal yang tersedia, berpura-pura bahwa biaya komputasi bukan masalah. Banyak perusahaan besar akan membeku karena terlalu takut, tidak melakukan apa pun. Lalu, karyawan biasa akan mulai membeli dan menggunakan alat-alat ini sendiri—melakukan apa yang biasanya dilakukan karyawan pada perusahaan besar yang punya uang, tetapi tidak mau mengeluarkan.

Di antara keduanya, akan ada beberapa perusahaan yang bersedia bertaruh karena berbagai alasan dan kondisi keuangan mereka memungkinkan. Perusahaan-perusahaan ini akan menjadi pemimpin di bidangnya, selama mereka mampu menjaga kesehatan finansial. Tidak akan ada situasi seperti karena CFO takut dipecat sehingga tidak ada yang berani masuk. Memang ada kemungkinan CFO melakukan kesalahan—tetapi itu normal.

Saya percaya ini akan menciptakan pemisahan pasar yang sangat menarik. Perusahaan menengah yang berani berinvestasi sejak awal dan bersedia menanggung risiko, mungkin akan memperoleh keunggulan kompetitif atas perusahaan besar. Mereka punya sumber daya yang cukup untuk berinvestasi pada AI, dan tidak seperti perusahaan raksasa yang terikat oleh sistem legacy dan sikap aversi risiko.

Pada saat yang sama, akan muncul sekelompok perusahaan layanan dengan jenis yang benar-benar baru. Bayangkan jika kamu membuat dari nol sebuah agensi pemasaran, perusahaan konsultasi engineering, atau perusahaan desain arsitektur, dan semuanya dibangun murni berdasarkan prinsip first-principles dari AI agent—tidak ada penghalang informasi dan batasan. Kamu bisa memberi agent seluruh konteks yang dibutuhkan untuk menyelesaikan pekerjaan, dan bisa menulis perangkat lunak kapan saja untuk kebutuhan tertentu. Perusahaan seperti ini akan sangat mendisrupsi untuk sementara waktu, sampai perusahaan-perusahaan besar yang ada mampu melepaskan diri dari belenggu mereka.

Anggaran Token: Arena Baru Manajemen Engineering

Ada satu bagian dalam percakapan tentang anggaran token yang terasa sekaligus realistis dan absurd. Aaron Levie berkata, “Percakapan tentang anggaran komputasi akan menjadi salah satu yang paling gila dalam beberapa tahun ke depan.”

Mengapa ia berkata begitu? Karena biaya engineering dalam pendapatan perusahaan teknologi publik mana pun berkisar antara 14% hingga 30%. Biaya komputasi adalah 2 kali biaya engineering, atau hanya 3% lebih tinggi; perbedaan di antara angka-angka itu bisa menjadi penentu bagi seluruh EPS (laba per saham) perusahaan.

Namun Steven Sinofsky berpendapat bahwa kita belum tahu jawabannya, dan CFO selalu ingin mengetahui jawaban dari pertanyaan yang mereka sendiri tidak tahu. Wall Street akan memaksa mereka memberikan angka dan menanggung tanggung jawab atasnya, lalu mereka akan dipecat, dan siklus ini akan terus berlanjut. Ini bukan hal baru; kita sudah mengalami hal yang sama pada setiap teknologi baru—mulai dari bandwidth internet, tabung vakum, transistor, hingga jumlah programmer.

Tapi Aaron Levie bersikeras bahwa kali ini memang agak berbeda. Ia mengajukan poin yang bagus: kita belum pernah memiliki momen ketika setiap pengguna akhir di dalam organisasi memiliki kemampuan elastis penuh untuk menginisiasi sumber daya atas nama mereka. Dan dalam banyak kasus, mereka menginisiasi sumber daya itu secara sepenuhnya masuk akal.

Ini benar-benar mirip dengan transisi cloud computing di awal 2000-an, ketika kita beralih dari CapEx (capital expenditure/pengeluaran modal) ke OpEx (operational expenditure/pengeluaran operasional), lalu menjadi pengeluaran tanpa batas. Aaron mengingat ketika itu di ruang briefing Box, CFO akan berkata, “Kamu tidak paham, kami perusahaan pertanian, kami hanya mengerti CapEx,” atau sebaliknya, “Kami perusahaan OpEx, kami menyukai cloud.” Perbedaan aturan akuntansi memang benar-benar memengaruhi adopsi teknologi.

Namun masalah anggaran token jauh lebih detail. Sebagai pemimpin engineering, kamu sekarang harus memutuskan: apakah kamu ingin engineer mempertimbangkan anggaran komputasi setiap kali mereka memberi prompt? Apakah kamu menginginkan prompt yang berjalan lama atau singkat? Apakah kamu ingin melakukan paralelisasi? Seberapa besar toleransi kamu terhadap pemborosan token?

Aaron mengatakan bahwa sikapnya saat ini adalah sebaiknya membuang banyak token, karena itu berarti kita sedang mencoba hal-hal baru. Apakah seharusnya kepala engineering merasa senang jika tim menjalankan 10 eksperimen secara paralel? Meski itu jelas memboroskan 90% token, tetapi kamu akan memilih jalur yang paling berhasil. Atau, seharusnya kamu memberi tahu tim untuk benar-benar merancang sistem yang sempurna sebelum dijalankan?

Saat rekaman percakapan ini dibuat, orang-orang sedang panik karena batasan pada rencana Max yang baru untuk Claude Code, di mana mereka dibatasi setelah tiga prompt. Ini akan menjadi topik yang sangat nyata sampai kita benar-benar bisa membangun kapasitas data center.

Namun saya sependapat dengan pandangan jangka panjang Steven Sinofsky: masalah ini pada akhirnya akan hilang. Penyebab utamanya adalah kamu harus melakukan perhitungan matematis ala Benioff. Jika kamu membayar sales perusahaan 1 juta dolar per tahun, kamu perlu bertanya: alat mereka bernilai berapa? Jika kamu membayar seorang engineer X dolar per tahun, maka alat mereka pada suatu titik pasti layak untuk investasi tersebut.

Selain itu, hukum bilangan besar akan menyelesaikan masalah ini. Pada akhirnya, jika kamu memiliki cukup banyak engineer yang menggunakan sumber daya komputasi sebanyak itu, semuanya akan menjadi seimbang. Kita sekarang sedang dalam fase transisi. Kebanyakan orang dua tahun lalu mengira pengeluaran untuk AI setara dengan tingkat biaya chatbot. Tetapi mereka keliru, karena mereka menganggapnya sebagai kasus penggunaan tertentu. Padahal sebenarnya itu adalah perubahan level platform.

Masa Depan Sistem SaaS: Nilai Kembali ke Lapisan Data

Ada satu bagian diskusi tentang masa depan sistem perusahaan yang membuat saya terkesan. Martin Casado mengemukakan bahwa para pemasok SaaS saat ini mengalami masalah yang menarik: mereka sebenarnya tidak menjual data lini bisnis; mereka menjual pengetahuan cerdas, keahlian domain, serta seluruh sistem. Namun agent di sisi tersebut hanya ingin membeli data, hanya ingin diberi otorisasi terhadap data, dan memiliki akses yang tak terbatas. Hal itu sama sekali bukan model bisnis mereka.

Ini telah menjadi titik ketegangan jangka panjang dengan sistem seperti Workday dan SAP—yakni seberapa banyak akses API yang diizinkan. Salesforce mengalami tiga kali perombakan besar platform sebagai respons terhadap hal ini. Ini merupakan masalah yang sangat menarik dari sisi teknis: ketika orang ingin mengakses data, apa sebenarnya arti dari system of record (sistem pencatatan)?

Steven Sinofsky mengatakannya secara tegas: “Membuat sistem seperti SAP dengan cara vibe coding itu benar-benar absurd.” Semua pengetahuan domain di SAP bukan hanya berada pada lapisan data yang dirancang dengan rapi. Pengetahuan itu ada di UI, ada di lapisan menengah, dan ada pada cara kamu menggunakannya.

Namun Aaron Levie memiliki pandangan berbeda. Ia berpendapat bahwa jika kamu melakukan iterasi yang cukup banyak, pada akhirnya agent akan sangat bertanggung jawab dalam memilih alat yang ingin mereka wujudkan dan gunakan. Meskipun agent tidak bisa mengganti sistem perusahaan, setelah melewati cukup banyak generasi, agent bisa saja menemui terlalu banyak hambatan dalam perangkat lunakmu sehingga agent berkata, “Kamu harus benar-benar menyingkirkan sistem legacy HR-mu, kalau tidak, aku tidak bisa mengotomatisasi alur kerja ini.”

Ini adalah pandangan yang disruptif. Bayangkan ketika jumlah agent adalah 100 atau 1.000 kali jumlah manusia—dan hal ini berulang terus-menerus—akhirnya harus dibangun sebuah tumpukan perangkat lunak khusus untuk agent. Mungkin ada beberapa sistem yang tetap bertahan sebagai benteng terakhir, misalnya beberapa sistem ERP, tetapi semua hal lainnya kinerja bisnis kamu akan terhubung langsung dengan seberapa baik agent dapat mengakses informasi yang mereka butuhkan untuk pekerjaan mereka. Jadi, tumpukan IT perusahaanmu harus disusun dengan cara yang mendukung agent agar bekerja secara efektif.

Martin Casado mengajukan perbedaan halus yang sangat saya setujui. Orang sering membahas secara abstrak seperti, “Sekarang kamu sedang memasarkan ke agent,” “Kamu harus menjadi API,” “Kamu harus memiliki bahasa deskripsi antarmuka yang baik.” Ia berpendapat itu hampir sepenuhnya salah. Yang agent benar-benar unggul adalah menemukan backend yang tepat. Mereka tidak akan berkata, “Antarmuka ini bagus, dokumentasinya lengkap,” melainkan, “Parameter biayanya begini, ketahanannya itu.” Mereka sebenarnya memiliki kebijaksanaan kolektif dari cara kita menggunakan platform-platform tersebut.

Ia memberi contoh: setiap kali ia meminta agent memilih platform cloud, agent menggunakan hal-hal yang bermakna, bukan hal yang berkaitan dengan tampilan antarmuka. Jadi sebagai industri, kita terlalu fokus pada antarmuka, lalu percaya pada topik seperti “kamu harus memasarkan ke agent.” Padahal yang akan dipilih justru adalah sistem yang lebih baik secara teknologi—dan yang akan menjadi bahan pilihan tersebut.

Menurut saya pandangan ini sangat mendalam. Di era agent, keunggulan teknis akan menjadi jauh lebih penting, sementara pentingnya pemasaran dan kemasan akan menurun. Produk yang benar-benar unggul secara teknologi akan menonjol, sedangkan produk yang terutama digerakkan oleh penjualan akan menghadapi tantangan.

Pemikiran Saya: Kita Meremehkan Skala Perubahan Ini

Setelah mendengarkan seluruh rangkaian percakapan, kesan terbesar saya adalah: Wall Street dan seluruh industri menggunakan kerangka yang salah untuk memahami dampak ekonomi dari perubahan ini. Aaron Levie benar: masalah terbesar adalah semua orang mencoba menguraikan manfaat ekonomi dari semuanya, tetapi perkiraan mereka terhadap skala peluangnya meleset setidaknya satu orde besarnya.

Steven Sinofsky menjelaskan ini dengan contoh sejarah. Saat melihat PC, orang menganggap konsumsi MIPS (juta instruksi per detik) adalah pasar yang terbatas. Mereka tidak menyangka jika semua MIPS itu diletakkan di setiap desktop, apa yang akan terjadi. Orang juga mengira perangkat lunak hanya berkembang seiring MIPS, dan hanya ada satu orang (yang dimaksud Bill Gates dan Paul Allen) yang berpikir bahwa perangkat lunak bisa dijual secara terpisah.

Hal yang sama terjadi pada cloud computing. Saat melihat cloud, orang mengira kita hanya memindahkan bisnis server (sekitar 60.000 server per tahun) ke pusat data pihak lain. Tidak ada yang terpikir bahwa penggunaan akan meningkat seribu kali lipat.

Pada AI pun sama. Model Wall Street memiliki “kue pendapatan” yang tetap—pemikiran zero-sum. Mereka berpikir perusahaan akan menghabiskan jumlah tertentu setiap tahun pada sesuatu. Tetapi ketika cloud datang, masalah yang dihadapi Salesforce adalah: bisnis CRM mereka menghasilkan 2 miliar dolar per tahun, yang berarti harus membeli semua server itu, lisensi Oracle, serta rasa sakit besar yang datang dari deployment dan konsultasi bertahun-tahun. Tetapi jika kamu memungkinkan sales rep untuk mendaftar sendiri, mereka akan melakukannya tanpa hambatan—dan justru itulah yang terjadi.

Saya percaya AI agent akan membawa ekspansi pasar yang serupa bahkan lebih besar. Ketika setiap pekerja pengetahuan memiliki satu atau lebih agent yang bekerja di sekitarnya, penggunaan perangkat lunak, jumlah data yang diproses, dan konsumsi komputasi akan tumbuh secara eksponensial. Ini bukan permainan zero-sum, bukan sekadar memindahkan pekerjaan dari manusia ke agent; ini akan menciptakan kemungkinan dan nilai yang benar-benar baru.

Aaron Levie menyebut bahwa sebagai investor, ia berinteraksi dengan sekitar 240 perusahaan infrastruktur, dan selama enam bulan terakhir semuanya menunjukkan pertumbuhan mendekati garis asimtot. Mengapa? Karena saat ini jumlah perangkat lunak yang dibangun jauh lebih banyak dibanding sebelumnya. Dengan makin banyak perangkat lunak dan makin banyak agent, konsumsi sumber daya komputasi akan ikut meningkat. Ketika semua orang menggunakan AI secara intensif di ponsel mereka, dan AI di sisi perangkat di ponsel menjadi kenyataan secara real-time, penggunaan akan meningkat hingga 1 miliar kali lipat.

Saya yakin kita sedang mengalami “momen transistor”. Steven Sinofsky menjelaskan hal ini dengan contoh tabung vakum. Dulu ada masa ketika orang mengira seluruh Dakota harus dipenuhi dengan gudang tabung vakum. Orang memakai sepatu roda di lorong untuk mengganti tabung vakum, hanya demi melakukan sesuatu untuk Perang Dunia II untuk kedua kalinya. Lalu seseorang berkata: “Lebih baik pakai transistor.”

Anggaran token mungkin akan seperti MIPS IBM pada masa itu. IBM menjual lebih banyak MIPS setiap tahun dengan harga lebih rendah, tetapi tetap mematok harga berdasarkan MIPS pada mainframe—hingga seseorang menunjukkan bahwa kurvanya menurun karena mereka memproduksi MIPS lebih cepat daripada kecepatan mereka menagih biaya. Hal yang sama akan terjadi pada token.

Namun dalam jangka pendek, kita akan melihat kekacauan besar dan ketidakpastian. Perusahaan akan berjuang menentukan seberapa banyak yang harus diinvestasikan, bagaimana mengendalikan biaya, dan bagaimana mengelola risiko. Startup akan berani bertaruh dan bergerak cepat. Akan ada kegagalan dan keberhasilan. Tetapi dalam jangka panjang, arah sudah jelas: perangkat lunak harus dibangun untuk agent, API akan menjadi lebih penting daripada UI, kualitas sistem akan lebih penting daripada pemasaran, dan biaya komputasi akan terus turun sementara penggunaan meningkat secara eksponensial.

Kita tidak sedang mengalami sekadar pembaruan alat, melainkan perubahan paradigma komputasi secara mendasar. Perusahaan dan individu yang memahami ini serta mengambil tindakan akan menentukan lanskap teknologi untuk sepuluh tahun ke depan. Sementara mereka yang masih berpikir dengan kerangka lama mungkin akan mendapati diri mereka tertinggal jauh.

Perubahan ini baru saja dimulai.