No. Waterfall is linear: you finish one phase entirely before starting the next, and you never go back. PUDO is explicitly cyclical and iterative — you are expected to loop back to earlier phases when you discover new information. The phases are a compass, not a cage.
Yes. The 4 phases (Plan, Understand, Develop, Optimize) are universal good practices. However, PUDO is optimized for AI-assisted workflows because:
Different levels of abstraction:
| Agile/Scrum | PUDO | |
|---|---|---|
| Scope | Team process | Individual task |
| Unit of work | Sprint (1–4 weeks) | Single task (minutes–days) |
| Focus | Project management | Coding methodology |
| Artifacts | User stories, backlogs | Plans, walkthroughs, prompts |
They’re complementary. You can use PUDO inside each Agile task.
No. Scale the depth to the task:
The goal is intention, not bureaucracy.
A good prompt is one output. PUDO is the system that produces good prompts and validates their output. The difference is the same as between “writing good code once” and “having a code review process.” PUDO adds structure, quality gates, and measurement on top of the prompt itself.
There is one published measured case study in benchmarks/results/stripe-webhook-2026-05 showing reduced AI turns and token waste for a Stripe webhook integration task. The directional targets in the README (34% token waste reduction, 18% dev time reduction) are aspirational targets, not statistically validated benchmarks. More case studies are in progress.
Go back to Plan. This is the system working correctly. PUDO’s value is in making these pivots explicit — you consciously decide to re-plan rather than patching around a flawed approach.
There’s no fixed ratio. It depends on the task:
| Task Type | Plan | Understand | Develop | Optimize |
|---|---|---|---|---|
| Greenfield feature | 20% | 10% | 50% | 20% |
| Legacy codebase change | 10% | 40% | 30% | 20% |
| Production bug fix | 10% | 40% | 30% | 20% |
| Refactoring | 15% | 25% | 30% | 30% |
Yes, for independent tasks. For complex features, you’ll often run nested PUDO cycles — one for the overall feature, and mini-cycles for each component. See the scaling section in the workflow doc.
A failed gate is not a failure of the process — it’s the process working. When a gate fails:
.pudo/session.mdUse PUDO Enterprise mode and weight the Understand phase heavily:
PUDO is model-agnostic. It works with:
The methodology is about how you interact with AI, not which AI you use.
The prompt library provides starting points. You should:
Absolutely. You might use:
PUDO structures your workflow, not your toolchain.
This is the most common source of scope creep in AI-assisted development. Fixes:
pudo score --strict — Failing the score check forces a scope review before mergeThat’s it. You’ve done your first PUDO cycle. See Getting Started for a full walkthrough.
This is the most common struggle. Try this: make your AI assistant create the plan. Open your AI tool and say:
Before I write any code, help me plan this task:
[describe the task]
Create an implementation plan with:
- Scope and constraints
- Key technical decisions
- Risks and unknowns
- Success criteria
Let the AI do the work of planning — you just review and approve. This takes 2 minutes and saves 20.
Start with one person and one task. Measure the outcome (turns, tokens, bugs found in review). Share the result with the team. Then use the Team Adoption Guide for a structured rollout.
Trying to mandate methodology top-down without evidence rarely works. One concrete case study from inside your own codebase is more convincing than any external benchmark.
The MCP server (packages/pudo-mcp-server) exposes PUDO operations as callable tools via the Model Context Protocol. Compatible agents (like Claude with MCP support) can call pudo.scoreRepoReadiness, pudo.runQualityGate, and other tools directly without the developer needing to run CLI commands manually.
Not yet. It is labeled 0.1.0-alpha.1. The alpha version uses local stdio transport only — no network exposure. Remote transport (HTTP + authentication) is planned for v1.4. It is suitable for local development use; do not expose it as a networked service with the current version.
See docs/mcp.md for full setup instructions.
Quick start:
npx @dongduong2001/mcp-server@alpha
See CONTRIBUTING.md for the full process, including the required template format and testing expectations.
See CONTRIBUTING.md for the template and submission process. Measured case studies from real codebases are the highest-value contributions to the project.
See SECURITY.md for the responsible disclosure process. Do not open a public issue.