Lima Agent, Lima Dokumen: Cara Kami Pakai AI Buat Bikin Software Pembayaran di DOKU

Tanggal 23 September kemarin gw dapat kesempatan ngisi Kelas Beta jalur Hacker dari Sekolah Beta, di Garuda Spark Innovation Hub Jakarta. Temanya How to Design AI Systems for Digital Payments.

Yang datang kebanyakan backend dev. Rata-rata udah pernah integrasi payment gateway, jadi VA, QRIS, webhook, settlement itu udah makanan sehari-hari. Kelasnya jam tujuh malam, habis mereka seharian kerja. Dan jujur aja, kata “AI” yang ditempel ke “payment” pasti udah sering banget mereka dengar.

Karena itu gw nggak mau buka pakai demo yang wah. Gw buka pakai peta sederhana. AI bisa masuk ke sistem pembayaran lewat tiga jalan: ikut membangun sistemnya, ikut menjalankan sistemnya, atau ikut memutuskan di tengah alur transaksi. Tiap jalan butuh pengaman yang beda.

Tulisan ini bahas jalan pertama. Di sini AI cuma pegang dokumen dan kode, belum pegang uang. Paling apes ya hasilnya jelek, dan buat hasil yang jelek kita udah punya obatnya dari dulu: review.

Agent-nya dibagi per peran

Pipeline yang kami pakai di internal DOKU jalan di Claude Code. Yang bikin beda, pembagiannya ngikutin peran yang emang udah ada di tim, bukan ngikutin kemampuan model.

• PO jalanin /new-feature, keluarnya functional-spec.md.
• Solution Architect jalanin /tech-design, keluarnya design.md sama openapi.yml.
• Tech Lead jalanin /impl-plan, barengan sama QA yang jalanin /test-plan.
• Baru terakhir developer jalanin /implementation. Kode baru ditulis di sini.

Coba lihat apa yang keluar dari tiap tahap. Semuanya dokumen. Bisa dibaca, bisa didebat, bisa di-diff, dan semuanya masuk git bareng kodenya. Jadi pas agent implementasi mulai kerja, dia nggak cuma pegang tiket satu paragraf. Dia pegang spec, desain, kontrak API, sama rencana tes yang udah disetujui empat orang.

Menurut gw ini yang paling sering di-skip tim yang ngaku “udah pakai AI”. Tiap engineer dikasih asisten, terus masing-masing nge-prompt dari tiket langsung jadi pull request. Cepat sih, nggak bohong. Masalahnya, keputusan yang dulu ditulis jelas (fitur ini buat apa, kenapa pilih desain A, kasus gagal apa aja yang wajib dites) sekarang cuma ada di history chat. Dan history chat itu nggak bakal dibuka siapa-siapa lagi.

Tiap tahap berhenti di orang

Polanya sama di kelima tahap. Agent bikin dokumen, reviewer AI ngecek dokumen itu dibandingin sama dokumen tahap sebelumnya, terus orang yang mutusin: lanjut atau balik. Approval orangnya wajib, nggak ada jalur pintas.

Contoh kecil biar kebayang. Reviewer di tahap tech-design ngecek apakah tiap acceptance criteria di functional spec ada pasangannya di desain. Misal PO nulis “merchant nggak boleh ketagih dua kali buat invoice yang sama”, tapi di design.md nggak ada idempotency key sama sekali. Ketahuan deh, padahal kodenya belum ada satu baris pun. Benerinnya cukup satu komentar. Coba kalau baru ketahuan di produksi: urusannya jadi insiden rekonsiliasi, plus minta maaf ke merchant.

Gw ngerti kalau ada yang bilang ini ribet. Satu fitur harus lewat lima dokumen dan lima approval. Engineer senior mungkin ngerasa lebih cepat ngerjain sendiri, dan buat perubahan kecil gw setuju. Fix satu baris ya ngapain lewat lima tahap. Tapi kalau udah nyentuh alur transaksi, gw mending bayar ribetnya di depan.

Yang jaga itu prosesnya

Ada satu hal yang mau gw tekankan: pipeline ini aman bukan karena modelnya pintar. Malah sebaliknya. Makin pintar modelnya, spec yang dia tulis makin meyakinkan, dan spec yang meyakinkan itu lebih susah di-review. Salahnya jadi lebih halus, lebih gampang lolos.

Yang beneran jaga itu dua hal. Tiap tahap berhenti di orang. Dan hasil tiap tahap disimpan sebagai file di git yang wajib dibaca tahap berikutnya.

Satu lagi yang ngebantu banget: CLAUDE.md di tiap repo. Isinya stack, konvensi, sama hal-hal yang nggak boleh dilakukan agent. Ditulis sekali, dibaca agent tiap kali jalan. Jauh lebih hemat daripada ngulang aturan yang sama di setiap prompt. Soal ini pernah gw tulis lebih panjang di Spec Sebelum Code.

Soal angka produktivitas

Di internal ada estimasi seberapa jauh pipeline ini lebih cepat dibanding cara manual. Angka itu sengaja nggak gw taruh di slide, dan nggak gw taruh di sini juga. Alasannya simpel: belum pernah diukur bener. Nggak ada sampelnya, nggak ada baseline-nya, dan “manual” itu sendiri maksudnya apa juga nggak jelas. Kalau gw pajang di depan ruangan isi backend dev, pasti langsung dibongkar pas sesi tanya jawab. Dan mereka berhak bongkar.

Yang berani gw klaim lebih sempit dari itu. Dokumennya ada, bisa di-review, dan keputusan yang dulu cuma nyangkut di kepala orang sekarang ada di git. Apakah bikin kami lebih cepat dalam jangka panjang? Gw belum tahu. Bisa jadi iya, bisa jadi cuma kerasa lebih rapi aja. Gw butuh data beberapa kuartal dulu sebelum berani ngomong.

Ongkosnya juga nyata. Bikin plus review satu functional spec bisa makan tiga sampai empat jam waktu PO. Di minggu yang lagi padat, nggak ada yang rela. Tapi buat fitur yang dekat ke uang, tetap kami jalanin.

Selanjutnya

Jalan pertama ini aman karena nggak ada satu bagian pun yang bisa mindahin uang. Di tulisan berikutnya kita masuk ke jalan kedua, saat agent manggil sistem pembayaran beneran, sekalian bahas MCP server DOKU itu sebenarnya dibikin buat apa. Tulisan ketiga ngebahas demo yang bisa langsung dicoba peserta dari HP malam itu.

---

Seri dari sesi Kelas Beta, 23 September 2026: 1 · AI-assisted development · 2 · MCP server DOKU itu buat apa · 3 · Kasir chat yang nggak boleh ngitung uang