One Dev, A Team of Agents: What the AI Team Model Actually Costs

Last week, Claude Fable 5 hit number one on WebDev Arena with the largest performance gap ever recorded.¹ My feed immediately filled with a version of the same take: “One experienced developer running AI agents can now match the output of a team of four or five engineers.”

That’s probably true. But the headline leaves a few things out.

The output problem

I use AI agents regularly and have been mostly impressed with the speed and quality of the output. But I’ve also been thinking about the overhead of using agents and how they compare to a team of developers.

Agents can write code. They can’t decide what to write (they’ll try). Every loop you run produces output you have to review – and reviewing AI-generated code at speed is its own skill. Get that wrong and you’ve multiplied your mistakes, not your output.

There’s also what I’d call prompt debt. Trying to “one-shot” a prompt and hoping for the best produces vague results coming out. You still have to understand what you’re building and why. The agent just builds it faster once you do. If you don’t have that understanding, you’re just shipping a black box and hoping.

The overhead that’s easy to miss

Running multiple agents across a complex project means keeping track of what each one knows, what it doesn’t, and where the handoffs are. That context management is genuinely tiring, even when the output is good.

And when an agent confidently goes in the wrong direction – which happens – you need to catch it before it compounds. That takes experience and attention, not more agents.

If you’re not a developer, should you be using agents?

Whether you’re a developer or not, AI vibe coding is great for personal projects or just having a play – it’s amazing what you can build in a weekend. But turning that project into a production app, or maintaining it long-term, is a different story.

If you’re not a developer, you’re better off hiring one.

That’s not gatekeeping – it’s a practical problem. Agents produce code that looks finished. The issue is you need to be able to tell whether it actually is.

An agent will write you an authentication system, a database integration, or an API connection with complete confidence, and get it subtly wrong in ways that don’t show up until something breaks or gets exploited. It’ll happily write you a suite of tests that all pass, giving you a sense of confidence, but is it testing the right things, in real-world scenarios?

If you can’t read the code, you can’t review it. You’re not working with an agent – you’re just shipping a black box and hoping.

Debugging compounds this. When something breaks (and it will), you need a foundation to understand why. Without one, your only option is to ask the agent to fix the problem it probably caused in the first place.

There’s also the direction problem. Agents are fast, but they’re only as good as what you ask them to do. Getting useful output requires knowing enough about what you’re building to ask for it correctly – the architecture, the trade-offs, the things you explicitly don’t want. Non-developers don’t have that vocabulary yet, which means the agent fills in the gaps however it sees fit.

And it sees fit generously. Agents don’t say “I’m not sure this is the right approach.” They just build. Which means technical decisions get made without anyone realising decisions are being made.

There’s so much to know about the web platform: how it works, its intricacies, hosting, security, accessibility, performance, DNS and how routing actually propagates, HTTPS and why it matters beyond the padlock, CORS and why it breaks in ways that make no immediate sense, authentication vs. authorisation and the ways they get confused, environment variables and what happens when you expose one, caching strategies and when they work against you, the critical rendering path, Core Web Vitals and why they’re harder to fix than to understand, semantic HTML and why it matters for screen readers, keyboard navigation, ARIA and when not to use it, cross-browser quirks, progressive enhancement, bundle size and what’s actually in it, code splitting, lazy loading, image optimisation, server-side vs. client-side rendering and the trade-offs that aren’t obvious until you’ve made the wrong call, database design, API rate limits, webhooks and what to do when they fail silently, SQL injection, XSS, CSRF, Content Security Policy, data privacy, cookie consent, GDPR – and that’s before you’ve touched the framework, the deployment pipeline, or the thing the client asked for last week that seemed simple.

That’s the iceberg. An agent can touch all of it. What it can’t do is know which parts matter for what you’re building, or catch the places where it got something quietly wrong.

The maintenance that’s often unplanned for

The productivity argument focuses on building. It rarely mentions what comes after.

Agent-generated code solves the problem in front of it. It doesn’t think about how the codebase will evolve, how another developer will read and make sense of it six months from now, or what happens when a dependency gets a security patch and something quietly breaks.

Dependencies go out of date. Frameworks release breaking changes. Security vulnerabilities get discovered in packages your agent chose without you knowing why. Someone needs to triage all of that – and do it with enough understanding of the codebase to know what’s safe to update and what isn’t.

The handoff problem is worse. If you built something with an agent and then bring in a developer to maintain it, they’re inheriting code that the original person can’t explain. That’s a rough starting point. The developer isn’t just maintaining a codebase – they’re reverse-engineering intent.

Without tests (and agents don’t always write them, and non-developers rarely know to ask), maintenance is guesswork. You change one thing, you don’t know what you’ve broken until a user finds it.

The cost of agent-generated code isn’t always upfront. Sometimes it shows up a year later, when the thing that seemed free to build turns out to be expensive to keep.

So is it worth it?

Yes, with the right expectations. I move faster on things that used to take days. But it’s not a one-in, team-out swap. It’s closer to having capable juniors who need clear direction and regular review.

The 1-to-5 productivity claim assumes the “one” knows what they’re doing and can hold the whole thing together. That judgment – the architecture, the debugging, the knowing when something’s wrong – still matters. Maybe more than ever.

Source: Code Arena WebDev Leaderboard ↩