Most teams are using AI wrong

Your company bought Claude licenses for every engineer. Maybe you added a chatbot to Slack. Someone on the team is “exploring agents.”

Congratulations. You have an AI budget, not an AI strategy.

Here’s the thing: the teams I see getting real leverage from AI aren’t the ones with the best tools. They’re the ones who rethought how work gets done. Everyone else just added autocomplete to a broken process.

The Claude Trap

Most engineering teams adopted AI the same way: hand every developer a code completion tool and wait for productivity to go up.

It feels like progress. Engineers report writing code faster. PRs show up sooner. Managers see activity.

But output isn’t impact.

The reality is that Claude-style tools optimize the part of engineering that’s rarely the biggest bottleneck. Writing code can be hard, sure. But on most teams, the time lost to figuring out what to build, understanding a gnarly codebase, making architectural decisions, and getting alignment dwarfs the time spent typing.

Speed up the typing and you get a faster team. Speed up the thinking and you get a different team entirely.

What Real AI Leverage Looks Like

The teams getting outsized results are doing something fundamentally different. They’re not adding AI to existing workflows. They’re redesigning workflows around what AI makes possible.

Here’s what I mean.

Instead of autocomplete, use agents that own tasks.

The shift from “AI helps me write code” to “AI writes code and I review it” sounds subtle. It’s not. It changes everything about how you decompose work, what code review means, and how you think about ownership.

I’ve been running coding agents — Claude Code, specifically — on real work. Not toy problems. Actual features, actual bugs, actual refactors.

Last month I needed to migrate a knowledge base — hundreds of markdown files, each needing schema validation, deduplication, and cross-linking. Old me would have spent a weekend on it. Instead, I broke it into tasks, spun up agents in isolated worktrees, and had them process batches in parallel. The whole migration — including finding and removing 550 duplicate files — took an afternoon. Most of my time was reviewing output, not producing it.

The workflow looks nothing like traditional development:

1. I break a feature into parallelizable tasks
2. Each task gets assigned to an agent in an isolated worktree
3. Agents write code, run tests, self-correct CI failures
4. I review the output like I’d review a junior engineer’s PR

It doesn’t always work. Early on, I gave an agent a task that was too ambiguous — “refactor the authentication module.” It produced something that technically ran but missed the point entirely. The architecture was wrong because I hadn’t specified the constraints clearly enough. That’s when I learned: agents don’t fail because they’re dumb. They fail because you gave them a bad brief. Just like junior engineers.

One person recently documented running 30 concurrent agents, producing 40,000 lines of TypeScript in 8 days. 84% of PRs were AI-created. All 41 CI failures were self-corrected by agents. The human did maybe 3 days of focused work spread across 8 days.

That’s not a faster version of the old process. It’s a completely different process.

Instead of generating code, generate understanding.

The best use of AI I’ve found isn’t writing code at all. It’s reading code. Explaining systems. Answering “why does this work this way?” across a 200,000-line codebase in seconds.

When a new engineer joins and can interrogate the entire codebase on day one, onboarding changes. When a senior engineer can understand an unfamiliar service in 20 minutes instead of 2 days, the cost of cross-team work drops dramatically.

This doesn’t show up in any productivity metric. But it compounds.

Instead of individual tools, build workflows.

The biggest unlock isn’t any single AI tool. It’s composing them into workflows.

I’ve seen teams build systems where: an agent reads the issue tracker, decomposes features into tasks, assigns each to a coding agent, monitors CI, and routes review comments back to the right agent. The orchestrator itself is an AI agent — not a dashboard, not a cron job.

When CI fails, the failure gets injected back into the agent session. The agent reads the logs and fixes it. When a review comment comes in, it routes to the right agent with context. No human plumbing.

That’s the difference between using AI and being AI-native.

Why Leaders Get This Wrong

If you’re an engineering leader, this is your problem to solve. Not your team’s.

The reason most teams are stuck at “Claude and done” is that adopting AI at the workflow level requires decisions that individual engineers can’t make:

• How should we decompose work differently? Tasks that are too large for agents need to be broken down. That changes sprint planning, ticket writing, and how you think about “doneness.”

• What does code review mean now? When 84% of PRs are AI-generated, the review process needs to shift from “did you write this correctly” to “does this solve the right problem in the right way.”

• How do we maintain quality? Agents can produce a lot of code fast. Without guardrails — automated tests, linting, architectural constraints — they’ll produce a lot of bad code fast.

• What skills do we hire for? If agents handle implementation, the premium skills become: taste in what to build, judgment in architectural decisions, and the ability to decompose problems well. The best prompt for an AI agent is a well-scoped task with clear acceptance criteria. Sound familiar? That’s what good engineering leadership has always been.

• How do you bring people along? Some engineers will thrive — they’ll love the leverage, feel like they have superpowers. Others will resist, not because they’re behind the times, but because the thing they were great at just became less important. That’s worth acknowledging, not steamrolling.

These are leadership decisions. Waiting for your team to “figure out AI” is like waiting for your team to figure out your product strategy. It’s your job.

What To Do Monday Morning

If you’re leading an engineering team and your AI strategy is “everyone has Claude,” here’s where to start:

1. Run an experiment with agents, not assistants. Pick one feature. Break it into small, well-defined tasks. Try running them through a coding agent. See what happens. Learn what works and what doesn’t.

2. Audit where time actually goes. Track where your engineers spend their time for a week. If 80% is understanding code, reviewing work, and getting alignment — that tells you where AI should be applied. Hint: it’s probably not code generation.

3. Redesign one workflow. Don’t try to change everything. Pick one workflow — maybe it’s bug triage, maybe it’s onboarding, maybe it’s writing tests — and redesign it with AI as a first-class participant, not an add-on.

4. Talk about what’s changing. Have the honest conversation with your team. Not “AI is coming for your job.” But “the way we work is evolving, and here’s how I see it. What do you think?”

The tools are good enough. The models are capable enough. The bottleneck is leaders who haven’t thought carefully about how to restructure work around them.

So what’s your AI strategy? If the answer starts with “we gave everyone Claude” — now you know where to start.