Key takeaways:
- AI agents aren’t aiding teamwork, they’re isolating individuals: most projects saw almost no collaborative use.
- 79% of agentic PRs are reviewed and modified by the same person, no second set of eyes.
- Fix requires team-level learning, not solo experimentation, and tracking quality, not just code volume.
AI-coding agents are often cast by their makers as new teammates: tireless colleagues able to pick up tickets, write code, and submit pull requests (PRs) while their human counterparts focus on harder problems. By putting the onus on the agents, engineers can spend more time working together with their colleagues.
However, it seems like it’s not happening, according to an analysis of 25,264 agent-generated PRs across 2,361 popular GitHub repositories.
The median project produced just one or two PRs over three months in 2025. The personnel involved with those PRs was surprisingly insular: in 70% of projects, fewer than one in five contributors took part in an agentic workflow.
What’s more, in 79% of agentic PRs, the same developer both reviewed and modified the AI’s contribution. Just one in eight workflows involved multiple humans.
More like this
AI-coding agents hamper engagement
The findings suggest that, for all the talk of AI joining engineering teams, adoption remains concentrated among individuals at the edge of existing workflows.
In part, that may be a reflection of how the tools were built. “Software development is not an isolated task, and writing new code was never the hard part,” says Courtney Miller, assistant professor of computer science at George Washington University, who tracks software engineering adoption.
Coding agents are useful tools, but each engineer can make them work with their own methods for prompting and correcting the tools. “You can kind of end up in this situation where you just suddenly have very different processes, even though you started from the same place,” Miller says.
Sarah Wells, a software engineering consultant, has seen developers turn to agents for conversations they might once have had with colleagues. That’s a concern for junior engineers, who may not have the experience to recognize when an agent’s suggestion is wrong.
“I’m worried that they’re not; they can’t make the judgement about whether the agent is making a sensible suggestion,” she says.
Teamwork triumphs over everything
So how can engineering leaders turn individual experimentation into a team capability?
Miller says organizations often provide access to a tool, promise large productivity gains, and then leave individuals to work out how to deliver them. That’s the wrong approach.
“If you internalize that, it’s your responsibility to figure out how to speed up your productivity by 10x using these tools. That’s a you problem,” she says.
Instead, teams need shared spaces for learning such as Q&A channels, short conversations during stand-ups, and demonstrations of their actual systems. “Make it more collaborative and don’t treat it as an individual’s responsibility,” Miller says. “Make it a team development – an evolutionary process.”
Wells has seen organizations use AI-focused hack weeks and showcases to spread what employees learn. However, engineering culture will determine whether people share failed experiments as readily as successful ones. That becomes less likely if managers reward raw usage or treat token consumption as proof of productivity.
“Some of it, I think, is that people started to run before they could walk,” Wells says.
Berlin • November 9 & 10, 2026
Engineering leadership has never moved this fast.
See how other leaders are keeping pace at LeadDev Berlin.
A little collaboration goes a long way
Engineering managers also have to decide where collaboration is genuinely needed. Wells argues teams should keep collaboration around the decisions that matter such as design, architecture, and risk. Knowledge sharing is also likely to move upstream.
“I think code reviews are probably going to stop being the way that you share knowledge,” Wells says. “You’re going to share knowledge at a higher level than the code itself.”
Leaders also have to carefully track whether agent use produces better software, not just more of it. LeadDev has previously reported how code volume and PRs can easily be gamed. Metrics often reveal little about whether code is secure or maintainable – nevermind what happens when it gets merged into production.
As a result, testing and quality assurance have to scale alongside code generation, Miller says, or the agent simply moves the bottleneck into review.
The answer for engineering leaders is to not leave every dev to work it out alone.
