21.1 Dari Prompt ke Brief: Cara Baru Memberi Instruksi ke AI
Bayangkan Anda baru saja menerima permintaan dari tim produk: buatkan halaman dashboard untuk menampilkan data penjualan bulanan. Sebagai arsitek, Anda langsung membayangkan tabel, grafik, filter, dan mungkin beberapa metrik agregat. Tapi saat Anda mulai mengerjakan, muncul pertanyaan: data dari mana? Periode kapan? Siapa penggunanya? Apa yang paling ingin mereka lihat? Semakin dalam Anda menggali, semakin banyak detail yang ternyata belum jelas.
Sekarang bayangkan skenario yang sama, tetapi kali ini Anda memberikan instruksi ke AI. Anda mengetik: “Buatkan kode untuk dashboard penjualan.” AI akan menghasilkan sesuatu — mungkin rapi, mungkin tidak sesuai harapan. Lalu Anda ulangi lagi, perbaiki lagi, frustrasi lagi. Pola ini akrab bagi banyak orang yang mulai memakai AI untuk pekerjaan teknis. Masalahnya bukan pada AI-nya, tetapi pada cara kita memberi instruksi.
Kita terbiasa memberi perintah pendek ke mesin. Selama puluhan tahun, kita mengetik perintah ke terminal, menulis query SQL, atau memanggil fungsi dengan parameter. Pola komunikasi itu singkat, presisi, dan tanpa konteks. Tapi AI bekerja berbeda. Ia butuh konteks, bukan hanya perintah. Ia butuh pemahaman tentang situasi, bukan hanya instruksi langkah demi langkah.
Di sinilah konsep brief masuk. Brief bukan sekadar prompt yang lebih panjang. Brief adalah dokumen ringkas yang berisi lima hal: role, context, constraint, objective, dan acceptance criteria. Role menentukan siapa AI-nya: apakah ia asisten arsitek, reviewer kode, atau analis dokumen. Context menjelaskan situasi: proyek apa, siapa pemangku kepentingan, apa yang sudah ada. Constraint membatasi: teknologi apa yang wajib dipakai, berapa performa yang diharapkan, aturan keamanan apa yang berlaku. Objective adalah tujuan yang ingin dicapai dalam bahasa yang bisa diukur. Acceptance criteria adalah daftar kondisi yang harus dipenuhi agar hasilnya dianggap selesai.
Coba lihat perbedaannya. Prompt lama: “Buatkan kode untuk validasi email.” Brief yang baik: “Anda adalah asisten arsitek yang membantu tim backend. Kami sedang membangun sistem registrasi pengguna untuk aplikasi perbankan. Validasi email harus menggunakan regex yang sudah disetujui tim security, tidak boleh memanggil API eksternal, dan harus memberikan pesan error yang jelas dalam bahasa Indonesia. Tolong buatkan fungsi validasi yang menerima string email dan mengembalikan struktur data berisi status valid atau tidak beserta pesan kesalahannya.”
Berikut contoh perbandingan langsung untuk kasus dashboard penjualan yang sama.
# Prompt pendek (kurang efektif)
Buatkan kode untuk dashboard penjualan.
# Brief terstruktur (lebih efektif)
Role: Asisten arsitek frontend
Context: Tim produk membutuhkan halaman dashboard untuk menampilkan data penjualan bulanan. Pengguna adalah manajer penjualan. Data berasal dari API internal /api/sales/monthly. Saat ini belum ada UI.
Constraint: Wajib menggunakan React + Tailwind CSS. Tidak boleh menggunakan library chart eksternal. Halaman harus responsif. Data hanya boleh di-fetch sekali saat mount.
Objective: Membuat komponen React yang menampilkan tabel penjualan per bulan, total penjualan, dan grafik batang sederhana (buat sendiri dengan div).
Acceptance Criteria:
- Tabel menampilkan bulan, jumlah transaksi, total nominal.
- Grafik batang proporsional terhadap nominal.
- Ada filter tahun (dropdown) yang memicu fetch ulang.
- Pesan loading dan error state ditampilkan.
Brief seperti ini mengubah segalanya. AI tidak perlu menebak-nebak. Ia tahu konteks perbankan, tahu batasan keamanan, tahu output yang diharapkan. Hasilnya langsung bisa dipakai atau setidaknya mendekati harapan. Anda tidak perlu bolak-balik memperbaiki karena instruksi awal sudah cukup kaya.
Perubahan dari prompt ke brief ini bukan soal teknis, melainkan soal cara berpikir. Prompt adalah pola pikir programmer: beri perintah, dapatkan hasil. Brief adalah pola pikir arsitek: pahami situasi, rumuskan kebutuhan, baru minta bantuan. Arsitek tidak langsung meminta kode. Arsitek pertama-tama memastikan bahwa orang yang akan mengerjakan — entah itu manusia atau AI — memiliki pemahaman yang cukup tentang apa yang harus dibuat dan mengapa.
Implikasinya untuk tim cukup besar. Jika setiap anggota tim terbiasa menulis brief sebelum berinteraksi dengan AI, kualitas output naik secara konsisten. Dokumentasi brief bisa menjadi artefak yang dipakai ulang, direview, dan diperbaiki. Tim tidak lagi bergantung pada satu orang yang jago merangkai prompt, tetapi memiliki standar komunikasi yang bisa dipelajari siapa pun.
Perbedaan kedua pendekatan ini dapat dilihat dalam diagram alur berikut.
Brief juga menjadi jembatan ke subbab berikutnya. Setelah Anda punya brief yang jelas, langkah selanjutnya adalah memahami apa yang sudah ada: codebase, dokumen, dan keputusan masa lalu. Tanpa brief, Anda tidak tahu apa yang perlu dicari. Dengan brief, Anda punya kompas untuk menjelajahi sistem yang sudah berjalan.