Trying a Three-Role AI Agent Split

The short version

What matters in AI agent development is not increasing the number of AIs you use. It is separating responsibility for design, implementation, inspection, and the final decision. This article reworks the role split Netsujo uses in production into steps you can try safely on a personal project or at a Miyako de IT mokumoku session.

Assuming that quality improves simply because you use ChatGPT, Claude Code, and Codex together is premature. Chaining several AIs in series while their roles stay vague adds handoffs, repeated explanation, token consumption, and branch confusion.

Fix in advance who decides what, who changes the code, what is checked mechanically, and where the human takes over, and adding AIs starts to pay off. This article takes Netsujo's published piece on role-separated development with ChatGPT, Claude Code, and Codex as its starting point and reorganizes it into a form Miyako de IT readers can reproduce on their own small development tasks.

What you separate first is responsibility, not AIs

The conclusion first: decide the role split before you decide the tools. You can use the same AI in several roles, but you must not mix the responsibilities of designer, implementer, and auditor.

Putting ChatGPT on design, Claude Code on implementation, and Codex on independent review is one arrangement that makes this separation easy to understand. It is not a claim that this combination of products is superior.

Start by writing a one-page task contract

Handing an AI "just fix it" makes the goal easy to inflate during implementation. Writing a short task contract first makes the boundary of the work visible.

Fix at minimum these five items.

1. Goal: what is being improved

2. Scope: which screens, features, or files are touched

3. Non-goals: what is explicitly not being fixed this time

4. Constraints: compatibility, permissions, prohibited operations

5. Completion conditions: which tests and which observations finish the job

Have the design-role AI organize these five items without ambiguity. What matters is not the word count but that the implementer can work without inventing decisions along the way.

Give change permissions to the implementer and withhold them from the auditor

An implementation role such as Claude Code is responsible for reading the target repository, making changes on a branch, and running the necessary tests. Keeping one unit of work inside one branch makes it easier to trace.

The independent review role, by contrast, should be read-only as a rule. If the reviewer fixes the code itself, the one who found the problem, the one who fixed it, and the one who judged it fixed become the same actor, and independence weakens.

When the review finds a problem, send it back to the implementer. After the fix, inspect the new diff again. It looks laborious, but that round trip is exactly where the responsibility boundary lives.

Run deterministic checks before you ask another AI to review

Before another AI reads the code, finish everything a machine can decide.

• formatter
• lint
• typecheck
• unit tests
• build
• automated tests for the feature in question

There is little point in moving to another AI's review while these are failing. Syntax errors and type errors do not need expensive inference to find.

In Miyako de IT's article on the value of IT meetups in the generative AI era we made a related point: in the AI era, the value of actually running something and observing how the results differ has risen above the value of listening to a finished explanation. The same holds in development. Make execution results your evidence first.

"Always route through Codex" is not automatically safe

Independent review has a cost too. Sending even low-risk wording fixes through several AIs every time makes the handoff cost the larger expense.

In practice it is more reasonable to vary review depth with the risk of the change.

In a hands-on session held for learning, it is fine to run even a low-risk exercise all the way through independent review so that participants experience the difference between the roles. In production operation, though, the judgment is not "how many AIs did we use" but "do we have the evidence the risk requires."

Before putting this branch into operation, there is a condition to check. Risk classification creates a state in which nothing is detected when the classification itself is wrong. In our own operation, a diff judged Low went through as it was, and defects were found later. In August 2026 we stopped using that branch and went back to running every diff that passes deterministic checks through independent review once, regardless of content or size. Classification is now used only to tune how deeply the reviewer reads, not to decide whether a review happens at all.

If you keep the branch, make sure you can state both of the following before you use it.

• Whether a misclassification can be detected by some other path
• Whether the diffs judged Low can be counted and re-examined later

Using three AIs does not give you three independent experts

This is the easy misunderstanding. Separating the product names ChatGPT, Claude Code, and Codex does not by itself establish independence.

What creates independence is this set of conditions.

• The auditor does not take the implementer's conclusions as given
• The auditor is not given change permissions
• The auditor reads the requirements and the diff directly
• Test results are confirmed as separate evidence
• Problems go back to implementation, and the state after the fix is re-confirmed

Differences between models are a supporting factor. If responsibility and permissions are the same, changing the model leaves the structure of self-review intact.

If you have 60 minutes, use this order

When you try this at a mokumoku session or an in-house study group, do not set completing a large feature as the goal. Taking a small change all the way through, and comparing what became visible at each stage, gives people more to take home.

0-10 minutes: write the task contract

Each participant picks one small, safe task. Have the design-role AI organize the goal, non-goals, constraints, and completion conditions.

10-35 minutes: implement

Hand the task contract and the repository to the implementation role. If the scope of the change starts to grow, stop and record why it became necessary.

35-45 minutes: run the deterministic checks

Run whatever deterministic checks that project has, such as lint, typecheck, and tests. If they fail, keep the failure itself as material to share.

45-55 minutes: review from another perspective

Do not let the independent review role make changes. Have it read the requirements, the diff, and the test results. When it raises a point, check its severity and its basis.

55-60 minutes: bring the results together

What you share is not only the prompts that worked.

• Where the roles collided
• Which check stopped the work
• What scope the AI tried to expand on its own
• What the independent review found
• Which rules you want to fix in place from next time

Running the same procedure with several people reveals differences that come from the OS, the repository layout, how the task was handed to the AI, and the size of the task. That is information you rarely get from building a single success story alone.

Decide "go, back, or stop" for each stage in advance

The biggest time sink in a 60-minute exercise is continuing in a state that is not working. Deciding the conditions for each stage up front keeps you from stalling on the judgment.

"The AI said it was fine" satisfies none of these conditions. Write the conditions in terms of execution results and locations in the diff.

These are the five lines to take home

The following is a record sheet the editorial team has drafted. The intent is for each participant to fill it in at the end of the exercise. The point is not the finished code but leaving behind what they based their judgment on at the time.

If that last line stays empty, the basis for the judgment remains inside the conversation. From there you cannot reproduce what you would choose in the same situation next time.

Do not let a failure end at a prompt fix

If you find yourself giving the AI the same caution repeatedly, that caution is more reproducible as part of the mechanism than as part of the conversation.

Conditions such as "do not change main directly," "do not ignore failing tests," and "the auditor does not rewrite code" can move into repository rules, CI, permissions, and checklists rather than being requested every time.

The skill of working with AI agents is not only writing longer prompts. It includes turning failures that keep recurring into a structure where they are less likely to recur.

If you bring this to Miyako de IT, we would rather see the differences than the successes

Miyako de IT has held a hands-on session comparing Claude Code and OpenClaw and an AI agent lightning talk event.

If you bring AI agent development to the next one, there is more value in a format where several people run the same small task through a role split and look at where the results diverged, rather than one that ends at "this tool was convenient."

The volume of code AI can write keeps growing. That is exactly why the value people bring to a shared room is moving away from successful output and toward the conditions of failure, the boundaries of judgment, and the rules that prevent recurrence.

See upcoming events

If this would be your first time, you can also read the first-timer's guide.