Will Claude Code ruin our team?

The first time I sat down and used Cloud Code’s Opus 4.5 to build software, I couldn’t believe how good it was.

My next thought was: This software will change the dynamics inside teams.

deadlock between roles

Marc Andreessen recently described this moment as the “Mexican standoff”:

  • Now every engineer thinks that he can become a Prime Minister and a designer.

  • Every PM thinks they can code and design.

  • Every designer thinks they can do the other two.

The risk is that many individual contributors believe they no longer need others.

In the short term, this is going to be incredibly disruptive to team culture.

When scarce skills become more attainable, people feel pressure to move “up the pile” to prove their value.

Kent Beck expressed this sentiment on X:

“The value of 90% of my skills dropped to $0. The remaining 10% of my skills made a thousand.”

My concern is that everyone is recalibrating toward the same 10%. Individual contributors are all racing toward the same layer of leverage.

In Ben Werdmuller’s article, “AI Coding Works Now,” he specifically gives advice to engineers. He comments, “AI coding shifts the center of gravity from implementation to decision,” and recommends that engineers focus on these four skills:

  1. setting goals for the product

  2. Understanding what users really want

  3. Being very clear about the experience and value you are creating

  4. Design, build, and maintain robust software architectures

Many people believe in the challenge of Ben’s advice They Own these skills.

  • Company leadership wants to create its goals and strategy.

  • Product managers consider themselves uniquely qualified to understand what users want.

  • Designers want control over crafting the user experience.

  • And marketing and sales want to define how value is expressed to the customer.

  • Engineers have ownership in planning and implementing the architecture. Performance, Scalability, Security; All this requires real expertise.

With AI, all of these roles become more fluid. As more people create software and reduce time, they will begin to absorb the lessons that took their colleagues decades to learn.

And ultimately, more individuals will want to own the highest-leverage identity: “In my role, I solve problems and provide value to users.”

If left unchecked, there will be competition for position. There may be more hostility (and jealousy) between team members.

What I’m hearing from software teams

I started asking my friends who run software teams what they were seeing.

One founder told me:

I think you are right here. We’re seeing this already – primarily around PMs who want to write code.

Said another:

We’re definitely feeling it on our team. Everyone feels like they can do everyone else’s work.

The president of an established software company described a similar change:

“We have a product lead and 15 engineers on our team. On smaller projects he’s sending a lot of PR himself and there aren’t any developers involved.”

But the biggest change wasn’t just in who was doing the work. This was who they were hiring:

“Where you really see the impact on jobs with us is in the people we’re no longer hiring: specialists. In this new era, generalists win.”

Ghost founder John O’Nolan commented:

It’s certainly a turbulent time – but overall I’m quite optimistic.

What has not happened yet and I hope will happen in the future is that in addition to the old roles being compressed, new roles emerge.

after the impasse

My hope (once the dust settles) is that we come out with the other side More Collaboration. Instead of competing for leverage, I’m hoping that individual contributors will find new ways to work together.

For example, what if product managers and engineers did more AI-powered pair programming? PMs can focus on customer behavior and product goals. The engineer can evaluate architecture, security, and maintainability. They will iterate together in real time using LLM.

My friend Matt Stauffer, CEO of Titan, commented that they are doing this right now:

I demo the work to my biz dev manager (the product owner for this internal project), she asks for changes, and then we signal the LLM live together. I am better at giving hints and reviewing, she knows the domain better than me. This type of pair programming is great, because I’m moving fast and she can hang off the call later while I’m reviewing, revising, etc.

Ben Werdmuller’s recipe will still be relevant: “All code should have a human owner who will take responsibility for it.” In my scenario, the PM and the engineer will be co-owners of the pull request.

37signals is famous for two-person teams (one designer, one engineer). In the world of AI, might such a paradigm become the norm?

Once the unrest ends, people will need a new vision for working together. How can we use AI? And Collaborate in ways that help us build better software?

to encourage,
justin jackson

Discuss this on Hacker News

Connect with me here:
🦋 bluesky
💼LinkedIn
🐘 Mastodon
🧵threads



<a href

Leave a Comment