LLM-First atau Code-First? Di Mana Kecerdasan Berada dalam AI Produksi

Bagaimana memutuskan apa yang harus ditangani model, apa yang harus ditangani kode Anda, dan bagaimana menghubungkan keduanya.

Beberapa tahun yang lalu, arsitektur aplikasi AI tampak seperti: mengirim prompt ke model bahasa besar → mendapatkan respons → menampilkannya kepada pengguna. Itu bukan lagi keseluruhan cerita saat ini. Model diminta untuk menafsirkan niat, mengambil informasi, memilih alat, memanggil API, membuat rencana, dan menjalankan alur kerja multi‑langkah.

Perubahan itu telah membagi bidang menjadi dua – LLM-First atau Code-First

Dalam arsitektur LLM-first, model berada di pusat dan memutuskan apa yang terjadi selanjutnya. Ia membaca permintaan, memilih alat, menentukan urutan operasi, memeriksa hasil antara, dan mengubah arah ketika diperlukan.

Dalam arsitektur code-first, perangkat lunak/kode tetap bertanggung jawab atas urutan, aturan bisnis, validasi, izin, dan eksekusi. LLM di sini seperti seorang spesialis yang dipanggil kode ketika diperlukan pemahaman atau generasi bahasa.

Orang-orang suka berdebat tentang mana yang lebih baik. Saya pikir itu argumen yang salah. Pertanyaan yang lebih tepat adalah di mana masing‑masing jenis kecerdasan seharusnya berada. Sistem produksi terkuat yang pernah saya lihat jarang murni satu atau lainnya. Mereka mencampur penalaran probabilistik dengan kontrol deterministik, dan mereka melakukannya secara sengaja.

Mengapa LLM-First Begitu Menarik

Perangkat lunak tradisional berfungsi dengan baik ketika Anda dapat merinci persyaratannya. Misalnya, seorang pengguna memilih produk, memasukkan jumlah, dan mengirimkan pembayaran. Anda mendefinisikan status yang diizinkan, aturan validasi, kondisi kesalahan, dan urutan transaksi dalam kode. Selesai.

Bahasa alami tidak berkooperasi seperti itu. Bayangkan seorang pengguna mengetik: “Temukan transaksi yang tampak tidak biasa, jelaskan apa yang terjadi, dan beri tahu saya apa yang harus saya selidiki terlebih dahulu.”

Tidak ada jalur tetap untuk permintaan itu. Di sini sistem harus memutuskan apa arti “tidak biasa”, menentukan data mana yang penting, mungkin memanggil beberapa alat, menimbang respons, dan menulis penjelasan yang dapat digunakan orang. Tidak ada tim insinyur/tanpa kode yang dapat mengantisipasi setiap cara pengungkapan dan setiap kombinasi permintaan sebelumnya.

Di sinilah LLM memainkan peran penting, berfungsi sebagai lapisan penalaran fleksibel antara bahasa manusia dan layanan deterministik Anda. Inilah juga mengapa agen mendapat begitu banyak perhatian. panduan arsitektur AI agentik Google Cloudmenjelaskan agen sebagai aplikasi di mana model AI berfungsi sebagai mesin penalaran, sementara alat memungkinkan ia mengakses sistem eksternal dan data.

Anthropic’s Building Effective AI Agents panduanmembuat perbedaan yang terus saya kembali ke. Dalam sebuah alur kerja, model dan alat mengikuti jalur yang ditentukan kode Anda. Dalam sebuah agen, LLM mengarahkan prosesnya sendiri dan memutuskan cara menggunakan alatnya. Panduan yang sama menyarankan memulai dengan arsitektur paling sederhana yang menyelesaikan masalah, alih-alih menambahkan kompleksitas agentik secara refleksif. Saya akan menekankan saran itu dua kali.

Batasan “Biarkan Model Memutuskan”

Sebuah model dapat menalar tentang apa yang seharusnya terjadi. Penalaran tidak sama dengan menegakkan aturan.

Misalnya ambil sebuah alur kerja keuangan. LLM mungkin sangat baik dalam memahami “kirim jumlah yang sama seperti yang saya kirim bulan lalu ke vendor yang sama.” Tetapi apakah ia juga harus memutuskan apakah transfer tersebut diotorisasi, menghitung batas regulasi, memverifikasi kepemilikan akun, mengesampingkan kebijakan keamanan, dan mengeksekusi transaksi?

Mungkin tidak. Pekerjaan ini bersifat deterministik, dapat diuji, dapat diaudit, dan dapat ditegakkan, dan itulah yang menjadi keunggulan perangkat lunak tradisional. Risiko meningkat ketika model memperoleh akses ke alat. panduan keamanan AI generatif OWASPmenandaikelebihan wewenang sebagai risiko signifikan: memberikan sistem berbasis LLM lebih banyak fungsionalitas, izin, atau otonomi daripada yang dibutuhkan tugasnya. Output model yang aneh atau dimanipulasi adalah satu hal ketika hanya menghasilkan teks. Itu menjadi jauh lebih besar ketika model dapat bertindak di dunia nyata.

