Skip to content

Run optional AI code review after each completed task, not only at the end #365

Description

@Labutin

Currently ralphex appears to run implementation task-by-task, and then performs the code review phase only after all tasks are completed.

It may be useful to support an optional mode where an AI code review is triggered after each completed task, before moving to the next one.

Why this could be useful

When a plan contains many tasks, problems introduced in early tasks can accumulate and become harder to fix later. By the time the final review runs, the implementation may already contain several layers of changes built on top of an earlier questionable decision.

A per-task review could help catch issues earlier, such as:

  • incorrect interpretation of the task requirements
  • architectural choices that will make later tasks harder
  • missing edge cases
  • inconsistent patterns compared to the existing codebase
  • incomplete implementation that still passes basic tests
  • changes that technically work but do not fit the intended design

This is different from a per-task verification gate such as running tests, lint, or typecheck. Automated verification is good at catching mechanical failures, but it does not always catch design problems, requirement mismatches, or subtle implementation issues. A per-task AI review would complement verification rather than replace it.

Suggested behavior

Add an optional mode, for example:

ralphex --review-after-each-task

or a config option such as:

review:
  after_each_task: true

Possible flow:

  1. Execute one task.
  2. Commit or stage the task changes as ralphex currently does.
  3. Run the configured reviewer on the diff for that task.
  4. If the reviewer finds required changes, send the feedback back to the implementation executor.
  5. Repeat until the task review passes or reaches a retry limit.
  6. Move to the next task.
  7. Optionally still run the existing final review after all tasks are done.

Why make it optional

This mode would likely increase token usage and runtime, so it should not be the default behavior for every workflow. But for larger plans, more sensitive codebases, or users who prefer higher confidence over speed, it could significantly improve the quality of the final result.

Relationship to per-task verification

There is already a related idea around per-task verification gates. This proposal is similar in timing but different in purpose:

  • verification gate: runs deterministic checks like tests, lint, or typecheck
  • per-task AI review: reviews the code diff for correctness, maintainability, design, and task alignment

Both features could work well together. Verification can catch objective failures, while AI review can catch higher-level implementation problems before they propagate into later tasks.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions