Perbedaan antara "hype" seputar agen otonom dan agen AI yang benar-benar bekerja di produksi

• Berlawanan dengan ekspektasi bahwa booming agen AI akan benar-benar tiba pada 2025, lingkungan produksi nyata memiliki keterbatasan yang realistis
• Karena akumulasi error dan masalah biaya token, otomatisasi penuh workflow multilangkah saat ini tidak memungkinkan
• Sebagian besar sistem agen yang sukses mengharuskan domain yang dibatasi secara ketat serta proses persetujuan atau verifikasi oleh manusia
• Tantangan yang sebenarnya bukan performa AI itu sendiri, melainkan perancangan tool dan sistem umpan balik yang bisa digunakan agen dengan baik
• Pada 2025, startup/perusahaan yang menonjolkan agen sepenuhnya otonom di garis depan diperkirakan akan menghadapi hambatan besar dalam proses adopsi dan skalanya

---

Mengapa saya bertaruh bahwa agen AI tidak akan benar-benar hadir pada 2025 (meskipun saya sendiri membangun agen AI)

• Hype bahwa 2025 akan menjadi tahun agen AI tersebar luas
• Penulis selama satu tahun terakhir membangun sendiri berbagai sistem agen AI yang benar-benar berjalan di lingkungan produksi
• Berdasarkan pengalaman kerja langsung tersebut, ia mengambil sikap skeptis terhadap narasi pasar tentang "revolusi agen"

Pengalaman membangun berbagai sistem agen

• Agen pengembangan: membuat komponen React dari bahasa alami, refactoring kode legacy, pengelolaan otomatis dokumentasi API, pembuatan fungsi berbasis spesifikasi, dan lain-lain
• Agen data & infrastruktur: menangani query dan migrasi yang kompleks, otomatisasi DevOps multi-cloud
• Agen kualitas & proses: perbaikan lint otomatis, pembuatan kode pengujian, code review, dan otomatisasi Pull Request yang terperinci
• Sistem-sistem ini benar-benar menghemat waktu dan memberi nilai, tetapi pengalaman itulah yang justru menjadi latar belakang sudut pandang kritis terhadap hype

Ringkasan inti: tiga kebenaran dingin tentang agen AI

1. Akumulasi tingkat error: makin banyak tahapan, tingkat keberhasilan turun secara eksponensial. Sulit memenuhi standar produksi (99,9% ke atas)
2. Context window dan biaya: makin panjang percakapan, biaya token meningkat secara kuadratik, sehingga keekonomiannya runtuh
3. Sulitnya desain tool dan umpan balik: tantangan terbesar bukan batasan teknis, melainkan merancang tool dan sistem umpan balik yang bisa dimanfaatkan agen

Realitas matematis dari akumulasi error

• Workflow otonom multilangkah tidak dapat diwujudkan pada skala operasi nyata karena akumulasi error
• Misalnya, meskipun tiap langkah memiliki tingkat kepercayaan 95%, pada 20 langkah tingkat keberhasilan akhir hanya 36% (kebutuhan produksi: 99,9% ke atas)
• Bahkan jika kita mengasumsikan reliabilitas yang tinggi, probabilitas kegagalan meningkat drastis seiring bertambahnya langkah
• Dalam praktik nyata, alih-alih mengotomatiskan seluruh proses secara penuh, sistem dirancang dengan verifikasi independen dan titik rollback di tiap langkah serta konfirmasi manusia
• Pola sistem agen yang sukses: konteks yang dibatasi dengan jelas, tugas yang dapat diverifikasi, dan keterlibatan keputusan manusia pada titik-titik penting

Struktur biaya token dan batas ekonomi

