What is a reviewed AI dev team?

By Julien Abenhaim, founder of Castforge. Published 7 September 2026.

A reviewed AI dev team is more than several agents in a row. It is roles with different jobs, plus gates that can send work back: a plan is checked before any code is written, delivered work is checked against the goal it was supposed to meet, and the build and the tests run before a phase is called done. Without those gates you have a relay, not a team.

Roles are jobs, not models

A role is a job description. Six of them cover most work:

• Lead organizes. It breaks a request into phases and tasks and tracks the work.
• Coder implements. This is the role that does the building.
• Tester runs the tests and reports failures.
• Reviewer checks diffs and requests changes.
• Researcher investigates first, in docs, in the code and on the web.
• Designer authors the view layer, the markup and styles and the empty, loading and error states.

Which agent fills a seat is a separate choice from what the seat does. That separation is the practical benefit: you can put your strongest model on the role where a mistake is expensive and a cheaper one where it is not, without changing what any role is responsible for.

The three gates

The plan check, before work starts. When the Lead produces a plan, the plan is critiqued against the acceptance criteria before a line of code is written. The point is to catch a weak or incomplete plan while fixing it is still cheap. It surfaces findings; it does not stop you approving a plan yourself.

Goal-backward verification, at settlement. Instead of asking whether the tasks ran, this one works backward from the goal and checks the delivered work against the criteria the team set out to meet. When it finds gaps it lists them and offers a re-run or an accept as-is. The framing is deliberate: it says "found gaps", not "failed".

Phase verification, when a phase completes. Every card being marked done is not the same claim as the phase working. So the build runs, the test suite runs, and the key flows the phase delivers get exercised as a whole. If it fails, fix cards are created automatically, one per problem, and the phase is checked again once they are done.

You choose how much checking

More checking means higher quality and more tokens. That trade is real, so it is a choice rather than a default someone made for you. There are three tiers:

• Draft: plan and code only. Both review gates are turned off.
• Standard: adds the plan check, goal verification and phase verification. This is the default.
• Max: adds research and testing on top of the full gate stack.

You pick the tier when you create a project, and a plan can raise or lower it for one phase.

Saying so when a check did not run

A tier that turns a gate off has to say so. A skipped check shows as skipped, with the reason, and it is written to the decision ledger the same way a pass or a fail is. It is never rounded up to a silent pass, and the fail-safe direction runs the same way: an unrecognized tier value leaves the gates on rather than turning them off.

This is the same rule the docs and the changelog are written under, which you can read in the editorial guidelines: say what a feature cannot do yet. A verdict you cannot audit is worth very little, and a check reported as passing when it never ran is worse than no check at all, because you would have looked yourself.

What this does not solve

• A review gate is another model reading a diff. It catches a class of mistakes, not all of them, and it does not replace you reading the change before you ship it.
• More gates cost more tokens. Draft turns both review gates off on purpose, and that is a legitimate choice for a throwaway change.
• The Tester runs tests. It does not write them, and when there is nothing runnable it says so rather than reporting a failure.
• Cost bands are approximate expectations, not billing promises. A small change costs far less than a large feature at the same tier.
• A verdict is only as good as the checks that actually ran, which is exactly why a check skipped by tier is recorded as skipped instead of rounded up to a pass.

What it looks like in Castforge

The work runs on a board, with the six roles above on seats you assign, and the quality tier set when you create the project. Every gate outcome, pass, fail or skip, lands in the project's decision ledger, so you can go back later and read why a phase was called done.

Castforge is a Windows desktop app, in open beta and free during early access. You can download it or read the gates in full in quality tiers and review gates.

Related

• Run Claude Code and Codex on the same project. What actually goes wrong when two agents share one repository, and the splits that hold.
• AI coding agents on Windows. Which agents run on Windows today, how you sign in to each, and the traps in the way.
• All Castforge walkthroughs.