Modul 1 · Bab 1: Membangun dengan AI
Apa itu membangun dengan AI
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.
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?
Menjelaskan arti sebuah pesan error
Mengusulkan nama kolom untuk tabel peminjaman
Memutuskan apakah satu barang boleh dipinjam dua orang sekaligus
Memutuskan kapan versi baru dirilis ke tim
Menulis draf kode formulir peminjaman
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.
Prototipe sering menyimpan data di memori. Aplikasi siap pakai menyimpannya di database dan punya cadangan.
Aplikasi siap pakai memeriksa di server siapa yang masuk dan apa yang boleh ia lihat atau ubah.
Aplikasi siap pakai menolak data yang tidak masuk akal, dan ada tes yang membuktikannya.
Aplikasi siap pakai menyimpan versi lama supaya bisa kembali dengan satu perintah bila versi baru rusak.
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.
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
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.
