17.2 Anatomi Brief Kerja untuk AI
Brief kerja bukan sekadar prompt yang lebih panjang. Brief kerja adalah dokumen mini yang memuat semua informasi yang dibutuhkan AI agar outputnya bisa langsung dinilai, bukan langsung dipakai. Seorang arsitek menyusun brief kerja seperti ia menyusun spesifikasi untuk tim engineering: jelas batasnya, jelas kriterianya, dan jelas cara memverifikasinya.
Ada delapan elemen yang membentuk anatomi brief kerja. Mari kita lihat satu per satu.
Pertama, role. AI perlu tahu peran apa yang harus ia mainkan. Apakah ia bertindak sebagai senior backend engineer yang akan menulis kode production-grade? Atau sebagai code reviewer yang hanya mencari celah keamanan? Atau sebagai documentation writer yang harus menjelaskan API ke audiens non-teknis? Role mengubah cara AI memproses permintaan. Jika role tidak diberikan, AI akan memilih peran default yang belum tentu sesuai.
Kedua, context. Context adalah situasi yang melatarbelakangi pekerjaan. Bukan sekadar “aplikasi ini untuk e-commerce”, tetapi lebih spesifik: aplikasi ini sudah berjalan di production selama dua tahun, menggunakan database PostgreSQL dengan schema tertentu, dan tim sedang dalam migrasi dari monolith ke microservices. Context membantu AI memahami apa yang sudah ada, apa yang sedang berubah, dan apa yang tidak boleh disentuh.
Ketiga, objective. Objective adalah hasil yang ingin dicapai. Bukan perintah teknis, tetapi outcome. Misalnya: “pengguna bisa mendaftar dengan nomor telepon dalam waktu kurang dari tiga detik” bukan “buat endpoint POST /register”. Objective membuat AI bisa memilih pendekatan terbaik, bukan sekadar menjalankan instruksi harfiah.
Keempat, constraint. Constraint adalah batasan yang harus dipatuhi. Bisa berupa teknologi yang wajib dipakai, standar keamanan yang harus dipenuhi, atau aturan arsitektur yang sudah ditetapkan. Contoh: “harus menggunakan library X versi Y”, “tidak boleh menyimpan password dalam bentuk plain text”, atau “setiap perubahan harus backward compatible”. Tanpa constraint, AI bisa menghasilkan solusi yang secara teknis benar tetapi melanggar aturan organisasi.
Kelima, scope. Scope menjelaskan apa yang termasuk dalam pekerjaan ini. Apakah cukup satu endpoint, atau perlu mencakup validasi input, error handling, logging, dan dokumentasi? Scope mencegah AI melakukan terlalu sedikit atau terlalu banyak. AI yang diberi scope sempit akan menghasilkan output yang fokus. AI yang tidak diberi scope bisa mengubah hal-hal di luar yang diminta.
Keenam, boundary. Boundary adalah batas yang tidak boleh dilanggar. Ini berbeda dengan constraint. Constraint membatasi cara kerja, boundary membatasi area kerja. Misalnya: “jangan ubah file konfigurasi database”, “jangan sentuh modul payment”, atau “jangan tambah dependency baru tanpa persetujuan”. Boundary adalah pagar yang menjaga agar AI tidak merembet ke bagian sistem yang seharusnya tidak tersentuh.
Ketujuh, acceptance criteria. Ini adalah daftar kondisi yang harus dipenuhi agar output bisa diterima. Acceptance criteria harus terukur dan bisa diuji. Contoh: “semua input divalidasi”, “error handling mencakup timeout dan duplicate entry”, “response time di bawah 200ms”. Acceptance criteria mengubah output AI dari “terlihat benar” menjadi “terverifikasi benar”.
Kedelapan, verification plan. Verification plan menjelaskan bagaimana acceptance criteria akan diuji. Apakah dengan unit test, integration test, manual review, atau staging deployment? Verification plan membuat proses penilaian menjadi eksplisit. Arsitek tidak perlu menebak-nebak apakah output sudah benar, karena cara memverifikasinya sudah ditentukan sejak awal.
Kedelapan elemen ini membentuk satu kesatuan. Role dan context memberikan orientasi. Objective dan constraint memberikan arah. Scope dan boundary memberikan batas. Acceptance criteria dan verification plan memberikan standar penilaian.
Berikut contoh brief kerja lengkap untuk menambahkan fitur registrasi dengan validasi domain email.
Role: Senior Backend Engineer
Context: Aplikasi SaaS production, database PostgreSQL, user sudah login via Google OAuth
Objective: User bisa registrasi dengan email perusahaan (domain @company.com) dalam < 3 detik
Constraint: Wajib pakai Express.js v4, JWT untuk session, email unik
Scope: Satu endpoint POST /register + validasi domain + error handling + logging
Boundary: Jangan ubah schema tabel users yang sudah ada, jangan sentuh modul auth Google
Acceptance Criteria:
- Email domain @company.com diterima, domain lain ditolak
- Response sukses mengembalikan token JWT
- Response time < 200ms
- Error handling untuk duplicate email dan invalid domain
Verification Plan:
- Unit test untuk validasi domain
- Integration test untuk endpoint /register
- Staging deploy dengan data dummy
Dengan template seperti ini, arsitek cukup mengisi bagian yang berubah setiap tugas, tanpa perlu menulis ulang delapan elemen dari nol.
Berikut diagram alir yang merangkum kedelapan elemen beserta contoh singkatnya.
Seorang arsitek tidak perlu menulis delapan elemen ini setiap kali ingin bertanya ke AI. Cukup menyusun template yang bisa dipakai berulang, lalu mengisi bagian yang berubah sesuai tugas. Yang penting adalah kebiasaan untuk tidak pernah memberikan instruksi ke AI tanpa setidaknya role, objective, dan boundary. Tiga elemen itu sudah cukup mencegah sebagian besar kesalahan.
Setelah brief kerja tersusun, pertanyaan berikutnya adalah: bagian mana dari brief ini yang boleh dikerjakan AI sepenuhnya, dan bagian mana yang harus melewati review manusia? Bagian berikutnya bergerak ke persoalan tersebut.
