Panggilan fungsi LLM tidak bisa diskalakan; orkestrasi kode lebih sederhana dan lebih efektif

• Cara LLM memproses seluruh hasil pemanggilan tool itu lambat, mahal, dan tidak menguntungkan untuk skalabilitas
• Sebagai gantinya, diusulkan pendekatan agar LLM melakukan orkestrasi sehingga data terstruktur berbasis skema output diproses dengan kode
• Pendekatan ini cocok untuk pemrosesan data skala besar melalui function chaining dengan kode dan manajemen memori berbasis variabel
• Metode pemrosesan data berbasis eksekusi kode unggul dalam akurasi dan skalabilitas karena LLM tidak memulihkan data secara langsung
• Membangun lingkungan runtime AI yang aman muncul sebagai tantangan baru, dan dibutuhkan lingkungan eksekusi yang berkelanjutan serta dapat mempertahankan state

---

LLM function calls don't scale; code orchestration is simpler, more effective.

Keterbatasan pendekatan lama yang mengirim kembali hasil pemanggilan tool ke LLM

• Saat menggunakan tool MCP(Machine Context Protocol), biasanya hasil output tool dikirim ke LLM sebagai pesan untuk mendorong tindakan berikutnya
• Dalam kasus penggunaan nyata, server MCP milik Linear dan Intercom mengembalikan respons besar dalam format JSON
• JSON mirip API, tetapi karena tidak ada skema output yang ditentukan, LLM dibebani untuk mem-parsing seluruh teks
• Misalnya, hasil kueri daftar issue di Linear sangat besar, yakni 50 item, 70.000 karakter, sekitar 25.000 token
• Banyak field id tidak bermakna, tetapi menghabiskan token, dan jika LLM harus mereproduksinya apa adanya, biaya dan error akan meningkat

Perlunya memisahkan pemrosesan data dan orkestrasi

• Pendekatan saat ini mencampurkan pemrosesan data dan orkestrasi dalam satu sesi chat
• Sebagian orang membuat thread lain sebagai "agent" untuk ini, tetapi jika JSON sudah terstruktur, cara itu tidak efisien
• Pendekatan yang lebih baik adalah memproses data terstruktur secara langsung dengan kode
  • Contoh: untuk mengurutkan issue, alih-alih LLM menghasilkan output, jalankan sort lewat kode lalu kembalikan hanya array hasilnya

Pemrosesan data berbasis eksekusi kode

• Komputasi AI melalui eksekusi kode sudah digunakan di berbagai interpreter AI
• Pendekatan ini memungkinkan struktur yang ringkas, di mana LLM tidak perlu langsung mengeluarkan data dan cukup menentukan cara penggunaan tool

Konsep utama

• Menggunakan variabel sebagai memori: pemberian nilai = simpan, output = ambil, saat memanggil fungsi diteruskan sebagai argumen
• Mendukung function chaining: menggabungkan beberapa pemanggilan fungsi secara paralel/berurutan, dengan dependensi diekspresikan secara alami dalam alur kode
• Pemrosesan data besar yang dapat diskalakan: dikombinasikan dengan NumPy, pandas, dll., ribuan~puluhan ribu data pun bisa diproses dengan mudah
• Bisa juga memanggil LLM lain: di dalam kode yang ditulis LLM, LLM lain dapat dipanggil untuk memproses data tak terstruktur

Apakah MCP sudah siap?

• Spesifikasi MCP sudah mendefinisikan skema input, dan baru-baru ini PR skema output juga telah diajukan
• Jika skema output menjadi umum digunakan, pemanfaatan berikut akan dimungkinkan:
  • dashboard status issue
  • laporan tiket selesai mingguan
  • AI memantau tiket yang macet lalu mendorong tindak lanjut

Tantangan lingkungan eksekusi kode

• Keamanan adalah isu inti: karena mengeksekusi kode yang dibuat AI/pengguna, diperlukan desain untuk mencegah kebocoran API key dan data
• Dalam kasus Lutra, lingkungan eksekusinya dibangun dengan metode sandbox, dan model hanya diberi dokumentasi pemanggilan API
• Lingkungan eksekusi stateful (seperti Jupyter) berbiaya tinggi, dan untuk sesi jangka panjang dibutuhkan karakteristik stateless + persistent
• Ini membentuk kategori baru bernama runtime AI, dan desainnya masih terus aktif dikembangkan

