Skip to main content
Blitzy generates code from a reviewed plan, not from a blank branch. By the time a PR opens, the important decisions - scope, file coverage, approach - have already been approved in the Agent Action Plan. Your review starts there, not in the diff.
Jump to: AAP as Source of Truth | Dynamic Validation | Code-Level Review | Post-Review Actions

​
The Core Principle - Review Intent, Not Just Implementation

Traditional code review is reactive: a developer writes code, a reviewer reads the diff. At the scale Blitzy operates, that model breaks. The most important review work on a Blitzy project happens before a single line of code is generated. Blitzy produces reviewable artifacts before execution, and its review model is built on three layers - each catching different classes of issues at the lowest cost.

​
Layer 1 - The AAP as Source of Truth

The Agent Action Plan (AAP) is the authoritative specification Blitzy produces before code generation begins. It maps every task to specific files, functions, and change types in plain language a domain expert can evaluate. Blitzy does not improvise beyond the plan. A thoroughly reviewed AAP gives you confidence in the resulting code before you read a single line of it. Reviewing the AAP is, in practice, reviewing the code - at a fraction of the cost.
The AAP review is your highest-leverage gate. Issues caught here cost minutes to fix. The same issues caught in a diff cost hours.

​
Why the AAP Replaces Traditional Diff Review

​
What to Look for in an AAP Review

  • Correct system understanding - Does the plan reflect an accurate read of the existing system?
  • File coverage - Are the right files being modified? Are any files conspicuously absent?
  • Change sequence - Does the sequence of changes make sense given system dependencies?
  • Scope appropriateness - Is the scope appropriate, or has the plan over- or under-reached?
  • Business logic implications - Are there business logic implications the plan does not account for?
When your team invests in AAP review, code review becomes confirmation, not discovery. For detailed guidance, see Agent Action Plan Review.

​
Layer 2 - Dynamic Validation

Once the AAP is approved and code is generated, the question is not “does this code look right?” but “does this code work?” Dynamic validation answers that through automated signals, not human reading. Test suites, performance benchmarks, and CI pipelines become your second review layer. A thorough AAP review plus passing dynamic validation gives high confidence without a line-by-line diff review.

​
Validation Signals

​
CI/CD Pipeline Timing

CI/CD pipelines validate generated code through your existing workflows. When the pipeline runs determines how Blitzy uses the results. The most reliable path is Refine PR.
When your pipeline triggers on each commit push to the Blitzy branch, results feed back into the generation cycle. Blitzy reads the pipeline output, identifies failures, and attempts to self-correct before the job ends.Configure this path when:
  • Your pipeline runs on push events to any branch
  • You want Blitzy to attempt resolving CI failures automatically during generation
  • Build, test, or lint failures should block the PR until fixed
Include passing CI checks as a success criterion in your AAP to ensure Blitzy treats pipeline failures as actionable feedback.
Self-correction depends on pipeline visibility, execution speed, and SCM provider configuration. Results vary by environment. If Blitzy does not self-correct, use Refine PR after the PR is created.
Regardless of when your pipeline triggers, Refine PR is always available as a fallback. Review the CI results on the PR, reference the failures in your Refine prompt, and Blitzy will iterate.
PAT-based SCM providers (Azure DevOps, GitLab, Bitbucket): These platforms may not expose pipeline status through Blitzy’s default permissions. If Blitzy cannot read pipeline results during generation, configure a PAT with pipeline read access in your environment settings, or use Refine PR after the PR is created.

​
When Dynamic Validation Is Enough

Dynamic validation alone can be sufficient when:
  • AAP was thoroughly reviewed and approved
  • Test coverage is comprehensive for the modified paths
  • All tests, benchmarks, and CI checks pass
  • Changes are in well-tested modules with established patterns
  • Risk tier is Light (boilerplate, config, scaffolding, test generation)
In these cases, a spot-check of the diff is appropriate, but a full line-by-line review is not necessary.
Dynamic validation does not replace judgment - it replaces reading. When your automated signals are strong enough, the reviewer’s job shifts from “verify correctness” to “verify that the right things are being tested.”

​
Layer 3 - Code-Level Review

Code-level review is the final layer. It catches what the AAP and dynamic validation cannot: nuanced business logic, security-sensitive paths, and gaps in automated coverage. When a PR is AI-generated, you are not reviewing human-authored code where you can lean on commit history and author intent. You are reviewing a large generated codebase - a fundamentally different problem. Line-by-line reading of tens of thousands of lines is not the goal. Triage by risk tier and focus where it matters.

​
Where to Focus

Before reading individual files, validate the high-impact areas first:
  • Architecture - Does the directory layout, dependency graph, and component structure match the approved AAP?
  • Boundaries and contracts - API endpoints, database schemas, type definitions, and inter-module interfaces are where the most consequential decisions live. If the contracts are right, implementation bugs are fixable. If the contracts are wrong, everything built on top of them is wrong.
  • Operational concerns - Environment and config handling, dependency versions (current and vulnerability-free), database migrations, authentication and authorization flows, logging and observability.

​
Risk Tiers

​
Domain-Assigned Reviewers

Large pull requests become tractable when reviewed by the right people, not the most available. A module owner catches deviations immediately that a generalist might miss entirely. Distribute review load by domain ownership, not by availability.

​
AI-Assisted Review

A separate AI model can help reviewers orient themselves in a large diff, freeing human attention for the sections that require genuine judgment.
AI-assisted review is a triage and flagging tool, not an approval authority. Human reviewers retain full accountability for sign-off.

​
AI-Assisted Review by Context

​
Be Transparent About Coverage

With large generated PRs, the temptation is to approve because exhaustive review is impossible. That is the worst outcome. Instead, be explicit about what you reviewed and what you did not.
Use a coverage statement in your PR approval. For example: “I validated the architecture, reviewed the API contracts and auth flow, spot-checked implementation in these areas, and ran the test suite. I have not reviewed X, Y, and Z in detail.”
Transparency about review coverage is more valuable than a false sense of thoroughness.

​
Post-Review Actions

After your review, choose one of four actions. Your choice determines whether the workflow advances or iterates.
The generated code meets quality standards and is ready for integration.
  • Code is merged to your target branch
  • Blitzy’s context updates to include the merged changes
  • You return to the generation prompt step to start your next task
Merge criteria and approval workflow
The code is fundamentally sound but needs specific improvements.
  • Submit targeted feedback about what needs to change
  • Blitzy updates the same PR with modifications
  • Review again and choose to merge, refine further, or close
How to request refinements
The target branch changed since generation, causing conflicts that block the merge.
  • Select Fix Merge Conflicts from the Blitzy PR dropdown menu
  • Blitzy rebases your branch and regenerates conflicting sections while preserving the original intent
  • Review the updated PR and proceed with merge, refine, or close
Merge conflicts and resolution
The code has fundamental issues, or starting over would be faster than refining.
  • PR is closed without merging
  • You refine your prompt based on what you learned
  • A fresh PR is generated from the improved request
When to close and restart

​
Decision Framework

​
Summary

AAP Review

Review the Agent Action Plan before code generation begins

Merge Pull Request

Criteria for accepting generated code

Refine Pull Request

Request targeted modifications to improve generated code

Close Pull Request

When to discard and restart with a new prompt