Skip to content

Planning & Review

DevFlow enforces two human checkpoints in every flow: plan approval before any code is written, and code review before anything is merged. These gates ensure you stay in control of what the AI builds and how it builds it.

When the agent finishes analyzing your flow, it creates an implementation plan that typically includes:

  • Summary of the approach — A high-level description of how the task will be accomplished
  • File changes — Which files will be created, modified, or removed
  • Architecture decisions — Structural choices and the reasoning behind them
  • Tasks with acceptance criteria — A step-by-step breakdown of the work, each with clear completion criteria
  • Risks and edge cases — Potential issues the agent has identified

The plan is written for you to read — it explains the “what” and “why” in plain language, not just the “how.”

Once the plan is submitted, the flow moves to the approval state. This is a hard gate:

  • The agent cannot write any code until you approve the plan
  • The flow stays in approval until you take action
  • No one else can move the flow forward — only you (or a project admin) can approve

This prevents the AI from making large, potentially unwanted changes to your codebase without your knowledge.

If the plan looks good, click Approve. The flow moves to ready, and the agent can begin implementation.

Before approving, consider:

  • Does the approach make sense for your codebase?
  • Are the file changes reasonable?
  • Do the tasks cover all the acceptance criteria?
  • Are there any risks the agent missed?

If the plan needs changes, click Reject and provide specific feedback. For example:

  • “Use the existing authentication middleware instead of creating a new one”
  • “This should be a separate component, not added to the existing file”
  • “The plan does not address error handling for the API calls”

The flow returns to planning, and the agent revises the plan based on your feedback. It will resubmit an updated plan for your approval.

You can reject and request revisions as many times as needed. The cycle continues until you are satisfied with the plan.

After the agent finishes implementing, the flow moves to review. You receive:

  • Agent summary — A description of what was implemented, including any deviations from the original plan and the reasons for them
  • Testing instructions — Step-by-step instructions for verifying the changes work correctly
  • Pull request link — A direct link to the PR with all code changes
  • Commit history — A list of all commits linked to this flow

Follow the testing instructions provided by the agent. These typically include:

  1. Steps to set up or run the feature
  2. Expected behavior to verify
  3. Edge cases to check
  4. Any manual checks that automated tests do not cover

Take the time to actually test. The value of the review gate depends on thorough verification.

If the changes work correctly and meet your standards, click Approve. The flow moves to done, and the work is complete.

If something is not right, click Reject and describe what needs to change:

  • “The loading state flickers when switching tabs”
  • “Error messages are not displayed to the user”
  • “The sort order is wrong — it should be newest first”

The flow returns to in_progress, and the agent reads your feedback. It makes the requested changes and resubmits for review.

As with planning, you can reject as many times as needed until the implementation meets your expectations.

DevFlow records every approval and rejection with full details:

EventWhat is recorded
Plan createdWho created it (which agent), when
Plan approvedWho approved it, when
Plan rejectedWho rejected it, when, with what feedback
Implementation startedWhich agent, when
Code submitted for reviewWhen, with summary and testing instructions
Code approvedWho approved it, when
Code rejectedWho rejected it, when, with what feedback

This audit trail is permanently attached to the flow. Months later, you can look at any completed flow and understand the full decision history — who approved the plan, who reviewed the code, and what feedback was given along the way.

  • Be specific in feedback — “Fix the layout” is less helpful than “The sidebar overlaps the main content on screens narrower than 1024px”
  • Review plans carefully — Catching issues at the planning stage saves implementation time
  • Test thoroughly — Run the feature, try edge cases, check error states
  • Check acceptance criteria — Compare the implementation against the original acceptance criteria on the flow