Kesimpulan

• Pendekatan lama yang memasukkan hasil pemanggilan tool ke LLM untuk diproses memiliki keterbatasan biaya dan akurasi
• Orkestrasi berbasis kode memungkinkan pemrosesan yang ringkas, akurat, dan dapat diskalakan
• Lingkungan eksekusi kode AI tengah mendapat perhatian sebagai runtime generasi berikutnya yang memiliki keamanan, persistensi, dan skalabilitas

[GN⁺]

Opini Hacker News

• Berbagi pengalaman yang selama 2 tahun terakhir berpendapat bahwa "agen yang cukup maju tidak bisa dibedakan dari DSL". Menurutnya, jauh lebih tepat untuk mengajarkan API kepada agen, lalu meminta agen merancang algoritme yang memanfaatkan API tersebut dan menjalankannya di user space, daripada memaksa agen menginternalisasi algoritme. Memasukkan algoritme ke dalam LLM dianggap tidak efisien kecuali dalam segelintir situasi tertentu (dari sisi biaya atau akurasi). Diibaratkan seperti meminta developer menjalankan pemanggilan fungsi di dalam kepala mereka
  • Ditafsirkan sebagai bukti bahwa jalan menuju ASI (kecerdasan umum buatan) bukanlah lewat memperluas kemampuan LLM, melainkan lewat proses mengekstrak dan mengompilasi algoritme perbaikan diri dari luar dalam bentuk aplikasi simbolik
  • Meminta dasar atau contoh bahwa istilah 'agent' sudah digunakan secara luas dalam konteks ini sejak 2 tahun lalu
• Pengalaman membangun sendiri sistem agentic untuk bisnis e-commerce. Sudah mengevaluasi smolagents; elegan dan menarik, tetapi punya kelemahan berupa peningkatan besar pada kompleksitas sistem. Sangat cocok untuk lingkungan seperti pelaporan dinamis, ketika data perlu diurutkan dan diagregasi tanpa skema, tetapi berlebihan untuk sebagian besar tugas. Gemini dan OpenAI menyediakan fitur interpreter Python yang bisa mencakup sebagian besar pekerjaan agen kode. Pendekatan menumpuk pesan pemanggilan tool tanpa akhir di stack tidak direkomendasikan karena skalabilitasnya rendah. Workflow agentic yang nyata berumur pendek, dan kompleksitasnya dikelola lewat struktur serta disiplin. Pelajaran dari pengembangan perangkat lunak lama tetap sama: mengelola skala pemanggilan fungsi dan mencegah kekacauan tetap menjadi masalah yang sama dari dulu sampai sekarang. Inti membangun sistem yang baik adalah mengelola beban kognitif developer, dan solusi yang sederhana tetapi cukup bekerja lebih unggul daripada pendekatan canggih yang performanya tinggi. Kombinasi pemanggilan fungsi adalah contoh solusi sederhana seperti itu, dan pemrosesan data terstruktur juga cukup ditangani dengan metode parsing dan transformasi tradisional. Saat strukturnya tidak diketahui, model murah pun bisa menunjukkan performa parsing yang sangat baik. Pengelolaan kompleksitas sistem agentic pada akhirnya dapat diringkas sebagai masalah mengelola state aplikasi secara teliti. Dengan memanipulasi message stack, konteks aktif yang akan diberikan ke model dapat disusun secara fleksibel, mirip dengan manajemen memori di lingkungan terbatas
  • Ringkasan yang sangat tepat tentang trade-off sistem agentic. Kami juga memikirkan masalah yang sama saat membangun solusi pencarian produk percakapan e-commerce (IsarTech). Kombinasi fungsi dan data terstruktur adalah kunci pengendalian kompleksitas. Dari pengalaman kami, output berbasis type schema yang jelas benar-benar meningkatkan skalabilitas pemanggilan tool. Berkat type schema, beban kognitif dan kompleksitas sistem sama-sama bisa dikelola. Sebisa mungkin andalkan perilaku deterministik, dan gunakan LLM hanya saat menghadapi data tanpa skema atau ambiguitas. LLM sangat efektif untuk memetakan permintaan ambigu ke sistem deterministik. Namun, tetap perlu menyeimbangkan antara pengurangan kompleksitas pada input berentropi tinggi (tak terstruktur) dan peningkatan kompleksitas akibat rantai pemanggilan tool. Di lingkungan commerce nyata, sulit hanya memakai satu pendekatan, dan output terstruktur juga punya keterbatasan pada intent yang ambigu sehingga butuh strategi tambahan
