 |
| Gunakan AI untuk membantu berpikir, menguji pilihan, dan menyusun pekerjaan secara lebih terarah. |
AI dapat membuat tampilan dan kode aplikasi dalam waktu singkat. Namun, hasil yang terlihat meyakinkan belum tentu sesuai dengan masalah, proses, data, keamanan, atau kondisi sistem yang sebenarnya. Course ini membantu orang awam menggunakan AI sebagai mitra berpikir dan mitra kerja—bukan sebagai mesin kebenaran.
Membuat Aplikasi dengan AI secara Benar
Membuat aplikasi dengan AI bukan sekadar mengetik “buatkan aplikasi ini” lalu menerima seluruh hasilnya. Proses yang benar dimulai dari memahami masalah pengguna, menyusun aturan bisnis, menentukan data dan hak akses, membandingkan pilihan, membangun fitur sedikit demi sedikit, serta membuktikan hasil melalui pengujian.
Tujuan course ini bukan menjanjikan AI tidak pernah salah. Tujuannya adalah mencegah kesalahan, dugaan, atau halusinasi AI diterima sebagai kebenaran dan masuk ke aplikasi tanpa pemeriksaan.
Course Overview
AI dapat membuat halaman aplikasi dalam hitungan menit. Hal itu memang mengesankan, tetapi tampilan yang menarik belum membuktikan aplikasinya benar. Aplikasi baru dapat disebut benar apabila menyelesaikan masalah nyata, mengikuti aturan bisnis, mengolah data dengan tepat, membatasi akses pengguna, menangani kegagalan, aman digunakan, dan telah lulus pengujian.
Kesalahan terbesar biasanya terjadi sebelum kode ditulis. Pengguna belum menjelaskan siapa yang memakai aplikasi, masalah apa yang perlu diselesaikan, bagaimana proses saat ini berjalan, data apa yang boleh digunakan, siapa yang berhak melakukan suatu tindakan, serta seperti apa hasil yang dianggap berhasil. AI kemudian mengisi ruang kosong tersebut dengan dugaan yang mungkin terlihat rapi, tetapi belum tentu benar.
Apa yang dimaksud halusinasi AI?
Halusinasi AI adalah keadaan ketika AI menghasilkan informasi yang salah, tidak tersedia, atau tidak didukung bukti, tetapi menyampaikannya seolah-olah benar. Dalam pembuatan aplikasi, AI dapat menciptakan nama tabel, field, API, aturan bisnis, fungsi, paket, hasil test, estimasi, atau klaim keamanan yang tidak sesuai dengan sistem sebenarnya.
AI dapat menebak aturan
Jika proses bisnis tidak diberikan, AI dapat mengisi kekosongan dengan pola umum yang belum tentu berlaku pada organisasi Anda.
AI dapat mengarang komponen
Nama API, tabel, field, fungsi, atau paket dapat terdengar benar meskipun tidak tersedia pada kode dan versi yang digunakan.
AI dapat membuat klaim palsu
AI dapat mengatakan masalah sudah diperbaiki atau test sudah lulus padahal pengujian belum benar-benar dijalankan.
AI dapat melewatkan dampak
Perubahan pada satu file mungkin merusak modul, data, integrasi, atau perilaku lama yang tidak masuk ke dalam konteks AI.
Lima fondasi aplikasi yang benar
Tabel dapat digeser ke kanan atau kiri pada perangkat seluler.
| Fondasi | Pertanyaan utama | Artefak minimum | Bukti |
|---|---|---|---|
| Masalah dan pengguna | Siapa mengalami masalah, apa dampaknya, dan perubahan apa yang diinginkan? | Problem statement, stakeholder map, indikator keberhasilan. | Wawancara, observasi, data layanan, atau keluhan nyata. |
| Proses dan aturan | Bagaimana alur normal, keputusan, persetujuan, dan pengecualian bekerja? | Process map dan business rule register. | Dokumen proses dan konfirmasi pemilik proses. |
| Data dan akses | Data apa yang dipakai, dari mana asalnya, dan siapa yang berhak mengakses? | Data dictionary dan access matrix. | Skema aktual, sampel aman, kebijakan, dan pemilik data. |
| Desain dan keamanan | Komponen apa yang dibutuhkan dan bagaimana risiko dibatasi? | Desain solusi, integration map, risk register. | Review teknis, keamanan, dan dokumentasi versi yang digunakan. |
| Test dan operasi | Bagaimana membuktikan fitur benar serta memulihkan layanan saat gagal? | Test plan, release plan, monitoring, backup, rollback, runbook. | Hasil test aktual, log, UAT, restore drill, dan persetujuan rilis. |
Protokol B.U.K.T.I.
B.U.K.T.I. adalah cara sederhana untuk mengurangi dan menangkap kesalahan AI sebelum berdampak kepada pengguna.
Beri sumber kebenaran
Lampirkan proses, aturan, skema data, dokumentasi API, versi teknologi, kode terkait, dan log. Nyatakan sumber yang paling berwenang jika isinya berbeda.
Urai ketidakpastian
Pisahkan Ⓕ fakta, Ⓐ asumsi, Ⓓ keputusan, dan Ⓤ belum diketahui. Jangan membiarkan dugaan tampil sebagai fakta.
Kerjakan bagian kecil
Bangun satu alur kecil dari tampilan sampai data, uji, lalu lanjutkan. Jangan meminta seluruh aplikasi sekaligus.
Tes hasilnya
Setiap fitur memiliki kondisi awal, tindakan, hasil yang diharapkan, dan bukti hasil aktual. “Seharusnya bisa” bukan hasil pengujian.
Izin manusia
Manusia menyetujui aturan, akses data, perubahan database, biaya, penghapusan, deployment, dan keputusan lain yang berdampak.
Peran AI dan manusia
AI membantu
- Merapikan ide dan menemukan pertanyaan.
- Menawarkan serta membandingkan alternatif.
- Membuat rancangan awal proses, data, kode, test, dan dokumentasi.
- Mendiagnosis gejala berdasarkan bukti yang tersedia.
- Mengkritik hasil dan mencari risiko.
Manusia bertanggung jawab
- Menetapkan masalah, tujuan, dan ukuran berhasil.
- Mengonfirmasi fakta serta aturan organisasi.
- Menentukan risiko yang dapat diterima.
- Menyetujui penggunaan data dan hak akses.
- Menyetujui perubahan penting dan rilis.
Capaian Pembelajaran
Setelah menyelesaikan course ini, pembelajar diharapkan mampu:
- Menjelaskan kemampuan dan keterbatasan AI generatif dalam pembuatan aplikasi.
- Membedakan fakta, asumsi, keputusan, dan informasi yang belum diketahui.
- Mengubah ide kasar menjadi app brief yang dapat diperiksa.
- Memetakan pengguna, proses, aturan, pengecualian, data, dan hak akses.
- Menulis kebutuhan serta kriteria penerimaan yang dapat diuji.
- Meminta AI menghasilkan beberapa alternatif yang benar-benar berbeda.
- Membandingkan pilihan menggunakan kriteria, bobot, risiko, dan bukti.
- Menentukan MVP berdasarkan manfaat, risiko, dan kemampuan pengujian.
- Meminta AI membangun aplikasi dalam bagian kecil yang dapat diverifikasi.
- Mendiagnosis error berdasarkan bukti sebelum mengubah kode.
- Menyusun test positif, negatif, batas, akses, integrasi, dan regresi.
- Menyiapkan rilis, monitoring, backup, rollback, serta handover.
Prasyarat dan perlengkapan
- Tidak wajib sudah menjadi programmer.
- Mampu menjelaskan satu pekerjaan atau masalah sehari-hari yang ingin dibantu aplikasi.
- Memiliki akses yang sah terhadap dokumen, data, kode, dan sistem untuk latihan.
- Gunakan data contoh atau data yang telah disamarkan.
- Jangan memasukkan password, token, private key, data pribadi, atau rahasia perusahaan ke percakapan AI.
- Siapkan lingkungan uji; jangan menjadikan production sebagai tempat pertama mencoba perubahan.
- Jika AI diberi akses file atau terminal, gunakan hak minimum dan minta persetujuan sebelum tindakan berisiko.
Syllabus
Syllabus terdiri atas sepuluh lecture dalam lima minggu. Setiap lecture menghasilkan artefak yang saling menyambung dan digabungkan menjadi Paket Pengembangan Aplikasi Berbantuan AI pada capstone.
Tabel dapat digeser ke kanan atau kiri pada perangkat seluler.
| Minggu | Lecture | Fokus | Aktivitas | Output |
|---|---|---|---|---|
| 1 | 1. AI dan halusinasi | Keterbatasan AI, tanggung jawab, dan B.U.K.T.I. | Mengklasifikasikan fakta, asumsi, keputusan, dan unknown. | Source Map dan aturan kerja AI. |
| 1 | 2. App brief | Masalah, pengguna, tujuan, scope, batasan, dan ukuran berhasil. | Mengubah ide kasar menjadi brief. | App Brief versi 1. |
| 2 | 3. Asumsi dan pertanyaan | Blind spot, pengecualian, dan validasi. | Menjalankan kritik AI dan wawancara. | Assumption and Question Log. |
| 2 | 4. Fondasi aplikasi | Proses, aturan, data, peran, dan acceptance criteria. | Membuat process map dan matriks. | Paket Fondasi Aplikasi. |
| 3 | 5. Pilihan solusi | Tiga jalur, kriteria, bobot, dan trade-off. | Membuat decision scorecard. | Options Analysis dan ADR. |
| 3 | 6. Desain dan keamanan | Komponen, integrasi, auth, log, backup, dan kegagalan. | Melakukan panel review. | Desain Solusi dan Risk Register. |
| 4 | 7. MVP dan prioritas | Prinsip 80/20, dependency, dan vertical slice. | Menentukan backlog MVP. | MVP Scope dan backlog. |
| 4 | 8. Implementasi terkendali | Kontrak kerja AI, perubahan kecil, version control, dan test. | Membangun satu alur utuh. | Increment yang dapat didemonstrasikan. |
| 5 | 9. Diagnosis dan review | Gejala, hipotesis, akar penyebab, regresi, dan kritik. | Mendiagnosis serta mereview fitur. | Diagnostic Report dan Review Record. |
| 5 | 10. Rilis dan operasi | Test, release gate, monitoring, rollback, dan handover. | Simulasi rilis dan kegagalan. | Test Report, Release Plan, dan Runbook. |
Required Reading
Bacaan berikut dipakai untuk memperkuat dua dasar course: pengelolaan risiko AI dan pengembangan perangkat lunak yang aman. Dokumentasi produk perlu diperiksa kembali ketika digunakan karena nama menu, fitur, model, dan versi dapat berubah.
Kerangka risiko dan pengembangan aman
Panduan vendor mengenai prompt, halusinasi, dan evaluasi
Lecture Summaries
AI sebagai mitra berpikir, bukan sumber kebenaran
AI tidak hadir dalam rapat organisasi Anda, tidak melihat database kecuali diberi akses, tidak mengetahui aturan terbaru kecuali tersedia pada sumber, dan tidak otomatis memahami alasan di balik proses. Kalimat “buatkan aplikasi pengadaan” memaksa AI menebak pengguna, alur, persetujuan, data, dokumen, notifikasi, serta laporan.
Gunakan pola kerja berikut:
Empat status informasi
- Ⓕ Fakta: tersedia pada sumber atau telah diamati langsung.
- Ⓐ Asumsi: dugaan sementara yang masih perlu dikonfirmasi.
- Ⓓ Keputusan: pilihan yang sudah disetujui oleh pihak berwenang.
- Ⓤ Belum diketahui: informasi belum tersedia atau bukti belum cukup.
Prompt dasar anti-halusinasi
Pertanyaan refleksi: bagian mana dari aplikasi yang selama ini Anda anggap “sudah jelas”, padahal belum pernah ditulis atau dikonfirmasi?
Mengubah ide kasar menjadi brief aplikasi
AI memberi hasil lebih tepat jika diminta menyusun persoalan sebelum membuat solusi. Dua mode pertama adalah Strategist dan Brief Builder.
① Mode Strategist · berpikir sebelum membuat
Gunakan ketika Anda mempunyai tujuan, tetapi belum yakin kebutuhan dan arah terbaiknya.
② Mode Brief Builder · merapikan ide yang belum terstruktur
Gunakan ketika ide masih berupa catatan, percakapan, keluhan, atau daftar harapan.
Isi minimum app brief
- Masalah: kondisi yang merugikan atau menghambat saat ini.
- Pengguna: pihak yang mengalami masalah atau menjalankan proses.
- Tujuan: perubahan yang ingin terlihat setelah aplikasi digunakan.
- Ukuran keberhasilan: angka atau bukti yang dapat dibandingkan.
- Ruang lingkup: hal yang dikerjakan pada versi ini.
- Di luar ruang lingkup: hal yang sengaja belum dikerjakan.
- Batasan: waktu, biaya, teknologi, kebijakan, dan kemampuan tim.
- Risiko: hal yang dapat membuat solusi gagal atau menimbulkan dampak.
- Pemilik keputusan: pihak yang berwenang mengesahkan kebutuhan dan aturan.
Pertanyaan refleksi: apakah tujuan aplikasi menjelaskan perubahan bagi pengguna, atau baru berupa keinginan memiliki fitur?
Menantang asumsi dan menemukan pertanyaan penting
AI yang selalu menyetujui pengguna dapat mempercepat keputusan yang salah. Sebelum menghabiskan waktu untuk membuat aplikasi, gunakan AI untuk mencari blind spot dan pertanyaan yang dapat mengubah solusi.
③ Mode Challenger · menguji ide sebelum menyetujui
⑦ Mode Question Finder · menemukan pertanyaan yang belum terpikirkan
Pertanyaan dasar yang sering terlewat
- Siapa yang boleh membuat, melihat, mengubah, menyetujui, membatalkan, dan menghapus data?
- Apa yang terjadi jika data tidak lengkap, ganda, terlambat, atau salah?
- Apakah satu orang boleh memiliki lebih dari satu peran?
- Dapatkah pengaju menyetujui permintaannya sendiri?
- Data berasal dari aplikasi ini atau dari sistem lain?
- Apa yang terjadi jika integrasi, jaringan, atau layanan pihak ketiga gagal?
- Perubahan apa yang harus tercatat untuk audit?
- Berapa lama data disimpan dan bagaimana data dihapus?
- Apa yang dilakukan jika rilis baru bermasalah?
Jawaban penting harus dikonfirmasi kepada pihak yang tepat. Pemilik proses mengesahkan alur dan aturan. Pemilik data mengesahkan arti, akses, serta retensi data. Tim teknis mengesahkan kondisi sistem dan integrasi. Pengguna memvalidasi apakah solusi dapat dipakai pada pekerjaan nyata.
Pertanyaan refleksi: siapa satu pihak yang jawabannya paling mungkin mengubah desain aplikasi Anda?
Proses, aturan, data, dan hak akses
Aplikasi adalah proses yang diterjemahkan ke dalam aturan, data, tampilan, dan tindakan sistem. Jika fondasinya tidak jelas, AI hanya akan membuat perkiraan yang terlihat seperti aplikasi.
Contoh kasus: aplikasi permintaan barang
Pemohon mengisi kebutuhan barang. Admin memeriksa kelengkapan. Pejabat yang berhak menyetujui atau menolak. Pemohon melihat status. Setiap perubahan penting harus tercatat.
Empat artefak fondasi
- Process map: alur normal, keputusan, pengembalian, pembatalan, kegagalan, dan pengecualian.
- Business rule register: kondisi, tindakan sistem, hasil, pemilik aturan, sumber, dan status konfirmasi.
- Data dictionary: arti, format, kewajiban, sumber, pemilik, validasi, akses, dan masa simpan setiap data.
- Access matrix: hak Lihat, Buat, Ubah, Setujui, Batalkan, Hapus, Ekspor, serta Kelola Pengguna untuk setiap peran.
Kriteria penerimaan yang mudah dipahami
Gunakan tiga unsur: kondisi awal, tindakan, dan hasil yang harus terjadi.
Contoh negatif
Pertanyaan refleksi: apakah aplikasi sudah mendefinisikan tindakan yang harus ditolak, bukan hanya tindakan yang harus berhasil?
Membandingkan tiga jalur solusi
Masalah tidak selalu membutuhkan aplikasi baru. Bisa jadi proses perlu disederhanakan, fitur pada sistem lama belum dimanfaatkan, atau platform no-code sudah cukup. Minta AI menawarkan jalur yang benar-benar berbeda.
⑤ Mode Three Paths · tiga pendekatan berbeda
⑧ Mode Decision Scoreboard · memilih dengan kriteria
Kriteria keputusan yang dapat digunakan
- Kesesuaian dengan proses dan kebutuhan pengguna.
- Waktu menuju manfaat pertama.
- Biaya awal dan biaya pemeliharaan.
- Kemudahan integrasi dan migrasi.
- Perlindungan data dan kontrol akses.
- Kemampuan tim mengoperasikan.
- Ketergantungan kepada vendor.
- Skalabilitas, performa, audit, dan pelacakan perubahan.
Catat keputusan
Pertanyaan refleksi: jika orang baru bergabung enam bulan lagi, dapatkah ia memahami mengapa teknologi atau pendekatan tersebut dipilih?
Desain, arsitektur, integrasi, dan keamanan
Arsitektur tidak harus berupa gambar rumit. Bagi pemula, arsitektur adalah penjelasan tentang bagian aplikasi, data yang mengalir di antaranya, sistem yang terhubung, serta apa yang terjadi ketika salah satu bagian gagal.
Minimum yang harus terlihat pada desain
- Pengguna dan perannya.
- Antarmuka dan layanan atau modul utama.
- Database serta jenis data penting.
- Integrasi, kontrak API, dan pemiliknya.
- Cara login dan pemeriksaan hak akses.
- Tempat menyimpan file serta secret.
- Log, monitoring, backup, dan pemulihan.
- Batas development, staging, dan production.
- Perilaku saat koneksi, database, atau integrasi gagal.
⑨ Mode Panel Review · melihat dari beberapa sudut
Security by design untuk pemula
- Apakah setiap pengguna benar-benar perlu melihat data tersebut?
- Apakah server memeriksa hak akses, bukan hanya menyembunyikan tombol?
- Apakah input diperiksa sebelum diproses?
- Apakah password, token, dan secret tidak ditulis di kode atau prompt?
- Apakah aktivitas penting tercatat tanpa menyimpan data sensitif berlebihan?
- Apakah dependency berasal dari sumber tepercaya dan masih didukung?
- Apakah backup telah diuji melalui restore?
- Apakah AI dan tool hanya memperoleh akses minimum?
Pertanyaan refleksi: jika akun pengguna biasa diambil alih, seberapa luas data dan tindakan yang dapat dijangkau akun tersebut?
Menentukan MVP dengan prinsip 80/20
MVP bukan aplikasi besar yang fiturnya dipotong secara acak. MVP adalah versi terkecil yang menyelesaikan satu masalah penting dari awal sampai akhir, dapat digunakan oleh pengguna yang jelas, dan menghasilkan pembelajaran nyata.
⑩ Mode High Leverage · menemukan bagian paling berdampak
Contoh MVP aplikasi permintaan barang
Masuk MVP
- Login dan pemeriksaan peran.
- Membuat permintaan dengan data wajib.
- Melihat daftar dan status permintaan sendiri.
- Verifikasi kelengkapan oleh admin.
- Persetujuan atau penolakan oleh pejabat.
- Riwayat perubahan status.
Ditunda
- Chat di dalam aplikasi.
- Rekomendasi barang berbasis AI.
- Dashboard analitik lanjutan.
- Integrasi ke banyak vendor.
- Aplikasi seluler native.
Pecah MVP menjadi vertical slice
Vertical slice adalah bagian kecil yang menyentuh seluruh lapisan yang diperlukan.
Pertanyaan refleksi: jika hanya satu alur boleh selesai minggu ini, alur mana yang paling cepat memberi manfaat atau mengurangi risiko terbesar?
Membangun bagian kecil yang dapat diuji
Sebelum AI mengubah kode, berikan kontrak kerja. Kontrak menjelaskan apa yang boleh dibaca, apa yang boleh diubah, bagaimana hasil diuji, serta kapan AI harus berhenti dan meminta keputusan.
Kontrak implementasi minimum
- Tujuan: perilaku pengguna atau sistem yang ingin dicapai.
- Ruang lingkup: file atau modul yang relevan.
- Di luar ruang lingkup: bagian yang tidak boleh disentuh.
- Sumber kebenaran: brief, aturan, data, dokumentasi API, dan versi teknologi.
- Kriteria penerimaan: perilaku yang harus lulus.
- Larangan: tidak mengarang API, field, dependency, secret, atau hasil test.
- Pengujian: perintah atau langkah yang harus dijalankan.
- Keamanan: hak minimum dan tindakan yang membutuhkan persetujuan.
- Rollback: cara membatalkan perubahan.
- Bukti: file berubah, hasil test, keterbatasan, dan risiko tersisa.
Master prompt implementasi
Aturan perubahan kecil
- Satu tujuan untuk setiap perubahan.
- Simpan kondisi awal pada version control.
- Baca kode dan test terkait sebelum mengubah.
- Jangan memperbaiki hal di luar scope tanpa persetujuan.
- Jalankan test terdekat dan test integrasi yang relevan.
- Periksa perbedaan file sebelum menerima hasil.
- Catat keputusan, alasan, dan risiko tersisa.
Pertanyaan refleksi: jika perubahan AI harus dibatalkan lima menit kemudian, apakah Anda mengetahui file, data, dan konfigurasi yang perlu dipulihkan?
Diagnosis sebelum perbaikan dan kritik sebelum persetujuan
Memperbaiki error tanpa memahami penyebab dapat memindahkan masalah atau menciptakan masalah baru. AI harus menghubungkan gejala dengan bukti, membuat hipotesis, dan menguji hipotesis tersebut.
④ Mode Diagnostician · mencari akar masalah
⑥ Mode Toughest Critic · review dengan kriteria
Review yang baik menanyakan
- Apakah hasil sesuai kebutuhan dan kriteria penerimaan?
- Apakah ada aturan yang diciptakan tanpa sumber?
- Apakah perubahan terlalu luas?
- Apakah akses diperiksa pada server?
- Apakah input, error, dan kondisi kosong ditangani?
- Apakah perubahan merusak perilaku lama?
- Apakah dependency dan konfigurasi sesuai versi?
- Apakah test benar-benar dijalankan?
- Apakah dokumentasi dan rollback diperbarui?
Pertanyaan refleksi: bukti apa yang membedakan “perbaikan terlihat masuk akal” dari “akar masalah benar-benar telah diperbaiki”?
Test, rilis, monitoring, dan pemeliharaan
Aplikasi belum selesai ketika kode dapat dijalankan. Aplikasi baru siap digunakan setelah perilaku penting diuji, data dilindungi, kegagalan diantisipasi, rilis dapat dipantau, dan pemulihan tersedia.
Lapisan pengujian
Fungsi normal
Pengguna yang benar menjalankan tindakan yang benar dengan data yang valid.
Test negatif
Input salah, kondisi tidak lengkap, dan tindakan tanpa hak ditolak dengan aman.
Test batas
Nilai minimum, maksimum, kosong, duplikat, format salah, ukuran file, dan kondisi waktu diuji.
Integrasi
Pertukaran data dengan database, API, email, file, dan sistem lain sesuai kontrak.
Regresi
Perubahan baru tidak merusak fungsi lama yang masih diperlukan.
Keamanan
Autentikasi, otorisasi, input, secret, dependency, session, upload, log, dan konfigurasi diperiksa.
Performa
Respons, timeout, retry, transaksi ganda, beban, dan kegagalan dependency diuji secara relevan.
User Acceptance Test
Pemilik proses dan pengguna membuktikan pekerjaan nyata dapat diselesaikan.
Bukti test minimum
- ID test dan kebutuhan yang diuji.
- Kondisi awal serta data uji.
- Langkah atau perintah yang dijalankan.
- Hasil yang diharapkan dan hasil aktual.
- Status lulus atau gagal.
- Waktu, versi, dan lingkungan.
- Log, tangkapan layar, atau laporan otomatis yang relevan.
- Nama pemeriksa dan catatan keterbatasan.
Gate sebelum rilis
- Kebutuhan dan aturan dalam rilis telah disetujui.
- Seluruh kriteria penerimaan mempunyai hasil test.
- Temuan kritis dan tinggi telah ditangani atau diterima pihak berwenang.
- Migrasi data diuji menggunakan salinan yang aman.
- Backup tersedia dan restore pernah diuji.
- Monitoring, alert, release plan, PIC, dan komunikasi siap.
- Rollback mempunyai kondisi pemicu, langkah, PIC, dan batas keputusan.
- Tidak ada secret di kode, log, prompt, atau dokumen publik.
Monitor setelah rilis
- Tingkat keberhasilan transaksi dan waktu respons.
- Jumlah error, timeout, serta pola login atau akses mencurigakan.
- Kapasitas antrean, server, database, dan penyimpanan.
- Kesesuaian data dengan sumber.
- Langkah tempat pengguna berhenti dan keluhan yang berulang.
Pertanyaan refleksi: jika pembuat aplikasi tidak tersedia besok, dapatkah orang lain memahami sistem, memulihkan layanan, dan melanjutkan pengembangan dari dokumen yang ada?
Sepuluh mode AI dalam satu alur
- Strategist: menentukan masalah, pengguna, arah, dan ukuran keberhasilan.
- Brief Builder: mengubah ide kasar menjadi app brief yang dapat diperiksa.
- Challenger: menantang asumsi dan mencari risiko.
- Diagnostician: mencari akar penyebab berdasarkan bukti.
- Three Paths: menawarkan tiga jalur solusi yang berbeda.
- Toughest Critic: mereview hasil berdasarkan kriteria.
- Question Finder: menemukan pertanyaan yang dapat mengubah solusi.
- Decision Scoreboard: membandingkan pilihan secara transparan.
- Panel Review: melihat desain dari beberapa sudut kepentingan.
- High Leverage: memilih sedikit pekerjaan dengan dampak terbesar.
Urutan proyek baru: Strategist → Brief Builder → Challenger → Question Finder → Three Paths → Decision Scoreboard → Panel Review → High Leverage → Implementasi kecil → Toughest Critic → Test dan rilis.
Diagnostician digunakan setiap kali muncul masalah; tidak perlu menunggu proyek selesai.
Template prompt kerja harian
Checkpoint anti-halusinasi
- Sumber, versi, tanggal, dan ruang lingkup yang digunakan jelas.
- Klaim penting dapat dilacak ke sumber atau hasil test.
- Fakta dipisahkan dari asumsi, keputusan, dan unknown.
- AI mengakui keterbatasan ketika bukti tidak cukup.
- Nama file, tabel, field, API, fungsi, dan paket benar-benar ada.
- Contoh dan konfigurasi sesuai versi yang digunakan.
- Test benar-benar dijalankan dan hasil aktualnya dicatat.
- Test negatif, akses, error, batas, dan regresi ikut diperiksa.
- Data sensitif dan secret tidak dimasukkan ke prompt atau bukti publik.
- Backup, rollback, monitoring, PIC, dan persetujuan tersedia.
Log halusinasi dan koreksi
Jangan hanya menghapus jawaban AI yang salah. Catat pola kesalahannya agar prompt, sumber, test, dan proses kerja dapat diperbaiki.
Contoh: AI menyatakan kolom approval_status sudah tersedia. Pemeriksaan pada migration dan skema staging menunjukkan kolom tersebut tidak ada. Solusinya adalah menggunakan status pada tabel yang telah disetujui dalam desain. Pencegahannya: AI wajib membaca migration dan skema aktual sebelum menyebut field.
Assignments
Problem and Source Map
Pilih satu masalah nyata. Identifikasi pengguna, dampak, kondisi saat ini, tujuan, pemilik proses, pemilik data, sumber kebenaran, dan informasi yang belum tersedia.
Output: Problem Statement, Stakeholder Map, dan Source Map.
App Brief
Gunakan Mode Strategist dan Brief Builder. Konfirmasi minimal tiga informasi kepada pihak yang tepat tanpa mengubah asumsi menjadi fakta.
Output: App Brief beserta daftar fakta, asumsi, keputusan, dan pertanyaan.
Paket Fondasi Aplikasi
Petakan alur normal dan minimal tiga pengecualian. Buat aturan bisnis, kamus data, matriks akses, serta kriteria penerimaan positif dan negatif.
Output: Process Map, Business Rule Register, Data Dictionary, Access Matrix, dan Acceptance Criteria.
Tiga Jalur dan Keputusan
Bandingkan tiga pendekatan berbeda menggunakan kriteria berbobot. Tandai skor yang belum mempunyai bukti.
Output: Options Analysis, Decision Scorecard, dan Architecture Decision Record.
MVP dan Vertical Slice
Tentukan alur terkecil yang memberi manfaat nyata, lalu pecah menjadi bagian yang dapat diuji.
Output: MVP Scope, daftar di luar scope, backlog prioritas, dan urutan vertical slice.
Implementasi dan Review
Implementasikan satu vertical slice pada lingkungan uji. Gunakan kontrak implementasi, jalankan test, lalu lakukan review ketat.
Output: Daftar perubahan, hasil test, review record, risiko tersisa, dan verifikasi manual.
Diagnosis dan Release Readiness
Diagnosis satu masalah berdasarkan bukti, usulkan perbaikan, uji regresi, dan susun rencana rilis serta rollback.
Output: Diagnostic Report, Test Report, Release Plan, Rollback Plan, Monitoring Plan, dan Runbook.
Urutan penerapan yang disarankan
Tabel dapat digeser ke kanan atau kiri pada perangkat seluler.
| Tahap | Tujuan | Tindakan utama | Gate sebelum lanjut |
|---|---|---|---|
| Mulai | Mencegah masalah palsu dan kebocoran data. | Validasi masalah, pemilik, sumber, izin, serta klasifikasi data. | Masalah nyata, sumber tersedia, dan data aman untuk digunakan. |
| Definisi | Mengurangi ruang AI untuk menebak. | Susun brief, proses, aturan, data, akses, dan acceptance criteria. | Pemilik proses serta data mengonfirmasi bagian kritis. |
| Desain | Memilih solusi yang tepat dan dapat dipelihara. | Bandingkan alternatif, nilai risiko, buat desain, dan tentukan MVP. | Keputusan, trade-off, risiko residual, dan scope disetujui. |
| Build | Menghasilkan perubahan kecil yang dapat dibuktikan. | Bangun vertical slice, review perbedaan, jalankan test, dan catat bukti. | Kriteria penerimaan lulus dan risiko perubahan dipahami. |
| Release | Memindahkan perubahan secara terkendali. | UAT, backup, release plan, monitoring, komunikasi, dan rollback. | Go atau no-go diputuskan pihak berwenang. |
| Operate | Menjaga manfaat dan belajar dari kondisi nyata. | Monitor transaksi, error, performa, keamanan, keluhan, dan known error. | Hasil operasi masuk ke backlog dan evaluasi berikutnya. |
Self-Assessment
Buka setiap pertanyaan setelah menulis jawaban sendiri.
1. Mengapa perintah “buatkan aplikasi pengadaan” berisiko menghasilkan aplikasi yang salah?
Kunci: Pengguna, masalah, alur, aturan, data, persetujuan, integrasi, keamanan, dan ukuran berhasil belum dijelaskan. AI akan terdorong mengisi kekosongan dengan pola umum atau dugaan.
2. Apa perbedaan fakta dan asumsi?
Kunci: Fakta didukung sumber atau observasi yang dapat diperiksa. Asumsi adalah dugaan sementara yang masih memerlukan konfirmasi.
3. Apakah prompt yang sangat rinci menjamin AI tidak berhalusinasi?
Kunci: Tidak. Prompt yang baik mengurangi ketidakjelasan, tetapi hasil tetap perlu dibatasi pada sumber, diuji, dan direview.
4. Mengapa tampilan bagus belum membuktikan aplikasi benar?
Kunci: Tampilan tidak membuktikan aturan bisnis, kualitas data, hak akses, integrasi, keamanan, performa, dan pemulihan telah bekerja.
5. Apa fungsi kriteria penerimaan?
Kunci: Menjelaskan perilaku yang dapat diamati untuk menentukan apakah kebutuhan benar-benar terpenuhi.
6. Mengapa test negatif diperlukan?
Kunci: Aplikasi harus membuktikan input salah, kondisi tidak lengkap, dan tindakan tanpa hak ditolak secara aman, bukan hanya membuktikan alur normal berhasil.
7. Kapan AI boleh menyatakan test lulus?
Kunci: Hanya ketika test benar-benar dijalankan pada lingkungan yang disebutkan dan hasil aktualnya tersedia sebagai bukti.
8. Mengapa aplikasi sebaiknya dibangun dalam vertical slice?
Kunci: Bagian kecil yang utuh lebih mudah dipahami, diuji, direview, didemonstrasikan, dan dibatalkan jika salah.
9. Mengapa AI perlu diberi hak akses minimum?
Kunci: Untuk membatasi dampak jika instruksi salah, konteks keliru, tool gagal, atau AI mencoba tindakan di luar kebutuhan.
10. Apa perbedaan diagnosis dan menebak perbaikan?
Kunci: Diagnosis menghubungkan gejala, fakta, hipotesis, dan test pembeda sampai penyebab terverifikasi. Menebak langsung mengubah sistem tanpa memastikan penyebab.
11. Siapa yang berhak menetapkan aturan bisnis?
Kunci: Pemilik proses atau pihak yang diberi kewenangan, bukan AI dan bukan developer yang hanya menebak dari kebiasaan umum.
12. Kapan aplikasi siap production?
Kunci: Setelah kebutuhan disetujui, kriteria penerimaan lulus, risiko dinilai, akses dan data dilindungi, deployment terencana, monitoring siap, serta backup dan rollback dapat digunakan.
Capstone
Buat Paket Pengembangan Aplikasi Berbantuan AI untuk satu aplikasi sederhana yang menyelesaikan masalah nyata. Aplikasi boleh berupa prototype, no-code, low-code, atau kode khusus. Penilaian tidak berfokus pada banyaknya halaman, tetapi pada ketepatan kebutuhan, keterlacakan keputusan, bukti pengujian, keamanan dasar, dan kesiapan pengelolaan.
Deliverable wajib
- Pernyataan masalah, tujuan, pengguna, ukuran keberhasilan, ruang lingkup, dan batasan.
- Source Map serta daftar Ⓕ fakta, Ⓐ asumsi, Ⓓ keputusan, dan Ⓤ belum diketahui.
- Process Map dengan alur normal dan minimal tiga pengecualian.
- Business Rule Register, Data Dictionary, dan Access Matrix.
- Tiga alternatif solusi, Decision Scorecard, dan catatan keputusan.
- Desain yang menunjukkan pengguna, komponen, data, integrasi, keamanan, log, backup, dan kegagalan.
- Scope MVP, backlog prioritas, serta minimal satu vertical slice yang dapat didemonstrasikan.
- Kriteria penerimaan dan test matrix yang mencakup test positif, negatif, batas, akses, integrasi, dan regresi.
- Bukti hasil test aktual tanpa secret atau data pribadi.
- Hallucination and Correction Log yang memuat minimal tiga pemeriksaan klaim AI.
- Review Record, Risk Register, dan daftar known error.
- Release Plan, Rollback Plan, Monitoring Plan, Runbook, dan dokumentasi handover.
Rubrik penilaian
Tabel dapat digeser ke kanan atau kiri pada perangkat seluler.
| Dimensi | 0 — Belum ada | 1 — Dasar | 2 — Memadai | 3 — Kuat |
|---|---|---|---|---|
| Masalah dan kebutuhan | Masalah dan pengguna tidak jelas. | Ada daftar fitur, tetapi hubungan dengan masalah lemah. | Masalah, pengguna, tujuan, proses, dan acceptance criteria terhubung. | Kebutuhan dikonfirmasi, pengecualian dipetakan, dan ukuran keberhasilan dapat diuji. |
| Sumber dan anti-halusinasi | Hasil AI diterima tanpa pemeriksaan. | Ada beberapa sumber, tetapi fakta dan asumsi bercampur. | Status informasi dipisahkan dan klaim penting dapat dilacak. | Konflik sumber ditangani, log koreksi tersedia, dan proses diperbaiki. |
| Data, desain, dan keamanan | Data dan akses tidak didefinisikan. | Struktur dasar ada, tetapi risiko belum ditangani. | Data, peran, integrasi, validasi, log, backup, dan kontrol utama tersedia. | Desain membahas kegagalan, least privilege, recovery, retensi, dan risiko residual. |
| Implementasi dan test | Hanya berupa tampilan atau klaim. | Alur normal bekerja, tetapi bukti terbatas. | Satu vertical slice lulus test positif, negatif, dan regresi yang relevan. | Hasil dapat diulang dan keterlacakan kebutuhan ke test jelas. |
| Rilis dan keberlanjutan | Tidak ada rencana operasi. | Rilis dapat dilakukan, tetapi monitoring dan rollback belum jelas. | Rilis, monitoring, backup, rollback, runbook, dan PIC tersedia. | Pemulihan disimulasikan, handover dapat digunakan, dan operasi menjadi masukan perbaikan. |
Nilai maksimum: 15. Rekomendasi kelulusan mandiri: minimal 11 tanpa nilai 0 pada dimensi mana pun.
Definition of done
- Masalah, pengguna, tujuan, dan ukuran keberhasilan disetujui.
- Setiap aturan penting mempunyai sumber dan pemilik.
- Fakta, asumsi, keputusan, dan unknown tidak dicampur.
- Scope MVP dan hal di luar scope dinyatakan jelas.
- Data, hak akses, integrasi, dan kondisi kegagalan dipetakan.
- Satu alur bernilai berjalan dari awal sampai akhir.
- Test positif, negatif, akses, error, dan regresi telah dijalankan.
- Klaim AI penting telah diverifikasi dengan bukti.
- Tidak ada secret atau data pribadi pada prompt dan bukti publik.
- Risiko tersisa, known error, dan keterbatasan dicatat.
- Release plan, monitoring, backup, rollback, dan PIC tersedia.
- Orang lain dapat melanjutkan proyek dari artefak handover.
FAQ dan Referensi
Apakah orang yang tidak bisa coding dapat mengikuti course ini?
Ya. Bagian terpenting adalah memahami masalah, proses, data, kebutuhan, risiko, dan pengujian. Implementasi dapat memakai prototype, no-code, low-code, atau dibantu orang yang memahami pengembangan aplikasi.
Apakah cukup memberi AI satu prompt untuk membuat seluruh aplikasi?
Untuk demo kecil mungkin terlihat berhasil. Untuk aplikasi nyata, cara tersebut menyulitkan pemeriksaan dan memperbesar risiko asumsi tersembunyi. Gunakan tahapan, persetujuan, vertical slice, dan test.
AI mana yang paling baik untuk membuat aplikasi?
Tidak ada satu jawaban yang selalu benar. Nilai kebutuhan, bahasa dan teknologi, kemampuan membaca konteks, integrasi tool, keamanan data, biaya, batas penggunaan, dan kemampuan tim memverifikasi hasil. Uji kandidat memakai tugas serta kriteria yang sama.
Apakah AI boleh memilih teknologi?
AI boleh mengusulkan dan membandingkan. Keputusan tetap mempertimbangkan kebutuhan, kebijakan, kemampuan tim, biaya total, dukungan versi, keamanan, integrasi, serta pemeliharaan.
Bagaimana jika seluruh kebutuhan belum diketahui?
Catat hal yang belum diketahui, tanyakan kepada pihak yang tepat, buat prototype untuk belajar, dan batasi keputusan yang sulit dibalik. Jangan meminta AI menyamarkan ketidakpastian dengan jawaban pasti.
Apakah hasil AI harus selalu diperiksa manusia?
Semakin besar dampaknya terhadap data, uang, keselamatan, hak pengguna, keamanan, dan operasi, semakin kuat pemeriksaan manusia yang dibutuhkan. Pekerjaan rutin berisiko rendah dapat lebih otomatis setelah kontrol dan evaluasinya matang.
Bolehkah database, password, atau token dimasukkan ke AI?
Jangan memasukkan secret. Gunakan data contoh atau data yang telah disamarkan, mekanisme penyimpanan secret yang tepat, dan kebijakan organisasi. Berikan AI hanya akses yang diperlukan dan dapat dicabut.
Jika kode berhasil di laptop, apakah siap production?
Belum. Konfigurasi, data, traffic, hak akses, jaringan, integrasi, monitoring, backup, dan deployment dapat berbeda. Uji pada staging yang representatif dan gunakan release gate.
Bagaimana memastikan AI tidak mengarang API atau field database?
Berikan dokumentasi dan skema aktual, batasi jawaban pada sumber itu, minta AI menunjuk asal setiap nama, lalu periksa melalui kode, migration, skema staging, atau request API yang aman.
Apakah meminta AI “berpikir lebih dalam” sudah cukup?
Belum. Yang lebih penting adalah sumber kebenaran, pertanyaan tepat, batas scope, kriteria penerimaan, test aktual, dan persetujuan manusia.
Apakah AI dapat menguji kodenya sendiri?
AI dapat menulis dan menjalankan test jika mempunyai tool serta lingkungan yang sesuai. Namun, test yang salah dapat meluluskan kode yang salah. Kebutuhan, data uji, expected result, cakupan, dan hasilnya tetap harus direview.
Apa yang dilakukan jika dua jawaban AI berbeda?
Jangan memilih jawaban yang paling meyakinkan. Bandingkan asumsi, sumber, versi, dan test yang digunakan. Jalankan pemeriksaan pembeda. Perbedaan adalah sinyal bahwa keputusan belum cukup terikat pada bukti.
Siapa yang bertanggung jawab jika aplikasi buatan AI salah?
AI bukan pemilik proses dan bukan penanggung jawab organisasi. Pihak yang merancang, menyetujui, mengoperasikan, serta menggunakan aplikasi tetap bertanggung jawab sesuai perannya.
Referensi yang digunakan
- National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework.
- National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1.
- National Institute of Standards and Technology. Secure Software Development Framework Version 1.1. NIST SP 800-218.
- Anthropic. Reduce Hallucinations.
- OpenAI. Prompt Engineering.
- OpenAI. Working with Evals.
- OWASP GenAI Security Project. OWASP GenAI LLM Top 10 2026.
Mulai dari Masalah, Selesaikan dengan Bukti
Pilih satu masalah kecil yang nyata. Temui pengguna dan pemilik proses. Kumpulkan sumber yang benar. Buat app brief. Pisahkan fakta dari asumsi. Bandingkan beberapa jalur. Pilih satu MVP. Bangun satu alur kecil. Uji tindakan yang harus berhasil dan yang harus ditolak. Catat bukti, risiko, serta keputusan. Baru setelah itu lanjutkan ke fitur berikutnya.
Jangan sekadar memberi AI tugas. Berikan masalah yang perlu dipahami, sumber yang harus dihormati, batas yang tidak boleh dilanggar, dan bukti yang harus dihasilkan.
Informasi perusahaan dan materi edukasi lain tersedia di website PT Mitra Solusindo Pratama.
Catatan editorial: Course ini merupakan materi edukasi umum. Materi tidak menjamin AI atau aplikasi bebas kesalahan, tidak menggantikan review profesional, dan tidak memberikan izin untuk mengakses sistem milik pihak lain. Terapkan perubahan hanya pada sistem yang Anda miliki atau yang memberikan izin. Sesuaikan praktik dengan arsitektur, teknologi, data, kebijakan, hukum, dan tingkat risiko. Gunakan staging, version control, backup, rollback, least privilege, change management, serta review tenaga yang kompeten sebelum penerapan pada production. Nama menu, kemampuan produk, model, dan versi dapat berubah setelah course diterbitkan.
Kutip Artikel Ini:
.aviv)
Tidak ada komentar
Posting Komentar
Silakan ajukan pertanyaan, kritik, maupun saran.