Berhenti Membangun Agen AI, Gunakan Workflow LLM yang Lebih Cerdas

• Sebagian besar tim yang membangun sistem berbasis LLM selalu mencoba membangun agen (Agent) lebih dulu, tetapi kebanyakan mudah runtuh karena kompleksitas, sulit dikendalikan, dan sulit di-debug
• Pola agen yang benar-benar membutuhkan memori, RAG, penggunaan alat, dan kontrol workflow sebenarnya jarang, dan sebagian besar masalah justru bisa diselesaikan lebih efektif dengan workflow sederhana (chaining, paralelisasi, routing, dll.)
• Disarankan untuk lebih dulu menerapkan 5 pola workflow LLM yang berguna di dunia nyata, dan hanya menggunakan agen dengan hati-hati saat benar-benar diperlukan
  • prompt chaining, paralelisasi, routing, orchestrator-worker, evaluator-optimizer
• Bahkan ketika agen memang diperlukan, keterlibatan manusia, kontrol yang jelas, dan observabilitas (Observability) tetap menjadi inti

---

Apakah Agen AI Benar-Benar Diperlukan?

• Wawasan dari Hugo Bowne-Anderson, yang memberikan konsultasi dan pelatihan terkait pembangunan sistem LLM kepada berbagai engineer dan tim seperti Netflix, Meta, dan Angkatan Udara AS
  • Ia mengelola kursus pelatihan Building LLM Applications for Data Scientists and Software Engineers

Awal yang Salah: Mengapa Semua Orang Terobsesi dengan Agen

• Banyak tim saat memulai proyek LLM lebih dulu mengadopsi struktur kompleks seperti agen, memori, routing, penggunaan tool, dan karakter/persona
• Saat benar-benar dibangun, berbagai masalah seperti kolaborasi antaragen, pemilihan tool, dan memori jangka panjang sering memunculkan perilaku aneh dan kegagalan berulang
• Sebagai contoh, pada proyek agen riset berbasis CrewAI, setiap peran (peneliti, peringkas, koordinator) gagal bekerja sama sesuai harapan dan akhirnya runtuh tanpa daya

Apa Itu Agen?

• Empat karakteristik sistem LLM: memori, pengambilan informasi (RAG), penggunaan tool, dan kontrol workflow
• Bagian terakhir, yaitu kontrol workflow (LLM secara langsung memutuskan langkah berikutnya atau apakah akan menggunakan tool), disebut sebagai sifat keagenan
• Dalam sebagian besar pekerjaan nyata, workflow sederhana (chaining, routing, dll.) menunjukkan stabilitas yang lebih tinggi

Pola Workflow LLM yang Sebaiknya Dipakai sebagai Pengganti Agen dan Berguna di Praktik Nyata

1. Prompt Chaining

• Penjelasan: Membagi beberapa tugas menjadi rangkaian tahap (chain), lalu membiarkan LLM memproses tiap tahap secara berurutan
• Contoh: Mengekstrak nama, jabatan, dan nama perusahaan dari profil LinkedIn → menambahkan informasi tambahan tentang perusahaan tersebut (misi, rekrutmen, dll.) → menulis email yang dipersonalisasi berdasarkan profil + informasi perusahaan
• Kelebihan: Karena tiap tahap dipisahkan dengan jelas, penyebab bug lebih mudah dilacak/diperbaiki, sehingga menguntungkan untuk debugging dan pemeliharaan
• Panduan:
  • Cocok untuk tugas yang saling terhubung secara berurutan
  • Jika satu tahap saja gagal, seluruh chain bisa runtuh
  • Dengan membaginya menjadi unit kerja kecil, hasil menjadi lebih dapat diprediksi dan debugging lebih mudah

2. Paralelisasi (Parallelization)

