InfraLoka AcademyPathwayAI
PathwayAI

Modul 1 · Bab 1: Membangun dengan AI

Apa itu membangun dengan AI

4 menit baca7 menit bacaDitinjau 26 Oktober 2026

Intinya

AI menulis sebagian besar kode; kamu memutuskan, membaca, menguji, dan merilis. Prototipe dan aplikasi siap pakai bisa tampak sama, bedanya di hal yang tak terlihat. Mulai dari alat kecil untuk timmu sendiri.

Setelah pelajaran ini kamu bisa

  • Menjelaskan apa yang dikerjakan AI dan apa yang tetap dikerjakan pembangun saat membuat aplikasi
  • Membedakan prototipe cepat dari aplikasi yang siap dipakai orang lain
  • Menentukan aplikasi kecil pertama yang layak dibangun

Istilah di pelajaran ini

Pahami

Membangun aplikasi bersama AI tidak sama dengan menyuruh agen AI (AI agent) membuat aplikasi lalu menunggu jadi. AI, terutama agen coding (coding agent: agen AI yang menulis dan menjalankan kode), memang mengerjakan sebagian besar ketikan. Agen semacam ini membaca berkas proyekmu, menjalankan perintah sendiri, lalu menulis formulir, rute server, tabel basis data (database), dan tes dalam hitungan menit. Pekerjaan yang dulu butuh satu tim kecil kini bisa dimulai oleh satu orang.

Tetapi menulis cepat bukan bagian yang sulit dari membangun aplikasi. Bagian yang sulit adalah memutuskan apa yang dibangun, memastikan yang dibangun benar, dan menjaga aplikasi tetap hidup setelah orang lain memakainya. Bagian itu tetap kerjamu. Di buku ini kamu disebut pembangun: orang yang memutuskan, membaca, menguji, dan merilis. AI adalah rekan yang menulis cepat, tidak pernah lelah, dan kadang yakin pada hal yang salah, persis seperti yang kamu pelajari di Fondasi AI.

Seluruh buku mengikuti satu alur empat tahap: Rencana, Bangun, Periksa, dan Rilis (release). Di tahap Rencana kamu menulis spesifikasi (spec): apa yang dibangun dan bagaimana tahu itu benar. Di tahap Bangun AI menulis kode, satu perubahan kecil pada satu waktu. Di tahap Periksa kamu membaca perubahan itu dan menjalankan tes, bukan sekadar membaca laporan AI. Di tahap Rilis kamu memindahkan aplikasi ke server dengan cara yang bisa dibatalkan. AI membantu di keempat tahap, tetapi keputusan di setiap tahap ada padamu.

Ada dua hal yang sering tertukar: prototipe dan aplikasi yang siap dipakai orang lain. Prototipe adalah versi cepat untuk melihat apakah ide masuk akal. Datanya boleh palsu, hanya kamu yang memakainya, dan kalau rusak tidak ada yang dirugikan. Cara membuatnya ada di pelajaran membuat prototipe, dan AI bisa menyelesaikannya dalam satu sore.

Aplikasi yang siap dipakai harus tahan terhadap hal yang tidak terjadi di prototipe: data asli yang harus tetap ada besok, orang yang hanya boleh melihat datanya sendiri, isian kosong atau aneh, dua orang menyimpan pada detik yang sama, kunci rahasia yang tidak boleh bocor, dan versi baru yang harus bisa dibatalkan kalau rusak. Jarak antara keduanya bukan soal tampilan. Prototipe dan aplikasi siap pakai bisa terlihat sama persis di layar. Bedanya ada di hal yang tidak terlihat, dan hal-hal itulah isi sebagian besar buku ini.

Aplikasi pertamamu sebaiknya kecil, nyata, dan murah kalau gagal. Pilih masalah yang hari ini kamu atau timmu kerjakan dengan lembar kerja, pesan grup, atau catatan kertas, untuk sekelompok kecil orang yang kamu kenal dan bisa kamu tanyai. Hindari data sensitif seperti data kesehatan, data keuangan pribadi, atau nomor identitas sampai kamu sudah menyelesaikan bab keamanan. Hindari juga pembayaran dan pendaftaran terbuka untuk umum. Ukuran yang baik: versi pertamanya bisa selesai dalam beberapa hari, dengan satu jenis pengguna dan satu alur utama. Contoh yang akan sering muncul di buku ini adalah alat peminjaman barang tim: siapa meminjam apa, kapan, dan kapan dikembalikan.

