17.8 Template AI Working Brief dan Checklist Evidence

Setelah membaca tujuh subbab sebelumnya, Anda mungkin merasa: ini semua masuk akal, tapi bagaimana cara memulainya? Saya perlu sesuatu yang bisa saya buka setiap kali akan meminta AI bekerja. Sesuatu yang mencegah saya kembali ke kebiasaan lama mengetik prompt pendek dan berharap yang terbaik.

Subbab ini memberikan dua alat kerja yang bisa langsung Anda pakai. Bukan teori, bukan konsep. Tapi template dan checklist yang bisa Anda cetak, tempel di dinding, atau buka sebagai tab pertama di browser saat bekerja dengan AI.

Template AI Working Brief

Template ini diisi sebelum Anda memberikan instruksi ke AI. Fungsinya satu: memastikan Anda sudah berpikir seperti arsitek sebelum meminta AI bekerja. Bukan setelah output keluar.

Berikut contoh pengisian template dalam format YAML yang bisa langsung Anda gunakan:

role: backend-engineer
context: project payment-service, hexagonal architecture, Java 21
objective: tambahkan audit trail untuk semua mutation endpoint di modul payment
scope:
  allowed:
    - file di package payment/*
  forbidden:
    - konfigurasi database
    - security filter
    - endpoint user
constraint:
  - gunakan library yang sudah ada di project
  - jangan tambahkan dependency baru tanpa persetujuan
  - semua method harus punya unit test coverage minimal 80%
acceptanceCriteria:
  - semua mutation endpoint punya log format JSON
  - log mencakup timestamp, user ID, action, old value
verificationPlan:
  - unit test untuk setiap method baru
  - integration test untuk satu skenario end-to-end
  - hasil compile clean

Template ini memiliki enam bagian:

  1. Role dan Context – Siapa AI saat bekerja? Sebagai apa? Dalam konteks project apa? Contoh: “Anda adalah backend engineer yang bekerja di project payment service. Arsitektur saat ini menggunakan hexagonal architecture dengan Java 21.”

  2. Objective – Apa yang ingin dicapai? Satu kalimat jelas. Bukan “buatkan fitur logging”, tapi “tambahkan audit trail untuk semua mutation endpoint di modul payment.”

  3. Scope dan Boundary – Apa yang boleh diubah? Apa yang tidak boleh disentuh? Ini area yang paling sering dilanggar. Tulis eksplisit: “Hanya ubah file di package payment. Jangan sentuh konfigurasi database, security filter, atau endpoint user.”

  4. Constraint – Batasan teknis yang harus dipatuhi. Contoh: “Gunakan library yang sudah ada di project. Jangan tambahkan dependency baru tanpa persetujuan.” Atau “Semua method harus punya unit test dengan coverage minimal 80%.”

  5. Acceptance Criteria – Bagaimana saya tahu output ini selesai? Bukan “kodenya rapi”, tapi “semua mutation endpoint punya log dengan format JSON yang mencakup timestamp, user ID, action, dan old value.”

  6. Verification Plan – Evidence apa yang harus disertakan? Ini jembatan ke checklist evidence. Contoh: “Sertakan unit test untuk setiap method baru, integration test untuk satu skenario end-to-end, dan hasil compile yang clean.”

Checklist Evidence

Checklist ini digunakan saat mereview output AI. Jangan review berdasarkan “apakah kodenya terlihat rapi.” Review berdasarkan evidence.

Checklist evidence memiliki empat fase sesuai siklus yang sudah dibahas di subbab 17.7:

Fase Sebelum Merge:

  • Apakah semua acceptance criteria terpenuhi?
  • Apakah unit test berjalan hijau?
  • Apakah tidak ada perubahan di luar boundary?
  • Apakah tidak ada asumsi tersembunyi yang perlu diverifikasi?

Fase Sebelum Release:

  • Apakah integration test dengan sistem nyata berhasil?
  • Apakah security scan untuk perubahan ini clean?
  • Apakah konfigurasi yang berubah sudah diverifikasi dampaknya?

Fase Setelah Release:

  • Apakah metrik error rate tidak naik?
  • Apakah log menunjukkan perilaku yang diharapkan?
  • Apakah ada anomaly yang perlu diinvestigasi?

Fase Setelah Alur Pengetahuan:

  • Apakah output knowledge assistant sesuai dengan sumber yang diharapkan?
  • Apakah pengguna bisa menemukan informasi yang mereka butuhkan?
  • Apakah ada feedback yang menunjukkan kesalahan informasi?

Cara Memakai Kedua Alat Ini

Jangan mencoba mengisi semua bagian template sekaligus di awal. Mulai dari objective dan boundary. Dua bagian ini yang paling sering membedakan output berguna dari output berbahaya. Setelah terbiasa, tambahkan acceptance criteria. Setelah itu, verification plan.

Checklist evidence bisa Anda gunakan sebagai daftar periksa saat review pull request. Tempel di samping layar. Setiap kali Anda melihat output AI yang terlihat rapi, tahan diri untuk langsung approve. Buka checklist. Jalankan satu per satu.

Dua alat ini adalah output konkret dari seluruh bab ini. Bukan sekadar dibaca, tapi dipakai. Setiap kali Anda membuka AI assistant, buka template ini. Setiap kali Anda selesai mereview, tandai checklist ini. Dalam beberapa minggu, kebiasaan ini akan menjadi otomatis. Anda tidak lagi berpikir seperti programmer yang mencari jawaban cepat. Anda berpikir seperti arsitek yang memastikan setiap output punya fondasi yang jelas.

Bab selanjutnya akan membawa pola pikir ini ke level organisasi. Jika satu arsitek bisa bekerja dengan template dan checklist, bagaimana jika seluruh tim, seluruh departemen, atau seluruh perusahaan menerapkan pola yang sama?