User Story dan Acceptance Criteria untuk AI Coding: Bikin Output Agent Bisa Dicek

Kamu tulis "bikin aplikasi kasir" ke Cursor atau Claude Code, agent-nya jalan, keluar kode yang kelihatan rapi. Tapi pas dicoba, alurnya bukan yang kamu bayangkan. Diskon kelewat, stok nggak kepotong, laporan harian kosong. Masalahnya bukan agent-nya bodoh, tapi kamu nggak pernah kasih tahu bentuk "selesai" itu seperti apa.

User story dan acceptance criteria adalah dua bagian PRD yang tugasnya persis itu: menerjemahkan ide jadi kalimat yang bisa dicek benar-salahnya. Tanpa keduanya, kamu dan AI cuma saling nebak maksud, dan kamu baru sadar tebakannya meleset setelah kodenya terlanjur jadi.

Kenapa AI coding butuh cerita yang bisa dicek

AI coding agent jago menebak pola, tapi dia nggak bisa membaca pikiranmu. Kalau instruksinya sependek "bikin fitur checkout", agent akan mengarang detail sendiri: metode bayar apa, validasi apa, apa yang terjadi kalau stok habis. Sebagian karangannya kebetulan benar, sebagian nggak. Yang berbahaya adalah kode yang salah tetap kelihatan meyakinkan, jadi kamu nggak punya pegangan buat bilang "ini keliru".

User story menaruh maksudmu di depan sebelum satu baris kode ditulis, dan acceptance criteria menaruh alat ukurnya. Ini juga inti dari menjelaskan ide aplikasi ke AI: kamu bukan sekadar cerita mau apa, tapi kasih cara memverifikasi hasilnya.

Format user story: sebagai X, ingin Y, agar Z

Satu user story adalah satu kalimat dengan tiga bagian. Bukan spesifikasi teknis, tapi kebutuhan dari sudut pandang orang yang pakai:

• Sebagai X = perannya siapa (kasir, admin, pelanggan, pemilik toko).
• Ingin Y = kemampuan konkret yang dia butuhkan (menyimpan transaksi, melihat stok, ekspor laporan).
• Agar Z = alasan atau nilai di baliknya (biar laporan otomatis, biar nggak salah hitung).

Bagian "agar Z" paling sering dilewat, padahal itu yang paling penting buat AI. Z memberi agent konteks keputusan: kalau dia harus memilih antara dua cara implementasi, dia tahu mana yang mendukung tujuanmu dan mana yang boleh dikorbankan. Story tanpa Z memaksa agent menebak prioritas.

User Story:
Sebagai kasir, saya ingin menyimpan transaksi penjualan,
agar stok dan laporan harian otomatis ter-update.

Acceptance Criteria:
- Saat kasir menekan "Simpan", satu baris baru muncul di tab
  Transaksi berisi tanggal, produk, qty, dan total.
- Stok produk di tab Produk berkurang sesuai qty.
- Kalau qty melebihi stok tersedia, transaksi ditolak dan
  muncul pesan "Stok tidak cukup".
- Total dihitung otomatis (harga x qty), kasir tidak input manual.

Yang bikin story lemah vs kuat

• Lemah: "Bikin halaman transaksi." Nggak ada peran, nggak ada tujuan, agent bebas mengarang.
• Lemah: "Sebagai kasir ingin sistem yang bagus." Y-nya nggak terukur, "bagus" itu rasa.
• Kuat: "Sebagai kasir, ingin menyimpan transaksi dalam satu klik, agar antrean nggak menumpuk saat ramai." Peran jelas, kemampuan konkret, alasan yang memandu keputusan teknis.

Acceptance criteria: ukuran "selesai" yang bisa dicek

Kalau story menjawab "apa dan kenapa", acceptance criteria menjawab "gimana saya tahu ini beres". Bentuk paling praktis adalah daftar kondisi konkret, atau pola Given/When/Then: dalam kondisi tertentu, saat aksi dilakukan, maka hasil yang pasti terjadi.

Ciri kriteria yang terukur

• Punya hasil yang bisa diamati, bukan kata sifat. "Hasil muncul di bawah 3 detik", bukan "harus cepat".
• Menyebut kondisi batas. Apa yang terjadi kalau input kosong, kalau stok habis, kalau angka minus.
• Satu kriteria menguji satu hal. Kalau satu baris mengandung "dan" beruntun, pecah jadi beberapa baris.
• Bisa diperagakan. Kamu bisa buka app, lakukan langkahnya, lalu tunjuk hasilnya cocok atau nggak.

Kenapa ini bikin output AI bisa dicek

Begitu kriterianya terukur, tiap baris berubah jadi alat verifikasi otomatis dalam kepalamu:

• Tiap baris kriteria langsung jadi langkah tes manual: buka app, lakukan aksi, cek hasil. Nggak perlu mikir ulang cara ngetesnya.
• Kriteria yang sama bisa kamu tempel balik ke agent sebagai checklist: "cek kodemu terhadap 4 kriteria ini, laporkan yang belum kepenuhan." Banyak agent sekarang bisa self-check begini sebelum bilang selesai.
• Kamu punya dasar objektif buat menolak. Bukan "kok rasanya beda", tapi "baris ke-3 belum jalan, qty di atas stok masih lolos."
• Kalau nanti mau nambah tes otomatis, kriteria ini sudah jadi kerangka test case-nya.

Ini bedanya PRD yang beneran kepakai sama coretan ide. Cara merakit semuanya jadi satu dokumen ada di panduan membuat PRD untuk aplikasi.

Contoh nyata: rangkai ke aplikasi Google Apps Script

Story dan kriteria yang terukur bukan cuma memandu logika, tapi juga bikin batasan teknis jadi eksplisit. Ambil kriteria "satu baris baru muncul di tab Transaksi". Buat AI yang menggarap aplikasi Google Apps Script, kriteria itu langsung menerjemahkan diri jadi keputusan implementasi yang benar:

// Server (Code.gs) - dipanggil dari client lewat google.script.run
function simpanTransaksi(item) {
  const lock = LockService.getScriptLock();
  lock.waitLock(30000); // cegah dua kasir nabrak baris yang sama
  try {
    const sheet = SpreadsheetApp.getActive().getSheetByName('Transaksi');
    const baris = [[new Date(), item.produk, item.qty, item.total]];
    // tulis borongan pakai setValues, bukan setValue per sel
    const mulai = sheet.getLastRow() + 1;
    sheet.getRange(mulai, 1, baris.length, baris[0].length).setValues(baris);
    return { ok: true };
  } finally {
    lock.releaseLock();
  }
}

Kriteria "satu baris berisi tanggal, produk, qty, total" memaksa fungsi ini menulis persis empat kolom, dan kriteria "transaksi ditolak kalau qty lebih dari stok" memberi tahu agent bahwa masih ada validasi yang harus ditambah sebelum penulisan. Detail seperti pakai pola baca-tulis borongan getValues/setValues, bungkus dengan LockService, dan panggil dari client lewat google.script.run (bukan fetch) memang urusan agent, tapi kriteriamu yang menentukan kapan itu dianggap benar.

Kalau kamu bikin aplikasi berbasis Spreadsheet, mode Web GAS di Skematik menyusun story dan kriteria ini jadi PRD lengkap dengan skema tab, daftar fungsi server, dan konvensi sadar-batasan GAS, siap kamu serahkan ke agent.

Kesalahan umum yang bikin kriteria nggak kepakai

• Kriteria rasa, bukan ukuran. "Harus gampang dipakai" nggak bisa dicek. Ganti jadi "kasir bisa simpan transaksi tanpa pindah halaman".
• User story tanpa Z. Tanpa alasan, agent nggak tahu mana bagian yang boleh dikompromikan saat ada tabrakan.
• Nyampur solusi teknis ke dalam story. Story soal kebutuhan ("ingin cari produk cepat"), bukan cara ("pakai dropdown dengan autocomplete"). Biar cara-nya jadi urusan agent, kamu yang pegang hasilnya.
• Story kegedean. "Sebagai pemilik toko ingin sistem lengkap" itu proyek, bukan story. Pecah jadi story-story kecil yang tiap satunya punya kriteria sendiri.
• Kriteria tanpa "maka X". Kalau satu baris nggak berujung ke hasil yang bisa dilihat, dia nggak akan pernah bisa dinyatakan lulus.

Aturannya sederhana: kalau kamu nggak bisa membayangkan cara menguji sebuah baris dalam 10 detik, baris itu belum layak diserahkan ke AI. Perbaiki dulu di dokumen, sebelum agent menerjemahkannya jadi kode yang salah dengan percaya diri.