Cara Kerja LLM untuk Developer

Asisten AI di editor, chat AI, dan agen coding di terminal semuanya digerakkan oleh mesin yang sama: LLM (large language model). Kalau kamu memakainya setiap hari tanpa tahu cara kerjanya, perilakunya terasa acak. Kadang ia menulis fitur rumit dalam sekali jalan, kadang ia memakai function yang tidak pernah ada, dan menjelaskannya dengan sangat yakin.

Perilaku itu sebenarnya bisa ditebak. Artikel ini menjelaskan lima sifat dasar LLM yang paling berpengaruh pada pekerjaan developer, dengan satu demo kecil yang bisa kamu jalankan sendiri. Setelah memahaminya, kamu akan tahu kapan bisa percaya pada hasilnya, kapan harus curiga, dan bagaimana memberi masukan supaya hasilnya lebih baik.

Inti: menebak kelanjutan teks

Di dasarnya, LLM melakukan satu hal: diberi sebuah teks, ia menebak potongan teks berikutnya. Potongan itu ditambahkan ke teks, lalu ia menebak lagi, terus berulang sampai jawabannya selesai. Semua kemampuannya, dari menjawab pertanyaan sampai menulis kode, muncul dari tebakan berulang ini.

Supaya terasa nyata, ini model bahasa mainan yang bekerja dengan prinsip yang sama, hanya jauh lebih sederhana. Ia “belajar” dari beberapa kalimat dengan mencatat kata apa yang biasa muncul setelah sebuah kata, lalu memakai catatan itu untuk menyusun kalimat baru:

// Model bahasa mainan: menebak kata berikutnya dari kata sebelumnya.
const teks = `
saya suka kopi susu . saya suka kopi hitam . saya suka teh manis .
dia suka kopi susu . dia minum kopi susu setiap pagi .
saya minum teh manis setiap sore .
`;

// 1. "Latih": hitung kata apa saja yang pernah muncul setelah setiap kata.
const kata = teks.trim().split(/\s+/);
const tabel = {};
for (let i = 0; i < kata.length - 1; i++) {
  const sekarang = kata[i];
  const berikut = kata[i + 1];
  tabel[sekarang] ??= {};
  tabel[sekarang][berikut] = (tabel[sekarang][berikut] ?? 0) + 1;
}

// 2. Ubah hitungan jadi peluang.
function peluang(kataSekarang) {
  const hitungan = tabel[kataSekarang] ?? {};
  const total = Object.values(hitungan).reduce((a, b) => a + b, 0);
  return Object.entries(hitungan)
    .map(([k, n]) => [k, n / total])
    .sort((a, b) => b[1] - a[1]);
}

const tampil = (k) => peluang(k).map(([w, p]) => `${w} ${Math.round(p * 100)}%`).join(", ");
console.log("Setelah kopi:", tampil("kopi"));
console.log("Setelah suka:", tampil("suka"));

// 3. Hasilkan kalimat, satu kata demi satu kata.
function pilihKata(kataSekarang, acak) {
  const pilihan = peluang(kataSekarang);
  if (pilihan.length === 0) return null;
  if (!acak) return pilihan[0][0]; // selalu ambil yang paling mungkin
  let r = Math.random();
  for (const [k, p] of pilihan) {
    r -= p;
    if (r <= 0) return k;
  }
  return pilihan.at(-1)[0];
}

function lanjutkan(awal, acak) {
  const hasil = [awal];
  while (hasil.length < 8) {
    const berikut = pilihKata(hasil.at(-1), acak);
    if (berikut === null || berikut === ".") break;
    hasil.push(berikut);
  }
  return hasil.join(" ");
}

console.log("Paling mungkin:", lanjutkan("dia", false));
for (let i = 1; i <= 3; i++) {
  console.log(`Acak #${i}:`, lanjutkan("dia", true));
}

Jalankan dengan node tebak-kata.js (diuji di Node 24). Salah satu hasilnya:

Setelah kopi: susu 75%, hitam 25%
Setelah suka: kopi 75%, teh 25%
Paling mungkin: dia suka kopi susu
Acak #1: dia suka kopi hitam
Acak #2: dia minum kopi hitam
Acak #3: dia suka kopi hitam

Tiga baris terakhir akan berbeda setiap kali dijalankan. Simpan demo ini di kepala, karena hampir semua sifat LLM di bawah bisa dilihat langsung di dalamnya.

LLM sungguhan tentu jauh lebih canggih. Ia tidak hanya melihat satu kata sebelumnya, tapi seluruh teks yang diberikan kepadanya. Ia juga tidak menyimpan tabel hitungan, melainkan jaringan saraf (neural network) dengan miliaran angka yang disetel dari teks dalam jumlah sangat besar, termasuk banyak sekali kode. Hasilnya, tebakannya bisa mengikuti logika, gaya, dan struktur yang rumit. Tapi prinsipnya tetap sama: menghasilkan kelanjutan yang paling masuk akal, bukan mencari kebenaran.