• Penjelasan: Menjalankan beberapa tugas independen secara bersamaan untuk meningkatkan kecepatan keseluruhan proses
• Contoh: Dari beberapa profil orang, mengekstrak item seperti pendidikan, pengalaman, dan skill secara paralel untuk mempersingkat total waktu pemrosesan
• Kelebihan: Efisien untuk ekstraksi/pemrosesan data independen, termasuk pada data skala besar, dan cocok dengan lingkungan pemrosesan terdistribusi
• Panduan:
  • Setiap tugas harus saling independen, dan eksekusi paralel dapat sangat meningkatkan kecepatan keseluruhan
  • Perlu waspada terhadap kondisi pengecualian seperti race condition dan timeout saat menjalankan paralel
  • Cocok untuk pemrosesan data dalam jumlah besar dan analisis serentak dari banyak sumber

3. Routing

• Penjelasan: LLM mengklasifikasikan data masukan lalu otomatis mengarahkannya ke workflow yang sesuai
• Contoh: Dalam tool dukungan pelanggan, masukan diklasifikasikan apakah itu pertanyaan produk, masalah pembayaran, atau permintaan refund, lalu otomatis diproses melalui workflow yang sesuai; jika tipenya ambigu, diteruskan ke handler default
• Kelebihan: Memisahkan berbagai kasus dengan rapi dengan menerapkan logika pemrosesan yang terspesialisasi untuk tiap jenis input
• Panduan:
  • Gunakan saat tipe input/situasi yang berbeda membutuhkan penanganan terpisah
  • Pada kasus batas atau situasi pengecualian, routing bisa gagal atau ada kasus yang terlewat
  • Wajib merancang handler catch-all untuk kasus tak terklasifikasi/pengecualian

4. Orchestrator-Worker

• Penjelasan: LLM yang berperan sebagai orchestrator memecah tugas/mengambil keputusan lalu mendelegasikan pekerjaan detail ke worker (LLM eksekutor), sambil mengendalikan sendiri alur dan urutan keseluruhan
• Contoh: Mengklasifikasikan profil target menjadi tech/non-tech → jika tech, mendelegasikan pembuatan email ke worker spesialis; jika non-tech, mendelegasikan ke worker lain
• Kelebihan: Memisahkan pengambilan keputusan (klasifikasi/penilaian) dan eksekusi (pemrosesan individual), sehingga baik untuk kontrol alur dinamis dan skalabilitas
• Panduan:
  • Cocok bila setiap tugas memerlukan penanganan spesialis, serta untuk percabangan kompleks dan koordinasi bertahap
  • Jika orchestrator salah memecah atau mendelegasikan tugas, seluruh alur bisa mengalami error
  • Jaga logika tetap eksplisit dan sederhana, serta rancang pendelegasian/urutan/kondisi berhenti dengan jelas

5. Evaluator-Optimizer

• Penjelasan: LLM mengevaluasi hasil (skor/umpan balik), lalu jika belum memenuhi kriteria akan merevisi dan memperbaikinya secara berulang
• Contoh: Membuat draf email → evaluator memberi skor kualitas/umpan balik → jika sudah memenuhi ambang tertentu atau melebihi jumlah iterasi maksimum maka berhenti, jika belum maka direvisi lagi
• Kelebihan: Kualitas output akhir bisa ditingkatkan berulang kali hingga mencapai tingkat yang dituju, dan cocok untuk menggunakan kriteria kuantitatif
• Panduan:
  • Cocok untuk situasi ketika kualitas lebih penting daripada kecepatan, dan workflow membutuhkan optimasi iteratif
  • Tanpa kondisi berhenti, sistem bisa terjebak dalam loop tak berujung
  • Wajib menetapkan kriteria kualitas yang jelas dan batas iterasi

Saat Agen Benar-Benar Diperlukan

