# There Aren’t Enough Chaperones for All Your Coding Agents > Source: > Published: 2026-10-21 07:54:51+00:00 ARTICLE # There Aren’t Enough Chaperones for All Your Coding Agents Explore the challenges of managing AI coding agents in engineering teams. Learn why trust issues arise and how to effectively supervise them. Nicholas Arcolano Imagine leading an engineering team where you have some major trust issues with 20% of your developers. These developers are reliable enough that you let them write code, but they require considerable supervision. They can’t be the sole reviewer on other people’s work and they certainly can’t grant approval to merge code to important systems. As developers go, they’re second-class citizens. Traditional software engineering would view this state of affairs as a serious structural problem. Effective development teams are built on a foundation of trust in high-agency individuals who (along with good processes and safeguards) can write, review, and ship code without needing to be micromanaged. However, that’s the situation the typical engineering team finds itself in today, except the 20% of developers we’re talking about are AI agents. Most teams require each agent to be chaperoned – and there aren’t enough chaperones to go around. ## The agent trust problem, in two charts At Jellyfish, we track how engineering organizations are using AI coding tools and agents, and how that usage connects to outputs like what code actually ships, what products and features are being built, and how much these things cost. Through our platform we have visibility into about 300K engineers across 1,300 companies and more than 100 million pull requests, the largest body of software engineering workflow data in the industry. In a recent edition of our monthly [AI Engineering Trends Report](https://jellyfish.co/ai-engineering-trends/), two charts in particular underscore the challenges that engineering teams face today as they scale their use of autonomous coding agents. The first is autonomous agent activity, which we define as the share of a company’s merged PRs that were authored by autonomous coding agents (i.e. with coding agents writing the code, making the commits, and/or opening the PR). The median company is now at 22% of PRs, up from 18% just a month earlier. Companies at the 90th percentile are at 53%. *Autonomous agent activity by company percentile. Source: Jellyfish AI Engineering Trends, September 2026.* To anyone who’s been working with AI coding agents in 2026, the incredible adoption of these tools shouldn’t be wildly surprising. Advances in harness and model capability have allowed AI coding agents to take over a large proportion of coding workloads. But that’s just the “raw coding” part, so to speak – you still need to approve, merge, and deploy this code. Let’s look at another chart: “agentically merged PRs”, i.e. pull requests that were reviewed and merged by agents without human review. This practice is far less common. The median company has achieved AI-only review for about 0.6% of its PRs, while the top 10% of companies are at 9% and climbing. *Agentically merged PRs by company percentile. Source: Jellyfish AI Engineering Trends, September 2026.* So at a typical company, agents are now authoring about a fifth of the code, but almost all of it requires a human at some point in the process. This human oversight is a reasonable way to build trust and ensure quality, but it also represents a hard constraint on how much additional capacity coding agents can provide. Everyone is talking about software factories, but a factory where every unit has to pass a human inspector before it ships isn’t a factory – it’s just a workshop with more conveyor belts. ## The review bottleneck is an ROI problem The review bottleneck isn’t just stressing out the engineers, it’s also stressing out the leadership team, because it’s a big contributor to the ROI problem. By “ROI problem” I mean that the upstream acceleration of code creation is much more dramatic than the downstream impact. For example, over the course of 2026 we’ve generally measured about a 2x increase in pull requests, but only about a 40-50% increase in product outputs like features shipped. One reason for this gap is that agent-authored PRs die on the vine at a much higher rate. When a human authors a PR, it fails to merge about 20% of the time, for all sorts of totally normal reasons (e.g. experimental work, wrong solution, new requirements, changing priorities). For agents though, the abandonment rate is double (40% vs 20%). Meanwhile, the agent PRs that do merge are getting more scrutiny rather than less: over the past year, the number of human reviews per merged agent PR has more than doubled. None of that is unreasonable on its own. Agent code is genuinely harder to review, and reviewers are right to be careful with it. The problem is the strain these loads put on the system as coding agent capability continues to grow. Review load scales with increasing agent output while human attention remains a fixed constraint, and the autonomy curve I showed above is compounding every month. If today’s median company gets to where the top 10% are today (with autonomous agents authoring more than half of all code), code review threatens to become the entire job of the human, stealing time from all the other important things that experienced developers need to be doing like collaborating with product and design, shaping software architectures, and bringing their engineering judgment to problems that don’t have clear solutions. ## How to build trust faster Fortunately, some companies are figuring this out. The top companies that have autonomous agents merging 9% of PRs aren’t just blindly trusting their agents more. Instead, they’re putting in the work to accelerate how fast trust can be built. Often this entails a lot of platform work, such as systems for routing low-risk work to autonomous agents, sandboxes and staging environments for safe and secure development and deployment, and of course lots and lots of automated testing. Perhaps most importantly though, they’ve started early and are pushing hard; trust can only be built over time, and the longer you wait, the longer you’ll have to live with a mounting review backlog. *Chaperoning every agent is a sensible way to start, but an impossible way to scale.* If you’re interested in learning more about how autonomous agents are evolving (or more accurately, disrupting) the SDLC, come join me at [aiDevCon](https://tessl.io/devcon) in New York City on November 2–4. I’ll be talking about this and much more in my session *Botsitting Doesn’t Scale: How to Navigate the Autonomy-Trust Gridlock in Real Engineering Orgs*, and sharing what we’ve learned from analyzing Jellyfish data about how the best engineering teams are tackling the biggest engineering workflow challenges of 2026. COPY & SHARE Nicholas Arcolano I'm a founding team member and Head of AI & Research at Jellyfish, where my team and I study how AI transformation is reshaping the software industry. We have a unique real-world view into how hundreds of thousands of developers are using AI coding tools and agents in production, and we use it to help engineering leaders spend intelligently, ship faster, and focus on what matters to the business. I've been in startups for 13 years and spent another 10 years before that in national defense research at MIT Lincoln Laboratory. My background is in applied mathematics (Ph.D., Harvard) and electrical engineering (M.S., Boston University and B.S., WPI). READING · 0% IN THIS POST COPY & SHARE Nicholas Arcolano I'm a founding team member and Head of AI & Research at Jellyfish, where my team and I study how AI transformation is reshaping the software industry. We have a unique real-world view into how hundreds of thousands of developers are using AI coding tools and agents in production, and we use it to help engineering leaders spend intelligently, ship faster, and focus on what matters to the business. I've been in startups for 13 years and spent another 10 years before that in national defense research at MIT Lincoln Laboratory. My background is in applied mathematics (Ph.D., Harvard) and electrical engineering (M.S., Boston University and B.S., WPI).