• Biaya token untuk mempertahankan context window dan percakapan menjadi realitas yang tidak ekonomis saat sistem diperluas
• Agen percakapan harus memproses seluruh riwayat percakapan setiap kali, sehingga biaya melonjak seperti kuadrat seiring bertambahnya putaran
• Percakapan sepanjang 100 putaran dapat menghabiskan 50–100 dolar hanya untuk biaya token, dan saat diterapkan ke banyak pengguna keekonomiannya runtuh
• Sebaliknya, agen pembuat fungsi single-shot tanpa state dan tanpa kebutuhan konteks lebih unggul dari sisi biaya dan skalabilitas
• Agen produksi yang paling sukses pada dasarnya lebih mirip "tool cerdas dengan tujuan yang jelas" daripada sesuatu yang "percakapan"

Tembok desain tool dan sistem umpan balik

• Hambatan sesungguhnya dalam membangun agen yang produktif adalah kemampuan desain tool yang sering diremehkan oleh tim yang sudah ada
• Akurasi tool call itu sendiri sudah meningkat, tetapi kuncinya adalah merangkum status dan hasil yang kompleks secara efektif lalu mengembalikannya sebagai umpan balik ke agen
• Contoh:
  • Saat pekerjaan hanya berhasil sebagian, perlu diputuskan seberapa banyak informasi dan ringkasan seperti apa yang dibutuhkan
  • Misalnya, jika hasil query berjumlah 10.000 baris, dibutuhkan desain abstraksi untuk memahami status seperti "berhasil, 10 ribu baris, hanya 5 teratas"
  • Saat tool gagal, perlu mengatur jumlah informasi pemulihan dan mencegah kontaminasi konteks
• Kunci agen database yang benar-benar berhasil dalam praktik: memberikan umpan balik terstruktur yang benar-benar bisa dipakai agen untuk mengambil keputusan
• Dalam kenyataan, bagian yang dikerjakan AI hanya sekitar 30%, sedangkan 70% sisanya terdiri dari kemampuan engineering tradisional seperti umpan balik tool, pemulihan, dan manajemen konteks

Batas integrasi sistem nyata

• Bahkan jika masalah reliabilitas dan biaya teratasi, masalah integrasi dengan dunia nyata menjadi tembok lain
• Sistem organisasi di dunia nyata tidak memiliki API yang konsisten, dan memuat kompleksitas yang tak terduga seperti karakteristik legacy, error pengecualian, autentikasi yang berubah-ubah, batasan yang dinamis, dan aturan kepatuhan
• Agen database nyata memerlukan pemrograman tradisional seperti pengelolaan connection pool, rollback transaksi, penghormatan terhadap replica read-only, timeout query, dan logging
• Janji bahwa "AI akan mengintegrasikan seluruh stack secara sepenuhnya otonom" terbentur dinding realitas ketika benar-benar dibangun

Pola pendekatan yang benar-benar bekerja

• Prinsip umum dari sistem agen yang sukses
  1. Agen pembuat UI: pengalaman pengguna tetap ditinjau akhir oleh manusia (AI hanya menangani kompleksitas konversi bahasa alami → React)
  2. Agen database: pekerjaan destruktif selalu dikonfirmasi manusia (AI hanya melakukan transformasi SQL, kontrol pelestarian data tetap di tangan manusia)
  3. Agen pembuat fungsi: perilaku dibatasi dalam spesifikasi yang jelas (tanpa state, efek samping, atau integrasi yang kompleks)
  4. Otomatisasi DevOps: AI membuat kode infrastruktur, tetapi deployment, versioning, dan pemulihan tetap melalui pipeline yang ada
  5. Agen CI/CD: tiap tahap dirancang dengan kriteria sukses yang jelas dan mekanisme rollback
• Ringkasan pola: AI menangani kompleksitas, manusia mempertahankan kendali, dan reliabilitas dijamin oleh engineering tradisional

Prospek dan prediksi pasar

