Why Most Teams Are Expert Beginners With AI Dev Tools

Ninety-five percent of developers now use AI tools at least weekly, with seventy percent juggling two to four tools at once. Adoption isn’t the issue anymore. Most teams adopted the tools without adopting any shared practices around them, and that creates a predictable plateau.

The Expert Beginner Plateau

Erik Dietrich coined the term “expert beginner” over a decade ago. The concept comes from the Dreyfus model of skill acquisition, which maps five stages from novice to expert. The key insight is that most people don’t progress linearly through all five. They hit “advanced beginner,” start getting decent results, and stop improving because the current approach feels good enough.

The expert beginner isn’t bad at the skill. They’re adequate. They’ve developed habits that produce passable results and lost any signal that they should keep pushing. They feel competent, their output looks reasonable, and nothing is visibly broken. They’ve capped out without realizing it.

If you’ve been on an engineering team for more than a few years, you’ve worked with this person. Now imagine it’s the entire team, all at once, with a tool category that didn’t exist two years ago. That’s where most organizations are with AI dev tooling right now.

What This Looks Like in Practice

Your team has Copilot or Cursor licenses. A few people are running Claude Code in a terminal. Someone on the team is a power user who generates half their PRs with AI. Everyone else is using it for autocomplete and the occasional “write me a test for this function.”

Nobody has talked about how to use these tools as a team. There’s no shared workflow, no standards for when AI-generated code needs extra scrutiny. Everyone figured it out on their own, developed their own habits, and stopped there. It’s ten developers with ten private workflows all pretending the team has an AI strategy because everyone has a license.

The Pragmatic Engineer survey data shows this clearly. Seventy percent of engineers are using two to four AI tools simultaneously, driven by individual preference and company procurement rather than team strategy. Staff+ engineers use agents at 63.5% while engineering managers sit at 46%. That’s a real adoption gap within the same organization, and nobody’s bridging it.

Each person on the team is individually an “advanced beginner” with AI tools. Capable enough to get value, not skilled enough to know what they’re leaving on the table. Multiply that across a team of ten, and you’ve got ten different workflows, ten different quality bars, and zero shared understanding of what “good” looks like.

The Perception Gap Makes It Worse

The thing that makes the expert beginner problem especially dangerous with AI tools is that people can’t tell they’ve plateaued.

METR ran a rigorous study in early 2025 on AI’s impact on developer productivity, a randomized controlled trial with experienced open-source developers working on their own repositories. They found that developers using AI tools took 19% longer to complete tasks. A follow-up study with newer models showed some evidence of speedup, though METR noted the results were inconclusive due to selection effects. What didn’t change: the perception gap. Developers predicted AI would make them 24% faster. After actually being slower in the original study, they still believed AI had sped them up by 20%.

That’s a 40-percentage-point gap between perception and reality, and it persists regardless of whether the tools are getting faster.

This isn’t an academic curiosity. It’s the mechanism that keeps expert beginners stuck. The normal feedback loop never kicks in. “I tried something, it didn’t work, I should try something different” requires noticing that it didn’t work. AI tools feel productive even when they’re not. You type a prompt, you get code back, it compiles, it mostly works. The overhead of reviewing, fixing, re-prompting, and context-switching is invisible because it’s distributed across the whole session.

At the team level, this means nobody raises their hand and says “I think we could be doing this better.” Why would they? Everyone feels like it’s working.

Four Failure Modes I Keep Seeing

I’ve been building and using AI coding tools seriously for over a year now, including an orchestration system that runs multiple agents in parallel. I’ve also been the expert beginner. More than once. Here are the patterns I keep seeing, both in other teams and in the mirror.

1. Tool Sprawl Without Strategy

The team has Copilot for inline completion, Cursor for chat, Claude Code for bigger tasks, ChatGPT for one-off questions, and maybe Codex or Gemini for specific things. Seventy percent of engineers are running two to four tools. Fifteen percent are running five or more.

Nobody decided this. It accumulated the way junk drawers accumulate: one tool at a time, each solving a specific annoyance, until you’re paying for five subscriptions and can’t remember which one you’re supposed to use for what.

The cost isn’t the subscription fees. It’s the context fragmentation. Every tool has a different mental model, different strengths and failure modes, and different expectations for what you should review carefully versus what you can trust. Jumping between them all day means never building deep fluency with any of them.

2. Power Users Hoarding Knowledge

