Why Out-of-the-Box AI Frustrates Teams — and What to Do About It

With most technologies, the longer you use them, the more calmly you come to rely on them. With AI tools, the opposite has held true: in its annual survey of more than 49,000 developers, Stack Overflow recorded usage climbing to 84% even as trust in the accuracy of these tools fell from 40% to 29% in the span of a single year.

That effect is familiar to me. Our own first experience with AI tools in development had little in common with the wow-effect of faster work and less drudgery that the tech press kept writing about. Our developers were let down: the AI produced mediocre code that took a long time to review and, in the end, had to be rewritten. The team expected AI to save time and instead got extra work. So not long after those first attempts to fold AI tools into the daily workflow, the team went back to working the way it always had.

Today those same tools speed up both writing code and reviewing it for our developers — not because we found a better model, but because we changed how we work with it. Here’s what helped us get there.

Why AI-Written Code Frustrates Developers

AI leans on an enormous mass of public code from across the internet, and that code is rarely exemplary: its quality is average, and the model reproduces that average.

But “average” isn’t the ceiling of what’s possible — it’s simply what the model puts out until it knows your project: its conventions, its code structure, its architectural decisions. In a survey of 600-plus developers, Qodo found that among those unhappy with the quality of AI code, 44% attribute it precisely to a lack of context. That’s what keeps the output stuck at a mediocre level.

The good news is that the context the AI receives is just about the only variable a team controls completely. How well the tool understands the project depends not on the model, but on what you feed it.

The second reason is mental — the very nature of the work changes. When AI writes most of the code, the developer’s main act is no longer writing but checking what’s been generated: reading someone else’s solution, weighing the alternatives, deciding what’s ready to ship. That’s a different skill from writing code yourself, and for anyone who loved the writing part, it doesn’t come easily.

In its 2025 Octoverse report, GitHub describes exactly this shift: the developers who’ve gone furthest with AI no longer call themselves “authors of code” and become something closer to its “creative directors,” where the key skill is to steer and to verify. But the road to that role runs through mistakes and frustration, until a person sees the payoff in their own work.

What Turns AI From a Source of Frustration Into a Working Tool

When our team first started using AI, some developers worked with Claude Code, others tried OpenAI Codex, GitHub Copilot, or Gemini CLI, and each tool gave a different result. So when we set about bringing order to the way the team worked with AI, the first thing we did was settle on a single tool.

This isn’t just our practice. Take the story of the team at Linear: until early 2026 they ran on a “let everyone work however suits them” principle, and in January leadership dropped that approach and moved everyone to a single way of working — narrowing the choice to two AI tools and asking developers to write code only with them, rather than by hand. According to the company, average productivity rose the very next month by 30% in merged PRs and by 33% in tasks closed per engineer.

That said, a shared tool on its own doesn’t improve the code — it has to be configured: set up rules, something like a rules.md, that spell out how to write code — which approaches to follow, what to avoid. Then come custom skills for the tasks typical of your project, so you’re not explaining the same thing over and over. And finally, it’s worth pointing the agent at your existing codebase: it analyzes how the project is written and produces new code in that same style rather than in a generic one. The more context the tool receives, the less you have to rewrite by hand afterward.

But the hardest part isn’t technical. The shift from author of the code to its evaluator doesn’t happen on its own — that transition needs help. The most direct route is training and certification. In our case, for example, ten developers are going through a partner program with the tool’s provider, while alongside them works a person responsible for adoption, who explains why the tool produced a given result and how to fix it.

Once the team is working in a coordinated way, one bottleneck remains — review — and it’s worth reinforcing with AI. The agent goes through every pull request first and takes on the obvious: routine mistakes, style, repetition, security gaps. The human reviewer then no longer looks at everything indiscriminately, only at the architecture and the critical decisions. The effect is noticeable even inside the companies that build these tools: at Anthropic, after introducing such an agent, the share of pull requests receiving substantive review rose from 16% to 54%, and engineers disagreed with less than 1% of its comments.

For us, this shortened a review cycle that used to stretch across two or three days over several rounds, and it lifted the routine off our senior engineers, leaving them the genuinely hard spots. Once the tool finally started producing results that didn’t need reworking, trust in it appeared too.

Where Trust in AI Tools Pays Off

First and foremost — in writing code: when the tool knows the project and the agent handles the first review, the team writes more, and better, in the same amount of time. In our case, AI tools sped up the work by roughly 30–40%.

Beyond that, AI has made onboarding easier. When a new person joins a project, someone experienced usually has to field dozens of questions about how the project’s code is put together. Now the agent takes on that role: if the project is well documented, the newcomer directs up to 95% of those questions to it rather than to colleagues.

It’s a similar story with documentation: a rough architectural draft that once ate up hours is now, for the most part, written by the agent itself — by our estimates, about 80% of the draft, if you give it enough context. What’s left to the human is what isn’t in the repository — the decisions, the trade-offs, the expertise.

Just as important is being honest about the limits of what AI can do, because it’s inflated expectations that breed disappointment in the first place. AI doesn’t take on compliance — a human signs off on medical or financial data, and the company, not the model, bears responsibility for a leak. It doesn’t speed up integrations with partners, where dozens of hours go into calls and coordination.

Out-of-the-box AI really is irritating — but only when it’s used as a finished solution. The whole difference between frustration and payoff lies in what you build around it: a shared standard, the context of your project, and the developer’s new role.