• Startup venture yang menonjolkan agen sepenuhnya otonom akan paling dulu bertabrakan dengan masalah profitabilitas
• Pada workflow 5 langkah, demo mungkin terlihat hebat, tetapi perusahaan nyata menuntut lebih dari 20 langkah dan akan berhadapan dengan batas matematis
• Perusahaan yang hanya menambahkan agen AI secara sederhana ke software yang ada kemungkinan besar akan mengalami stagnasi adopsi karena integrasi nyata yang tidak memadai
• Pemenang sesungguhnya: tim yang, dalam domain yang dibatasi dengan jelas, hanya menerapkan AI pada pekerjaan yang sulit dan memberi manusia serta batas-batas pengaman pada keputusan penting
• Pasar diperkirakan akan mempelajari perbedaan antara "AI yang bagus untuk demo" dan "AI yang benar-benar andal" lewat pengalaman yang mahal

Prinsip membangun sistem agen yang diinginkan

• Menetapkan batas yang jelas: definisikan dengan terang peran agen dan titik handoff ke manusia/sistem yang ada
• Merancang dengan asumsi gagal: struktur rollback dan pemulihan wajib dirancang untuk saat error AI terjadi
• Memverifikasi keekonomian: rancang struktur dengan mempertimbangkan biaya per interaksi dan ekspansi skala (stateless lebih ekonomis daripada stateful)
• Mengutamakan reliabilitas daripada otonomi: sistem yang bekerja konsisten akan lebih dipercaya pengguna dibanding sistem yang sesekali terasa ajaib
• Membangun di atas fondasi yang kokoh: hanya bagian yang sulit (interpretasi niat, generasi, dll.) yang dialokasikan ke AI, sedangkan sisanya (eksekusi, penanganan error, dll.) diserahkan ke software tradisional

Pelajaran nyata dari pengalaman lapangan

• Kesenjangan antara "berjalan di demo" dan "beroperasi nyata dalam skala besar" sangat besar
• Reliabilitas agen, optimasi biaya, dan kompleksitas integrasi masih merupakan masalah utama yang belum terpecahkan di seluruh industri
• Pengalaman implementasi nyata dan berbagi pengalaman secara jujur adalah kunci kemajuan industri
• Semakin banyak praktisi lapangan mendiskusikan metodologi yang masuk akal dan kasus kegagalan yang realistis, semakin besar peluang keberhasilan secara keseluruhan

[GN⁺]

Opini Hacker News

• Pernah berbincang dengan seorang AI production engineer di Amazon, dan menurutnya saat ini tidak ada perusahaan yang hanya menggunakan AI generatif di titik yang berinteraksi langsung dengan pelanggan; semua autoresponder masih memakai teknologi lama yang non-generatif, karena masalah keandalan AI generatif masih terlalu besar untuk mempertaruhkan reputasi perusahaan

  • Dulu saya sangat tertarik pada agen yang menggabungkan teknik simbolik "AI lama" dengan machine learning tradisional, tetapi kebanyakan pekerjaan saya justru di jaringan saraf pra-transformer; pada akhirnya kami selalu membangun sistem dengan intervensi manusia lebih dulu sambil mengumpulkan data evaluasi dan pelatihan, lalu sistem tersebut mengambil alih sebagian pekerjaan dan sekaligus meningkatkan kualitas sisanya; khususnya untuk pekerjaan yang "subjektif", sistem simbolik juga wajib dievaluasi, dan kalau sistemnya perlu dilatih maka evaluasi memang tidak bisa dihindari

  • Kenyataannya, banyak perusahaan teknologi sudah mulai menerapkan AI generatif untuk dukungan pelanggan chatbot real-time; saya tahu beberapa seperti Sonder dan Wealthsimple, dan jika LLM tidak bisa menjawab kueri maka percakapannya langsung dialihkan ke agen manusia

