AI Coding: Mental Models: Plan > Implement > Validate

The PIV Loop for AI Coding Agent Development

The PIV loop is a useful mental model for building software with AI coding agents.

PIV = Plan → Implement → Validate

The core idea is that you don't simply tell an AI agent:

"Build this feature."

Instead, you deliberately put planning and validation around the agent's coding work.

The approach is particularly useful for modern coding agents such as Codex, Claude Code, Cursor agents, Gemini CLI, and similar tools.

The Basic Loop

The important distinction is who owns each stage:

• Human: primarily owns what should be built and whether it is actually correct.
• AI agent: primarily owns how to implement it.
• Automated validation: provides objective feedback to both the agent and human.

The loop is generally repeated for relatively small units of work, such as a Jira ticket, GitHub issue, or feature slice.

1. Plan

Planning is arguably the most important part.

Instead of giving an agent a vague instruction such as:

"Add authentication to my API."

You first ask it to investigate the repository and produce a concrete implementation plan.

An example from one of my projects:

Task: Add Clerk authentication to Translation API
 
Requirements:
- Validate JWT bearer tokens
- Require authentication on POST /translations
- Extract user ID from claims
- Associate TranslationAttempt with user
- Return 401 for missing/invalid token
 
Existing architecture:
- ASP.NET Core Minimal API
- Clean Architecture
- EF Core
- PostgreSQL
 
Files likely affected:
- Program.cs
- Authentication extensions
- TranslationEndpoint.cs
- TranslationAttempt entity
- EF configuration
 
Implementation approach:
1. Configure JWT bearer authentication
2. Add authorization policy
3. Add authenticated endpoint
4. Extract subject claim
5. Persist user ID
6. Add integration tests
 
Validation:
- Unit tests
- Integration test with valid JWT
- Integration test with invalid JWT
- Integration test with missing JWT
- dotnet test

The plan becomes a persistent artefact, rather than relying entirely on the conversation history.

This is particularly useful because the implementation can happen in a fresh agent session with the plan as its context.

Why Planning Matters

AI coding agents are generally very capable once they understand:

• What the objective is
• What constraints exist
• How the existing code works
• What "done" means

They're much less reliable when they're simultaneously trying to discover all of those things while writing the code.

2. Implement

Once the plan has been agreed upon, give it to the coding agent.

The agent performs most of the actual implementation:

Read plan
   ↓
Inspect relevant files
   ↓
Implement task 1
   ↓
Run tests
   ↓
Implement task 2
   ↓
Run tests
   ↓
...

This is where tools such as Codex, Claude Code, Cursor agents, and Gemini CLI become particularly powerful.

The important PIV principle is:

Don't continuously micromanage the implementation.

You've already established the desired outcome during planning.

The agent can then:

• Inspect the repository
• Edit multiple files
• Run commands
• Run tests
• Inspect errors
• Correct mistakes
• Continue implementing

This allows you to delegate a much larger amount of work.

3. Validate

Validation is what prevents PIV from degenerating into "vibe coding."

The agent shouldn't simply report:

"Done! Everything looks good."

You want evidence.

For example:

Validation
──────────
✓ dotnet build
✓ 43 unit tests
✓ 8 integration tests
✓ Authentication test
✓ Unauthorized request test
✓ Existing API tests
✓ EF migration generated
✓ API manually tested

For a frontend task:

✓ TypeScript compilation
✓ ESLint
✓ Unit tests
✓ Playwright E2E
✓ Desktop browser check
✓ Mobile browser check
✓ Screenshot inspected

Validation doesn't necessarily have to be automated.

You can also ask a second agent to review the implementation against the original plan:

Reviewer agent
 
Input:
- Requirements
- Implementation plan
- Git diff
- Tests
 
Question:
 
Does the implementation actually satisfy the requirements?

This is a powerful pattern because the implementation agent and reviewing agent have different jobs.

The Outer Loop

The interesting aspect of PIV is what happens when validation discovers a problem.

Suppose the agent introduces a bug.

You fix the bug.

But instead of simply moving on, ask:

Why did our AI development process allow this bug to happen?

For example:

Agent forgot to validate authorization
            ↓
Fix the code
            ↓
Why did agent miss it?
            ↓
Planning template doesn't mention security
            ↓
Improve planning process
            ↓
Future agents automatically consider authorization

This creates a second feedback loop:

Your AI development environment effectively becomes another part of your engineering system.

You can continually improve:

• Agent instructions
• Skills
• Planning templates
• Validation scripts
• Coding standards
• Architecture documentation
• Testing requirements
• Repository context

Why PIV Is Useful

1. It Addresses the Biggest Weakness of Coding Agents

The problem generally isn't:

"AI can't write C#."

Modern coding agents can write a huge amount of C#.

The bigger problem is:

How do I know the agent built the right thing?

PIV directly addresses that problem.

2. It Reduces Context Drift

A long-running agent conversation can look like:

User request
    ↓
50 tool calls
    ↓
20 file changes
    ↓
Multiple corrections
    ↓
Agent starts forgetting original constraints

A persistent plan.md provides an anchor:

Requirements
     ↓
plan.md
     ↓
Fresh implementation session
     ↓
Implementation

This also makes it easier to hand work between agents or sessions.

3. It Makes Agents More Autonomous

Paradoxically, more structure can give you more autonomy.

Without PIV:

"Stay there while I watch everything you do."

With PIV:

"Here's the plan and acceptance criteria. Implement it, run the validation, and tell me what failed."

The second approach allows the agent to operate much more independently.

4. It Fits Existing Development Workflows

PIV maps naturally onto an existing software development process:

Jira / GitHub ticket
        ↓
      Plan
        ↓
   Implementation
        ↓
      Tests
        ↓
     Review
        ↓
       PR
        ↓
      Merge

The PIV artefacts can live alongside the project rather than requiring an entirely new methodology.

Downsides

PIV isn't universally appropriate.

1. It's Slower for Trivial Tasks

For:

"Rename this variable."

A full PIV process is complete overkill!.

You don't want:

Research
   ↓
Plan
   ↓
Plan review
   ↓
Implementation
   ↓
Validation
   ↓
PR

for a 30-second change.

PIV works best when the unit of work is meaningful enough to justify planning.

2. Planning Can Become Bureaucratic

There's a danger of turning this:

Plan → Implement → Validate

into:

PRD
 ↓
Architecture document
 ↓
Technical design
 ↓
Implementation plan
 ↓
Task breakdown
 ↓
Review
 ↓
Implementation

before you've written one line of code.

At that point you've effectively recreated a heavyweight waterfall methodology.

The process should therefore remain proportional to the complexity and risk of the task.

3. The Agent Can Produce a Bad Plan

A beautifully formatted plan doesn't mean it's correct.

You can get:

Excellent Markdown
Excellent architecture diagram
Excellent task breakdown
 
        ↓
 
Based on a completely wrong
understanding of the codebase

Therefore, human judgement is still important during planning.

You shouldn't blindly approve an AI-generated architecture.

4. Validation Can Also Be Wrong

Passing tests doesn't necessarily mean the feature is correct.

For example:

Requirement:
Users cannot access another user's translations.
 
Tests:
✓ API returns 200
✓ Translation saved
✓ Authentication works
 
But:
 
❌ User A can request User B's translation

All the tests might pass while the security model is fundamentally wrong.

Therefore, validation should ideally have several layers.

Layer 1 — Automated

• Unit tests
• Integration tests
• E2E tests
• Type checking
• Linting
• Build
• Static analysis

Layer 2 — AI Review

Compare:

Requirements
     ↓
Implementation plan
     ↓
Git diff
     ↓
Tests

and ask another agent:

"Does this implementation actually satisfy the requirements?"

Layer 3 — Human Review

Human judgement is particularly important for:

• Architecture
• Business logic
• Security
• Data modelling
• Performance
• User experience
• Important trade-offs

5. More Agent Calls Can Mean More Cost

Planning, implementation, and validation can involve several model calls.

For small tasks, this can cost considerably more than simply asking:

"Fix this bug."

The solution is to scale the process according to the size and risk of the task.

A Practical Version of PIV

I wouldn't recommend making PIV a rigid process.

Instead, scale it according to the task.

This gives you the benefits without turning every coding task into a ceremony.

Recommended PIV Workflow for .NET / Next.js

For a modern stack such as:

• .NET
• ASP.NET Core
• EF Core
• PostgreSQL
• Next.js
• React
• TypeScript
• Authentication
• AI integrations

I'd use a slightly expanded workflow:

RESEARCH
    ↓
PLAN
    ↓
HUMAN APPROVAL
    ↓
IMPLEMENT
    ↓
AUTOMATED VALIDATION
    ↓
AI CODE REVIEW
    ↓
HUMAN REVIEW
    ↓
PR

Example

Suppose the ticket is:

Persist translation attempts

Research

The agent investigates:

• Existing translation flow
• API endpoints
• EF Core models
• Database configuration
• Existing tests
• Authentication
• Existing error handling

Plan

The agent produces a plan covering:

• Entity
• Database relationship
• Migration
• API changes
• Validation
• Tests

Human Approval

You quickly review the plan:

✓ Architecture makes sense
✓ Correct entities
✓ Correct relationship
✓ Tests cover expected behaviour
✓ No unnecessary changes

Then approve it.

Implement

The agent:

Creates entity
      ↓
Updates EF configuration
      ↓
Creates migration
      ↓
Updates service
      ↓
Updates API
      ↓
Creates tests
      ↓
Runs tests

Validate

The agent runs:

dotnet build
dotnet test
integration tests
linting
static analysis

Then an independent review agent examines the diff.

PR

Finally:

Implementation
     +
Tests
     +
Validation
     +
AI review
     ↓
    PR

That's a much more powerful way of thinking about AI-assisted software development.

Summary

PIV is essentially a feedback-controlled software development loop for AI agents.

The agent gets freedom over implementation, while the development process provides constraints around intent and correctness.

For serious software projects, that's considerably more robust than simply asking an agent to "build the feature" and reviewing whatever it produces afterwards.