• Agen menunjukkan nilai sebenarnya dalam lingkungan yang menjamin intervensi manusia secara real-time (Human-in-the-loop)
  • Contoh 1: Pendamping data science - pada SQL query, visualisasi, rekomendasi analisis data, dll., LLM dapat mencoba pendekatan kreatif dan manusia yang menilai/memperbaiki hasilnya
  • Contoh 2: Mitra kreatif - pada ide copywriting, usulan headline, rekomendasi struktur teks, dll., koreksi arah dan penilaian kualitas oleh manusia menjadi inti
  • Contoh 3: Asisten refaktorisasi kode - pada usulan design pattern, deteksi edge case, optimasi kode, dll., developer memberikan persetujuan/penyempurnaan
• Karakteristik: Agen bukan menangani “semua hal sendiri”, tetapi paling efektif dalam lingkungan tempat manusia secara real-time mengoreksi error dan mengarahkan jalannya proses

Saat Agen Tidak Cocok

• Sistem enterprise dan mission-critical (keuangan, kesehatan, hukum, dll.):
  • Karena keandalan otomasi dan perilaku yang deterministik sangat penting, struktur di mana agen LLM mengambil keputusan menjadi berisiko
  • Gunakan pola kontrol yang jelas seperti orchestrator, routing, dan sejenisnya
• Semua situasi yang mengutamakan stabilitas dan prediktabilitas
  • Contoh kasus abnormal: agen berulang kali salah memilih tool tanpa konteks/memori, atau pembagian kerja/koordinasi gagal sehingga seluruh alur runtuh
• Faktor kegagalan sistem agen yang sering muncul di praktik kerja
  • Konteks hilang karena sistem memori eksplisit tidak dirancang
  • Kurangnya batasan pemilihan tool (penggunaan tool yang tidak perlu/salah)
  • Gagal mengoordinasikan kolaborasi karena hanya mengandalkan struktur delegasi yang terlalu bebas

Pelajaran untuk Perancangan di Dunia Kerja

• Bahkan saat mengadopsi agen, tetap diperlukan desain, observabilitas, dan sistem kontrol setara “sistem perangkat lunak yang matang”
• Dibanding framework agen yang kompleks, merancang dengan observabilitas (Observability), loop evaluasi yang jelas, dan struktur yang bisa dikontrol langsung lebih cepat dan lebih aman

Kesimpulan (TL;DR)

• Agen sering kali terlalu dibesar-besarkan dan digunakan berlebihan
• Sebagian besar tugas nyata lebih cocok dengan pola workflow sederhana
• Agen menunjukkan nilai terbaiknya dalam lingkungan dengan keterlibatan langsung manusia
• Dalam sistem yang stabil, agen justru bisa menjadi faktor risiko
• Rancang sistem dengan observabilitas, kontrol eksplisit, dan struktur evaluasi berulang

• Alih-alih framework agen yang kompleks, rahasia membangun layanan berbasis LLM yang lebih cepat dan aman di dunia nyata adalah merancang dengan observabilitas, loop evaluasi yang jelas, dan struktur yang bisa dikontrol langsung

[samdo103]

Sebulan lalu, sambil menggunakan CURSOR untuk mempelajari apa itu AI coding, saya mulai mengembangkan framework pengembangan.

Selama sekitar 3 minggu, saya berulang kali mengalami situasi di mana source code yang sempat berhasil dan tervalidasi oleh AI Agent malah rusak kembali. Saya mencoba segala cara untuk mengendalikan AI Agent, tetapi gagal.

Lalu saya menyadari bahwa sebelum mengembangkan framework pengembangan, prioritas utamanya adalah mengembangkan source code untuk mengendalikan AI Agent.

Akhirnya, tepat 1 bulan setelah mulai karena ingin memahami apa itu AI pertama saya, saya berhasil menyelesaikan pengembangan software yang dapat diimplementasikan 100% dan dioperasikan 100% oleh AI dengan kendali sempurna atas AI Agent (lebih tepatnya, tidak memerlukan LLM eksternal maupun AI Agent).

