Part 5 of 10: The Team Dynamics No One’s Talking About

I’d figured out how to work productively with Claude.

Two-hour sessions. Clear role separation. Session retrospectives. Code review. Verification checklists.

My Pomodoro timer was coming together. Features worked. Tests passed. I was shipping code regularly.

Then I started thinking about what would happen if this wasn’t just me and Claude.

What if I had a team?

That’s when I realized: everything I’d learned was about to get exponentially harder.

The Solo Developer Privilege

Working alone with Claude, I had luxury I hadn’t fully appreciated:

Complete context. Every decision was in my head. Every conversation with Claude was one continuous thread. I knew what we’d tried, what had failed, and why.

Immediate verification. When Claude said something was fixed, I could test it within minutes. No hand-offs. No waiting for someone else’s review.

Coherent architecture. I’d made all the technical decisions. The codebase had one voice, one set of patterns, one person’s understanding of quality.

But software development isn’t a solo sport.

Real projects have teams. Multiple branches. People with different skill levels. Conflicting opinions about architecture.

I started sketching out scenarios: what would happen if I had to bring developers onto this project?

Every scenario looked like a disaster.

The Junior Developer Problem

Imagine hiring a junior developer fresh from bootcamp. Smart, eager, some classroom projects under their belt.

Day one: “Use Claude Code to implement this feature.”

What happens?

They watch Claude generate code. It looks good. It works when they test the happy path. They commit.

Except the code violates three coding standards they don’t know exist. It has a race condition that only appears under load. The error handling is missing for edge cases they haven’t encountered yet.

How would they know?

With a human senior developer, you can pair program. The senior explains why certain patterns matter. Points out edge cases from experience. Teaches by showing consequences.

With Claude, you get confident, competent-looking code with invisible problems.

A junior developer doesn’t have the pattern recognition to know what’s wrong. They just know Claude is really fast and their features work.

Until production. Or until a senior developer reviews their work and finds it’s a mess.

The Expert Blindspot

Now imagine a senior developer. Ten years of experience. Strong opinions about architecture.

Day one: “Use Claude Code to implement this feature.”

They watch Claude generate code. It works, but it doesn’t match their mental model. They ask Claude to refactor.

Claude refactors. The code now matches their preferred pattern… except Claude also changed the error handling, removed some edge case checks, and introduced a subtle bug in how state is managed.

The senior developer is reviewing for architecture, not for correctness. They assume Claude got the correctness right while making their requested changes.

It didn’t.

This is perhaps more dangerous than the junior developer problem. The senior developer has enough expertise to be confident, but not enough context into Claude’s changes to catch everything.

The Trio Problem

Based on my experience, I think the effective team structure for AI development might be trios:

Two humans, one AI.

Not pairing—trioing.

One human drives. One human reviews in real-time. Claude implements.

But this sounds insanely expensive. You’re doubling your developer headcount for the same output.

Except… maybe it’s not the same output?

My session retrospectives showed clear patterns. Rework cycles dropped significantly once I’d established good process—from around 3 per feature to less than 2.

That’s a meaningful efficiency gain just from better verification.

Now imagine two developers working together, catching issues even faster, sharing context Claude can’t maintain.

Maybe trios aren’t twice as expensive. Maybe they’re twice as fast with higher quality.

But I don’t know. I’m one person working alone. This is theoretical.

It’s also terrifying to recommend to a hiring manager: “Yes, add AI to your team. Also double your headcount.”

The Branch Management Nightmare

My solo workflow avoided one of the biggest challenges in team development: branches.

I work on one branch at a time.

But real teams have feature branches. Multiple developers working in parallel. Pull requests. Code review. Merge conflicts.

Now add AI into that mix:

Developer A has Claude implement a feature on branch A. Developer B has Claude implement a different feature on branch B.

Both features work in isolation. Both pass code review. Both get merged to main.

Suddenly the app breaks. The features conflict in a way that wasn’t obvious in either branch.