• Masalahnya bukan pada pemanggilan fungsi itu sendiri, melainkan pada desain MCP dan cara penggunaannya. Kebanyakan MCP hanyalah tiruan API dan menimbulkan masalah keluaran data yang tak bermakna. JSON berulang kali dinest sehingga menghabiskan terlalu banyak konteks input secara tidak perlu, dan banyak informasi yang tidak relevan ikut terbawa. Diperlukan optimisasi seperti data flattening dan penghapusan field yang tidak perlu. MCP SaaS pada akhirnya hanya berperan sebagai API gateway. MCP saat ini dianggap sumber utama noise dan belum cukup dioptimalkan
  • GraphQL adalah teknologi yang memang dioptimalkan untuk tujuan seperti ini. Dirancang agar hanya field yang dibutuhkan yang bisa dipilih. Ada yang mengembangkan gateway open-source yang mengubah beberapa query GraphQL menjadi satu server MCP
  • Muncul pertanyaan apakah masalahnya justru model tidak mampu mengikuti JSON schema yang kompleks dengan benar
  • MCP memang tidak terlalu membantu, tetapi memfilter semuanya juga bukan selalu solusi terbaik. Kadang agen perlu memproses data dalam jumlah besar. Dalam kasus seperti itu, eksekusi kode yang disertai evaluasi data sederhana dan penjelasan schema adalah pendekatan yang lebih skalabel. Tentu saja, kalau sistem menjadi terlalu besar, masalah serupa akan muncul lagi. Solusi akhirnya adalah mereproduksi presisi tingkat pemikiran deterministik manusia ke dalam kode, lalu membuat LLM memanggil sistem keputusan tersebut. Secara teori tampak mudah, tetapi sangat sulit diwujudkan dalam praktik
  • Saat menguji pembalikan string dengan ChatGPT, terasa sangat sulit membuat LLM hanya memberikan hasil sederhana dan tingkat keandalannya pun rendah. Sejak pengalaman itu, jadi terbiasa memverifikasi dengan beberapa LLM sekaligus. Dengan laju seperti ini, bercanda bahwa mungkin perlu menyiapkan data center GPU sendiri hanya untuk menghitung jumlah karakter dalam string sederhana
• Tim Shopify baru-baru ini merilis Roast sebagai open-source. Ini adalah alat untuk menyisipkan pekerjaan LLM non-deterministik ke dalam workflow untuk mengotomatisasi codebase yang sangat besar. Dianggap penting untuk otomatisasi tugas yang kompleks
  • Sangat terkesan dengan Roast. Perpaduan antara determinisme dan non-determinisme sangat menonjol. Namun sedikit bingung bagaimana LLM mengorkestrasi beberapa pemanggilan tool dan menentukan urutan pemanggilannya. Tampaknya bisa bekerja untuk instruksi refactor, tetapi penasaran apakah cocok juga untuk tugas gabungan seperti "perbaiki → uji berulang"
  • Terasa segar melihat Ruby tetap bekerja secara konsisten dan bermakna bahkan di era AI
  • Bahkan hanya dari dokumentasinya pun pendekatan ini terasa merangsang secara intelektual. Kesan yang kuat datang dari cara kemampuan LLM dikemas secara declarative
  • Meminta contoh konkret bagaimana workflow seperti ini benar-benar digunakan di internal Shopify
  • Ada pengalaman membuat Claude Code Research Preview dan ChatGPT 4.5 Pro Deep Research sama-sama crash (dan ada buktinya), sehingga sedang mencari tool yang benar-benar andal
