Can a PDCA Framework Unlock AI Code Generation’s Full Potential?

Problem Statement

Recent surveys (Google DORA DevOps 2024, GitClear 2024) show that increasing AI‑assisted coding correlates with lower deployment stability, a ten‑fold rise in duplicate code, and a defect rate around 17 %.

Why a Structured PDCA Loop Is Needed

AI code generators lack mature usage patterns. Embedding developer expertise through a repeatable Plan‑Do‑Check‑Act (PDCA) workflow forces testability, incremental commits, and alignment with existing code bases.

PDCA Framework Overview

Working Agreements : A one‑minute commitment to quality standards (small commits, low coupling, no duplication).

Planning Analysis : AI reviews business goals, existing patterns, and feasible solutions (2‑10 min).

Task Breakdown : AI produces a step‑by‑step, testable plan (≈2 min).

Do : Test‑driven development (TDD) with AI writing code, explaining reasoning, limited to ≤3 h.

Check : AI audits code, documentation, and README against the original goals (≈5 min).

Act : A brief retrospective (2‑10 min) to refine prompts and collaboration.

Working Agreements – Human Responsibility

Developers retain control by committing small, incremental changes, avoiding large‑scale coupling, and enforcing TDD through prompts.

Experimental Comparison

Two experiments were run in the Cursor IDE using Anthropic models: a structured PDCA workflow versus an unstructured workflow. The same development story (adding a flexible tracer implementation) was used for both.

Token Consumption

Unstructured workflow total tokens: 1,485,984
  • Code writing: 264,767
  • Issue investigation: 1,221,217

PDCA workflow total tokens: 1,331,638
  • Analysis: 106,587
  • Detailed plan: 20,068
  • Do (implementation): 1,191,521
  • Check: 6,079
  • Act (retrospective): 7,383

Code Output Metrics

Metric                     | Unstructured | PDCA
---------------------------|--------------|------
Production code lines      | 534          | 350
Test code lines            | 759          | 984
Methods implemented        | 16           | 9
New classes                | 1            | 1
Files changed              | 5            | 14

The PDCA approach produced fewer production lines, more test lines, and a higher number of changed files, indicating finer‑grained, test‑first commits.

Qualitative Developer Experience

Developers reported a smoother experience with PDCA because interaction is distributed throughout planning and coding, whereas the unstructured approach concentrates most communication in a final debugging phase.

Prompt Templates (Illustrative)

Analysis Pre‑conditions Identify 2‑3 similar implementations in the code base. Record existing architecture layers (namespaces, interfaces). Map integration touch points (methods to modify). List reusable abstractions (FileProvider, base classes).

Planning Phase Prompt Based on the analysis, produce a clear, executable plan for test‑driven implementation.

TDD Implementation Rules Do not test interfaces; test concrete implementations. Compilation errors do not count as a red test; a failing behavior does. Create stub code that compiles but fails the test. Prefer real components over mocks when possible.

Check Phase Checklist All tests pass. Manual tests completed. Documentation updated. No regression issues. No outstanding TODOs.

Act (Retrospective) Prompt Identify 2‑3 critical moments that affected success or failure. Determine which decisions or interventions were pivotal. Highlight patterns that improved efficiency. Suggest faster ways to proceed.

Success Metrics Monitored via GitHub Automation

Large commit rate (>100 lines) – target <20 %.

Diffused commit rate (changes >5 files) – target <10 %.

Test‑first rate (simultaneous test and code changes) – target >50 %.

Average files changed per PR – target <5.

Average lines changed per PR – target <100.

Configuration for these metrics is stored in a public GitHub repository.

Further Development Directions

Match Process Rigor to Task Complexity : For low‑risk changes, simplify analysis and planning while retaining full PDCA for high‑impact work.

Dynamic Model Selection : Use stronger models (e.g., Anthropic Claude Sonnet) for analysis/planning and cheaper models (e.g., Claude Haiku) for implementation when the context is well‑defined.

Conclusion

AI‑generated code alone does not deliver promised productivity gains due to quality degradation and integration overhead. Applying a disciplined PDCA workflow restores code quality, reduces post‑implementation debugging effort, and improves developer experience, making human‑in‑the‑loop AI coding sustainable at scale.