Saat ini, selama 14 hari terakhir, saya sedang menjalankan proses peningkatan lanjutan dengan melatih tambahan META AI tersebut sambil membuat aturan operasional agar dipatuhi. Pada saat yang sama, saya juga sedang melakukan migrasi, perbaikan, dan standardisasi secara bersamaan terhadap tiga sistem MES yang sebelumnya dibuat secara tidak sempurna oleh manusia, dan kini sudah memasuki tahap akhir.

Dan sekarang saya sedang menyiapkan evolusi lainnya.

[spilist2]

Namun, dalam prompt chaining, apakah tidak masalah jika masing-masing disebut agen, seperti LLM yang menjalankan prompt individual, worker eksekusi, worker orkestrator, evaluator LLM, dan sebagainya?

[spilist2]

Ah, jadi ada konsep bahwa “kontrol alur kerja terakhir (LLM secara langsung memutuskan langkah berikutnya atau apakah akan menggunakan alat) disebut sebagai sifat agentik.” Saya paham. Berarti ini tulisan yang membahas dengan menargetkan autonomous agent. Saya sendiri masih belum terlalu paham soal agen...

[GN⁺]

Komentar Hacker News

• Mengembangkan agen memang sangat menyenangkan, tetapi jelas ada masalah serius dalam context engineering. Seberapa pun besar context window-nya, kita tetap harus mengkurasi apa yang bisa dilihat agen, dan rasanya masih kurang filter yang efektif untuk memilih hanya informasi yang benar-benar penting. Karena itu, kita harus membantu dengan cara menyebarkan file .md di berbagai tempat, dan penetapan peran juga penting. Sistem .md ini semacam sistem memori yang masih primitif, dan bisa dikembangkan jauh lebih kokoh. Menurut saya juga memungkinkan untuk membuat program atau model berbasis bahasa alami secara real-time berdasarkan interaksi pengguna. Saat memakai Claude Code, saya sadar bahwa ‘mengendalikan’ agen dengan test suite adalah mekanisme reinforcement yang sangat kuat, dan karena loop ini sebagian besar berjalan sukses, saya berharap akan muncul ide-ide baru untuk menjadikan agen kolaborator yang lebih cerdas ke depannya
  • Rasanya jadi menghabiskan lebih banyak waktu bertarung dengan tool daripada mengerjakan pekerjaan yang sebenarnya
  • Saya penasaran apakah ada praktik yang direkomendasikan untuk menyusun file .md dalam sistem seperti ini. Saya khawatir kalau terlalu banyak markup agar mudah dibaca manusia justru akan menyulitkan llm memprosesnya. Saya ingin tahu apakah membuat file .md dengan format yang sama seperti untuk pembaca manusia akan mengganggu penggunaan oleh llm atau tidak
  • Dari pengalaman saya, manajemen konteks adalah inti dari hampir semua masalah. Misalnya membuat konteks yang tepat untuk pekerjaan paralel/rekursif, menghilangkan beberapa tahap tertentu (misalnya mengedit respons sebelumnya) dan hanya menampilkan hasil revisinya, membuat agen menyadari output-nya sendiri saat saya menambahkan komentar, dan seterusnya—praktiknya memang ada banyak situasi seperti ini
  • Bagian tentang memperkuat agen dengan test suite menarik, saya ingin tahu apakah Anda bisa menjelaskan lebih detail prosedur konkretnya
