Wira Delta Indonesia

Mengapa WDI Method

Mengapa WDI Method: AiDD vs. Vibe Coding

Mengapa sebuah framework dibutuhkan saat AI agent menulis kode, dan bagaimana lima gerbang review manusia menahan sebuah perubahan sampai keputusan di baliknya diperiksa orang.

AI-Driven Development (AiDD) vs. Vibe Coding

Vibe coding juga memakai spesifikasi, tetapi tidak konsisten: setiap sesi prompt bisa berbeda, dokumennya tidak terstruktur, dan prosesnya tidak dijaga tetap sistematis. Akibatnya efisiensi dan efektivitas jauh lebih rendah, dan ada risiko nyata menumpuk technical debt. Itulah alasan sebuah framework dibutuhkan.

Tanpa Framework 1

Setiap Sesi Mulai dari Awal

Sesi prompt yang baru bisa membaca permintaan yang sama dengan cara berbeda. Keputusan minggu lalu tidak sampai ke agent kecuali ada yang menuliskannya di tempat yang dibaca agent.

Tanpa Framework 2

Dokumen Tidak Terstruktur

Catatan, riwayat obrolan, dan spec yang tercecer tidak menyebut janji mana yang dilayani sebuah kode, jadi tidak ada yang bisa memeriksa apakah perubahan masih menepatinya.

Tanpa Framework 3

Laporan Selesai yang Keliru

Agent bisa melaporkan test lulus padahal tidak mengubah satu file pun. Hanya pemeriksaan terhadap file dan hasil test yang menunjukkan apa yang benar-benar berubah.

Cara AiDD Berjalan di WDI Method

Di WDI Method, AI agent tidak menentukan arsitektur secara mendadak. Agent bekerja di dalam spesifikasi yang sudah disetujui manusia di gerbang.

Gagasan intinya lugas: Sekadar memaksakan prompt (prompting harder) tidak menciptakan akuntabilitas. Disiplin delivery pengembangan software-lah yang mewujudkannya.

Urutan Kerja:

Janji dicatat sebagai FR dan use case, lalu gerbang, lalu spec dipotong menjadi tiket dengan to-spec dan to-tickets, lalu setiap tiket dibangun dengan test lebih dulu, lalu satu PR yang di-review dan di-merge pemilik.

Cara Gerbang Menahan Perubahan

WDI Method bekerja dengan prinsip Satu Keputusan per Gerbang. Setiap gerbang memutuskan satu hal. Di G1 sampai G4 Anda membaca satu halaman hasil render; di G5 Anda membaca baris RTM spec. Anda menjawab daftar periksa singkat, dan satu jawaban "tidak" pada pertanyaan bertanda bintang menahan gerbang.

  • G1 Problem: Apa masalahnya, milik siapa, dan mengapa layak dikerjakan.
  • G2 Product: Apa yang dibangun, dan bagaimana rasanya dipakai.
  • G3 Blueprint: Gambaran utuh produk, sekali per produk.
  • G4 Component: Bagaimana satu komponen dibangun (dilewati pada mode: catalog).
  • G5 Release: Apakah sudah selesai dan terbukti.

Aturan di balik pertanyaan bertanda bintang adalah Perbaiki, Jangan Lanjutkan: satu jawaban "tidak" pada pertanyaan daftar periksa bertanda bintang (★) menahan gerbang. Perbaiki dokumennya lalu jalankan gerbang lagi; jangan menyetujuinya dengan rencana memperbaikinya nanti. Mengulang gerbang jauh lebih murah daripada memperbaiki cacatnya sesudah kode jadi.

Terbuka untuk Diperiksa

WDI Method dirilis dengan Lisensi MIT dan dipasang langsung di dalam repositori produk. Skill, panduan, dan validatornya adalah file biasa di repositori Anda, jadi setiap aturan yang diikuti agent bisa Anda baca.

Kami memakai metode yang sama di proyek klien. Hubungi tim kami.