Kamus Istilah Coding untuk Non-Programmer yang Lagi Bikin App Pakai AI

Kamu lagi asik cerita ide aplikasi ke AI coding kayak Cursor atau Claude Code. Terus tiba-tiba dia balas: "Oke, aku bikin dulu endpoint-nya, nanti kita deploy setelah frontend-nya beres." Kamu ngangguk. Pura-pura ngerti. Padahal dalam hati mikir, endpoint itu apa sih, deploy itu makan apa.

Wajar banget. Istilah-istilah ini emang dilempar begitu aja seolah semua orang udah lahir tahu artinya. Kabar baiknya, kamu nggak perlu jadi programmer buat ngerti. Kamu cuma perlu tahu maksudnya cukup buat ngobrol lancar. Anggap ini kamus saku kecil biar percakapan kamu sama AI nggak lagi kayak dengerin orang ngomong bahasa alien. Aku jelasin 16 istilah yang paling sering muncul, pakai analogi yang nempel di kepala.

Frontend dan Backend: yang keliatan vs yang ngumpet

Ini dua istilah yang bakal kamu dengar tiap hari, jadi kita mulai dari sini. Bayangin aplikasi kamu itu restoran.

Frontend

Frontend itu ruang makannya. Meja, kursi, menu di tangan pelanggan, warna dinding, semua yang dilihat dan disentuh langsung sama tamu. Di aplikasi, frontend adalah tombol, teks, gambar, form isian, semua yang muncul di layar. Kalau kamu bilang ke AI "warna tombolnya kurang kontras" atau "tulisannya kegedean", kamu lagi ngomongin frontend.

Backend

Backend itu dapurnya. Tamu nggak pernah lihat, tapi di situlah masakan dibikin. Di aplikasi, backend ngurus logika: ngitung total harga, ngecek password bener atau nggak, nyimpen pesanan. Kalau ada yang salah hitung atau data nggak kesimpen, biasanya masalahnya di backend, bukan di tampilan. Bisa aja tampilan udah cakep tapi tombolnya nggak ngapa-ngapain waktu diklik. Itu tanda backend-nya belum nyambung.

API: pelayan yang bolak-balik ke dapur

Nah, kalau frontend ruang makan dan backend dapur, siapa yang nganterin pesanan bolak-balik? Pelayan. Itulah API.

API (singkatan dari Application Programming Interface, tapi lupain kepanjangannya) adalah jembatan yang bikin dua sistem bisa saling ngobrol. Kamu di meja pesan nasi goreng, pelayan bawa pesanan ke dapur, dapur masak, pelayan balik bawa nasi gorengnya. Kamu nggak perlu masuk dapur, nggak perlu tahu resepnya. Cukup pesan lewat pelayan.

API sering dipakai buat nyambung ke layanan orang lain juga. Aplikasi kamu mau nampilin cuaca? Dia "pesan" data cuaca lewat API punya layanan cuaca. Mau terima pembayaran? Manggil API-nya penyedia pembayaran. Jadi kalau AI bilang "kita pakai API Google Maps buat nampilin lokasi", maksudnya aplikasimu numpang minta data peta, bukan bikin peta dari nol. Kalau mau ngerti lebih dalam soal cara mikir kayak gini, cara menjelaskan ide aplikasi ke AI bakal ngebantu banget.

Endpoint: alamat tiap layanan di dapur

Endpoint itu masih nyambung sama API tadi. Kalau API itu pelayannya, endpoint itu satu item spesifik yang bisa kamu pesan, lengkap sama alamatnya.

Gampangnya gini: di restoran ada beberapa loket. Loket "ambil pesanan", loket "bayar", loket "komplain". Tiap loket punya tujuan sendiri dan alamat sendiri. Di aplikasi, endpoint adalah satu alamat spesifik buat satu keperluan. Ada endpoint buat login, endpoint buat ambil daftar produk, endpoint buat simpan pesanan. Bentuknya biasanya kayak alamat web:

GET  /api/produk        -> ambil daftar produk
POST /api/pesanan       -> simpan pesanan baru
POST /api/login         -> cek email & password

Jadi kalau AI bilang "endpoint login-nya error", artinya bagian yang ngurus proses masuk lagi bermasalah. Kamu nggak perlu benerin sendiri, tapi sekarang kamu tahu dia lagi ngomongin bagian yang mana.

Database: lemari arsip raksasa aplikasimu

Semua aplikasi butuh tempat nyimpen data. Daftar pengguna, produk, pesanan, chat, semua harus disimpan di suatu tempat biar nggak hilang pas aplikasi ditutup. Tempat itu namanya database.

Bayangin lemari arsip raksasa yang super rapi. Ada laci khusus "Pelanggan", tiap map isinya nama, email, nomor HP. Ada laci "Pesanan", tiap map isinya siapa yang pesan, beli apa, tanggal berapa. Database itu ya lemari itu, dengan aturan penyimpanan yang ketat biar gampang dicari lagi nanti.

