Wira Delta Indonesia

Why WDI Method

Why WDI Method: AiDD vs. Vibe Coding

Why a framework is needed when AI agents write the code, and how five human review gates hold a change until a person has checked the decision behind it.

AI-Driven Development (AiDD) vs. Vibe Coding

Vibe coding also uses specifications, but not consistently: each prompt session can differ, the documents are unstructured, and the process is not kept systematic. The result is much lower efficiency and effectiveness, and a real risk of accumulating technical debt. That is why a framework is needed.

Without a Framework 1

Each Session Starts Over

A new prompt session can read the same request differently. A decision made last week is not in front of the agent unless someone writes it down where the agent reads.

Without a Framework 2

Unstructured Documents

Notes, chat logs, and loose specs do not say which promise a piece of code serves, so nobody can check whether a change still keeps it.

Without a Framework 3

False Completion Reports

An agent can report the tests as passing without having edited a file. Only a check against the files and the test run shows what really changed.

How AiDD Runs in WDI Method

In WDI Method, AI agents do not decide the architecture on the fly. They work inside specifications a person has already approved at the gates.

The core idea can be stated simply: Prompting harder does not create accountability. An engineering delivery system does.

The Order of Work:

Promises registered as FR and use cases, then the gates, then the spec cut into tickets with to-spec and to-tickets, then each ticket built test-first, then one PR the owner reviews and merges.

How the Gates Hold a Change

WDI Method works on the principle of One Decision Per Gate. Each gate decides one thing. At G1 to G4 you read one rendered page; at G5 you read the spec's RTM rows. You answer a short checklist, and one "no" on a starred question holds the gate.

  • G1 Problem: What the problem is, whose it is, and why it earns work.
  • G2 Product: What is built, and how it feels to use.
  • G3 Blueprint: The whole picture of the product, once per product.
  • G4 Component: How one component is built (skipped at mode: catalog).
  • G5 Release: Whether it is done and proven.

The rule behind the starred questions is Refine, Do Not Advance: one "no" on a starred (★) checklist question holds the gate. Refine the document and run the gate again; do not approve it with the plan to fix it later. Re-running a gate is cheap compared with fixing the defect after code exists.

Open and Inspectable

WDI Method is released under the MIT License and installed directly into product repositories. Its skills, guides, and validators are plain files in your repository, so you can read every rule the agent follows.

We use the same method on client projects. Contact our team.