• Saya masih belum yakin AI agent akan dipakai secara massal seperti yang orang-orang katakan di LinkedIn, tetapi saya tetap membuka kemungkinan itu. Saat ini saya memakai AI dengan kendali yang kuat, seperti Claude Code dan Cursor. Bukan karena modelnya kurang bagus, melainkan karena saya ingin sering memberikan taste dan arah saya sendiri secara langsung. Memberi AI lebih banyak otonomi justru tidak terlalu menarik bagi saya, karena saya merasa identitas dan keterhubungan muncul ketika saya ikut campur. Mungkin saya akan berubah pikiran kalau cara kerja atau UX baru muncul di masa depan, tetapi untuk saat ini saya tidak ingin AI yang terlalu agentic
  • Saya penasaran apakah menurut Anda, seiring waktu ketika kita makin memahami cara model bertindak, hanya dengan memberi konteks dan instruksi yang lebih banyak/lebih baik maka kebutuhan pengguna soal taste dan arah bisa dipenuhi sampai tingkat tertentu. Dari pengalaman saya, prompt engineering yang dibuat dengan baik saja sudah cukup membuat AI bekerja seperti yang saya mau dalam cukup banyak workflow, jadi sering kali saya tidak perlu terlalu sering campur tangan
  • Sangat setuju. Saya pernah meninggalkan komentar serupa di tempat lain, dan saya rasa pepatah lama bahwa tidak ada makan siang gratis masih benar. Jika LLM bisa menyelesaikan masalah tanpa manusia sama sekali, itu berarti semua orang bisa membuat sistem canggih yang sama hanya dengan beberapa baris prompt, dan pada titik itu tiap sistem kehilangan pembeda dan nilainya. Jika prompt adalah level abstraksi yang baru, misalnya saat kita berkata pada Claude, “tolong buatkan aplikasi catatan,” jutaan orang akan memasukkan prompt murah yang sama, dan saat itu saya jadi bertanya-tanya apa sebenarnya nilai tambah yang dibawa oleh prompter
  • Menurut saya, seiring waktu masing-masing elemen taste ini juga akan makin bisa disistematisasi sebagai prompt. Misalnya satu prompt untuk mendorong agar perubahan kode tidak menciptakan variabilitas yang tidak perlu dan tetap ditulis immutable jika memungkinkan. Prompt lain untuk menghindari logging yang tidak berguna, dengan aturan yang saya definisikan secara spesifik, dan seterusnya. Saat meninjau perubahan kode, saya menjalankan semua prompt ini secara terpisah lalu mengumpulkannya sebagai output MCP yang terstruktur. Bagian-bagian seperti ini diterapkan ke code-agent untuk mewujudkan iterasi review otomatis. Jika muncul situasi yang mengharuskan saya menambahkan konteks secara langsung, saya membuat prompt baru atau memperluas prompt yang ada untuk memperkuatnya
• Menarik juga melihat munculnya ‘otoritas’ di bidang yang anehnya terasa baru 1–2 tahun. Rasanya seperti versi terbalik dari meme “mencari orang dengan 10 tahun pengalaman untuk bahasa yang baru berumur 2 tahun”
  • Saya sudah membuat hal-hal yang disebut 'ai agent' sejak GPT-3 keluar, dan banyak orang lain juga punya pengalaman yang sama. Itu sudah 5 tahun sekarang, dan kalau setelah 5 tahun pun belum lahir pakar, menurut saya itu berarti memang tidak ada pakarnya. Tentu saja, belakangan kata ‘agen’ juga berubah menjadi buzzword, jadi maknanya makin memudar
  • Begitu membaca cerita pengalaman seperti “saya sudah bekerja dengan puluhan tim...”, reaksi saya justru merasa itu agak dramatis
• Ringkasan intinya: jika sudah ada solusi yang didefinisikan sebelumnya, tidak perlu repot memakai agen (misalnya ‘pattern’ yang muncul di artikel). Biasanya programmer akan merekomendasikan solusi yang lebih sederhana dan andal untuk masalah yang bisa dipecahkan dengan program. Di masa depan AI mungkin benar-benar cukup pintar untuk menyelesaikan masalah apa pun dengan brute force, tetapi saat ini itu hanya menambah kompleksitas. Saya rasa salah satu alasan orang antusias dengan agen adalah karena kebanyakan mengenal LLM lewat penggunaan sebagai chat assistant. Chat assistant seperti ini sering tidak punya solusi baku dan interaksinya kompleks, sehingga justru agen bisa menunjukkan keunggulannya. Contoh: “cari Jumat malam terdekat lalu kirim pesan ke Bob menanyakan apakah dia bisa bertemu”—hal seperti ini sulit diprogram untuk semua kemungkinan dari awal. Cara berinteraksi dengan assistant nyaris tak terbatas, sehingga agen lebih cocok
  • Ini bekerja sangat baik saat kecepatan verifikasi lebih cepat daripada melakukannya sendiri dari awal. Hanya saja, saya memang sulit mempercayai AI tanpa verifikasi