Who debugs this? Both developers swear their feature works. They’re right—it did work, in their branch.

Now you need someone who understands both features, both code changes, and the interaction. That someone probably isn’t Claude—Claude’s context doesn’t span branches.

It’s a senior developer. Doing archaeology on AI-generated code written by two other developers, neither of whom fully understands what Claude did.

The Velocity Trap

Here’s the scenario that keeps me up at night:

A team adopts AI development tools. Velocity skyrockets. Features ship faster than ever.

Leadership celebrates. The team feels productive. Everyone’s happy.

Months later, the codebase is unmaintainable. Technical debt is crushing. Bugs appear faster than they can be fixed.

What happened?

The team confused “code written” with “value delivered.”

Claude makes it trivially easy to write code. But code isn’t the constraint in software development—understanding is.

Understanding the problem. Understanding the implications. Understanding the trade-offs.

AI doesn’t provide understanding. It provides implementation.

If your team is measuring velocity by “features shipped” instead of “problems solved,” AI will make that metric look amazing while destroying your codebase.

Lessons for Leaders (From Imagined Disasters)

I haven’t actually managed a team using AI development. Everything in this article is extrapolation from solo work.

But as someone who’s coached teams for over a decade, here are the patterns I’d watch for:

Lesson 1: Your onboarding process is about to get critical.

Junior developers have always needed mentorship. But with AI, they need something more specific: they need to learn how to verify AI-generated code.

That’s a different skill than writing code. It’s closer to code review, security auditing, and requirements validation.

If your onboarding process is “watch the senior developer, then try it yourself,” you’re going to create developers who are fast and dangerous.

Lesson 2: Your code review process needs to evolve.

Right now, code review probably looks like: read the PR, understand the change, verify it solves the problem correctly.

With AI, you need an additional step: verify the AI didn’t introduce problems while solving the problem.

That sounds redundant, but it’s not. Claude regularly makes requested changes while also making unrequested changes you need to catch.

Your team needs to review AI-assisted PRs differently than human-written PRs.

Lesson 3: Faster isn’t always better.

This is hard for leadership to internalize because velocity is measurable and feels like progress.

But with AI, you can ship bad code so fast that your technical debt accumulates faster than your feature value.

You need metrics beyond velocity. Code quality metrics. Rework metrics. Bug escape rates. Time-to-understand-existing-code.

I built these for my solo work. Teams need them even more.

The Real Question I Can’t Answer

Here’s what I don’t know:

Is AI-assisted development a team multiplier or a team divider?

Does it make good teams better? Or does it paper over dysfunction until it explodes?

My gut, after several weeks of solo work: it depends entirely on the team’s existing practices.

A team with strong code review, clear standards, and good verification practices? AI will make them significantly faster.

A team that’s already struggling with technical debt, unclear requirements, and poor communication? AI will accelerate their problems.

It’s the classic Agile insight: the practices don’t create good teams, they reveal what’s already there.

AI is the same, but faster.

What I’m Building Toward

All of this is theoretical. I’m still working alone.

But my Pomodoro timer is getting close to done. Real users will test it soon. I’ll learn whether my practices actually produce maintainable code.

And I’m starting to think about the next phase: bringing in another developer.

Not to build faster. To learn whether what I’ve built is a process or just personal habits.

Whether the retrospectives, the checklists, the verification systems—whether any of it transfers to a team.

That’s the experiment I’m most curious about. And most nervous about.

Because if this only works solo, then I haven’t solved anything. I’ve just built an expensive personal productivity system.

But if it scales…

That’s the next part of the story. The one where theory meets reality.

---

This is part 5 of a 10-part series. Part 1, Part 2, Part 3, Part 4 covered building practices that work solo. Part 6 explores what happened when those practices faced their first real test.

About the Author: I coach engineering teams. Everything in this series is based on real experience building with Claude Code—including the team dynamics I’m worried about but haven’t fully tested yet.