• Hal yang belum banyak dibahas adalah context window; manusia dalam bidang keahliannya pada dasarnya bisa menangani konteks yang nyaris "tak terbatas", dan model memang bisa sedikit mengatasi batas ini dengan data pelatihan yang lebih besar dan beragam, tetapi menurut saya itu bukan solusi yang sesungguhnya; saat ini orang harus memadatkan konteksnya sendiri ke dalam prompt, sehingga dalam bahasa yang fleksibel seperti bahasa Inggris rasanya lebih seperti merapal mantra atau menebak-nebak daripada rekayasa, dan saya merasa banyak bagian data hilang dibanding pendekatan yang deterministik

  • Pada manusia, "konteks" dan "bobot" tidak dipisahkan secara tetap; seiring waktu, pengalaman dan hasil terus mengubah "bobot" saya sendiri, tetapi pada LLM hal itu mustahil karena secara arsitektur bobotnya bersifat read-only

  • Ada juga keraguan apakah manusia benar-benar punya context window sebesar itu; saat menyelesaikan masalah yang rumit saya sendiri sering menabrak batas "context window" manusia, jadi saya penasaran apakah benar ada contoh nyata untuk klaim itu

• Pengalaman saya memakai tool AI secara umum positif; sangat membantu untuk menyerahkan tugas kecil saat perlu istirahat, atau untuk merapikan dan memulai pekerjaan, tetapi masalah biaya cepat sekali muncul; misalnya memakai Claude Code pada codebase besar bisa menghabiskan sekitar $25 dalam 1–2 jam, dan kalau ditambah proofreading otomatis bisa naik sampai $50/hr; ada trade-off antara kecepatan, akurasi, dan biaya, dan agent-agent yang muncul belakangan ini juga masih belum jelas posisinya di segitiga itu, jadi berbagai eksperimennya memang menarik tetapi menurut saya tetap berisiko

  • Kalau dilihat agak sinis, struktur LLM yang terus me-reprompt dirinya sendiri untuk memperbaiki kesalahan, serta pendekatan "tidak perlu RAG! lempar saja seluruh kode ke context window 1m token", pada akhirnya sangat cocok dengan framing model bisnis 'bayar per token'

  • Ide yang sedang saya pikirkan belakangan ini adalah membiarkan AI membuat beberapa draf commit sejak awal, lalu hasilnya difilter dan dipoles manual oleh manusia atau secara otomatis; makin besar pekerjaannya, makin besar peluang penyimpangan kecil di awal merusak hasil keseluruhan, jadi bahkan dengan SOTA saat ini, membiarkan agent mencoba beberapa opsi secara paralel bisa mengurangi waktu refactoring manual; saya pernah menulis tentang proses terkait di GitHub

  • Saya ingin bertanya, apakah ini layanan berlangganan?

• Workflow manusia yang bertahap biasanya memiliki checkpoint verifikasi, karena manusia pun tidak akurat lebih dari 99% setiap saat; ke depan, agent juga akan dirancang dengan prosedur verifikasi untuk outputnya dan dilatih agar hanya melangkah ke tahap berikutnya setelah lolos proses itu; bahkan bisa saja dilakukan penilaian risiko sebelumnya seperti "bagian ini minimal harus 99% akurat"

  • Claude Code terus berhenti sebelum melanjutkan pekerjaan dan menanyakan apakah pengguna ingin lanjut, sambil lebih dulu menampilkan perubahan yang diusulkan; ini efektif untuk mencegah pemborosan token dan pekerjaan yang tidak efisien

  • Banyak aplikasi juga perlu didesain ulang agar cocok dengan struktur seperti ini; menurut saya arsitektur microservices cukup cocok dengan LLM sehingga bisa kembali populer

• Saya setuju bahwa "masalah sebenarnya bukan kemampuan AI, melainkan merancang tool dan sistem umpan balik yang benar-benar bisa dipakai agent secara efektif"; saya sempat hanya mengamati karena tidak yakin pasar akan menerimanya, lalu bergabung dengan startup sangat kecil yang khusus membuat agent, dan dalam 5 bulan saya berubah dari skeptis → sejalan → yakin; jika cakupan topiknya dibuat sangat sempit dan fokusnya pada tooling agar model bisa bekerja, tingkat penyelesaiannya bisa tinggi; memang ada kecenderungan tidak suka pada sifat non-deterministiknya, tetapi dengan tooling yang sangat baik dan scope yang makin sempit, secara praktis ini cukup berguna; tooling itu sendiri terasa sulit, tetapi menurut saya masih bisa ditangani dengan cukup baik, jadi saya optimistis soal masa depan

