Make Agents Fight: Claude Code Curious 2
Last week, 100 close personal friends (Claude Code Curious attendees) and I had the opportunity to quiz Conner from the Claude Code team in a live Q&A.
Because he sits on the Product team, he was able to bring a really broad perspective, with some good advice for anyone hoping to level up their use of Agents.
One big trick: agree to disagree
"If you can put two agents at each other with opposite goals — so think kind of like Adam and Eve, where one's the coder and one's the evaluator, and they actually have this contract with each other — one's writing the code, it stops, one then reviews the code, it QAs it, it gives the coder feedback. They're basically at this contract where the cycle can't end until the evaluator is happy with the coder's work."
Love this. In the human work world, its true that teams are greater than the sum of their parts, and it follows this would be correct with agents.
Of course the nuance becomes in how you compose the team, how you manage it, where you draw the lines and what's allowed. What is too much disagreement?
Conner expanded:
Recommended by LinkedIn
"If you have a small task and you have six people debating implementation details, that's just a waste of time. You should have one single agent working on it. Just like you should have one developer working on it."
"The team lead would actually just terminate child teammates or child agents when they were disagreeing too much or refusing to do a task because their opinion was so strong."
Agents work while you sleep
Conner described an internal setup at Anthropic where Claude handles the full cycle from Slack to shipped code:
"Claude would search Slack, find issues, add them to Asana. A teammate on the agent team would then pull that task in, push a fix or add a feature, commit it to GitHub, initiate a pull request, get it merged, back to Asana, mark it as done. Every day you go in the morning, you can see what's been done, what's been shipped."
Twenty-four-hour-plus tasks are now possible using sub-agents and stop hooks. We're in a time where most examples from people like Conner still reference coding. But I can't help but feel it may be more exciting to describe real work.
Ask yourself the question: when you come in in the morning, what work would you wish was just done and waiting for you to review?
Maybe your Claude agents are like a team in a different timezone -- time to give them Australian accents!
Great write up Max, and thanks for organising! I immediately tried putting the "antagonist" approach into practice. In a friendly way of course. When I sat down with Claude Code this weekend I made two skills: /review-pr-team /review-pr The team version I use to review the (Markdown saved) plan I draw up in conversation with Claude about a new feature or opportunity. The skill takes in a pull request with the plan documents committed to the repo, reads through the plan, and then spawns three "sub agents": security BOFH, product manager person, technical architect expert. They review the PR from their perspectives and post the result as a comment on the PR. After addressing the critique, as I move into implementation, I run one session for the implementer, and one where I run the /review-pr skill to review every pull request. That skill only spawns one agent, a "senior full stack engineer". Implementer and reviewer exchange information via comments on the PR. it's fascinating! :D And for the trinket I am building now, this genuinely seems like a step up in quality of final output and staying on track. Time and token consuming? Sure. But really feels like a collaborative "team effort".