• Saya heran kenapa begitu banyak contoh pada akhirnya bermuara pada “cara mengirim spam lebih cepat dan lebih baik”
  • Bukankah memang itu contohnya? Misalnya crawl LinkedIn untuk mencari orang, lalu mengirim spam lewat email yang ‘dipersonalisasi’
  • Itu bisa dianalogikan seperti roda yang pada akhirnya tidak bisa berputar tanpa pelumas
• Itu benar pada akhir 2023 sampai awal 2024, tetapi sekarang sekitar pertengahan 2025 saya rasa hal itu tidak lagi berlaku untuk banyak tugas jika memakai SOTA LLM. Dulu kebanyakan orang memanggil LLM seperti fungsi, tetapi itu juga karena salah memilih alat. LLM papan atas saat ini (Gemini 2.5 Pro, Claude 4, dan lain-lain) benar-benar cerdas, jadi kemampuan instruction following dan pemilihan tool mereka sangat bagus. Tool checklist, perintah delegate, pemecahan tugas, dan semacamnya tetap dibutuhkan. Tetapi pendekatan membuat instruksi dan menetapkan perintah—terutama jika tool command bisa ditentukan dengan mudah dalam lingkungan UI—lebih fleksibel dan merupakan level abstraksi yang lebih tinggi daripada workflow. Workflow visual pada akhirnya juga hanyalah pemrograman yang rapuh dan sulit dituning. Enam sampai dua belas bulan lalu ini memang belum mungkin, tetapi kalau LLM-nya kurang bagus, itu juga masih belum berlaku. Secara umum hanya sedikit model yang sangat bagus dalam instruction following dan integrasi tool, sehingga menerapkan agen pada model-model seperti itu menguntungkan. Dalam 1–2 tahun ke depan akan ada tren besar agen untuk pemakaian browser/komputer. Mereka juga akan dipadukan dengan sistem memori yang baik dan ‘mode demonstrasi/observasi’, sehingga dapat mempelajari (merekam) proses pengguna memakai UI, dan juga mempelajari prosedur yang dioptimalkan dari instruksi lisan/dokumen manusia
  • Dengan munculnya model agen yang paling kuat belakangan ini (Claude Opus 4, dll.), situasinya memang berubah total. Tetap perlu konteks yang baik, tetapi kemampuan memilih tool yang tepat benar-benar luar biasa
  • Teknik-teknik di postingan aslinya pada dasarnya adalah 'memodelkan masalah sebagai data flow graph lalu mengikutinya apa adanya'. Kalau pendekatannya melompat dari tahap pemodelan menjadi sekadar “nanti juga beres sendiri”, itu bukan rekayasa, melainkan iman