• Menurut saya ini semua masalah yang bisa dipecahkan, hanya saja banyak startup tidak fokus ke sana karena berlomba mengejar ARR dengan cepat; pendapat bahwa agent tidak berguna seperti yang dijanjikan ada benarnya, tetapi pada praktiknya ini masalah engineering; kalau didekati dari sudut pandang lain saya rasa akan berhasil (secara pribadi saya lebih mendukung pendekatan RL), misalnya dibutuhkan verifier yang bagus; untuk banyak tugas, memverifikasi lebih mudah daripada mengerjakannya langsung, dan bahkan jika hanya ada 5 hasil paralel dengan akurasi 80%, ada peluang 99,96% bahwa setidaknya satu hasil benar dan verifier bisa memilihnya; dalam situasi multistep ini juga menguntungkan secara matematis; ini pendekatan yang berbeda dari sebelumnya, dan artikel tersebut juga menyebut paradigma workflow 3–5 langkah yang memang terasa cocok, jadi ke depan kita perlu lebih banyak model seperti ini

  • Ada pendapat bahwa pada banyak tugas, verifikasi justru lebih sulit daripada tugas itu sendiri; khususnya di lapangan software QA, restrukturisasi sering dilakukan dengan logika seperti ini dan hasilnya kualitas malah memburuk; verifier menjadi sangat sulit karena jumlah kombinasi keadaan sistem dan dunia luar bertambah secara eksponensial; LLM memang menarik untuk menggantikan pekerjaan repetitif seperti mocking dependency atau mengisi data lebih dulu dalam lingkungan kerja yang kompleks seperti ini, tetapi agar pengujian verifikasi bermakna selalu muncul tuntutan bahwa ia harus 100% akurat, dan pada akhirnya setiap prasyarat membutuhkan verifier lagi; kalau semua tahap harus 100%, probabilitas keseluruhannya justru menurun; manusia biasanya menguji dengan hati-hati per kasus tertentu dan tidak memverifikasi semua kemungkinan secara sempurna (white-box testing jauh lebih umum daripada black-box), tetapi jika LLM menghasilkan banyak kode maka pekerja pada akhirnya harus memahami seluruh kode untuk bisa melakukan verifikasi white-box, dan waktu yang dihemat pun berkurang lagi; untuk saat ini LLM membuat sesuatu lalu saya sendiri harus memperbaiki semua error-nya, jadi kepercayaan diri saya justru turun dan waktunya juga lebih lama; dalam beberapa situasi ini bisa diatasi dengan menyesuaikan antarmuka agar cocok dengan ekspektasi LLM, tetapi itu tidak universal; di luar software, verifikasi sering kali bahkan mustahil sama sekali (misalnya: "pilih 5 startup game paling menjanjikan" yang tidak bisa diverifikasi secara objektif), jadi kalau area seperti itu diserahkan begitu saja ke mesin alih-alih manusia, akibatnya bisa tidak tertangani

  • Saya penasaran apakah masuk akal mengasumsikan lima kali generasi itu saling independen

  • Betul, dalam praktiknya efektif jika banyak agent mencoba, mengulang berkali-kali, dan menerapkan berbagai solusi; saya sendiri pernah mengalami kasus di mana satu pendekatan mendapat umpan balik negatif lalu pendekatan lain berhasil

• Cukup mengejutkan bahwa satu individu (atau tim yang sangat kecil) bisa membuat lebih dari 12 AI agent yang benar-benar dipakai di produksi untuk pengembangan, DevOps, data operations, dan sebagainya; melihat tingkat kegagalan startup, membuat "satu" produk bagus saja sudah sulit, jadi fakta bahwa ada 12 terasa luar biasa; kami sendiri membutuhkan 2 tahun untuk tool data stack+AI agent seperti Definite, dan baru sekitar 6 bulan terakhir rasanya mulai cukup bagus, Definite

  • Sebenarnya itu bukan 12 produk independen, melainkan 12 tool dengan tujuan sangat spesifik yang dipakai di tempat kerja sesuai kebutuhan; seperti tema keseluruhan tulisan ini, agent hanya menjadi berguna jika fokus pada tujuan yang sangat sederhana dan jelas

  • Agak terasa janggal bahwa seseorang yang bekerja penuh waktu selama 3 tahun bisa menghasilkan lebih dari 12 hal seperti itu