Kenapa ini penting buat kamu? Karena struktur data itu keputusan awal yang gede pengaruhnya. Kalau dari awal kamu bilang "tiap pelanggan bisa punya banyak alamat pengiriman", AI bakal nyiapin lacinya beda dibanding kalau tiap pelanggan cuma boleh satu alamat. Makanya mikirin data ini enaknya dituangin di awal lewat sebuah PRD, dokumen yang ngerangkum maunya aplikasimu apa aja.

Server: komputer yang nggak pernah tidur

Aplikasi kamu harus "nyala" 24 jam biar orang bisa akses kapan aja. Kamu nggak mungkin ninggalin laptop nyala terus di kamar buat itu. Di situlah server masuk.

Server itu pada dasarnya komputer juga, tapi kerjaannya cuma satu: nyala terus dan ngelayani permintaan dari mana-mana. Dia yang nyimpen database, jalanin backend, dan jawab tiap pelayan (API) yang datang minta data. Bayangin dia kayak pegawai kantor yang shift-nya nggak pernah habis. Ada yang buka aplikasimu jam 3 pagi? Server yang layani. Nggak pakai ngeluh, nggak pakai ngantuk.

Hosting dan Deploy: mindahin masakan dari dapur latihan ke restoran beneran

Dua istilah ini paling sering bikin pemula bingung, padahal maksudnya sederhana.

Hosting

Hosting itu nyewa tempat buat server-mu. Kamu nggak beli komputer server sendiri (mahal dan ribet), kamu nyewa ke penyedia kayak Vercel, Netlify, atau Railway. Ibarat kamu nggak bangun gedung restoran sendiri, kamu nyewa ruko yang udah jadi. Bayar bulanan, tempat udah siap pakai.

Deploy

Deploy itu proses naikin aplikasimu ke tempat sewaan tadi biar bisa diakses publik. Sebelum deploy, aplikasimu cuma jalan di laptop kamu, cuma kamu yang bisa lihat. Setelah deploy, dia "pindah" ke server yang online, dan siapa pun yang punya link-nya bisa buka. Ibarat kamu udah latihan masak di dapur rumah, terus deploy itu momen kamu pindahin menu itu ke restoran beneran yang bukanya buat umum.

Jadi kalau AI bilang "udah selesai, tinggal deploy", artinya aplikasimu udah jadi dan siap dionlinein. Momen paling seru sekaligus paling deg-degan.

Repo, Git, dan Commit: buku sejarah proyekmu

Tiga istilah ini satu keluarga. Semuanya soal nyimpen dan ngelacak perubahan kode.

• Repo (repository): folder besar tempat semua kode aplikasimu disimpan, lengkap sama riwayatnya. Anggap ini map proyek induk. Kalau kamu simpan di GitHub, repo kamu bisa diakses dari mana aja dan aman kalau laptop rusak.
• Git: sistem yang ngerekam tiap perubahan. Ibarat tombol "save" yang super pinter, dia inget setiap versi. Salah edit? Bisa balik ke versi kemarin. Git itu kayak mesin waktu buat kodemu.
• Commit: satu titik simpanan di Git, kayak checkpoint di game. Tiap kali selesai satu perubahan, kamu (atau AI) bikin commit dengan catatan singkat, misal "nambah tombol logout". Jadi kalau nanti ada yang rusak, gampang dilacak commit mana biang keroknya.

Kenapa ini berguna buat kamu yang non-teknis? Karena commit yang rapi bikin kamu bisa bilang "tolong balikin ke versi sebelum tombol itu ditambah" dan AI bisa nurutin. Tanpa Git, sekali salah ya susah balik. Ini juga alasan kenapa ngerjain bareng AI kayak Cursor terasa aman: tiap langkah kerekam.

Framework dan Library: perkakas siap pakai biar nggak bikin dari nol

Programmer jarang bikin semuanya dari nol. Mereka pakai alat bantu yang udah dibikin orang lain. Dua jenisnya: framework dan library.

Library

Library itu kayak satu alat spesifik di kotak perkakas. Butuh nampilin kalender di aplikasi? Ada library-nya, tinggal pakai, nggak usah bikin logika kalender dari awal. Butuh grafik? Ada library-nya. Ibarat kamu masak dan butuh santan, kamu beli santan instan, nggak perlu meres kelapa sendiri.

Framework

Framework itu lebih gede, kayak seperangkat dapur lengkap yang udah tertata. Dia ngasih kamu struktur dan aturan main, jadi kamu tinggal ngisi bagian yang penting. React, Next.js, Laravel itu contoh framework. Bedanya sama library: library kamu yang panggil pas butuh, framework yang ngatur alur kerja kamu secara keseluruhan. Kamu masuk ke dapurnya dia, ngikutin tata letaknya.

