Overview
Hey everyone 👋
For a long time my OpenCode workflow was one agent, one giant conversation, and me asking it to code, then revi...
For further actions, you may consider blocking this person and/or reporting abuse
"Fresh eyes. The agent that wrote the code isn't the one reviewing it" is the most important sentence here, and it's the exact reason I stopped asking a single agent to review its own work.
The "propose first, apply after approval" rule is also smart, but I'm curious how you handle the case where the reviewer proposes a fix that the builder disagrees with. Does the builder just implement it, or does it push back and escalate to you?
Hi, as we all know, even AI makes mistakes, so a developer might not agree with what’s being proposed.
In that case, you make an overall assessment and weigh the pros and cons of the proposal.
"Weigh the pros and cons" is the right answer for a human, but it's harder to automate.
If the reviewer suggests a fix and the builder disagrees, the final decision should probably go to the human (you), not to another agent. Otherwise you're just adding a third agent to argue with the first two.
Curious if your setup has a "tie-breaker" rule. Something like "if builder and reviewer disagree, escalate to human" — or does the builder just implement the reviewer's suggestion?
The "propose first, apply after approval" gate is the detail I'd steal first. In my own agent setups, failures rarely came from the model choosing the wrong edit — they came from edits landing in files nobody reviewed because the approval step was implicit rather than enforced. Your sandbox rule-ordering note is a good catch too: last-matching-rule-wins is exactly the kind of thing that silently breaks when someone reorders a config file months later. One thing I'm curious about: how do you keep the primary agent from over-delegating? Once an agent knows it has specialists, mine started dispatching for trivially small tasks and the token bill climbed fast. Did you add any threshold or heuristic for when NOT to call a subagent?
Hi, for now, I've simply instructed the agent to delegate to subagents only when the task at hand requires a specialist.
I'm also thinking, to avoid delegating too often, of asking the user for approval.
The failure mode I'd watch in "delegate only when a specialist is needed" is that the agent grades its own homework — the judgment of "needed" comes from the same system that benefits from delegating. One cheap fix: log a one-line reason with every delegation. Over-delegation stops being a vibe and becomes an auditable list.
On the approval gate: it's a good backstop, but measure it. Track approval latency, and the share of approvals that are rubber stamps. If users approve almost everything without reading, the gate is a delay rather than a check — and at that point widening the autonomous band, with the reason log as the audit trail, is the safer design.
Nice setup, “the agent that wrote the code is the worst one to judge it” is so true. Have you thought about an accessibility reviewer as a fifth one? It’s the stuff that slips through most code reviews, like missing labels, focus order and contrast, and it fits the same propose-first flow really well.
Hi, yes, I'm actually developing it right now :)
The fresh-eyes split paid off for me too. The detail that bit me was rule order. I ported a similar setup between tools with different precedence, and the sandbox quietly stopped doing what the file said. Now the deny goes last everywhere so the config means the same thing copied. The agent file versus skill split is worth guarding. When both described the review process in mine they drifted apart, the agent kept following the stale copy, so process lives in one place only. The blanket MCP allow is the piece I'd tighten. Permission rules gate what the agent requests. The server process runs with its own access, so I enable MCP servers per project.
I had a similar idea for splitting to seperat roles. For my use case it was product owner, architect, dev & qa and reviewer.
It made a huge difference in my project, significant reduction in work redo.
But it does come with a cost 😉
Everything in life comes at a cost 🤣
I’d love to hear your thoughts on the roles I defined for my use case. I shared my approach here: dev.to/litalkumiq/we-split-claude-...
Propose first, apply after approval is the rule I'd keep even if I dropped everything else. Having the reviewer be a different agent from the writer matters more than people expect: the writer reads its own code as what it meant, not what it wrote.
The split between a primary agent and specialists is a strong real-world test case—especially your
edit: askrule and the separate reviewer. Would you be open to a small, no-migration cross-check on one completed task? We would keep your OpenCode setup as-is, map the existing agent files to a role/task contract, record a baseline PASS, inject one contradiction (for example, the reviewer receives a task requiring an out-of-scope file write), repair it, and publish setup time plus any false positives.ARC only checks the supplied declarations offline; it would not prove that OpenCode enforced them, so this complements your runtime permissions rather than replacing them. I maintain it here: github.com/suirindo/agent-role-con...
If you're interested, which finished task would make a fair fixture?
You call the two checkpoints heavy on small tasks, and I can see why. The code-reviewer already sorts findings from critical to info, so I'd keep the second ask only for fixes that come from critical findings and let the info-level ones apply after the first approval. Have you tried splitting it that way?