Sifat 1: yang dihitung adalah token, bukan kata

LLM tidak membaca huruf atau kata, tapi token: potongan teks yang bisa berupa satu kata utuh, sebagian kata, tanda baca, atau spasi. Kata umum dalam bahasa Inggris sering menjadi satu token. Kata yang lebih jarang, termasuk banyak kata bahasa Indonesia dan nama variabel seperti hitungTotalSetelahDiskon, biasanya dipecah menjadi beberapa token.

Kenapa developer perlu tahu? Karena batas dan biaya dihitung dalam token. Panjang maksimal input, panjang maksimal jawaban, dan tagihan API semuanya memakai satuan ini. File log berukuran besar yang kamu tempel ke chat bisa menghabiskan jatah token jauh lebih cepat daripada yang kamu kira.

Sifat 2: hanya tahu apa yang ada di context window

Semua teks yang “dilihat” LLM saat menjawab disebut context, dan batas panjangnya disebut context window. Isinya adalah semua yang dikirim ke model dalam satu permintaan: instruksimu, riwayat percakapan, isi file yang dilampirkan, dan instruksi tersembunyi dari aplikasi yang kamu pakai.

Akibatnya sangat praktis:

• LLM tidak melihat proyekmu kecuali isinya dimasukkan ke context. Asisten di editor dan agen coding bekerja keras memilih file mana yang dimasukkan. Kalau file yang penting tidak terpilih, jawabannya akan menebak-nebak.
• LLM tidak punya ingatan antarsesi. Setiap permintaan dimulai dari nol. Kesan bahwa ia “ingat” percakapan sebelumnya muncul karena aplikasinya mengirim ulang riwayat percakapan ke dalam context. Begitu sesi baru dimulai, semua itu hilang, kecuali disimpan di file yang selalu dibaca ulang, seperti file aturan proyek.
• Context yang panjang tidak selalu lebih baik. Percakapan yang sudah sangat panjang, penuh percobaan yang gagal, sering membuat jawaban makin kacau. Ini salah satu alasan kenapa memulai sesi baru dengan ringkasan yang bersih sering menyelesaikan masalah, seperti dibahas di masalah 70%.

Coba lihat lagi demo tadi. Kalau diminta melanjutkan kata yang tidak pernah ia lihat, misalnya laptop, peluang("laptop") mengembalikan array kosong dan model mainan itu berhenti. LLM sungguhan tidak akan diam seperti itu. Ia tetap menghasilkan sesuatu yang terdengar masuk akal, dan di situlah masalah berikutnya muncul.

Sifat 3: pengetahuannya berhenti di satu titik

LLM belajar dari data sampai tanggal tertentu, yang disebut knowledge cutoff. Hal yang terjadi setelahnya tidak ia ketahui, kecuali diberikan lewat context, misalnya dari hasil pencarian web atau dokumentasi yang kamu tempel.

Bagi developer, akibatnya sering terlihat seperti ini:

• AI menyarankan cara lama untuk sebuah library yang API-nya sudah berubah di versi terbaru.
• AI tidak tahu framework atau fitur yang baru rilis.
• AI mencampur sintaks dari beberapa versi sekaligus.

Solusinya sederhana: sebutkan versi yang kamu pakai (“Next.js 16, Node 24”), dan kalau perlu tempelkan potongan dokumentasi resminya. Begitu informasinya ada di context, LLM bisa memakainya.

Sifat 4: jawabannya tidak selalu sama

Di demo tadi, mode “paling mungkin” selalu menghasilkan kalimat yang sama, sedangkan mode “acak” berbeda setiap kali dijalankan. LLM sungguhan biasanya memakai cara kedua: kata berikutnya diambil secara acak sesuai peluangnya, bukan selalu yang paling tinggi. Proses ini disebut sampling. Seberapa berani ia memilih kata yang peluangnya kecil diatur oleh parameter seperti temperature.

Sampling membuat jawaban terasa lebih alami dan kreatif. Konsekuensinya, prompt yang sama bisa menghasilkan kode yang berbeda. Satu kali bisa benar, kali berikutnya bisa salah. Jadi jangan menganggap satu hasil yang berhasil sebagai bukti bahwa cara itu selalu berhasil. Yang membuat hasilnya bisa dipercaya adalah pengujian, bukan keberuntungan.

Sifat 5: lancar tidak sama dengan benar

