Why your AI coding agents are making the team slower (and how to fix it)

A rigorous randomized controlled trial gave experienced open-source developers 246 real tickets and let them use AI coding tools on some, but not others. Before starting, the developers predicted AI would make them 24% faster. After finishing, they still believed AI had made them 20% faster. The actual result? The developers predicted a 24 percent speedup, but even after the study concluded, they believed AI had helped them complete tasks 20 percent faster when it had actually delayed their work by about that percentage.

That gap between feeling productive and being productive is the entire problem with how most engineering teams have adopted AI coding tools. Everyone got a Cursor or Claude Code license, nobody agreed on how to use it, and now every developer has their own private, inconsistent relationship with the model. One person writes detailed prompts and reviews every line. Another pastes a vague request and ships whatever comes back. There's no shared standard, no shared context, and no shared definition of "done."

This guide walks through how to fix that at the system level — turning your entire software development life cycle, from the product requirement doc to the pull request, into something genuinely AI-native instead of AI-adjacent.

Why does adding AI tools sometimes make teams slower?

The METR study isn't an argument against AI coding tools. It's an argument against using them without structure. Researchers who dug into the screen recordings found that developers spent 9% of total task time specifically reviewing and modifying AI-generated code, and combined with time spent prompting AI systems and waiting for generations, these overhead activities overwhelmed any time savings from reduced coding and debugging.

In plain terms: writing the code got cheaper, but reviewing code you didn't write, verifying it actually does what you think, and debugging someone else's (an AI's) assumptions all got more expensive. If your team hasn't built a system for managing that overhead — shared context, shared conventions, a shared way of prompting — every developer is reinventing that overhead alone, every single day.

That's also why the study matters less as a verdict on AI and more as a diagnosis. The tools have moved fast since the study ran, but the underlying lesson holds: an agent without context about your codebase, your conventions, and your team's standards will keep making the same category of mistakes, and someone will keep paying the review tax to catch them.

What does an "AI-native SDLC" actually mean?

Making your development cycle AI-native means every stage of the process — planning, ticket creation, coding, review, and testing — has the coding agent baked in as a first-class participant, with the same rules and context available no matter who's driving.

Practically, that breaks down into a few concrete pieces:

1. A shared source of project context the agent can read automatically (not something each developer has to remember to paste in).
2. Rules and skills that live in the repo, version-controlled like code, so a new hire or a new agent session gets the same guardrails everyone else has.
3. Agent-assisted planning, not just agent-assisted coding — using the model to help turn a PRD into well-scoped tickets before anyone writes a line.
4. A review habit that treats the agent as a collaborator you interrogate, not a black box you rubber-stamp.

Here's how to build each one.

How do you give every developer the same context automatically?

The fix for "everyone prompts differently" is to stop relying on prompts as the only source of context. Both major agent ecosystems now support persistent, file-based context that loads automatically.

In Claude Code, Anthropic's official docs describe three layers worth knowing: CLAUDE.md for always-loaded project facts, scoped rules for narrower constraints, and skills for repeatable workflows. The distinction matters for keeping your context window efficient — use rules for constraints, and if the instruction has phases, scripts, references, or assets, it probably belongs in a skill instead of a rule. Anthropic's own guidance is direct about scoping: an API-specific rule without paths, if a rule only applies to a specific folder, scoping it with paths keeps it out of context during unrelated work, since an unscoped rule is mechanically identical to putting the content in CLAUDE.md, always loaded, always costing tokens.

If your team uses Cursor instead, the equivalent is Project Rules — Markdown files with frontmatter stored in .cursor/rules/. Cursor's own documentation lays out the precedence model clearly: rules are applied in this order — Team Rules, then Project Rules, then User Rules — and all applicable rules are merged, with earlier sources taking precedence when guidance conflicts. That means a team lead can set enforced standards that apply to every repo, while individual developers still layer on personal preferences underneath.

The payoff of doing this well is that onboarding a new team member — or spinning up a fresh agent session — stops requiring a setup ritual. The rules and skills already live in the repository, so anyone who clones it gets the same standards the rest of the team is already using.

How do you use agents earlier in the cycle, not just for coding?

Most teams only bring AI in at the "write the function" stage. That's the least valuable place to start. The bigger unlock is using a coding agent during planning — turning a PRD sitting in Confluence or Notion into a set of well-scoped, agent-ready tickets before a single file gets touched.

The workflow looks like this: instead of a PM manually writing out every ticket by hand, they work with a coding agent to break the PRD into individual, appropriately-scoped stories — each one written with enough technical context that whichever developer (or agent) picks it up later doesn't have to reverse-engineer the intent. This front-loads the context-gathering that would otherwise happen ad hoc, mid-sprint, when a developer finally opens the ticket and realizes half the information is missing.

This is also where voice input starts to matter more than people expect. Typing out a long planning conversation with an agent is slow, and it's easy to lose your train of thought mid-sentence. Claude Code's voice dictation feature lets you talk through your plan instead of typing it — you speak your prompts instead of typing them, your speech is transcribed live into the prompt input, and you enable dictation with /voice, then either hold a key while you speak or tap once to start and again to send. For planning sessions where you're thinking out loud with the agent, that's a meaningfully faster loop than typing paragraph after paragraph.

How should code review change when an agent wrote the first draft?

This is where the "review tax" from the METR study either gets managed well or spirals out of control. The trick isn't to review AI code less carefully — it's to use the review process as an active conversation instead of a passive check.

While you're doing manual testing on a feature an agent built, treat it as an opportunity to interrogate the agent's choices directly: ask why it picked a particular library, why it structured a function a certain way, or whether there was a simpler approach it considered and rejected. This does two things. First, it surfaces reasoning you'd otherwise have to reverse-engineer yourself, which is exactly the kind of "reviewing code you didn't write" overhead the METR researchers flagged as cognitively expensive. Second, it turns every review into a small feedback loop that improves the next set of rules or skills you write — if the agent keeps making a questionable choice, that's a sign to codify the correct pattern into a rule rather than correcting it manually every time.

Which tools should you actually set up first?

If you're starting from a brownfield codebase with none of this in place, don't try to do everything on day one. A sensible order:

1. Pick your primary agent. Claude Code and Cursor are the two most mature options for teams right now, and both support the rules/skills model described above.
2. Write your first CLAUDE.md or root rule file. Keep it short — architecture, conventions, and things the agent keeps getting wrong. Anthropic's guide on steering Claude Code is a good reference for deciding what belongs where.
3. Convert your two or three most repeated workflows into skills or commands — deployment steps, test scaffolding, a PR checklist — anything a developer currently explains to the agent from scratch every session.
4. Commit all of it to the repo. Rules and skills should be reviewed in pull requests just like code, so the whole team evolves them together instead of everyone running a different local setup.
5. Bring the agent into planning, not just implementation, once the basics are stable.

None of this requires a bigger model or a more expensive subscription. It requires treating "how we use AI" as a team standard worth documenting, the same way you'd document a style guide or a deployment process.

The teams getting real speed gains out of AI coding tools aren't the ones with the most enthusiastic individual developers. They're the ones who stopped treating the agent as a personal productivity hack and started treating it as infrastructure — something with shared rules, shared memory, and a shared place in the process that everyone, including new hires, inherits automatically. Build that system once, and the next debate about whether AI is actually making your team faster comes with an answer you can point to, instead of a feeling you have to defend.