Apa yang sebenarnya ada di dalam aplikasi buatan AI: sebuah tur untuk non-developer

Kamu mengetik sebuah deskripsi, menekan go, dan dua puluh menit kemudian kamu punya aplikasi yang berfungsi. Bagus. Tapi sekarang kamu mengklik “view files” dan kamu menatap pohon folder yang tampak seperti ditulis dalam bahasa yang berbeda. Apa itu package.json? Kenapa ada empat puluh hal di node_modules? Apa arti “schema” dan kenapa kamu punya satu?

Postingan ini adalah tur berpemandu. Bukan tutorial — sebuah tur. Setelah membacanya kamu tidak akan tahu cara menulis sendiri file-file ini, tapi lain kali ada yang terlihat aneh, kamu akan tahu sudut mana dari aplikasi yang harus ditunjuk.

Saya akan memakai tiga contoh berjalan sepanjang tulisan ini, supaya bagian-bagian yang abstrak punya sesuatu yang konkret untuk disandingkan:

• Maya, seorang marketing lead, yang membangun papan peringkat referral untuk timnya.
• Jordan, seorang guru yoga, yang membangun situs booking kelas.
• Sam, yang menjalankan bakery, yang membangun halaman “pre-order croissant besok”.

Ketiganya memakai AI app builder. Ketiga aplikasinya tampak sepenuhnya berbeda di mata pelanggan. Di balik layar, bentuknya ternyata sangat mirip.

Frontend: apa yang sebenarnya dilihat pelangganmu

Frontend adalah segala sesuatu yang termuat di browser seseorang. Tombol, tata letak, font, animasi, cara sebuah formulir membersihkan dirinya setelah kamu mengirimnya. Kalau kamu bisa melihatnya, itu frontend.

Bagi Maya, frontend-nya adalah papan peringkat dengan rank, nama, dan jumlah referral. Bagi Jordan, ia adalah kalender kelas dengan tombol “book”. Bagi Sam, ia adalah daftar kue dengan tombol plus-dan-minus kecil di sebelah masing-masing.

Di dalam proyek, frontend biasanya berada di folder yang bernama semacam app/, pages/, atau src/. Kamu akan melihat file yang berakhiran .tsx atau .jsx. Masing-masing kira-kira adalah “satu layar” atau “satu bagian dari sebuah layar.” Baris papan peringkat adalah satu file. Header-nya adalah file lain. Halaman yang menyatukan semuanya adalah file ketiga.

Saat kamu meminta AI builder untuk “buat tombolnya lebih bundar” atau “pindahkan papan peringkat ke kanan”, inilah bagian yang berubah.

Backend: bagian yang berpikir

Backend adalah bagian yang tak seorang pun melihatnya, tapi semua orang bergantung padanya. Ia adalah kode yang berjalan di tempat lain — di sebuah server, bukan di browser pelanggan — ketika sesuatu perlu terjadi yang tak seharusnya dipercayakan pada browser pelanggan untuk dilakukan sendirian.

Kenapa browser tidak bisa melakukan semuanya? Karena browser adalah mesin si pelanggan, dan kamu tidak bisa memercayainya. Kalau papan peringkat Maya memperbarui jumlah referral murni di browser, siapa pun bisa klik-kanan dan menambahkan 9.000 referral untuk dirinya sendiri. Jadi backend adalah tempat aturan-aturan berada: “orang ini boleh melakukan ini, tapi tidak itu”, “simpan ini ke database sungguhan”, “kirim email ini”.

Backend biasanya berada di folder yang bernama api/, server/, atau app/api/. File di sana biasanya pendek. Masing-masing menangani satu permintaan spesifik: “buat sebuah booking”, “daftar croissant hari ini”, “tambahkan sebuah referral”.

Ketika sesuatu berfungsi di aplikasimu tapi hasilnya tidak menempel — kamu klik submit, kamu lihat konfirmasi, tapi besok datanya hilang — backend hampir selalu jadi tempat bug-nya.

Database: memori aplikasimu

Bayangkan memori aplikasimu sebagai sederet lemari arsip. Setiap lemari punya label di depannya. Satu bertuliskan “users.” Satu bertuliskan “bookings.” Satu bertuliskan “croissant_orders.” Di dalam setiap lemari, setiap laci adalah satu baris. Setiap laci punya kumpulan slot yang sama: sebuah nama, sebuah email, sebuah created_at, sebuah status.

Struktur itu — “lemari apa yang ada, slot apa yang dimiliki setiap baris” — disebut schema. Ia adalah file terpenting dalam proyek, sekalipun ia juga mungkin yang paling membosankan tampilannya. Temukan file bernama schema.ts, schema.prisma, atau sesuatu di dalam folder bernama db/ atau migrations/. Buka. Kamu akan melihat daftar yang mencerminkan apa yang sebenarnya diingat aplikasimu tentang dunia.

Schema Jordan punya tabel classes, tabel bookings, dan tabel users. Milik Sam punya products, orders, dan order_items. Milik Maya punya members dan referrals. Bentuk schema adalah bentuk produk, itulah kenapa mengubahnya kemudian lebih sulit daripada mengubah tampilan tombol.

Sebuah trik berguna: kalau kamu bisa menjelaskan apa yang diingat aplikasimu, dalam kata-kata sederhana, kamu biasanya bisa menjelaskan schema-nya. “Aku mengingat nama dan email setiap pelanggan. Untuk setiap pelanggan, aku mengingat pesanan yang mereka buat. Untuk setiap pesanan, aku mengingat kue yang mana dan berapa banyak masing-masing.” Kalimat itu, hampir kata demi kata, adalah schema-nya.