Supaya jujur sejak awal, ini yang dijanjikan dan yang tidak dijanjikan buku ini. Setelah menyelesaikannya, kamu bisa membangun aplikasi web kecil bersama AI, membaca perubahan yang ditulisnya cukup baik untuk menangkap kesalahan umum, menulis tes, menyimpan riwayat pekerjaan dengan kontrol versi, dan merilis aplikasi ke server dengan cara yang bisa dibatalkan. Kamu juga akan tahu kapan sebuah pekerjaan sudah di luar kemampuanmu dan perlu insinyur berpengalaman.

Buku ini tidak menjanjikan bahwa kamu akan menjadi insinyur senior, atau bahwa AI akan membuat aplikasi besar tanpa masalah. Agen coding bisa menulis ratusan baris yang tampak rapi dan tetap salah di satu tempat yang penting. Ia bisa melaporkan tes lulus padahal tes itu tidak pernah dijalankan. Ia bisa mengubah berkas yang tidak kamu minta. Hal-hal ini terjadi juga pada kami, dan kasus di akhir setiap bab menceritakan sebagian di antaranya, termasuk bagaimana kami mengetahuinya dan aturan yang kami pegang sekarang.

Urutan bukunya: empat bab dasar (bab ini, peta aplikasi web, menyiapkan komputer kerja, dan dari ide ke spesifikasi), lalu keterampilan inti seperti membaca kode dan meminta perubahan kecil, lalu alat dalam praktik seperti terminal (command line), git, dan rilis, lalu cara kerja yang lebih matang dengan tes lebih dulu dan reviewer (peninjau) terpisah. Ada empat proyek di sepanjang jalan, dan setiap proyek membangun di atas yang sebelumnya.

Contoh

Sebelum

Permintaan

Buatkan saya aplikasi peminjaman barang yang lengkap untuk kantor.

Hasilnya

Agen membuat puluhan berkas: halaman masuk dengan tiga peran, pengingat lewat email, kode QR untuk setiap barang, laporan bulanan, dan dasbor grafik. Di akhir ia menulis: "Aplikasi sudah selesai dan semua fitur berjalan dengan baik." Tidak ada tes yang dijalankan, dan pengiriman email memakai alamat dan kunci contoh yang tidak pernah ada.

Sesudah

Permintaan

Tujuan: saya ingin versi pertama alat peminjaman barang tim, yang menggantikan lembar kerja kami. Pembaca: lima orang di tim saya; satu orang, saya, yang mengelola barang. Bahan: kolom lembar kerja kami sekarang adalah nama barang, peminjam, tanggal pinjam, tanggal kembali. Batas: belum ada email, peran, atau laporan. Jangan menulis kode dulu. Bentuk: rencana singkat berisi halaman, data yang disimpan, dan urutan tugas, ditambah pertanyaan yang perlu saya jawab. Cek: setiap tugas punya cara memeriksa bahwa ia selesai.

Hasilnya

Agen menulis rencana satu halaman: dua halaman (daftar barang dan formulir peminjaman), satu tabel peminjaman dengan empat kolom, dan lima tugas berurutan, masing-masing dengan cara memeriksanya. Di bawahnya ada tiga pertanyaan: apakah satu barang boleh dipinjam dua orang sekaligus, apakah tanggal kembali wajib diisi saat meminjam, dan siapa yang boleh menghapus catatan.

Yang berubah

  • Permintaan yang lebih baik memakai enam bagian permintaan dari Fondasi: tujuan, pembaca, bahan, batas, bentuk, cek.
  • Batas "jangan menulis kode dulu" membuat keputusan terjadi di rencana, bukan di ratusan baris kode.
  • Pertanyaan dari agen adalah keputusan yang memang milikmu; jawab sendiri, jangan biarkan agen menebak.

Kesalahan umum

Kesalahan
Menerima laporan "sudah selesai, semua tes lulus" dari AI tanpa melihat sendiri keluaran tesnya.
Kenapa merugikan
Model menulis laporan berdasarkan apa yang seharusnya terjadi. Laporan yang meyakinkan bisa menutupi tes yang tidak pernah dijalankan atau fitur yang hanya berjalan di contoh paling mudah, dan kamu baru tahu saat pengguna mengeluh.
Lakukan ini
Minta perintah yang dijalankan beserta keluarannya, jalankan ulang sendiri bila perlu, lalu coba fitur itu seperti pemakai biasa sebelum menyebutnya selesai.

Kesalahan umum