Buat kamu, intinya cukup: kalau AI nyebut nama-nama ini, dia lagi milih fondasi buat aplikasimu. Kamu boleh nanya "kenapa pilih itu?" dan biasanya jawabannya soal kecocokan sama kebutuhanmu.

Dependency: bahan-bahan yang aplikasimu butuhin

Tiap library atau framework yang aplikasimu pakai, itu namanya dependency. Harfiahnya "ketergantungan". Aplikasimu bergantung sama bahan-bahan itu buat jalan.

Analogi masaknya pas banget: kalau resep nasi goreng kamu butuh kecap, telur, dan bawang, itu semua dependency-nya. Nggak ada kecap, nasi goreng nggak jadi. Di aplikasi, daftar dependency ini dicatat rapi di satu file, jadi siapa pun (termasuk server pas deploy) tahu harus "belanja" apa aja biar aplikasi bisa jalan. Kadang error muncul cuma gara-gara satu dependency belum "kebeli" alias belum ke-install. Sekarang kamu tahu kalau AI nyebut "missing dependency", dia lagi bilang ada bahan yang kurang.

Environment: dapur latihan vs dapur restoran

Environment (lingkungan) itu istilah buat "tempat aplikasimu jalan". Yang paling sering kamu dengar ada dua: development dan production.

• Development (dev): tempat coba-coba. Ini dapur latihan tempat kamu dan AI ngoprek, bikin fitur, ngetes, salah, benerin. Kalau meledak nggak masalah, nggak ada pelanggan yang lihat.
• Production (prod): versi asli yang dipakai pengguna beneran. Ini restoran yang lagi buka. Salah dikit di sini kelihatan semua orang, jadi biasanya lebih hati-hati.

Kenapa dipisah? Biar kamu bisa eksperimen liar di dev tanpa takut ngerusak pengalaman pengguna di prod. Kalau AI bilang "ini masih di environment development, aman buat dicoba", artinya kamu boleh gaspol nyoba. Kalau dia bilang "hati-hati, ini di production", itu tandanya kamu lagi di zona yang dilihat pengguna asli.

Bug: kesalahan yang bikin aplikasi ngambek

Ini istilah paling terkenal, dan kamu bakal sering ketemu. Bug itu kesalahan atau cacat di aplikasi yang bikin dia nggak jalan sesuai harapan. Tombol yang harusnya nyimpen data malah nggak ngapa-ngapain? Itu bug. Harga total yang kehitung salah? Bug juga.

Namanya "bug" (kutu) konon karena dulu ada ngengat nyangkut di komputer jadul yang bikin error. Bagian pentingnya: bug itu hal normal, bukan tanda kamu gagal. Bahkan programmer paling jago pun bikin bug tiap hari. Yang penting cara ngelaporinnya. Makin spesifik kamu jelasin bug ke AI, makin cepet dia benerin. "Waktu aku klik tombol simpan di halaman checkout, nggak ada yang terjadi dan nggak muncul pesan apa-apa" jauh lebih berguna daripada "error nih". Cara nulis instruksi yang jelas kayak gini aku bahas di prompt untuk AI coding.

Kenapa repot-repot ngapalin ini?

Kamu nggak perlu ngapalin. Kamu cukup kenal, kayak kenal sama tetangga yang sering lewat. Bedanya orang yang lancar ngobrol sama AI dan yang selalu bingung bukan di skill teknis, tapi di kosakata. Waktu kamu bisa bilang "backend-nya udah oke tapi frontend-nya belum nyambung ke endpoint yang bener", AI langsung nangkep dan kerjanya presisi. Bandingin sama "kok gini sih, betulin dong", yang bikin AI harus nebak-nebak.

Ini persis semangat di balik vibe coding untuk pemula: kamu nggak nulis kode, tapi kamu ngarahin. Dan ngarahin yang bagus butuh bahasa yang sama. Anggap kamus ini sebagai kamus perjalananmu, bukan hafalan buat ujian. Balik lagi ke sini kapan aja ada istilah yang bikin dahi berkerut.

Cara paling ampuh biar istilah-istilah ini nempel bukan dihafalin, tapi dipakai. Begitu kamu mulai bikin aplikasi pakai AI tanpa coding, istilah tadi bakal muncul satu per satu di konteks nyata, dan di situ dia baru bener-bener masuk ke kepala.

Modal awal biar percakapan sama AI kamu makin nyambung bukan cuma kosakata, tapi juga kejelasan soal maunya aplikasimu apa. Di situlah PRD berperan: dia ngerangkum ide kamu jadi dokumen yang gampang dicerna AI, lengkap sama data, alur, dan fitur. Nggak perlu ngerti coding buat bikinnya. Kalau mau nyoba, cara membuat PRD untuk aplikasi bisa jadi langkah pertamamu.

Istilah asing cuma tembok kecil di awal. Sekali kamu tahu di baliknya cuma analogi sederhana, dia berhenti nakut-nakutin. Sekarang giliran kamu yang megang kemudi obrolannya.