Auth: penjaga pintu

“Auth” adalah dua kata yang digabung: authentication (siapa kamu?) dan authorization (apa yang boleh kamu lakukan?). Keduanya biasanya ditangani oleh sekumpulan kecil file di folder bernama auth/, atau oleh sebuah layanan yang namanya mungkin kamu kenali: Clerk, Auth0, Supabase Auth, NextAuth.

Kedua pertanyaan itu berbeda. Authentication menjawab: “apakah ini benar-benar Maya?” — biasanya dengan password, login Google, atau magic link yang dikirim ke emailnya. Authorization menjawab: “apakah Maya boleh menghapus referral milik orang lain?” — dan jawaban jujurnya untuk sebagian besar aplikasi buatan AI di minggu pertamanya adalah “kita lupa memeriksanya.”

Inilah bagian yang paling sering diam-diam rusak. Layar login berfungsi, jadi terasa aman. Tapi backend tidak selalu memeriksa bahwa orang yang sudah login adalah orang yang sama dengan pemilik data yang coba mereka baca. Kalau aplikasimu punya konsep apa pun soal “dataku vs datamu”, tanyakan ke AI builder secara eksplisit: “Pastikan pengguna hanya bisa melihat dan mengedit data mereka sendiri.” Kamu akan terkejut betapa sering satu kalimat itu mengungkap pemeriksaan yang hilang.

Integrasi: hal-hal yang tidak kamu bangun tapi tetap kamu pakai

Di sinilah sebagian besar non-developer meremehkan apa yang sebenarnya terjadi. Hal yang mengirim email “croissant-mu sudah siap” milik Sam bukanlah kode — ia adalah sebuah akun di SendGrid atau Resend. Hal yang memproses pembayaran kelas Jordan bukanlah kode — ia adalah Stripe. Hal yang meng-host foto-foto di papan peringkat Maya bukanlah kode — ia adalah layanan penyimpanan seperti S3 atau Cloudinary.

Setiap integrasi muncul di dua tempat. Ada potongan kecil kode di backend yang berkata “hei, Stripe, tagih kartu ini.” Dan ada sebuah kunci — string rahasia yang panjang — yang disimpan di suatu tempat yang aman (biasanya file bernama .env yang tak seorang pun boleh meng-commit-nya) yang membuktikan ke Stripe bahwa permintaannya datang dari bakery Sam dan bukan orang asing.

Kalau kamu pernah bertanya-tanya kenapa aplikasimu tiba-tiba berhenti mengirim email atau berhenti menerima pembayaran, penyebabnya hampir selalu salah satu dari: kunci yang kedaluwarsa, batas pemakaian yang tercapai, atau perubahan dalam kebijakan integrasinya. Kodenya tidak rusak. Jabat tangannya yang rusak.

Deploy: bagaimana ia sampai ke internet

Bagian terakhir adalah bagian yang mengubah folder di disk-mu menjadi sesuatu yang bisa dikunjungi pelangganmu di sebuah URL. Ini biasanya berarti tiga hal kecil yang bekerja bersama:

• Host: sebuah layanan seperti Vercel, Netlify, Fly, atau Render yang menjalankan backend-mu dan menyajikan frontend-mu.
• Domain: sebuah nama seperti mayas-leaderboard.com yang menunjuk ke host-mu.
• Build: resep yang mengambil file sumbermu yang berantakan dan mengubahnya menjadi versi yang lebih ramping dan cepat yang benar-benar berjalan.

Ketika sesuatu berfungsi secara lokal tapi rusak di produksi, masalahnya biasanya di sini. Sebuah kunci yang diatur di laptopmu tapi tidak di host. Sebuah pustaka yang terpasang di development tapi tidak di produksi. Sebuah database yang ada di browser-mu tapi tidak di situs live.

Kebiasaan lima menit yang membayar dirinya sendiri

Kamu tidak perlu membaca setiap file di proyekmu. Kamu tidak perlu tahu apa yang dilakukan sebagian besarnya. Tapi sebaiknya, sekali seminggu, lakukan jalan-jalan lima menit di mana kamu membuka masing-masing folder di atas dan bertanya ke AI builder, dalam kata-kata sederhana, apa yang berubah.

Maya melakukan ini setiap Jumat sore. Ia mengetik: “Apa yang berubah di schema minggu ini, dan kenapa?” Dan: “Apakah ada integrasi baru di aplikasi ini yang tidak kuminta?” Jawabannya hampir selalu menenangkan. Beberapa kali ketika tidak, ia menangkap masalah selagi mereka masih kecil.

Itulah keseluruhan tujuan memahami bagian-bagiannya. Bukan untuk menjadi developer. Cuma supaya bisa mengajukan pertanyaan yang lebih baik.

Ke mana selanjutnya

Kalau tur ini membantu, dua lanjutan layak waktumu. Bug ‘kelihatan baik-baik saja’ membahas apa yang harus dilakukan ketika salah satu bagian ini diam-diam rusak, dan siap-demo vs siap-produksi membahas cara mengetahui kapan aplikasimu sudah berpindah dari tahap pertama ke tahap kedua. Peta yang sama, kegunaan yang berbeda untuknya.