Kesalahan
Memilih aplikasi pertama yang besar dan penting, misalnya sistem gaji atau aplikasi yang dibuka untuk umum.
Kenapa merugikan
Kesalahan pemula di aplikasi seperti itu langsung mengenai uang, data pribadi, atau orang asing. Kamu juga belum punya kebiasaan tes, kontrol versi, dan rollback untuk memulihkannya, sehingga satu kesalahan bisa membuatmu atau timmu berhenti percaya pada pendekatan ini.
Lakukan ini
Mulai dari alat kecil untuk tim sendiri yang datanya tidak sensitif. Naikkan taruhannya setelah kamu menyelesaikan proyek pertama dan bab keamanan.

Coba

Kartu pilah

Saat membangun alat peminjaman barang, pekerjaan mana yang bisa diserahkan ke AI dan mana yang tetap kerjamu?

  1. Menjelaskan arti sebuah pesan error

  2. Mengusulkan nama kolom untuk tabel peminjaman

  3. Memutuskan apakah satu barang boleh dipinjam dua orang sekaligus

  4. Memutuskan kapan versi baru dirilis ke tim

  5. Menulis draf kode formulir peminjaman

  6. Membaca keluaran tes dan memutuskan apakah perubahan boleh diterima

6 kartu lagi

Kamu baru mulai dan ingin membangun aplikasi pertama dalam satu minggu. Mana yang paling layak?

Prototipe yang terlihat selesai sering menyimpan masalah ini. Tebak dulu apa artinya untuk aplikasi siap pakai, lalu buka kartunya.

Bawa pulang

Sebelum memilih aplikasi pertamamu

  • Masalahnya nyata dan hari ini dikerjakan dengan lembar kerja, pesan, atau kertas
  • Penggunanya sedikit dan bisa kamu tanyai langsung
  • Datanya tidak sensitif: tanpa data kesehatan, keuangan pribadi, atau nomor identitas
  • Tidak ada pembayaran dan tidak ada pendaftaran terbuka untuk umum
  • Versi pertama punya satu jenis pengguna dan satu alur utama
  • Kalau aplikasinya rusak, tim bisa kembali ke cara lama untuk sementara

Minta AI membantu menyaring ide aplikasi pertama

Bisa dipakai di asisten AI mana pun.

Isi bagianmu
Contoh: alat peminjaman barang tim; jadwal piket ruang rapat; daftar tamu kantor

Prompt-mu

Tujuan: saya ingin memilih satu aplikasi kecil pertama untuk dibangun bersama AI dalam beberapa hari.
Pembaca: saya sendiri; saya belum pernah bekerja sebagai programmer.
Bahan: ide-ide saya di bawah, masing-masing dengan siapa penggunanya dan bagaimana pekerjaan itu dilakukan sekarang.
‹daftar-ide›
Batas: jangan memilihkan untuk saya. Jangan menambah fitur pada ide saya. Tandai ide yang memakai data sensitif, pembayaran, atau pengguna umum.
Bentuk: tabel dengan kolom ide, jumlah pengguna, data sensitif ya atau tidak, perkiraan ukuran versi pertama (kecil, sedang, besar), dan risiko bila rusak.
Cek: sebutkan untuk setiap ide satu hal yang perlu saya pastikan sendiri sebelum memilih.

Yang salah di tempat kami

Insiden, Oktober 2026

Klaim "selesai" yang hanya diasumsikan

Konteks
Kami membangun fitur besar dengan beberapa agen AI. Setiap agen pelaksana menyerahkan hasilnya ke agen peninjau yang terpisah dan tidak melihat percakapan pelaksana.
Yang terjadi
Satu pelaksana melapor tugasnya selesai dan semua tes lulus. Peninjau menjalankan pemeriksaannya sendiri dan menemukan bahwa sebagian yang dilaporkan lulus ternyata hanya diasumsikan, tidak pernah dijalankan.
Dampaknya
Tidak ada yang sampai ke pengguna. Tugas itu dikembalikan ke pelaksana dan memakan satu putaran tambahan.
Akar masalah
Model menulis laporan yang meyakinkan berdasarkan apa yang seharusnya terjadi, bukan apa yang ia jalankan.
Yang kami lakukan
Pelaksana menjalankan pemeriksaan yang terlewat, memperbaiki yang gagal, dan peninjau memeriksa ulang.
Pengaman yang kami pasang
Setiap tugas agen ditinjau oleh agen lain yang menjalankan pemeriksaannya sendiri. Klaim tanpa bukti keluaran perintah tidak diterima.

PelajarannyaLaporan AI bukan bukti; keluaran perintah yang dijalankan itulah buktinya.

Artinya untuk kerjamuKalau AI atau rekan bilang sebuah pekerjaan sudah beres, mintalah hasil yang bisa kamu lihat sendiri, lalu periksa sebagian, sebelum kamu ikut menyatakan selesai.