• Selama 3 minggu terakhir saya berusaha membuat agen bekerja secara stabil, tetapi akhirnya beralih ke pola yang jauh lebih sederhana. Agen saat ini terasa seperti tangan dengan enam jari—masih tahap awal evolusi
• Ketika melihat hal seperti “koordinator menyerah jika definisi tugas tidak cukup jelas” lalu langsung menyimpulkan “kalau begitu buang saja koordinatornya dan pakai logika imperatif”, menurut saya sebenarnya itu bisa jadi masalah yang selesai jika prompt atau deskripsi tool ditulis lebih spesifik, lalu ditambahkan prosedur seperti ringkasan antara atau kompresi konteks LLM. Kalau artikelnya bahkan tidak menyertakan contoh prompt/deskripsi tool panjang yang benar-benar layak dipakai, sulit juga membuat penilaian. Secara intuitif, jawabannya memang memakai orkestrasi yang sesuai dengan tugasnya, tetapi saya percaya dalam praktiknya jauh lebih banyak tugas yang bisa memanfaatkan orkestrasi bergaya agen secara efektif
• Saya juga 100% setuju. Agen memang sangat seru dan bagus untuk eksperimen, tetapi untuk benar-benar meningkatkan produktivitas, kuncinya adalah mengorkestrasi workflow dan proses tertentu dengan baik, serta fokus pada bagian yang memang hanya bisa dilakukan oleh AI. Sebagai referensi, saya juga merekomendasikan tulisan tentang AI workflow di ai.intellectronica.net
• Hal yang belakangan sering saya lihat adalah orang memasukkan LLM ke tool orkestrasi workflow yang sudah ada sehingga membangun sistem jadi jauh lebih mudah. Sebagian besar kompleksitas ada pada a) model itu sendiri (lab mutakhir menyediakan model yang mudah dipakai), b) produksisasi workflow (tool workflow mempermudahnya). Karena workflow seperti ini berlandaskan pekerjaan yang sudah ada, nilainya mudah dikenali dan diukur. Pola seperti ini makin banyak, sampai-sampai saya merilis SDK yang dipaketkan khusus untuk Airflow (tool workflow yang sangat populer).
  https://github.com/astronomer/airflow-ai-sdk

[sto1111]

Saya juga saat ini sedang membuat Computer-use Agent bernama UseDesktop.

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

Karena itu, saya setuju dengan sebagian besar isi tulisan ini.

Tulisan ini lebih membahas gambaran besarnya daripada tips yang benar-benar praktis, jadi kalau menambahkan beberapa tips lagi saat mengembangkan agentic/agent berbasis LLM, pada akhirnya LLM itu berbasis transformer (yaitu penalaran berbasis probabilistik; berdasarkan token/state saat ini, ia bukan memahami konteks/semantik lalu mengucapkan kata berikutnya, melainkan menghasilkan output secara probabilistik). Karena itu, sebaik apa pun sys prompt yang kita berikan, cukup sering ia tidak memberikan jawaban yang kita inginkan (misalnya diminta menjawab dalam output JSON, tetapi kadang lupa menutup } dan sebagainya). Jadi, menambahkan beberapa fallback fn berbasis regex selalu merupakan hal yang wajib.

Lalu, kalau menulis sys prompt yang meminta structured output, biasanya lebih baik memakai non-reasoning model, dan semakin panjang context, semakin sering halusinasi muncul, jadi lebih baik membuat beberapa sys prompt lalu meng-chain-nya.

Saat mengembangkan layanan, karena berbagai error bisa terjadi, kuncinya adalah merancang arsitektur layanan yang modular dan fault tolerant (misalnya supervisor agent dibuat async dan agent lainnya sync), terutama untuk agentic/agent yang sering menghasilkan unexpected output.
Karena itu, sejak awal sebaiknya menulis kode sambil menjaga SRP dan menulisnya secara declarative; saya ingin mengatakan bahwa pendekatan fungsional itu baik (= tidak ada side effect, dan flow-nya intuitif).

Lalu, tergantung apakah LLM dipakai lewat API atau kita akan melakukan model serving sendiri, tetapi jika Anda akan langsung men-serving SLM atau LLM, jangan lakukan model serving di server yang sama dengan backend hosting; akan lebih baik dan lebih fault tolerant jika IO bound task dan CPU bound tasks (yaitu task yang membutuhkan GPU, perkalian matriks, dan semacamnya) ditempatkan di server yang berbeda (misalnya hosting CPU bound task di runpod).

Masih ada banyak tips pengembangan lainnya, tetapi karena takut jadi terlalu panjang, saya tulis sampai di sini saja.

Semoga ini bisa membantu seseorang.

[jypark]

Terima kasih banyak telah berbagi pengalaman dan pendapat yang begitu berharga. Masukan dari orang yang benar-benar berada di lapangan seperti ini sangat membantu.