Perhatikan output demo tadi: dia minum kopi hitam. Kalimat itu tidak pernah ada di data latihnya. Data latih hanya menyebut dia minum kopi susu. Model menyambung dia minum kopi dengan kopi hitam dari kalimat lain karena setiap potongannya terlihat wajar, dan hasilnya sebuah “fakta” baru yang tidak pernah ada.

Inilah yang disebut halusinasi: LLM menghasilkan sesuatu yang terdengar meyakinkan tapi tidak benar. Ia tidak sedang berbohong. Ia memang tidak punya mekanisme untuk membedakan “benar” dan “terdengar benar”. Di dunia kode, halusinasi muncul sebagai:

• Function atau method yang tidak ada, tapi namanya sangat masuk akal, misalnya method yang ada di library lain.
• Opsi konfigurasi karangan yang tidak dikenali oleh tool-nya.
• Nama paket yang tidak ada di npm atau PyPI. Ini juga masalah keamanan. Penyerang bisa mendaftarkan paket dengan nama yang sering “dikarang” AI lalu mengisinya dengan kode berbahaya. Sebelum menjalankan npm install atau pip install dari saran AI, pastikan paketnya memang ada, memang paket yang dimaksud, dan aktif dipelihara.
• Penjelasan yang salah tapi rapi, misalnya tentang kenapa sebuah bug terjadi.

Model yang lebih baru umumnya lebih jarang berhalusinasi dibanding model-model awal, tapi belum pernah nol. Karena itu, kebiasaannya tetap sama: jalankan kodenya, baca pesan errornya, dan cek dokumentasi resmi untuk hal-hal yang penting.

Dari sifat ke kebiasaan kerja

Hampir semua teknik memakai AI yang baik, dari menulis prompt sampai memakai agen coding, adalah cara mengatasi lima sifat ini.

Data yang kamu kirim

Satu hal lagi yang sering terlupa: semua yang masuk ke context dikirim ke server penyedia model, kecuali kamu menjalankan model di komputermu sendiri. Itu termasuk isi file yang dibaca asisten di editor.

• Jangan menempelkan password, API key, atau isi file .env ke chat. Kalau sudah telanjur, anggap rahasia itu bocor dan ganti. Caranya ada di environment variable dan secrets.
• Untuk kode kantor atau data pelanggan, cek dulu kebijakan perusahaanmu dan pengaturan privasi tool-nya, termasuk apakah data boleh dipakai untuk melatih model.

Pertanyaan yang sering diajukan

Apakah LLM benar-benar “mengerti” kode?

Tergantung definisi “mengerti”. LLM jelas menangkap pola, struktur, dan logika kode dengan sangat baik, sehingga bisa menulis dan menjelaskan kode yang belum pernah ia lihat persis. Tapi ia tidak menjalankan kodenya di kepala dan tidak bisa memastikan hasilnya benar. Untuk keperluan sehari-hari, anggap ia rekan yang sangat cepat dan berpengetahuan luas, tapi tetap perlu diperiksa.

Kenapa jawabannya kadang salah padahal soalnya mudah?

Soal yang mudah bagi manusia belum tentu mudah bagi mesin penebak token. Menghitung huruf dalam sebuah kata, misalnya, sulit karena LLM melihat token, bukan huruf. Untuk hal yang butuh ketelitian seperti hitungan, minta ia menulis dan menjalankan kode untuk menghitungnya, jangan menebak langsung.

Model yang lebih besar selalu lebih baik?

Untuk tugas rumit, model yang lebih kuat biasanya menghasilkan kode yang lebih baik. Tapi model yang lebih kecil lebih cepat dan lebih murah, dan sering sudah cukup untuk tugas sederhana seperti autocomplete. Banyak tool memakai beberapa model sekaligus untuk keperluan yang berbeda.

Bagaimana kalau aku ingin AI tahu kode proyekku?

Masukkan informasinya ke context. Asisten di editor dan agen coding melakukannya otomatis dengan membaca file proyek. Untuk aturan yang berlaku terus, seperti konvensi penamaan atau perintah menjalankan test, kebanyakan tool mendukung file aturan proyek yang selalu dibaca di awal sesi.

Kesimpulan

LLM menebak kelanjutan teks yang paling masuk akal, satu token demi satu token, hanya berdasarkan apa yang ada di context-nya. Dari situ lahir lima sifat yang perlu kamu ingat: berhitung dengan token, terbatas pada context, punya knowledge cutoff, memakai sampling, dan bisa berhalusinasi. Semua teknik memakai AI dengan baik berangkat dari kelima sifat ini.

Langkah berikutnya di jalur Developer + AI: memakai asisten AI di editor, dari autocomplete sampai chat, dengan cara yang membuatmu lebih cepat tanpa kehilangan kendali atas kodenya.