• Jawaban terbaik ada pada pendekatan hybrid, bukan di salah satu ekstrem. Menyelesaikan sebanyak mungkin dengan pendekatan deterministik, lalu memakai LLM untuk bagian kompleks yang sulit dispesifikasikan atau sulit ditangani teknik deterministik dianggap sebagai cara terbaik
  • Pendekatan yang menarik: memanfaatkan LLM untuk menghasilkan solusi deterministik (kode), lalu setelah kode itu tervalidasi, gunakan kembali sebagai kode deterministik ke depannya
  • Ada pendapat bahwa arah yang harus dituju adalah meminimalkan penggunaan LLM di dalam workflow
• Kaget melihat eksperimen rumit seperti ini ternyata sudah menjadi hal umum, padahal sudah lebih dari setahun meninggalkan industri
  • Kenyataannya, yang bereksperimen masih sedikit, dan meski belum ada contoh revolusioner, sudah ada beberapa kasus yang berguna
  • Ada juga pandangan bahwa jika sekarang tidak mengerjakan hal seperti ini, justru mungkin akan segera meninggalkan industri lagi
  • Pekerjaan sehari-harinya sendiri sudah sangat berfokus pada otomatisasi desain agen AI berbasis LLM. Bukan karena ingin begitu, tetapi tanpa sadar memang bergeser ke sana
• Bertanya-tanya kenapa LLM dipakai untuk mengurutkan data terstruktur
  • Tujuannya lebih ke pemrosesan data yang lebih kompleks seperti membangun dashboard, mengidentifikasi tiket isu secara otomatis, dan review kuartalan. Pengurutan sendiri hanya contoh sederhana untuk memudahkan memahami skala masalah
• huggingface smolagent adalah contoh representatif dari pendekatan ini, tetapi bila eksekusi nyata gagal, rollback atau pemulihannya menjadi sangat sulit. Secara prinsip bisa diatasi, misalnya dengan membungkus seluruh blok eksekusi dalam distributed transaction, tetapi dalam praktiknya LLM cenderung membuat kode yang kokoh dengan cara yang tidak cocok dengan pola ini, sehingga pelacakan error dan identifikasi penyebab kegagalan menjadi sulit
  • Ada yang setuju bahwa ide dasar smolagent bagus, tetapi realitas eksekusi dan error handling-lah masalahnya. Misalnya, ketika eksekusi kode terhenti, diinginkan bisa langsung melanjutkan dari state tersebut. Sudah terbukti LLM cukup baik menulis kode pemulihan state, dan saat ini fitur seperti itu bekerja cukup baik di produk nyata (Lutra)
• Sebagai pendekatan lain, ada yang mendorong LLM untuk menulis kode yang memanggil MCP seperti fungsi, dalam bentuk skrip Python. Contoh kode dibagikan
  • Lutra.ai diperkenalkan sebagai contoh penerapan nyata dari pendekatan ini. Kuncinya sangat bergantung pada seberapa baik runtime kode dirancang
• Fakta bahwa LLM sangat lemah dalam menangani JSON, terutama JSON berukuran besar. Endpoint sebenarnya tidak harus mengembalikan data dalam format JSON. LLM kadang justru jauh lebih kuat pada XML, dan data juga bisa diubah menjadi teks naratif lewat template
  • XML adalah format dengan informasi makna yang inheren, sehingga terasa mengejutkan bahwa format ini tidak lebih luas dipakai sebagai default untuk LLM. Jika perlu, XML bisa diubah secara deterministik ke JSON lalu dimasukkan ke pipeline dengan efektif
  • Ada pengalaman mendapat hasil yang cukup baik saat menggunakan tabel Markdown untuk mengembalikan data ke LLM
  • Muncul rasa penasaran apakah XML berkinerja lebih baik karena lebih sering muncul dalam data pelatihan LLM, atau karena jumlah token teksnya lebih banyak. Disebutkan juga kemungkinan bahwa blok teks justru memberi lebih banyak konteks bagi LLM