• Pekerjaan saya juga memang mengembangkan agent/otomasi AI, dan coding agent yang open-ended itu menurut saya ide yang bodoh; checkpoint verifikasi oleh manusia, ruang pencarian yang kecil, serta pertanyaan/prompt yang sangat spesifik (misalnya: apakah email ini berisi invoice YES/NO) adalah pendekatan yang realistis; saya paham keinginan untuk punya agent yang sepenuhnya otomatis, tetapi teknologinya belum sampai ke sana; saya pribadi tidak menyentuh pembuatan konten (teks, gambar, kode), karena hal seperti itu pada akhirnya akan berbalik menghantam kita

  • Saya juga dengan agent framework dan chat coding berhasil mengurangi sekitar 50% beban kerja, dan benar-benar merasakan manfaat GPT; tetapi sekitar 1 dari 10 kali pasti muncul error, dan saya rasa tingkat error ini tidak akan hilang tanpa mengubah arsitektur LLM secara mendasar; selama hype saat ini tidak sampai menghancurkan kepercayaan developer, saya yakin ke depan akan muncul sistem yang jauh lebih kokoh; peningkatan produktivitasnya begitu jelas sampai perekrutan anggota tim nyata-nyata bisa jauh dikurangi dibanding sebelumnya; learning curve untuk berbagai topik juga turun drastis karena LLM menutupi penurunan kualitas Google Search; dalam workflow otomatis, struktur terpenting adalah Orchestration Framework yang membuat LLM mengambil alih sebagian pekerjaan manusia, dan LLM juga harus melaporkan tingkat keyakinannya sendiri sehingga jika confidence % rendah bisa langsung dilempar ke manusia; selama testing, guardrail, dan hal serupa dilakukan dengan baik, untuk pekerjaan non-inti sangat mungkin menggantikan peran manusia; tujuannya bukan mengganti manusia sepenuhnya, melainkan mengotomatiskan pekerjaan agar ukuran tim bisa diperkecil; contohnya, saya yakin akan datang hari ketika tugas yang dulu dikerjakan manusia di e-commerce besar—seperti deskripsi produk, verifikasi gambar, typo, ketidaksesuaian gambar—ditangani oleh LLM

  • Secara umum saya setuju, tetapi jika didekati seperti itu yang tersisa mungkin cuma "sistem workflow yang mahal"; jadi saya bertanya-tanya apakah memang perlu LLM untuk hal-hal yang sebenarnya bisa dilakukan dengan teknologi lama

  • Saya juga setuju, saat ini titik paling pas untuk agent adalah "cakupan sempit, risiko rendah, repetitif, dan membosankan"; sebagai contoh, saya pernah menuliskan pengalaman menggunakan agent untuk membantu pekerjaan markdown dev-log di sini

  • Memang benar bahwa verifikasi oleh manusia paling dapat diandalkan untuk membuat checkpoint, tetapi ada juga banyak cara tambahan seperti unit test dan validasi ad-hoc terhadap sistem secara keseluruhan

• Saya justru merasa penulis seharusnya lebih optimistis terhadap agent otonom daripada sekarang; 90% dari yang sedang kita lakukan sekarang masih mustahil pada awal 2024, jadi kita tidak boleh meremehkan kurva perkembangannya

• Saya juga berpikir begitu; ada tulisan blog terkait juga, dan perbedaan intinya adalah bahwa mengurangi error dengan HITL(Human in the loop) itu benar, sedangkan HOTL(Human out of the loop) justru menciptakan masalah