Every team has one or two people who are significantly further ahead with AI tools than everyone else. They’ve figured out prompting patterns that work, they know which tasks to delegate to AI and which to do manually, and they’ve developed workflows that genuinely save them time.

All of that knowledge lives in their head. It doesn’t get shared in code reviews, doesn’t show up in onboarding docs, doesn’t get discussed in retros. When the power user is on vacation, the team’s AI productivity drops to the floor.

This is the single biggest waste I see. The gap between a team’s best AI user and their average AI user is enormous, and nobody’s closing it because nobody even knows the gap exists. Remember: everyone feels productive.

3. No Quality Calibration

When a developer writes code manually, teams have years of shared understanding about what “good” looks like. Style guides, design patterns, review norms, testing expectations, all evolved over time through collective practice.

AI-generated code exists outside all of that. A developer prompts an AI, gets code back, reviews it against their own personal bar, and opens a PR. What’s the right level of scrutiny? How much should you refactor AI output before committing it? When do you throw away the AI’s suggestion and write it yourself?

Every person on the team has a different answer, and the team has never discussed it. METR found that developers accepted less than 44% of AI code suggestions, and 56% reported needing major changes to clean up what they did accept. That’s a lot of variability in how teams process AI output, and most of it is invisible.

4. Measuring Adoption Instead of Outcomes

When leadership asks “how’s our AI tool adoption going,” the answer is almost always about seats and usage. “85% of developers are using Copilot daily.” “Our team logged 10,000 completions last month.”

These are input metrics. They tell you people are using the tools, not whether the tools are making the team faster, the code better, or the delivery more reliable.

The Pragmatic Engineer survey found that 56% of respondents do 70% or more of their work with AI. That sounds impressive until you pair it with METR’s finding that the users themselves consistently can’t tell whether AI is actually making them faster.

If your only measure of success is “are people using it,” you’ll never catch the expert beginner problem. By definition, expert beginners use the tool plenty. They just don’t use it well.

What Getting Past This Actually Looks Like

I don’t think the answer is a twelve-step maturity model or an “AI center of excellence” or whatever the consulting industry is selling this quarter. (Though I’m sure the slide deck is beautiful.) From what I’ve seen, the teams that break past the expert beginner plateau do a few specific things.

They treat AI tooling as a team practice, not an individual preference. The same way a team decides on testing standards or code review norms, they make explicit decisions about AI workflows. Not rigid rules, just shared defaults and shared vocabulary.

They create feedback loops that actually work. The METR perception gap tells you that vibes-based assessment is useless. Teams that get past this measure something concrete: cycle time, defect rates on AI-generated PRs versus manual ones, time spent in review. They don’t trust feelings.

They share what works. Power users demo their workflows. Teams do “AI retros” where they look at PRs that went well and ones that went sideways and figure out why. The knowledge gets distributed instead of hoarded.

They scope AI usage deliberately. Instead of “use AI for everything and hope for the best,” they identify which types of tasks benefit most and which don’t. Well-scoped, spec-driven work? AI can do a lot. Ambiguous, architectural work on a codebase you know intimately? You might be better off writing it yourself, and METR’s data backs that up.

I’ve written more about the stages teams move through from ad-hoc AI usage to intentional practice. The progression is real, and knowing where your team sits on it is the first step to getting unstuck.

The Real Problem Is Invisible

The expert beginner concept resonated so widely in software because it named something everyone had seen but couldn’t articulate. The senior developer who’d been doing things the same way for ten years and couldn’t figure out why their output wasn’t improving. The team that kept hiring but never got faster. The person who knew enough to be dangerous and not enough to know what they didn’t know.

AI tooling is in that exact phase right now, at a much larger scale. Entire teams of individually capable developers, each with their own ad-hoc AI workflows, none of them aware that the team could be getting significantly more value out of the tools they’re already paying for.

The ceiling is high. The same model scores anywhere from 42% to 78% on coding benchmarks depending on the scaffolding around it. The gap between “individual developer prompting an AI” and “team with intentional AI workflows” is at least that wide, probably wider.

The expert beginner doesn’t know they’re an expert beginner. That’s the whole point. If your team has AI tool licenses, decent adoption numbers, and no shared practices, you’re probably there. Most teams are. The uncomfortable part is that reading this article doesn’t fix it. Knowing the name for the plateau is step one. Actually changing how your team works together with these tools is the rest of the staircase.