Tidak ada yang berarti model tidak boleh pernah mengambil tindakan. Itu berarti otonomi model harus dibatasi oleh otoritas deterministik.

Code-First Masih Penting

Dengan AI yang berkembang begitu cepat, mudah merasa bahwa rekayasa konvensional sudah ketinggalan zaman. Saya berpendapat sebaliknya. AI membuat sistem deterministik yang baik menjadi lebih penting, bukan kurang.

Kode masih menjadi pilihan yang tepat setiap kali suatu tugas menuntut keterulangan yang tepat. Otentikasi adalah contoh paling sederhana. Sebuah model tidak boleh “menalar” tentang apakah seseorang memiliki hak admin. Aplikasi Anda harus meminta sistem manajemen identitas dan akses yang berwenang. Hal yang sama berlaku untuk perhitungan moneter, pemeriksaan hak, validasi data, batasan regulasi, batas transaksi, validasi skema, dan segala sesuatu yang tidak dapat dibatalkan. Hal‑hal ini memerlukan kontrak eksplisit, bukan dugaan terbaik.

Ini sejalan dengan pemikiran tata kelola yang lebih luas. NIST AI Risk Management Framework meminta organisasi mengelola risiko AI di seluruh desain, pengembangan, penerapan, dan penggunaan. Rekanannya Generative AI Profile menambahkan bahwa sistem generatif mungkin memerlukan pengawasan ekstra, dokumentasi, tinjauan, dan kontrol, tergantung pada risiko yang terlibat.

Jadi saya merasa membantu untuk membagi setiap keputusan desain menjadi dua pertanyaan:

Apa yang seharusnya terjadi?

dan

Apa yang diizinkan terjadi?

LLM sering dapat membantu dengan yang pertama. Sistem deterministik biasanya harus menangani yang kedua.

Pola Hibrida: Berpikir Probabilistik, Eksekusi Deterministik

Untuk kebanyakan aplikasi perusahaan, jawabannya secara praktis adalah hibrida. LLM berfungsi sebagai lapisan interpretasi dan penalaran. Layanan deterministik berfungsi sebagai lapisan eksekusi dan penegakan.

Berikut contoh. Misalkan asisten AI membantu pengembang membuat lingkungan pengujian API sementara, dan seorang pengembang mengetik: “Berikan saya sandbox untuk alur kerja onboarding pelanggan.”

LLM dapat menafsirkan itu, menentukan alur kerja mana yang kemungkinan dimaksud, membaca dokumentasi, dan menyarankan API mana yang mungkin relevan. Namun sebenarnya membuat lingkungan tidak seharusnya bergantung pada teks yang dihasilkan secara bebas. Kode dapat memastikan API yang diminta ada, memvalidasi kontraknya, memeriksa otorisasi, menegakkan batas sumber daya, menghasilkan konfigurasi yang disetujui, dan menjalankan penerapan.

Pembagian kasar terlihat seperti ini:

• LLM: memahami, menalar, mengklasifikasikan, mengusulkan, merangkum.
• Kode: memvalidasi, mengotorisasi, menghitung, menyimpan, menegakkan, mengeksekusi.

Setiap sisi melakukan pekerjaan yang paling cocok untuknya, dan tidak ada yang diminta meniru kekuatan sisi lain.

Batasan Lebih Penting Saat Agen Menjadi Lebih Kuat

Pemisahan ini menjadi lebih penting saat kita beralih dari asisten ke agen. Asisten yang memberikan jawaban buruk hanya menyusahkan seseorang. Agen dengan akses menulis ke produksi dapat menyebabkan kekacauan yang jauh lebih besar.

Solusinya tidak harus menghilangkan otonomi. Melainkan menambahkan otonomi secara bertahap sambil mempertahankan titik kontrol eksplisit.panduan Google tentang sistem multi‑agen merekomendasikan memadukan perilaku AI dinamis dengan kontrol keamanan deterministik, observabilitas, otonomi yang jelas terdefinisi, dan pengawasan manusia untuk skenario bisnis‑krusial.

Persetujuan manusia juga dapat dibangun ke dalam alur kerja itu sendiri alih-alih menjadi jaring pengaman informal. Microsoft’s agent framework documentation, misalnya, mendukung pemanggilan alat yang berhenti sampai seseorang secara eksplisit menyetujui operasi yang diminta.

Prinsipnya sederhana: semakin tinggi konsekuensi suatu tindakan, semakin kuat kontrol deterministik di sekitarnya harus.

Lima Pertanyaan untuk Diajukan Sebelum Menyerahkan Tugas ke LLM

Saat saya memutuskan apakah sebuah komponen harus LLM-first atau code-first, saya mempertimbangkan hal-hal berikut:

1. Apakah tugas memiliki satu jawaban yang secara objektif benar? Jika ya, condonglah ke kode deterministik. Perhitungan pajak, izin, dan validasi skema tidak boleh berubah karena model membacanya secara berbeda hari ini.
2. Apakah melibatkan bahasa ambigu atau informasi tidak terstruktur? Jika ya, LLM dapat menambah nilai nyata.
3. Apa yang terjadi jika model salah? Arsitektur yang tepat untuk ringkasan rapat sangat berbeda dari arsitektur yang tepat untuk memulai pembayaran.
4. Bisakah output divalidasi secara independen? Rencana yang dihasilkan LLM menjadi jauh lebih aman ketika aturan deterministik dapat memeriksa tindakan yang dihasilkan sebelum dijalankan.
5. Apakah ini benar-benar membutuhkan agen? Jika Anda sudah mengetahui langkah-langkahnya, alur kerja biasa dengan beberapa panggilan LLM yang ditargetkan biasanya lebih sederhana, lebih murah, lebih mudah diuji, dan lebih mudah dioperasikan.

Pertanyaan terakhir itu layak mendapat perhatian ekstra. Agen kuat karena mereka dapat menangani situasi di mana Anda tidak dapat memprediksi setiap langkah. Tetapi jika Anda bisa memprediksi langkah-langkahnya, mengubahnya menjadi masalah penalaran terbuka sering menambah variabilitas tanpa menambah kecerdasan.

Keandalan adalah Properti Arsitektural, Bukan Prompt

Banyak tim memulai dengan mencoba meningkatkan keandalan hampir sepenuhnya melalui rekayasa prompt. Prompt penting, tetapi mereka tidak dapat menanggung seluruh beban.

Sebuah sistem produksi harus mengasumsikan bahwa output model kadang-kadang akan tidak lengkap, rusak, tidak terduga, atau hanya salah. OWASP Top 10 untuk aplikasi LLM mencantumkan risiko seperti penyuntikan prompt dan penanganan output yang tidak tepat, yang menegaskan kebiasaan penting: memperlakukan output model sebagai masukan yang tidak dipercaya ke sistem hilir, bukan sebagai instruksi yang dijalankan secara otomatis.

Itu mengubah pertanyaan yang Anda ajukan. Alih-alih \”Bagaimana saya menulis prompt yang selalu membuat model mengikuti aturan?\”, tanyakan \”Bagaimana saya merancang sistem sehingga aturan tidak dapat dilanggar bahkan ketika model membuat kesalahan?\”

Itu adalah masalah arsitektur perangkat lunak, bukan masalah prompting. Sebuah prompt dapat memberi tahu agen untuk tidak melakukan tindakan yang tidak sah. Layanan otorisasi dapat benar-benar menghentikannya. Kedua kontrol tersebut tidak setara.

Melebihi Perdebatan: Sistem Intent-First

Memikirkan semua ini, saya menjadi percaya bahwa perdebatan LLM-first versus code-first mengarah pada ide ketiga: intent-first arsitektur.

Dalam sistem intent-first, aplikasi dimulai dengan memahami apa yang ingin dicapai pengguna. Di sinilah LLM paling berharga, karena orang jarang tepat tentang apa yang mereka inginkan. Dari situ, sistem secara bertahap mengubah ketidakjelasan itu menjadi operasi terstruktur dan deterministik.

Permintaan seperti \”Bantu saya menyelesaikan masalah pembayaran pelanggan\” dapat berubah menjadi alur kerja: memahami intent, mengambil transaksi, mengidentifikasi alasan kegagalan, merekomendasikan perbaikan, meminta persetujuan, mengeksekusi operasi yang disetujui.

Beberapa tahap tersebut mendapat manfaat dari penalaran model bahasa. Lainnya harus berupa layanan tetap. Arsitektur tidak ditentukan oleh apakah AI atau kode \”menang.\” Itu ditentukan oleh di mana ketidakpastian dapat diterima.

Intinya

Seiring model meningkat, akan menggoda untuk memberi mereka kontrol atas bagian yang semakin besar dari tumpukan. Kadang itu akan menjadi keputusan yang tepat. Pada sistem lain, desain paling canggih adalah yang sengaja memberi model kurang wewenang.

Rekayasa AI produksi, pada akhirnya, adalah tentang menempatkan kecerdasan pada batas yang tepat. Gunakan model bahasa di mana interpretasi, penalaran, sintesis, dan adaptasi menciptakan nilai. Gunakan perangkat lunak deterministik di mana konsistensi, otorisasi, presisi, dan penegakan penting. Kemudian hubungkan keduanya melalui antarmuka yang sempit, dapat diamati, dan teruji dengan baik.

Masa depan AI perusahaan mungkin tidak sepenuhnya LLM-first atau sepenuhnya code-first. Itu LLM di mana ketidakpastian memerlukan kecerdasan, dan kode di mana kepastian memerlukan kontrol.

Perbedaan itu mungkin jauh lebih penting daripada model mana yang Anda pilih.