Vincen Marginalia

Ketika Model Bukan Lagi Bagian Paling Penting dari AI Agent

Sun, 23 Aug 2026 17:34:00 GMT

## Modelnya Bukan Lagi Seluruh Cerita Selama ini kalau membicarakan AI, kita biasanya mulai dari model. Claude, GPT, Gemini, DeepSeek. Model mana yang lebih pintar. Model mana yang lebih bagus untuk coding. Model mana yang lebih murah. Tapi begitu model mulai dipakai sebagai agent, ada banyak hal lain yang ikut menentukan hasil akhirnya. Agent perlu membaca file, menjalankan command, menggunakan tools, menyimpan session, mengatur permission, lalu mengulangi proses tersebut sampai pekerjaannya selesai. Jadi ada bagian yang menarik di luar modelnya. Pada 13 Agustus, DeepSeek membuka [`deepseek-ai/deepseek-harness`](https://github.com/deepseek-ai/deepseek-harness), sebuah open-source agent harness dengan pendekatan "everything is a plugin". Repository ini kemudian tumbuh sangat cepat. GitHub Radar mencatat sekitar 3.000 star baru dalam 24 jam pada 23 Agustus, dengan total sekitar 185 ribu star. Angkanya memang menarik. Tapi saya lebih tertarik pada apa yang terjadi setelah orang mulai menggunakannya. ## Yang Dicari Orang Bukan Cuma Model Baru DeepSeek Harness memberi ruang untuk mengganti dan menambahkan berbagai bagian dari agent. Tools bisa menjadi plugin. Model backend juga bisa diganti. Ada session, workspace, skill, sampai agent loop yang menjadi bagian dari lingkungan tersebut. Ini sebenarnya terasa cukup familiar kalau kita sudah lama membangun software. Kita terbiasa membuat database yang bisa diganti. Storage yang bisa diganti. Message broker yang bisa diganti. Bukan karena kita tahu sejak awal komponen mana yang paling bagus, tapi karena kita tahu kebutuhan akan berubah. AI agent sepertinya mulai menuju arah yang sama. Kita mungkin tidak akan selalu menggunakan model yang sama. Kita mungkin juga tidak ingin menggunakan tools yang sama. Bahkan cara agent menyelesaikan pekerjaan bisa berbeda antara satu orang dengan orang lainnya. Kalau semua itu dikunci menjadi satu aplikasi, perubahan kecil akan menjadi sulit. Kalau komponennya bisa diganti, kita punya lebih banyak ruang untuk bereksperimen. ## Begitu Bisa Bertindak, Masalahnya Ikut Berubah Ada satu hal yang menurut saya lebih penting dari arsitektur plugin ini. Agent bukan cuma menghasilkan teks. Ia melakukan sesuatu. Ia bisa membaca repository. Menjalankan shell command. Mengubah file. Memanggil tool lain. Dan semua itu membuat masalah keamanan menjadi jauh lebih nyata. Sebuah studi yang diterbitkan pada 17 Agustus menguji DeepSeek Harness terhadap indirect prompt injection melalui 16 jenis channel dan 14.560 eksekusi terkontrol. Studi tersebut menemukan beberapa skenario dengan tingkat keberhasilan serangan yang cukup berarti, termasuk payload melalui file dan skills. Ini bukan berarti Harness adalah project yang buruk. Justru menurut saya, ini konsekuensi yang wajar ketika kita memberikan lebih banyak kemampuan kepada agent. Ketika AI hanya menjawab pertanyaan, kesalahan biasanya berhenti pada jawaban yang salah. Ketika AI bisa melakukan pekerjaan, kesalahan bisa ikut berubah menjadi tindakan. Itulah kenapa lingkungan tempat agent bekerja menjadi penting. Permission bukan lagi detail kecil. Tool registry bukan sekadar implementasi. Session bukan cuma tempat menyimpan percakapan. Semuanya ikut menentukan batas kemampuan agent. ## Mungkin Agent Akan Menjadi Platform Yang membuat saya penasaran adalah arah setelah ini. Kalau model semakin mudah diganti dan tools semakin mudah ditambahkan, mungkin kita akan mulai melihat agent seperti platform. Ada core-nya. Ada plugin. Ada skill. Ada workflow. Lalu komunitas membangun sesuatu di atasnya. DeepSeek Harness sendiri masih berstatus developer preview dan dokumentasinya secara eksplisit memperingatkan bahwa breaking changes masih mungkin terjadi. Jadi terlalu cepat untuk mengatakan bahwa pendekatan ini akan menjadi standar. Tapi pertumbuhannya menunjukkan ada banyak orang yang tertarik pada gagasan tersebut. Dan mungkin itu bagian yang paling menarik. Kita mulai berpindah dari pertanyaan: > "Model apa yang kamu pakai?" ke pertanyaan: > "Agent kamu bekerja di lingkungan seperti apa?" Saya tidak tahu apakah pertanyaan kedua akan benar-benar menjadi lebih umum. Tapi kalau agent terus diberi kemampuan untuk melakukan lebih banyak hal, saya rasa lingkungan kerjanya akan semakin sulit dianggap sebagai detail teknis belaka. Model adalah bagian yang berpikir. Tapi lingkunganlah yang menentukan apa yang bisa dilakukan setelah ia selesai berpikir.

