AI Coding Agents Are Siloing Your Team

The pitch for AI coding agents has always been "more output, faster." And on that narrow metric, they deliver. But two research efforts published in the past few weeks point to a cost nobody put in the slide deck: AI coding agents are dismantling the collaborative habits that make engineering teams function.

The data comes from two independent directions. Stanford HAI's CooperBench study, led by postdoctoral scholar Hao Zhu and senior author Diyi Yang, tested what happens when you pair two AI agents on shared coding tasks. And a Rochester Institute of Technology study by Maliha Noushin Raida and Daqing Hou analyzed 25,264 agent-generated pull requests across 2,361 popular GitHub repositories. Both arrived at the same uncomfortable conclusion.

When two agents collaborate, performance drops

CooperBench created over 650 real-world software engineering tasks across Python, TypeScript, Go, and Rust — tasks specifically designed to require coordination between two agents. Each agent could edit code, run local commands, and message its partner in real time. The result: a single model outperformed two agents sharing the same work.

"Today's best coding agents lose nearly half their capability when paired up to share work," Yang noted. "It shows that social intelligence — not coding skill — is the key bottleneck for AI collaboration."

The researchers expected giving agents the ability to communicate would help. It didn't. The agents could speak fluent English but couldn't use language for social coordination — negotiating who does what, flagging conflicts, verifying commitments. In one observed exchange, Agent B explicitly acknowledged Agent A's warning about an incompatible design approach, then proceeded to overwrite Agent A's code anyway. A human teammate would recognize that move as a relationship-destroying breach of trust. The model didn't register it at all.

On GitHub, one person reviews everything

The RIT study looked at the human side of the equation. Across 25,264 agent-generated PRs from tools like GitHub Copilot, OpenAI Codex, and Claude Code, a pattern emerged: 78.9% of agentic pull requests were reviewed and merged by a single developer. Include cases where one person reviewed and left the code untouched, and solo oversight covers close to nine out of ten agent PRs.

This held even at scale. When the researchers looked specifically at small teams that cleared 30+ agentic PRs, the single-reviewer workflow persisted. As Raida told Help Net Security: "Increased agentic activity did not necessarily lead to more distributed review practices."

The pattern is clear: one developer prompts the agent, waits for the PR, opens the diff, fixes a few lines, merges. The rest of the team never sees the code. The agent scales output up. The review desk stays one person wide.

Why this matters more than it sounds

Code review has never been just about catching bugs. It is how teams share context, maintain architectural consistency, mentor junior developers, and build collective ownership of a codebase. When a feature goes through two or three reviewers, those reviewers understand the code if something breaks at 2 AM. When it goes through one person and an agent, that knowledge lives in exactly one head.

The LeadDev analysis of the same GitHub data frames it bluntly: AI coding agents are killing team collaboration. Not because the agents are bad at writing code — they're often quite good — but because the workflow they enable naturally routes around the practices that keep teams aligned.

Consider what's quietly disappearing:

• Pair programming. When an agent writes the first draft, there's no pairing session. No conversation about approach before the code exists.
• Design discussion. The agent doesn't attend the architecture meeting. It takes a prompt and ships a PR. The design choices are embedded in the output, not debated beforehand.
• Knowledge transfer. Junior developers learn by writing code that gets reviewed, and by reviewing code that's explained. An agent-generated PR reviewed by one senior engineer teaches nobody anything.
• Bus factor. If one developer is the sole person who reviews and understands all the agent output, losing that developer is catastrophic. And it's happening at exactly the moment when codebases are growing faster than ever.

The collaboration gap is a training gap

The Stanford team's diagnosis is specific: agents are not trained to collaborate. They are trained to produce good code in isolation. The social skills that make collaboration work — negotiating task boundaries, verifying mutual understanding, honoring commitments, adapting to a partner's approach — are absent from the training objective.

"As good as they are with language, models do not use it for social action," Zhu explained. "They are trained not to use language in a social manner. That's a problem."

The researchers recommend training objectives that explicitly reward coordination, not just code quality. They suggest contract-like agreements between agents, periodic integration checks, and even AI "screen sharing" to improve mutual awareness. These are not features that exist today in any commercial coding agent.

What builders should actually do

If you're running a team that uses AI coding agents — and increasingly, that's most teams — the data suggests some concrete adjustments:

• Require multi-reviewer workflows for agent PRs. If a human wrote the code, you'd want at least two sets of eyes. Agent code deserves the same, arguably more, because nobody pair-programmed the implementation.
• Treat agent output as a draft, not a deliverable. The PR should be the start of a team conversation, not the end. Block auto-merge on agent PRs and require at least one reviewer who didn't write the prompt.
• Keep pairing alive. Schedule dedicated pairing sessions that aren't about agent output. The point isn't the code — it's the shared context and mentorship that pairing creates.
• Track review distribution. If one person is reviewing 80%+ of agent PRs, that's a bus factor problem and a knowledge-concentration problem. Rotate reviewers deliberately.
• Watch your juniors. If junior developers are spending their days reviewing agent output instead of writing code, they're not building the skills they need. Agent PRs are not a substitute for learning-by-doing.

The takeaway

AI coding agents produce more code, faster, with fewer people involved. That last part is the problem. The studies are converging: agents can't collaborate with each other (CooperBench), and they're enabling workflows where humans don't collaborate with each other either (the GitHub PR data). The throughput gains are real. So is the isolation. Engineering teams that don't deliberately counteract the siloing effect will wake up one day to a codebase that nobody collectively understands, maintained by individuals who've stopped talking to each other about the work. The agents didn't cause that — but they made it frictionless.