Ketika AI Mulai Belajar Mencari Tahu Sebelum Menjawab

Sun, 23 Aug 2026 16:55:00 GMT

Saya mulai merasa ada satu kebiasaan baru yang cukup menarik sejak coding agent semakin sering digunakan: kita tidak lagi hanya meminta AI untuk mengerjakan sesuatu, tetapi mulai meminta AI untuk mencari tahu dulu sebelum mengerjakannya. Beberapa hari terakhir saya menemukan [last30days-skill](https://github.com/mvanhorn/last30days-skill), sebuah skill untuk coding agent yang mencoba melakukan hal tersebut. Ide dasarnya sederhana: ketika kita ingin tahu apa yang sedang terjadi tentang sebuah topik, agent tidak hanya mengandalkan pengetahuan yang sudah ada di model, tetapi mencari percakapan dan informasi terbaru dari berbagai sumber seperti GitHub, X, Reddit, YouTube, Hacker News, dan web. Kelihatannya sederhana. Tapi menurut saya, ini menyentuh masalah yang cukup fundamental dalam cara kita menggunakan AI. Selama ini kita terbiasa bertanya kepada AI seolah-olah dia adalah ensiklopedia. Kita punya pertanyaan, lalu berharap model sudah memiliki jawabannya. Untuk pertanyaan seperti "apa itu Kubernetes?" cara seperti ini tentu masuk akal. Tapi coba ganti pertanyaannya menjadi "apa yang sedang ramai dibicarakan tentang Kubernetes minggu ini?" Itu sudah menjadi pertanyaan yang berbeda. Model bisa saja tahu banyak tentang Kubernetes, tetapi pengetahuan bukan berarti mengetahui apa yang baru saja terjadi. Ada project baru, repository yang tiba-tiba naik, orang menemukan bug, seseorang membuat workflow baru, atau ada pendekatan yang mulai ditinggalkan. Semua itu terjadi di luar pengetahuan statis sebuah model. Di sinilah menurut saya konsep seperti `last30days-skill` menjadi menarik. Agent tidak hanya menjawab berdasarkan apa yang sudah diketahuinya. Ia diberi kemampuan untuk melihat keluar, mencari sumber yang relevan, kemudian menyusun kembali informasi tersebut menjadi sesuatu yang bisa kita pahami. Saya sendiri cukup sering melakukan proses ini secara manual. Kalau ingin tahu sebuah teknologi sedang ramai atau tidak, biasanya saya buka GitHub. Setelah itu X. Kadang Reddit. Lalu YouTube untuk melihat apakah ada orang yang benar-benar membuat sesuatu dengan teknologi tersebut. Setelah beberapa tab terbuka, baru saya mencoba menyimpulkan apakah sesuatu memang menarik atau sebenarnya hanya kelihatan ramai karena satu postingan. Masalahnya bukan proses itu sulit. Masalahnya, proses itu melelahkan. Dan pekerjaan seperti inilah yang menurut saya cocok diberikan kepada agent. Bukan karena agent lebih pintar daripada kita, tetapi karena agent tidak keberatan melakukan pekerjaan yang sama berkali-kali. Ada perbedaan yang cukup besar antara meminta AI menjawab "apa yang kamu tahu tentang X?" dengan meminta AI mencari tahu "apa yang sedang terjadi dengan X?" Yang pertama membutuhkan pengetahuan. Yang kedua membutuhkan observasi. Semakin cepat sebuah bidang berubah, semakin penting perbedaan tersebut. Dunia software bergerak cukup cepat. Repository baru muncul setiap hari. Library berganti arah. Model baru dirilis. Cara orang menggunakan AI berubah. Bahkan tool yang baru beberapa bulan lalu terasa seperti eksperimen bisa tiba-tiba menjadi bagian dari workflow sehari-hari. Dalam kondisi seperti ini, saya rasa AI yang hanya mengandalkan memorinya sendiri akan semakin terasa terbatas. Bukan berarti modelnya kurang pintar. Informasinya saja memang sudah berubah. Mungkin karena itu saya mulai melihat arah yang cukup menarik dari coding agent. Agent tidak hanya dibuat supaya semakin bagus dalam reasoning atau semakin jago menulis kode. Agent juga mulai diberikan kemampuan untuk melakukan riset, memeriksa sumber, membandingkan informasi, dan mencari konteks sebelum mengambil keputusan. Pada akhirnya, mungkin AI yang paling berguna bukan AI yang selalu punya jawaban. Tapi AI yang tahu kapan jawabannya belum cukup. Dan daripada mengarang jawaban dari apa yang sudah dia tahu, dia memilih membuka beberapa tab, mencari tahu apa yang baru terjadi, lalu kembali kepada kita dengan sesuatu yang lebih masuk akal. Menurut saya, kemampuan sederhana untuk mengatakan **"sebentar, saya cari tahu dulu"** justru akan menjadi salah satu kemampuan paling penting dari AI agent.

Membangun API yang Bisa Dijelaskan dalam Satu Napas

Mon, 10 Aug 2026 09:00:00 GMT

Ada satu pertanyaan yang saya ajukan di setiap review API: kalau kamu harus menjelaskan endpoint ini kepada orang baru dalam satu kalimat, apa yang kamu katakan? Kalau jawabannya panjang, biasanya masalahnya bukan pada kata-katanya, tapi pada batas tanggung jawabnya. API yang mudah dipakai jarang lahir dari dokumentasi yang bagus. Dokumentasi hanyalah cermin. API yang mudah dipakai lahir dari nama yang jujur, bentuk data yang jelas, dan satu endpoint yang melakukan satu hal sampai tuntas. ## Mulai dari kontrak, bukan dari database Godaan terbesar adalah meniru bentuk tabel. Tabel `users` jadi `/users`, kolomnya jadi field respons. Hasilnya cepat dibuat, tapi bocor: perubahan internal langsung menjadi perubahan publik. Balik urutannya. Tulis dulu kontrak yang paling enak dibaca oleh pemakai, lalu petakan ke dalam sistem. Bentuk respons adalah produk, bukan efek samping dari skema database. ```ts type Result = | { ok: true; value: T } | { ok: false; error: string }; function parseId(raw: string): Result { const id = Number(raw); if (!Number.isInteger(id) || id <= 0) { return { ok: false, error: "id harus bilangan bulat positif" }; } return { ok: true, value: id }; } export async function GET(request: Request) { const url = new URL(request.url); const parsed = parseId(url.searchParams.get("id") ?? ""); if (!parsed.ok) { return Response.json({ error: parsed.error }, { status: 400 }); } // satu tanggung jawab, satu hasil } ``` ## Error adalah bagian dari kontrak Respons sukses biasanya didesain, respons error biasanya muncul begitu saja. Padahal pemakai API menghabiskan lebih banyak waktu membaca error daripada membaca dokumentasi sukses. Standarkan bentuk error: selalu ada `error` berupa string pendek yang bisa ditampilkan langsung, plus detail terstruktur untuk mesin. Jangan campur pesan untuk manusia dengan kode untuk mesin dalam satu field. > API yang baik terasa seperti bahasa yang sudah kamu kuasai, bukan seperti sistem yang sedang kamu lawan. ## Sedikit, tapi tuntas - Satu endpoint untuk satu operasi, jangan satu endpoint dengan sepuluh mode. - Nama jamak untuk koleksi, tunggal untuk satu item, dan biarkan URL bercerita. - Versi lewat URL atau header, tapi pilih satu dan konsisten. Pada akhirnya, ukuran API yang baik sederhana: orang yang tidak menulisnya bisa menjelaskannya dalam satu napas.

Kenapa Saya Berhenti Mengejar Arsitektur Sempurna

Tue, 14 Jul 2026 09:00:00 GMT

Dulu saya cukup sering menghabiskan waktu memikirkan arsitektur sebelum benar-benar menulis kodenya. Rasanya masuk akal. Kalau dari awal desainnya sudah benar, bukankah pekerjaan setelahnya akan jauh lebih mudah? Saya pikir begitu selama bertahun-tahun. Saya mencari struktur yang paling tepat, abstraksi yang paling masuk akal, pembagian service yang paling bersih. Kadang bahkan belum ada satu baris kode pun, tapi di kepala saya sistemnya sudah harus terlihat rapi. Belakangan saya sadar, ada sesuatu yang keliru dari cara berpikir itu. Bukan karena perencanaan itu buruk. Masalahnya adalah saya sering mencoba mendapatkan jawaban sebelum punya cukup pengalaman untuk tahu pertanyaannya. ## Kesempurnaan yang belum pernah dipakai Arsitektur yang terlihat sangat rapi di awal biasanya memang terlihat rapi karena belum pernah dipakai. Belum ada requirement yang berubah. Belum ada traffic yang aneh. Belum ada developer lain yang mencoba memahami kode tersebut. Belum ada bug yang memaksa kita mempertanyakan keputusan yang dulu terasa sangat masuk akal. Jadi hampir semua yang kita desain di awal sebenarnya masih berupa dugaan. Dan semakin banyak dugaan yang kita masukkan ke dalam arsitektur, semakin mahal pula kalau ternyata dugaan itu salah. Saya pernah menganggap abstraksi sebagai sesuatu yang membuat kode lebih baik. Sekarang saya lebih hati-hati. Abstraksi memang bisa membuat kode lebih baik. Tapi abstraksi yang dibuat terlalu cepat juga bisa membuat kode jauh lebih sulit dipahami. Karena kita akhirnya bukan cuma memecahkan masalah yang ada, tetapi juga memelihara solusi untuk masalah yang mungkin tidak pernah muncul. > Kode yang baik bukan kode yang tidak bisa diubah. Kode yang baik adalah kode yang murah untuk diubah. ## Saya sekarang lebih suka keputusan kecil Saya tidak lagi terlalu percaya pada arsitektur yang langsung lengkap sejak hari pertama. Saya lebih suka membuat keputusan sekecil mungkin yang masih memungkinkan sistem berjalan. Lalu melihat apa yang terjadi. Kalau ternyata keputusan itu benar, kita punya bukti untuk mempertahankannya. Kalau ternyata salah, kita masih punya ruang untuk mengubahnya. Ini juga mengubah cara saya melihat abstraksi. Kalau baru ada satu contoh, saya biasanya tidak buru-buru membuat interface. Kalau baru ada satu implementasi, saya tidak selalu merasa perlu membuat factory. Kalau baru ada satu service, saya tidak merasa harus langsung memecahnya menjadi lima service hanya supaya diagramnya terlihat bagus. Mungkin nanti memang akan dibutuhkan. Tapi saya lebih suka membiarkan kebutuhan itu muncul daripada menebaknya terlalu jauh. ## Tidak semua kode harus terlihat cantik Ada bagian dari kode yang memang akan terasa sedikit jelek. Dan sekarang saya tidak selalu menganggap itu sebagai kegagalan. Kadang kode yang sedikit jelek justru lebih jujur. Ia mengatakan: *"Di bagian ini kita belum benar-benar tahu bentuk yang tepat."* Menurut saya itu jauh lebih sehat daripada membuat abstraksi yang sangat elegan hanya untuk menutupi ketidaktahuan tersebut. Karena kode akan terus berubah. Requirement berubah. Cara kita memahami masalah berubah. Traffic berubah. Tim berubah. Bahkan asumsi kita sendiri tentang sistem bisa berubah. Arsitektur yang baik bukan arsitektur yang berhasil memprediksi semua perubahan itu. Saya rasa kita memang tidak mungkin melakukannya. Arsitektur yang baik adalah arsitektur yang tidak terlalu melawan ketika perubahan akhirnya datang. Mungkin itu alasan saya sekarang berhenti mengejar arsitektur yang sempurna. Saya lebih tertarik membuat sesuatu yang cukup baik untuk dipakai, cukup sederhana untuk dipahami, dan cukup lentur untuk diubah ketika saya ternyata salah. Karena biasanya, kita baru benar-benar tahu arsitektur yang kita butuhkan setelah sistemnya hidup.

Menulis Adalah Berpikir Dua Kali

Tue, 30 Jun 2026 09:00:00 GMT

Banyak yang mengira menulis itu menuangkan pikiran yang sudah jadi. Pengalaman saya sebaliknya: pikiran itu setengah jadi, dan menulis adalah cara menyelesaikannya. Ketika sebuah ide hanya ada di kepala, ia terasa utuh. Begitu ditulis, lubangnya kelihatan: premis yang melompat, contoh yang tidak nyambung, kesimpulan yang tidak mengikuti. Tulisan tidak mengekspos ide, tulisan menguji ide. ## Menulis untuk satu pembaca Tulisan teknis yang baik selalu punya satu pembaca bayangan: seseorang yang cukup pintar untuk mengerti, tapi belum tahu apa yang kamu tahu. Menulis untuk semua orang adalah cara lain menulis untuk tidak ada siapa-siapa. ## Terbitkan sebelum yakin - Yakin datang setelah terbit, bukan sebelumnya. - Artikel yang setengah sempurna lebih berguna daripada catatan yang sempurna di draft. - Umpan balik adalah revisi yang tidak bisa kamu lakukan sendirian. Jadi blog ini bukan tempat saya memamerkan pemahaman, melainkan tempat memaksakan diri untuk paham.